Tworzenie aplikacji mobilnych na wiele platform [zamknięte]


109

Coraz więcej platform mobilnych jest uruchamianych, a sdk są dostępne dla programistów. Dostępne są różne platformy mobilne: Android, iOS, Moblin, Windows mobile 7, RIM, symbian, bada, maemo itp.

A tworzenie aplikacji wieloplatformowych to ból głowy dla programistów. Szukam wspólnych rzeczy na platformach, które pomogą programistom, którzy chcą przenieść aplikację na wszystkie platformy. Na przykład, jakie są rozdzielczości ekranu różnicowego, metody wprowadzania, obsługa Open GL itp., Podziel się szczegółami, które znasz dla dowolnej platformy.

Czy są możliwości, pisząc kod w html (typ widgetu) i ładując go do natywnej aplikacji. Wiem o Androidzie, w którym możemy dodać widok sieciowy do aplikacji poprzez wywołaniesetContentView(view)

Udostępnij szczegółowe informacje o klasie, w której możemy dodać widok HTML do natywnych aplikacji różnych typów platform, które znasz.

Celem tego wątku jest udostępnianie wspólnych informacji programistom. oznaczanie jako wiki społeczności.

Narzędzia i biblioteka wieloplatformowa


1
Chociaż znalazłem jeden interesujący wątek, który jest powiązany z tym, stackoverflow.com/questions/3326110/ ...
sohilv

kolejny dobry post o
deweloperach

1
Głosował za zamknięciem tego jako duplikat. Jest to zbyt ważne, aby podzielić na dwa pytania. stackoverflow.com/questions/51988/…
ripper234

Odpowiedzi:


97

Moja odpowiedź tutaj obejmuje niektóre ograniczenia techniczne narzędzi wieloplatformowych, ale pozwól mi trochę rozwinąć:

Myślę, że narzędzia wieloplatformowe zawsze były również wykorzystywane do robienia zakupów, ponieważ takie narzędzia mają niewłaściwy filozoficzny cel.

Wszystkie zalety narzędzi cross-plaform to korzyści, jakie przynoszą programistom . Są sprzedawane z myślą, że pozwalają programistom pisać - raz uruchomione - gdziekolwiek. Są sprzedawane z myślą, że pozwalają programistom rozszerzyć swój rynek bez uczenia się nowych interfejsów API. Są sprzedawane z myślą, że pozwalają programistom obniżyć koszty i skrócić czas wprowadzania na rynek.

To, na czym NIE sprzedaje się narzędzia typu cross-plaform, to korzyści, jakie przynoszą użytkownikom końcowym .

Korzyść dla użytkownika końcowego nie jest punktem sprzedaży, ponieważ rozwój międzyplatformowy rzadko przynosi korzyści użytkownikowi końcowemu. Końcowego użytkownika nie obchodzi, jak ciężko pracował programista, aby wprowadzić produkt na rynek. Nie obchodzi ich też, na ilu platformach aplikacja może działać, gdy nie używają tylko jednej platformy. Dbają tylko o to, czy aplikacja robi to, czego potrzebują, na sprzęcie, na którym jest potrzebna. O ile nie mają konkretnej potrzeby uruchamiania aplikacji na wielu różnych platformach, fakt, że tak jest, nie przynosi im żadnej wartości.

I odwrotnie, nieuniknione kompromisy związane z tworzeniem wieloplatformowego interfejsu API oznaczają, że wszystkie aplikacje utworzone przez interfejs API będą w najlepszym przypadku klasy B na każdej platformie. Nigdy nie będą najlepszym narzędziem do wykorzystania na każdej platformie.

Wszystko to oznacza, że ​​w większości przypadków użycia narzędzia wieloplatformowe dają użytkownikowi końcowemu produkt gorszy w porównaniu do tych stworzonych z wykorzystaniem interfejsów API specyficznych dla platformy. Końcowy użytkownik zawsze będzie miał lepszy wybór.

Na dłuższą metę zarabiasz, udostępniając użytkownikom końcowym najbardziej przydatne narzędzia. Jeśli nie koncentrujesz się filozoficznie na ułatwianiu życia użytkownika końcowego i zwiększaniu jego produktywności, od samego początku jesteś skazany na porażkę. Użytkownicy końcowi mają wiele możliwości wyboru, a jeśli Twoje narzędzie nie jest jednym z najlepszych, nie trafisz na rynek.

Używaj narzędzi wieloplatformowych tylko wtedy, gdy myślisz, że „użytkownicy naprawdę skorzystają na uruchomieniu tej aplikacji na wielu różnych platformach”. Jeśli zaczniesz przyglądać się narzędziom wieloplatformowym wyłącznie dlatego, że ułatwią ci życie (programistom), to wybrałeś je z niewłaściwego powodu i bardziej cię zranią niż pomogą.


