Sto trasferendo la mia app da iOS ad Android: cosa devo sapere? [chiuso]

Quali insidie ​​dovrei evitare?

• Quali paradigmi del linguaggio Java gli sviluppatori Objective-C fraintendono costantemente? Ho imparato a programmare in Java, ma per anni ho lavorato solo con Objective-C.
• In che modo i modelli di progettazione differiscono tra Android e iOS?
• Se hai effettuato tu stesso la transizione, quali parti di Android ti hanno confuso o ti hanno impiegato più tempo per imparare di quanto avrebbe dovuto?
• Eclipse è il miglior IDE OS X per Android?

Per la cronaca, la mia app è strettamente legata a UIKit e Foundation, quindi la parola "porting" potrebbe essere un termine improprio; In realtà lo riscriverò completamente per Android. Nessun riutilizzo del codice. Inoltre, lo sto facendo per imparare Android, quindi preferirei fallire alla porta e imparare Android piuttosto che prendere una scorciatoia.

Come sfondo, questa domanda è stata posta dai tipi di domande che vedo su StackOverflow. Spesso puoi dire qual è il background di qualcuno (C # o Java) da quali sciocchi errori fanno quando provano a scrivere Obj-C. Vorrei evitare i tipi di errori che fanno roteare gli occhi agli sviluppatori Java e dire "Silly Objective-C sviluppatori, non impareranno mai?"

Sto eseguendo il porting di un'app da iOS ad Android, è l'app di qualcun altro con cui sto lavorando per fare il port ma comunque.

Prima di tutto direi che alle basi di utenti sono stati insegnati modi drasticamente diversi di interagire con i loro dispositivi. Molto di questo deriva dalla progettazione effettiva delle applicazioni e dai modi in cui funzionano i dispositivi.

Alcune cose generali:

• Il paesaggio è praticamente richiesto sui dispositivi Android
• Le app Android tendono a continuare a funzionare quando non vengono utilizzate attivamente, quindi è necessario pensarci per problemi di rete, gps, ecc ...
• Segmentazione del dispositivo, ci sono tonnellate di dispositivi Android e risoluzioni dello schermo, è qui che i layout relativi e le immagini a nove patch sono molto utili.

Un grosso Your UI can not be exactly the same on both devicesproblema a cui molte persone inizialmente non pensano , sicuramente può essere simile ma il porting di un'interfaccia utente di iPhone su un dispositivo Android non funzionerà molto bene.

Alcuni motivi:

• Menu contestuali a tocco lungo
• Popup di menu
• Segmentazione del dispositivo che causa risoluzioni e proporzioni diverse
• Non gli stessi controlli con cui lavorare

Il back-end in realtà non è un grosso problema poiché la maggior parte di essi sta semplicemente implementando la maggior parte di ciò con cui stavi lavorando in Java e Android SDK. I miei maggiori problemi derivano da ciò che l'utente si aspetta e dal comportamento e dalle differenze dell'interfaccia utente, a volte è meglio e a volte è peggio. Dipende solo da cosa sta facendo la tua app.

MODIFICARE

Ho appena realizzato di non aver risposto alle parti effettive delle tue domande, quindi ecco qui (almeno il mio scatto migliore)

Non direi che ci sono paradigmi di linguaggio di grandi dimensioni che Obj-C non comprende, direi che Java è probabilmente più semplice ottenere ciò che voglio che faccia da una prospettiva OOP. (Devo dire che lavoro davvero solo con .NET e Java e conosco solo Obj-C abbastanza per cavarmela).

Userei sicuramente Eclipse, mi sono stancato di usare IntellijIdea per un po 'e mi ha dato molti problemi cercando di farlo fare certe cose.

[questa risposta è un po 'una trappola o un rant. Stavo per eliminarlo, ma ho pensato che potesse essere interessante: fammi sapere tramite commenti se dovessi eliminarlo e lo farò].

Non lavoro su Android ma lavoro su Java e iOS (con Obj-C). L'unica cosa che è veramente diversa nello sviluppo di Java è quanto un IDE può aiutare (le persone ti diranno di non usare un IDE, che è una visione totalmente diversa della stessa cosa: poche persone lo consigliano con Java, tuttavia) . XCode non è generalmente in grado di rilevare nemmeno CORRETTAMENTE gli errori di sintassi più semplici (a causa della struttura del linguaggio, credo). In Java, d'altra parte, l'IDE può farti muovere molto più velocemente di quanto saresti senza di esso. Puoi anche fare cose davvero interessanti come programmare il chiamante e POI scrivere il metodo. In Eclipse, ad esempio, se digito

blah.doIt(firstObj, secondObj);

e firstObje secondObjsono Stringistanze, l'IDE mi darà la possibilità di creare un metodo con il sig "public void doIt (String firstObj, String secondObj)." È davvero bello, e solo la punta dell'iceberg: l'IDE è tuo amico. Ho sentito che IntelliJ potrebbe essere ancora più bello (anche se nelle mie prove non lo è stato).

C'è una trappola in questa risposta? Forse lo è: pensare l'IDE gioca lo stesso ruolo in Obj-C e Java. In Java, l'IDE può fare cose che sarebbe incredibilmente difficile da fare da soli. Il refactoring automatico, a causa del modo in cui è Java, è 100 volte più potente di XCode. Ciò significa che è possibile rimandare alcune domande di progettazione a più tardi.