Czego potrzeba, aby uzyskać każdą aplikację na każdej platformie?

Istnieją trzy sposoby wyboru sposobu korzystania ze smartfona: według operatora, urządzenia i aplikacji. Wybór według operatora stawia jakość usługi komórkowej na pierwszym miejscu, podczas gdy podjęcie decyzji na podstawie urządzenia oznacza, że ​​szukasz określonej platformy i funkcji sprzętowych. Ale wybór według aplikacji może być trudniejszy.

Obecny zestaw ekosystemów mobilnych jest jednocześnie podzielony i ujednolicony na różnych platformach. Niektóre główne aplikacje są dostępne na wielu platformach, podobnie jak aplikacje mniejszych programistów. Inne aplikacje są dostępne wyłącznie dla platformy ze względu na funkcje unikalne dla systemu operacyjnego lub ograniczenia zasobów programisty. Ale jeśli naprawdę potrzebujesz tej jednej aplikacji, operator lub urządzenie nie ma tak dużego znaczenia.

Ale co by było, gdyby wszystkie aplikacje były dostępne na wszystkich platformach? Czy programowanie międzyplatformowe jest czymś, o co programiści powinni się martwić i czy są w tym przeszkody? Czy lepiej jest zbudować aplikację specjalnie dla każdej platformy, czy też aplikacja powinna być zbudowana za pomocą wieloplatformowej platformy internetowej?

Użytkownicy i programiści mogą zgodzić się, że posiadanie aplikacji niezależnie od platformy jest świetnym ideałem. Ale jakim kosztem?

Zacznijmy rozmowę!

W rzeczywistości pytanie jest bardziej skomplikowane. Najczęściej „następna wielka rzecz” została stworzona przez jednego naprawdę utalentowanego programistę lub mały zespół, który po prostu nie ma zasobów, umiejętności lub zdolności do programowania wieloplatformowego. Widzieliśmy to wcześnie na Instagramie i Androidzie - firma stojąca za aplikacją miała słynną tylko trzynastu pracowników. Takie ograniczenia opóźniły na jakiś czas aplikację na Androida na Instagramie, a nawet teraz po jej wykupieniu Facebook za miliard dolarów wciąż nie wydali aplikacji kompatybilnej z BlackBerry 10 lub Windows Telefon.

Platforma musi często trafiać w jakąś niewidoczną i niejednoznaczną miarę, według której jest uważana za „akceptowaną” przez masy.

Małe firmy nie są tutaj same, ponieważ często widzimy ogromne firmy medialne wahające się przed tworzeniem aplikacji wieloplatformowych. Platforma, o której mowa, musi często trafiać w jakąś niewidoczną i niejednoznaczną metrykę, według której jest uważana za „akceptowaną” przez masy i dopiero wtedy firmy rozważą stworzenie dla niej aplikacji. Czasami deweloperzy, którzy są „fanami” konkretnego systemu operacyjnego, najpierw tworzą aplikację dla tej platformy, nawet jeśli nie ma tam gigantycznego udziału w rynku. Stało się tak w przypadku oficjalnej aplikacji Disqus na Windows Phone, która była pierwszą (i jak dotąd jedyną) platformą mobilną, która otrzymała oficjalną aplikację z usługi komentowania.

Więc tak, firmy powinny zawsze starać się przejść na wiele platform, kiedy tylko mogą, a jeśli nie mogą, powinny skontaktować się z programistami z tej społeczności, aby pracować nad partnerstwem. Foursquare zrobił to, gdy programista Zhephree niezależnie stworzył aplikację Foursquare dla systemu webOS w 2009 roku, która stała się de facto aplikacją Foursquare na platformę. Niestety jest to rzadkie zjawisko i zbyt często konsumenci są obarczani wyborami aplikacji, które nie zawierają najnowszych lub najlepszych z powodu wyboru platformy mobilnej.

Czy wieloplatformowy język programowania, taki jak HTML5 lub Unity do gier, byłby pomocny? Standardy są z pewnością lepsze niż chaos, chociaż, jak do tej pory widzieliśmy w HTML5, był to raczej szum szumu niż sukces.

W.chociaż są wyjątki od każdej reguły, naprawdę chcę żyć w świecie, w którym większość aplikacji mobilnych jest wieloplatformowych i działa tylko wtedy, gdy chcę i gdzie chcę. Weźmy na przykład Internet. Mogę uzyskać dostęp do prawie każdej witryny internetowej z prawie każdego urządzenia na rynku. Witryna Facebooka nie dba o to, czy korzystam z komputera Mac czy PC z systemem Windows, smartfona czy tabletu, Androida czy BlackBerry 10.