52
Cóż, mniej (niepotrzebnej) pracy dla programistów oznacza szybsze cykle aktualizacji, szybsze nowe funkcje, szybsze poprawki błędów i tak dalej. Przy tej samej sile roboczej można osiągnąć więcej. Uważam to za korzyść dla użytkownika końcowego.
schoetbi

10
Teoretycznie szybszy rozwój może być lepszy dla użytkownika końcowego, ale nie jest to filozoficzna podstawa większości wieloplatformowych interfejsów API. Widziałem wiele prób wykorzystania takich narzędzi w wielu środowiskach i zawsze kładę nacisk na ułatwienie życia programistom kosztem jakości produktu końcowego. Co więcej, obietnica szybszego i tańszego patelni rzadko się sprawdza. Zawsze wydaje się, że miejsce, w którym zatrzymuje się program, zjada większość zaoszczędzonego czasu.
TechZen

5
Aby skierować moją uwagę do sedna, rozważmy to: istnieją międzyplatformowe interfejsy API dla wielu różnych klas sprzętu i systemu operacyjnego. Z ilu aplikacji wieloplatformowych osobiście regularnie korzystasz? Z ilu aplikacji wieloplatformowych kiedykolwiek korzystałeś, o których dobrze myślałeś? Ludzie wypychają wieloplatformowe interfejsy API, odkąd ich była więcej niż jedna platforma, ale nigdzie tak naprawdę nie odnieśli sukcesu. Nie odnoszą sukcesu, ponieważ nie tworzą najbardziej przydatnych aplikacji dla użytkowników końcowych.
TechZen

4
@TechZen - Używam StackOverflow teraz w mojej przeglądarce internetowej i nie widzę powodu, by szukać natywnego klienta. Myślę, że zbytnio uogólniasz swoje twierdzenia.
Youval Bronicki

4
Jestem bardzo zdenerwowany, że tego rodzaju subiektywna debata filozoficzna otrzymuje właściwą ocenę na technicznej stronie internetowej. Co gorsza, teza tego posta jest nieważna w przypadku większości głównych programów, których używamy dzisiaj: Przeglądarki internetowe są wieloplatformowe; Photoshop, MS Office, Dropbox i stuff są wieloplatformowe; po prostu otwórz menu Start lub Finder i wymień ludzi na konkretną platformę - najprawdopodobniej znajdziesz małe oprogramowanie narzędziowe. Twój argument byłby słuszny, gdybyś uważał, że telefony komórkowe są radykalnie różne (bardzo słuszne założenie), ale wydaje się, że nie ma argumentów, aby zbudować ten fundament.
kizzx2

14

Istnieje kilka podejść do programowania międzyplatformowego na urządzeniach mobilnych. Oczywiście wszystkie mają ograniczenia. Żadne rozwiązanie nie jest w stanie wykorzystać wszystkich funkcji urządzenia tak, jak aplikacja natywna.

Ponowne użycie kodu

Chociaż wszystkie mobilne systemy operacyjne nie używają tego samego języka programowania i interfejsu API, czasami można udostępniać niektóre klasy lub kod warstwy logiki.

Na przykład C ++ można prawdopodobnie ponownie wykorzystać do aplikacji na iOS , do aplikacji na Androida przy użyciu NDK , do aplikacji Symbian, ponieważ są one opracowywane w C ++ itp.

