Jak już ostatnio pisałam, będąc w Rzeszowie, opowiadałam o tworzeniu aplikacji mobilnych. Skupiłam się głównie na synchronizacji danych, ale wspomniałam również o kilku innych cechach, które odróżniają je od np. webowych, czy desktopowych. Tematyka może być niezbyt odkrywcza dla kogoś, kto pracuje z aplikacjami mobilnymi, ale gdy ja po raz pierwszy siadłam do komputera, by zostać developerem Windows Phone, zupełnie nie wiedziałam z czym to się je. Myślałam, że zwyczajnie siądę do Visual Studio, otworzę projekt stworzony w specyficznym szablonie i… zacznę programować.

Okazało się, że to nie takie proste, nie tylko dlatego, że zanim cokolwiek dało się zrobić musiałam zainstalować tysiące rzeczy, ale również ze względu na fakt, iż nie jest to zwykła aplikacja warstwowa. Więc jaka? Z grubsza aplikacje mobilne można podzielić na dwa rodzaje – natywne i webowe.

Aplikacja webowa, czy też responsive desing, to tak naprawdę strona internetowa zaprojektowana dla mniejszego ekranu. Aplikacja natywna z kolei, to taka, która jest ściągana i instalowana na urządzeniu. Którą wybrać i kiedy używać? Jak zwykle – to zależy… Wybrałam kilka aspektów, które przedstawiłam podczas spotkania, ale oczywiście jest ich o wiele więcej.

Wieloplatformowość

Jeśli planujemy działanie naszej aplikacji na wielu platformach (albo choćby na dwóch), to mniejszego nakładu pracy będzie wymagało stworzenie wersji webowej. Dzisiaj jedynie niewielka ilość działa tylko na jednym systemie. Głównie z uwagi na to, by nie skazywać użytkowników na  kupno odpowiedniego sprzętu, albo nie skazywać nas na klęskę rynkową, bo użytkownicy raczej nie kupią odpowiednich telefonów tylko dla naszej aplikacji. Poza tym dostęp do funkcjonalności z różnych źródeł może być cechą bardzo pożądaną ze względu na UX. W przypadku aplikacji natywnych, każda platforma to tak naprawdę odrębne środowisko i wymagać będzie adekwatnych umiejętności developerskim. To może oznaczać, że będziemy potrzebowali wiedzy na temat każdej z platform i zapewne również różnych ludzi, którzy tę wiedzę posiadają.

Wykorzystywanie funkcji smartfonów

Czy twoja aplikacja będzie używać funkcjonalności specyficznych dla urządzenia? Będzie dzwonić, wysyłać smsy, robić zdjęcia? Chociaż aplikacje webowe rozwijają się w kierunku wykorzystania coraz większej ilości funkcjonalności telefonów wciąż, jeśli bardzo chcesz na nich polegać – wybierz aplikacje natywną.

Personalizacja

Jedną z największych zalet aplikacji mobilnych jest możliwość użycia personalizacji urządzenia przy jak najmniejszych ograniczeniach. Ponieważ aplikacje natywne są ściśle związane z urządzeniem, pozwalają na lepsze wykorzystanie ich możliwości.

Praca offline

Jasne jest, że jeśli mamy mieć możliwość pracy offline, to nie ma wyboru – należy zdecydować się na aplikację natywną. Ale po co w ogóle pracować bez sieci? Czy dzisiaj w ogóle istnieje taka potrzeba? No cóż, pewnie są takie miejsca na świecie, gdzie odpowiedź jest negatywna, ale gdy myślę o moich niedawnych podróżach z Krakowa do Warszawy, kiedy to przez jakieś 60-80% czasu nie miałam zasięgu, to niestety muszę przyznać, że tak.

Więc kiedy potrzebujemy takiej formy pracy? Niestety jeszcze przez jakiś czas nie tylko w lesie czy w samolocie. Oczywiście nikt nie wyobraża sobie “pracy” z facebookiem w trybie offline, ale jeśli myślimy o aplikacjach, do których wprowadzane są dane (np. Evernote), to uniemożliwianie pracy użytkownikowi, bo jest on odcięty od sieci, nie wydaje się sensowne. Miejmy nadzieję, że to się niedługo zmieni, wi-fi będzie praktycznie wszędzie, a tam gdzie jej nie zaznamy, poratuje nas XG/LTE czy jakiś następca. Ale póki co, jeśli chcemy pracować z przesyłem dużej ilości danych, to wielu z nas wybrałoby opcję, by działał jedynie gdy mamy internet.

Czego więc potrzebuje aplikacja działająca offline? Przede wszystkim lokalnej bazy danych. Bazy która najczęściej jest spersonalizowana – zawiera jedynie dane dla konkretnego użytkownika, więc nie jest to kopia bazy globalnej.

A teraz najlepsze – siedzimy sobie w lesie, pracujemy nad naszym zbiorem danych i wszystko jest fajnie dopóki… jesteśmy offline. Bo jeśli chcemy z tych danych skorzystać na innym urządzeniu, to potrzebna będzie synchronizacja.

Jak ona się odbywa? Po pierwsze nasza aplikacja mobilna pobiera dane, których brakuje w stosunku do tego co jest w globalnej bazie danych. Można to zrobić np. używając timestampów. Po drugie do bazy globalnej należy wysłać lokalne zmiany wprowadzone na urządzeniu. W najprostszym przypadku rozpatrywanymi zmianami są utworzenie, usunięcie i zmiana stanu obiektów.

I tu pojawić się mogą konflikty. Na przykład skąd wiadomo które dane mają być zaakceptowane jako finalne? Te z serwera, czy lokalne? Można odpowiedzieć, że te które są nowsze, ale co jeśli zmiany w tym samym obiekcie zostały wprowadzone równolegle, na dwóch różnych urządzeniach? Które powinny zostać uznane za ostateczne, skoro zostały wprowadzone na podstawie stanu bazy globalnej?

W przypadku dodawania nowych obiektów częstą praktyką jest użycie lokalnych identyfikatorów na urządzeniach mobilnych. W trakcie synchronizacji, obiekty takie są rozpoznawane jako nowe, dodane do globalnej bazy danych, gdzie nadawane jest im globalne id. I tu pojawia się kolejny aspekt, który powinien być obsłużony w trakcie synchronizacji, czyli relacje między obiektami. Jeśli np. dodajemy nowy obiekt i obiekt z nim powiązany, to skąd wiadomo na którym id bazuje ta relacja? I co się stanie gdy połączymy nowy obiekt z już istniejącym? Jak serwer czy nawet nasza logika sobie z tym poradzi?

Aktualizacje

Aktualizacje są zawsze bardziej bolesne w przypadku aplikacji natywnych, dla których należy je wprowadzić na wszystkich platformach. Dodając do tego kwestie bazy danych, dochodzi tutaj wzięcie pod uwagę jej aktualizacji. Każda nowa wersja oprogramowania może skutkować zmianami w schemacie danych i potrzebą dostosowania lokalnych baz do globalnej. Jeśli więc planujesz częste update’y, lepiej to robić w responsive design, bo wiąże się to ze zmianą aplikacji i bazy tylko w jednym miejscu.

Podsumowując – łatwiej jest zbudować aplikację webową, natomiast jeśli chcemy stworzyć coś poważniejszego, nie obejdzie się bez aplikacji natywnych.