Przenoszę swoją aplikację z iOS na Androida: co muszę wiedzieć? [Zamknięte]

Jakich pułapek powinienem unikać?

• Jakie paradygmaty języka Java konsekwentnie źle rozumieją programiści Objective-C? Nauczyłem się programować w Javie, ale od lat pracuję w Objective-C.
• Czym różnią się wzorce projektowe między Androidem a iOS?
• Jeśli dokonałeś przejścia samodzielnie, jakie części Androida Cię zdezorientowały lub zajęły Ci dłużej naukę, niż powinna?
• Czy Eclipse jest najlepszym OS X IDE na Androida?

Dla przypomnienia, moja aplikacja jest bardzo mocno powiązana z UIKit i Foundation, więc słowo „portowanie” może być mylące; Naprawdę całkowicie go przepiszę dla Androida. Bez ponownego użycia kodu. Robię to również, aby nauczyć się Androida, więc wolę nie zawieść portu i nauczyć się Androida, niż skorzystać ze skrótu.

Jako trochę tła, pytanie to zostało zadane przez typy pytań, które widzę w Stackoverflow. Często możesz powiedzieć, jakie było czyjeś pochodzenie (C # lub Java), po jakich głupich błędach popełniają, gdy próbują napisać Obj-C. Chciałbym uniknąć błędów, które powodują, że programiści Java przewracają oczami i mówią: „Twórcy Silly Objective-C, czy nigdy się nie nauczą?”

Przesyłam aplikację z iOS na Androida, to czyjaś aplikacja, z którą współpracuję, ale niemniej.

Po pierwsze, powiedziałbym, że bazy użytkowników zostały nauczone drastycznie różnych sposobów interakcji z ich urządzeniami. Wiele z tego wynika z samego projektu aplikacji, a także ze sposobu działania urządzeń.

Kilka ogólnych rzeczy:

• Krajobraz jest prawie wymagany na urządzeniach z Androidem
• Aplikacje na Androida zwykle działają, gdy nie są aktywnie używane, więc musisz o tym pomyśleć w przypadku problemów z siecią, GPS itp.
• Segmentacja urządzeń, istnieje mnóstwo urządzeń z Androidem i rozdzielczości ekranu, tutaj względne układy i obrazy z 9 łatami są bardzo przydatne.

Duży, o którym wiele osób początkowo nie myśli Your UI can not be exactly the same on both devices, na pewno może być podobny, ale przeniesienie interfejsu użytkownika iPhone'a na urządzenie z Androidem nie zadziała bardzo dobrze.

Pewne powody:

• Długie dotykowe menu kontekstowe
• Wyskakujące menu
• Segmentacja urządzenia powoduje różne rozdzielczości i współczynniki proporcji
• Nie te same kontrolki do pracy

Back-end naprawdę nie jest wielkim problemem, ponieważ większość z nich po prostu implementuje większość tego, z czym pracowałeś w Javie i zestawie SDK dla Androida. Moje największe problemy wynikają z oczekiwań użytkownika oraz zachowania i różnic interfejsu użytkownika, czasem jest to lepsze, a czasem gorsze. To zależy tylko od tego, co robi Twoja aplikacja.

EDYTOWAĆ

Właśnie zdałem sobie sprawę, że nie odpowiedziałem na rzeczywiste części twoich pytań, więc proszę (przynajmniej mój najlepszy strzał)

Nie powiedziałbym, że istnieją jakieś duże paradygmaty językowe, których twórcy Obj-C nie rozumieją. Powiedziałbym, że Java jest prawdopodobnie łatwiejsza do uzyskania tego, co chcę, z perspektywy OOP. (Powinienem powiedzieć, że naprawdę pracuję tylko z .NET i Javą i znam tylko wystarczająco dużo Obj-C, aby się z tym pogodzić).

Zdecydowanie skorzystałbym z Eclipse, przez pewien czas miałem dość korzystania z IntellijIdea, co sprawiło mi wiele problemów z próbą zmuszenia go do robienia pewnych rzeczy.

[ta odpowiedź jest trochę bełkotem lub rantem. Chciałem go usunąć, ale pomyślałem, że to może być interesujące: daj mi znać poprzez komentarze, czy powinienem to usunąć, a zrobię to].

Nie pracuję na Androidzie, ale pracuję w Javie i iOS (z Obj-C). Jedną rzeczą, która naprawdę różni się w rozwoju Java, jest to, jak bardzo IDE może pomóc (ludzie powiedzą ci, abyś nie korzystał z IDE, co jest zupełnie innym podejściem do tego samego: niewiele osób doradza to w Javie) . XCode generalnie nie jest w stanie PRAWIDŁOWO wykryć najprostszych błędów składniowych (chyba ze względu na strukturę języka). Z drugiej strony w Javie IDE może sprawić, że będziesz się poruszać znacznie szybciej niż bez niego. Możesz także robić naprawdę fajne rzeczy, takie jak programowanie wywołującego klienta i NASTĘPNIE pisanie metody. Na przykład w Eclipse, jeśli piszę

blah.doIt(firstObj, secondObj);

i firstObji secondObjsą Stringprzypadki, IDE da mi możliwość wykonania metodę z SIG „public void doit (String firstObj, String secondObj).” To jest naprawdę fajne i tylko wierzchołek góry lodowej: IDE jest twoim przyjacielem. Słyszałem, że IntelliJ może być jeszcze fajniejszy (choć w moich testach tak nie było).

Czy w tej odpowiedzi jest pułapka? Być może jest tak: myślenie, że IDE odgrywa tę samą rolę w Obj-C i Javie. W Javie IDE może robić rzeczy, które byłyby niezwykle trudne do zrobienia samemu. Automatyczne refaktoryzowanie, ze względu na sposób, w jaki Java jest, jest 100 razy silniejsze niż XCode. Oznacza to, że możesz odłożyć niektóre pytania projektowe na później.