Tak długo, jak platforma ma nowoczesną przeglądarkę internetową, mogę uzyskać dostęp do praktycznie każdej witryny. Potrafię zbudować i wdrożyć witrynę internetową na wiele różnych urządzeń i każdy może ją zobaczyć. W większości przypadków, jeśli witryna jest zgodna ze standardami, to naprawdę „po prostu działa”.

Stan wieloplatformowych aplikacji mobilnych jest zupełnie inny.

Weź Android Central, CrackBerry, iMore i Windows Phone Central. Witryny używają bardzo podobnego kodu i działają w większości przeglądarek komputerowych lub mobilnych. Cztery strony internetowe, wszystkie przeglądarki. Dobry interes.

Ale zrobienie tego z aplikacjami oznaczałoby użycie osobnych, zasadniczo różnych frameworków dla Androida, BlackBerry 10, iOS i Windows Phone dla każdej z aplikacji witryn. Cztery aplikacje razy cztery platformy, w sumie szesnaście aplikacji. Niezbyt dobry interes.

To samo można powiedzieć o akcesoriach, które opierają się na połączonych aplikacjach. Nike + FuelBand został wprowadzony tylko na iOS, ale w przypadku inwestycji Nike w sprzęt idealnie pasowałby do wszystkich platform. Wielu użytkowników innych niż iOS mogło kupić jeden na wakacje w 2012 roku, ale to FuelBand nie obsługuje i nadal nie obsługuje innych platform, ogranicza jego potencjalny rynek. Użytkownicy nie przejmowaliby się cross-platformą - liczy się tylko to, że działa z ich urządzeniem.

Nikt nie chce aplikacji na BlackBerry 10, która wygląda dokładnie tak jak na iOS i nie obsługuje gestów BlackBerry 10.

Gry są często najbardziej zaawansowane dzięki silnikom wieloplatformowym, takim jak Unity i Titanium. Jednak gry mają zwykle własne interfejsy niezgodne z platformą. Aplikacje inne niż gry są inne. Chociaż aplikacje mogą udostępniać wspólne funkcje, usługi, a nawet kod między platformami, potrzebują wyglądu i sposobu działania platformy oraz mogą korzystać z funkcji specyficznych dla platformy. Nikt nie chce aplikacji na BlackBerry 10, która wygląda dokładnie tak jak na iOS i nie obsługuje gestów BlackBerry 10.

Ostatecznie, jeśli wyłączysz z równania właścicieli platform, producentów, a nawet programistów, ludzie chcą tylko aplikacji, które kochają, na urządzeniach, które kochają. Oznacza to, że każda większa aplikacja musi obsługiwać każdą główną platformę. Teraz.

Tteoretycznie posiadanie tych samych aplikacji na wszystkich platformach powinno być oczywiste, prawda? Więcej aplikacji w większej liczbie miejsc. Ale rozczarowująca prawda jest taka, że ​​nawet dzisiaj nie wszystkie aplikacje są sobie równe.

Różne platformy działają inaczej. Czasami jest to kwestia sprzętu. BlackBerry 10 i Windows Phone nie oferują czystej mocy obliczeniowej Androida. Apple iOS jest prawdopodobnie łatwiejszy do opracowania i może zrobić więcej za mniej. A zatem aplikacja dostępna na iPhone'a i iPada może mieć inne funkcje niż na Androida, BlackBerry 10 lub Windows Phone. W rzeczywistości widzieliśmy przypadki popularnych aplikacji, które tracą znaczną część swojej funkcjonalności podczas przenoszenia z jednej platformy na drugą.

Rozczarowująca prawda jest taka, że ​​nawet dziś nie wszystkie aplikacje są sobie równe.

Jednak nie zawsze jest tak głęboko. Czasami to tylko kwestia wyglądu. Może po prostu aplikacja nie wygląda tak dobrze na jednej platformie, jak na innej. Powierzchowny? Być może. Aplikacje powinny mieć spójne środowisko na różnych platformach. Lub przynajmniej spróbuj mieć to samo doświadczenie. Ale nadal muszą mieć doświadczenie z platformą. To trudne do rozdwojenia włosy.

Dobra wiadomość jest taka, że ​​aplikacje to płynne bestie. Stale się zmieniają i ulepszają. Prawdopodobnie nie tak szybko, jak wszyscy byśmy chcieli, ale rzadka jest popularna aplikacja, która nigdy nie jest aktualizowana, nigdy nie poprawia się i nigdy nie zmienia się sama.

