Od jakiegoś czasu zastanawiam się, jak obecnie podejść do tworzenia oprogramowania dla urządzeń mobilnych. Częstym, jeżeli nie wyborem jest tworzenie aplikacji natywnych – czyli budowanych w oparciu o SDK danego producenta (w przypadku Androida  grupy producentów/urządzeń).

Wybór taki przypomina decyzje, jakie podejmowane były, i w sumie nadal są, w przypadku aplikacji na zwykłe komputery. Inaczej tworzymy aplikację na Windows & inaczej na Mac OS X, jeszcze inaczej na Linux’a (oczywiście to uproszczony pogląd).

Sytuację to ogromnie zmienił trend jakim stał się SaaS, czyli aplikacje dostępne 24h na dobę, w przeglądarce, dla dowolnej platformy i z dowolnego miejsca na świecie. Mimo zmiany “terminala” jakim jest komputer nie potrzebujesz reinstalacji czy zmiany ustawień.

Moim zdaniem taki właśnie ruch czeka niebawem aplikacje mobilne. Jaki sens ma używanie rewelacyjnej aplikacji do zarządzania czasem, która jest natywna dla Twojego iPhona, jeżeli za rok czy dwa postanowisz zmienić telefon na pracujący pod kontrolą Androida. Poniesienie znacznych nakładów pracy na wprowadzenie danych odnośnie Twoich klientów do aplikacji na Androidzie może okazać się stratą czasu i energii, gdy zgubisz telefon, co gorsze w przypadku kradzieży dane z telefonu są bez większego problemu dostępne dla złodzieja.

Jakie inne rozwiązanie ma więc racje bytu? Według mnie SaaS dla urządzeń mobilnych. Ilość danych w pakietach naszych telefonów rośnie w szybkim tempie, nie jest już problemem koszt transferu. Więc obranie kierunku tworzenia aplikacji w architekturze Mobilny Klient – Serwer ma duże szanse powodzenia.

Interaktywność samego interfejsu dzięki takim rozwiązaniom jak jQuery Mobile może być zbliżona do aplikacji natywnych. Do tego dochodzi większe zbliżenie interfejsów na różnych telefonach, za czym idzie lepszy odbiór użytkownika, który przyzwyczaja się do konkretnego wyglądu aplikacji, który po zmianie telefonu nie czuje się zagubiony w naszym programie.

Co ciekawsze, zastosowanie rozwiązań takich jak jQuery Mobile pozwala jedną aplikacją “pokryć” znacznie więcej urządzeń, co zmniejsza koszty jej budowy i utrzymania.

Dodatkowym atutem za takim podejściem jest gotowość bieżącej infrastruktury, zarówno technicznej jak i zasobów ludzkich do budowy takich aplikacji. Trudniej znaleźć programistę dla iPhone SDK niż dla tzw. aplikacji webowych (PHP, J2EE Ruby on Rails itp.).

Reasumując, na chwilę obecną skłonny był bym bardziej wybrać rozwiązanie SaaS dedykowane urządzeniom mobilnym, niż budowę wielu natywnych aplikacji. Oczywiście mowa tu o aplikacjach usługowych, a nie o grach, a generalizując nie o takich aplikacjach dla których kluczowa jest wydajność sprzętowa.