Ich portiere meine App von iOS auf Android: Was muss ich wissen? [geschlossen]

Welche Fallstricke sollte ich vermeiden?

• Welche Java-Sprachparadigmen verstehen Objective-C-Entwickler durchweg falsch? Ich habe das Programmieren in Java gelernt, arbeite aber seit Jahren ausschließlich in Objective-C.
• Wie unterscheiden sich die Designmuster zwischen Android und iOS?
• Wenn Sie die Umstellung selbst vorgenommen haben, haben Sie dann in welchen Teilen von Android mehr Verwirrung gestiftet oder länger gebraucht, um zu lernen, als es hätte sein sollen?
• Ist Eclipse die beste OS X-IDE für Android?

Für das Protokoll ist meine App sehr stark an UIKit und Foundation gebunden, sodass das Wort "Portierung" eine falsche Bezeichnung sein kann. Ich werde es tatsächlich komplett für Android umschreiben. Keine Wiederverwendung von Code. Außerdem mache ich das, um Android zu lernen, also würde ich lieber am Port scheitern und Android lernen, als eine Abkürzung zu nehmen.

Als Hintergrund wurde diese Frage durch die Arten von Fragen ausgelöst, die ich auf Stackoverflow sehe. Oft kann man den Hintergrund einer Person (C # oder Java) daran erkennen, welche dummen Fehler sie macht, wenn sie versucht, Obj-C zu schreiben. Ich möchte die Fehler vermeiden, die Java-Entwickler dazu bringen, mit den Augen zu rollen, und sagen: "Dumme Objective-C-Entwickler, werden sie das nie lernen?"

Ich portiere eine App von iOS auf Android, es ist die App eines anderen, mit der ich arbeite, um den Port zu erstellen, aber nichtsdestotrotz.

Zuallererst würde ich sagen, dass den Anwenderbasen drastisch unterschiedliche Arten der Interaktion mit ihren Geräten beigebracht wurden. Ein Großteil davon hängt mit dem tatsächlichen Design der Anwendungen sowie der Funktionsweise der Geräte zusammen.

Einige allgemeine Dinge:

• Landscape ist auf Android-Geräten so ziemlich erforderlich
• Android-Apps neigen dazu, weiter zu laufen, wenn sie nicht aktiv genutzt werden. Daher sollten Sie bei Netzwerkproblemen, GPS-Problemen usw. darüber nachdenken.
• Gerätesegmentierung, es gibt Unmengen von Android-Geräten und Bildschirmauflösungen, hier sind relative Layouts und Neun-Patch-Bilder sehr praktisch.

Eine große Sache, an die viele Leute anfangs nicht denken Your UI can not be exactly the same on both devices. Sicher kann sie ähnlich sein, aber die Portierung einer iPhone-Benutzeroberfläche auf ein Android-Gerät funktioniert nicht sehr gut.

Einige Gründe:

• Kontextmenüs mit langer Berührung
• Menü-Popups
• Gerätesegmentierung mit unterschiedlichen Auflösungen und Seitenverhältnissen
• Nicht die gleichen Steuerelemente zum Arbeiten

Das Backend ist wirklich keine große Sache, da das meiste davon nur den Hauptteil dessen, mit dem Sie gearbeitet haben, in Java und das Android SDK implementiert. Meine größten Probleme sind auf das zurückzuführen, was der Benutzer erwartet, auf das Verhalten und die Unterschiede in der Benutzeroberfläche, manchmal ist es besser und manchmal ist es schlechter. Es hängt wirklich nur davon ab, was Ihre App tut.

BEARBEITEN

Mir ist gerade klar geworden, dass ich die eigentlichen Teile Ihrer Fragen nicht beantwortet habe.

Ich würde nicht sagen, dass es große Sprachparadigmen gibt, die von Obj-C-Entwicklern missverstanden werden. Ich würde sagen, dass Java aus OOP-Sicht wahrscheinlich einfacher zu bekommen ist, was ich möchte. (Ich sollte sagen, ich arbeite nur wirklich mit .NET und Java und kenne nur genug Obj-C, um damit auszukommen).

Ich würde definitiv Eclipse verwenden, ich war es leid, IntellijIdea für eine Weile zu verwenden, und es gab mir nur viele Probleme, es dazu zu bringen, bestimmte Dinge zu tun.

[Diese Antwort ist eine Art Streifzug. Ich wollte es löschen, dachte aber, dass es interessant sein könnte: lass es mich über Kommentare wissen, wenn ich es löschen sollte und ich werde].

Ich arbeite nicht mit Android, aber mit Java und iOS (mit Obj-C). Was an der Java-Entwicklung wirklich anders ist, ist, wie viel eine IDE helfen kann (die Leute werden Ihnen sagen, dass Sie keine IDE verwenden sollen, was eine völlig andere Sichtweise auf dasselbe ist: Nur wenige Leute raten jedoch zu Java). . XCode ist im Allgemeinen nicht in der Lage, die einfachsten Syntaxfehler sogar RICHTIG zu erkennen (aufgrund der Struktur der Sprache, denke ich). Auf der anderen Seite bringt Sie die IDE in Java viel schneller voran als ohne sie. Sie können auch wirklich coole Dinge tun, wie den aufrufenden Client zu programmieren und dann die Methode zu schreiben. In Eclipse zum Beispiel, wenn ich tippe

blah.doIt(firstObj, secondObj);

und firstObjund secondObjsind StringInstanzen, die IDE wird mir die Option geben, eine Methode mit dem Zeichen "public void doIt (String firstObj, String secondObj)" zu erstellen. Das ist wirklich cool und nur die Spitze des Eisbergs: Die IDE ist dein Freund. Ich habe gehört, dass IntelliJ vielleicht noch cooler ist (obwohl es in meinen Versuchen nicht so war).

Gibt es eine Falle in dieser Antwort? Vielleicht liegt es daran, dass die IDE in Obj-C und Java dieselbe Rolle spielt. In Java kann die IDE Dinge tun, die selbst erstaunlich schwierig wären. Das automatische Refactoring ist aufgrund der Art und Weise, wie Java arbeitet, 100x leistungsfähiger als das von XCode. Dies bedeutet, dass Sie einige Entwurfsfragen auf einen späteren Zeitpunkt verschieben können.