Non ho mai fatto qualsiasi sviluppo iPhone, ma mi piacerebbe sottolineare alcuni sviluppi nel mondo Symbian che si riferiscono ad alcuni dei tuoi punti:
Symbian C++ vs Objective C - il primo è yuck IMHO.
Non è certo per tutti i gusti! Per lo sviluppo di applicazioni, Symbian C++ diventerà sempre meno rilevante, poiché lo Qt (che è generalmente considerato un insieme di librerie molto intuitivo) verrà utilizzato per la prossima generazione dei livelli di struttura/interfaccia utente dell'applicazione. I livelli inferiori del sistema operativo continueranno a utilizzare il dialetto Symbian di C++, ma verranno aggiunti Qt libraries for functionality such as multimedia, location and messaging, pertanto è improbabile che gli sviluppatori di app debbano chiamare direttamente le API della piattaforma nativa.
emulatore - quanto vicino è l'emulatore al dispositivo vero e proprio - l'emulatore Symbian è davvero un simulatore come librerie Symbian modificato per funzionare su Win32. Per esempio. un processo è un thread su l'emulatore Symbian e non un processo Symbian . L'emulatore è un target di build separato .
La descrizione dell'emulatore (processo host singolo, destinazione di compilazione separata) è corretta. Per questo motivo, l'emulatore è essenzialmente una porta del sistema operativo su una piattaforma completamente diversa (in questo caso x86), quindi non modella affatto un telefono. Fortunatamente, è stato eliminato e sostituito con un simulatore, come quelli già inclusi negli SDK per iPhone e Android.(Infatti, il simulatore si basa sulla stessa tecnologia - QEMU - utilizzato da Android) Poiché il simulatore traduce le istruzioni ARM in quelle comprese dalla macchina desktop, gli stessi binari possono essere distribuiti sia sul simulatore che sul dispositivo stesso.
Il simulatore include un "modello di scheda" costituito da un certo numero di periferiche virtuali, ognuna delle quali mappa parte della macchina host, così ad esempio il dispositivo audio del simulatore può essere collegato alla scheda audio del desktop. Poiché questo modello di scheda può essere modificato, l'ambiente del simulatore può essere adattato per modellare molto da vicino un particolare dispositivo, quindi aspettatevi di vedere i produttori di dispositivi spedire un simulatore nel loro SDK che assomiglia molto al dispositivo fisico corrispondente.
IDE - Come si confronta (per esempio eclissi o CodeWarrior vs rilevanti iPhone IDE)
CodeWarrior è un piuttosto vecchio e un po 'scricchiolante IDE. Carbide (che è basato su Eclipse) è migliore e offre un supporto per il debug su dispositivo ragionevolmente maturo (anche se non è così scorrevole sulla soluzione XCode/iPhone). L'IDE incluso in tutti gli SDK Qt (Qt Creator) è probabilmente il più bello ed è stato paragonato a XCode in termini di usabilità.
frammentazione - Ci sono molte versioni del sistema operativo Symbian e telefoni che può può potenziale obiettivo - questo può essere un vero e proprio sviluppo e manutenzione incubo. Più vari tipi di interfaccia utente.
Definitivamente vero in passato. Spero di migliorare in futuro. Dove una volta c'erano più UI (S60, S80 e UIQ), ora ce n'è solo uno (attualmente basato su S60, che sta per essere sostituito con un'interfaccia utente basata su Qt).
È quell'obiettivo C per iPhone? – zapping
Triste che ho mentalmente sostituito * sybian * quando ho letto questo. Ho davvero bisogno di uscire di più. :) – Randolpho
Queste due domande sono correlate a questo: http://stackoverflow.com/questions/1414288/j2me-vs-android-vs-iphone-vs-symbian-vs-windows-ce, http: // stackoverflow. it/questions/1092144/what-mobile-platform-should-i-start-learning –