H.Aplikacje TML5 są tworzone przy użyciu standardowych technologii internetowych, takich jak HTML, CSS i JavaScript. Te aplikacje działają w przeglądarkach, takich jak Mapy Google lub iCloud.com, lub na urządzeniach lokalnych, takich jak Chrome OS lub późny, lamentowany webOS. Ponieważ tak wielu programistów już wie, jak tworzyć bogate doświadczenia internetowe, ogólnie zakłada się, że aplikacje HTML5 będą najłatwiejszą drogą do przeniesienia ich na urządzenia mobilne. Stąd wszystko, od oryginalnego „słodkiego” rozwiązania Apple, aplikacji w przeglądarce iPhone'a, przez Palm's Mojo i późniejsze frameworki Enyo, po WebWorks BlackBerry.

Doprowadziło to do założenia, generalnie od osób niebędących programistami, że HTML5 jest ostatnią, najlepszą nadzieją na utopijną przyszłość, w której aplikacje są pisane raz i wdrażane wszędzie, na wielu platformach, od komputera stacjonarnego po tablet i telefon oraz wszystko i wszystko w pomiędzy.

I to trochę BS.

Oryginalne „słodkie” rozwiązanie Apple wyszło tak słabo, że rok później zaczęli próbować wypuścić natywny App Store, aplikację kalendarza na webOS 1.0 zajęło dwadzieścia sekund na uruchomienie, a Google zapewnia znacznie lepsze wrażenia z natywnie zakodowanych aplikacji na Androida i iOS niż na sieć. Nawet najlepsze mobilne aplikacje internetowe, takie jak Gmail.com i prognost.io, bledną w porównaniu z bogatszymi, lepiej działającymi natywnymi kuzynami.

Aplikacje natywne skorzystają na nowym sprzęcie i nowych strukturach. Ich przewaga pozostanie, jeśli nie wzrośnie.

Niektórzy twierdzą, że wraz ze wzrostem wydajności sprzętu i poprawą obsługi JavaScript wydajność i funkcjonalność aplikacji internetowych wzrośnie. To absolutna prawda. Jednak aplikacje natywne również skorzystają na nowym sprzęcie i nowych strukturach. Ich przewaga pozostanie, jeśli nie wzrośnie.

Dlatego aplikacje HTML5 nazywane są przyszłością - zawsze nadchodzi, ale nigdy nie nadejdzie.

Próba stworzenia całej aplikacji w HTML5 jest jak próba stworzenia całej aplikacji, która istnieje całkowicie offline, w trybie samolotowym. Nie jest to niemożliwe, ale nie jest idealne i znacznie ogranicza zakres i doświadczenie, które można zapewnić.

Sprowadza się to do tego: Internet najlepiej zapewnia dynamiczne dane, a aplikacje natywne są najlepsze pod względem interfejsu i interaktywności. Świetne aplikacje wykorzystają to, co najlepsze z obu. Podobnie jak iTunes. Podobnie jak Mapy Google na Androida i iOS. Podobnie jak nowa natywna wersja Facebooka na urządzenia mobilne (nawet Facebook nauczył się tej lekcji na własnej skórze).

HTML5 nie jest w żaden sposób ostateczną przyszłością aplikacji. Ale to niezwykle ważna część tej przyszłości.

doaplikacje platformy Rossa to trudne przedsięwzięcie. Programiści muszą poruszać się po pakietach SDK i interfejsach API oraz przewodnikach dotyczących interfejsu użytkownika i UX, starając się jednocześnie zachować niepowtarzalny wygląd, funkcje i doświadczenie własnej aplikacji. To równoważenie wymagań i pragnień, oczekiwań i ograniczeń.

Idealnie byłoby, gdyby aplikacje działające na wielu platformach miały sens i byłoby to łatwe. Ale to zaciekły rynek i właściciele większych platform nie są zainteresowani ułatwianiem tworzenia aplikacji który będzie działał na urządzeniach konkurencji, podczas gdy mniejsi gracze chcą maksymalnie ułatwić przenoszenie tych samych aplikacje.

Istnieją platformy i narzędzia międzyplatformowe, ale ich zakres i moc są ograniczone. Ułatwiają budowanie spójnego środowiska na każdej platformie, ale poświęcają to, co sprawia, że ​​każda platforma jest wyjątkowa, i kompromis w zakresie jakości i wydajności. Jednak tworzenie aplikacji dostosowanych do platformy wymaga czasu i pieniędzy, których nie mają wszyscy programiści.

Nie ma dobrej odpowiedzi - ale jaka jest najlepsza?