Niektóre rozwiązania oferują również możliwość napisania aplikacji w innym języku niż ten, którego zwykle używa urządzenie. Najbardziej znane (a właściwie jedyne jakie znam) są komercyjne i oparte na projekcie Mono (programowanie w C #):

Ale nie jestem pewien, czy naprawdę możemy nazwać to programowaniem wieloplatformowym, ponieważ ponowne użycie kodu jest ograniczone w zależności od urządzenia:

  • Windows Phone 7 nie pozwoli na tworzenie kodu natywnego (może w dalszych aktualizacjach)
  • AFAIK mono jak projekt nie istnieje na wszystkich platformach (jeszcze?) Bada, webOS, maemo itp.

Część interfejsu użytkownika również pozostaje specyficzna dla każdego urządzenia.

tworzenie stron internetowych

Typową odpowiedzią na pytanie o tworzenie aplikacji na różne platformy dla telefonów komórkowych jest tworzenie stron internetowych. Potrzebowalibyśmy wtedy opakowania, które będzie korzystało z przeglądarki mobilnej, aby wyglądało i zachowywało się jak aplikacja natywna. W ten sposób działają niektóre ramy międzyplatformowe, które zobaczymy w dalszej części.

Pojawienie się HTML5 zapewnia funkcje tworzenia stron internetowych, które można było wykonać tylko za pomocą natywnej aplikacji, takiej jak geolokalizacja, aplikacja offline, pamięć lokalna.

Możemy znaleźć coraz więcej frameworków do tworzenia aplikacji internetowych na telefony komórkowe o natywnym wyglądzie i działaniu, korzystając z najnowszych standardów internetowych HTML5, CSS3, Js:

Ale HTML5 jest wciąż bardzo młody i implementacja może się różnić w zależności od przeglądarki. Większość domyślnych przeglądarek mobilnych korzysta z silnika WebKit (głównym wyjątkiem jest telefon komórkowy / telefon z systemem Windows przy użyciu przeglądarki Internet Explorer), a mimo to niekoniecznie obsługują te same funkcje . Praca z lokalną bazą danych jest nadal niewygodna i nie możemy być pewni, jak zostanie zaimplementowana przez różne przeglądarki. Co więcej, nawet w przypadku HTML5 tworzenie stron internetowych jest nadal bardzo ograniczone w porównaniu z aplikacjami natywnymi. Nie możesz uzyskać dostępu do kontaktów, aparatu, akcelerometru itp.

Edycja: Na początku tego miesiąca W3C dostarczyło ostrzeżenia o ewolucji HTML5: artykuł z ZDNet

Tak więc będzie pasować tylko do ograniczonej kategorii zastosowań.

Struktury międzyplatformowe

A niż mamy wieloplatformowe ramy aplikacji mobilnych. Za pomocą którego można przypuszczalnie raz opracować i wdrożyć na różnych platformach. Rozwiązania te zwykle koncentrują się na systemach iOS i Android i opierają się na silniku WebKit. Oferują większą interakcję z funkcjami telefonu, jednocześnie rozwijając technologie internetowe. Najbardziej znane to Nitobi PhoneGap, RhoMobile Rhodes, Appcelerator Titanium. Ale wiele innych jest dostępnych i nie wszyscy używają tej samej techniki, co MoSync, która tłumaczy twój kod na własny język pośredni przed skompilowaniem go dla pożądanej platformy.

[1] Pamiętaj, że Apple ma specjalne zasady dotyczące aplikacji napisanych na ich platformę. Wydaje się, że obecnie nie blokują tych aplikacji, ale jest to informacja, którą należy wziąć pod uwagę. Edycja: Apple zmienił tę politykę od 9 września.


6

Podczas wdrażania jako aplikacji internetowej (html5, jak wspomniano powyżej) pojawia się pewne podobieństwo, ale w przypadku bogatych aplikacji natywnych interfejsy API są zupełnie inne dla różnych smartfonów.

HTML5 może nieco poprawić sytuację, ale aby robić interesujące rzeczy, musisz być natywny.

Istnieją „wieloplatformowe” frameworki dla smartfonów, takie jak Phonegap, ale słyszałem głównie złe rzeczy o używaniu go do „prawdziwej” pracy. (dużo narzutów itp.)


5

Tak, HTML5 przyciąga uwagę. Powinieneś również spojrzeć na to konsorcjum i platformę, które pojawią się w czwartym kwartale. Nie jestem pewien powodzenia tego projektu, bo brzmi to jak ogromne wyzwanie, ale oto szczegóły:

Strona internetowa: http://www.wholesaleappcommunity.com/default.aspx

Wiadomości: http://news.google.de/news/search?aq=f&pz=1&cf=all&ned=us&hl=en&q=%22Wholesale+Applications+Community%22

WAC zamierza opublikować swoją wstępną specyfikację i składniki swojego SDK dla programistów w listopadzie. Ta specyfikacja będzie oparta na standardach W3C i stworzy silną platformę do tworzenia rozbudowanych mobilnych aplikacji internetowych. WAC zapewni również zgodność wsteczną dla urządzeń w oparciu o aktualne specyfikacje JIL i BONDI. ( http://www.convergedigest.com/Bandwidth/newnetworksarticle.asp?ID=31021 )

.

To jest międzynarodowa koalicja około 25 firm telekomunikacyjnych, której celem jest stworzenie platformy otwartej dla wszystkich programistów i sprzedawanej wszystkim użytkownikom telefonów komórkowych. ( http://www.downloadsquad.com/2010/02/15/atandt-wholesale-applications-community-is-a-platform-not-an-app/ )


1

O ile wiem, większość z tych urządzeń jest w stanie to uruchomić:

Java ME - najbardziej wszechobecna platforma aplikacji dla urządzeń mobilnych

Myślę, że może to służyć zarówno jako dobry, jak i zły przykład.


Właściwie nie ma java na iPhone, i, o ile mi wiadomo, Java ME nie działa na android
Alaa Nassef

Rozwój Androida jest w dużej mierze oparty na Javie. developer.android.com/reference/java/net/package-summary.html
Nick Garvey,

Nie znam szczegółów, ale Avian JVM pozwala java działać na urządzeniach z iOS.
Quazi Irfan
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.