Jak zrobić „pół-appkę" i nie wpaść w pułapkę?

Materiał promocyjny Rynek aplikacji mobilnych jest jednym z najdynamiczniej rozwijających się obszarów IT. Wcześniej czy później (raczej wcześniej) biznes w każdym przedsişbiorstwie przyjdzie do IT po „appkę", zapewne niejedną. Na co szczególnie warto zwrócić uwagę (swojemu zespołowi lub zewnętrznemu dostawcy) przy projektach mobilnych?

Jak zrobić „pół-appkę" i nie wpaść w pułapkę?
Rozwój rynku potwierdza, że ten sposób efektywnego zapewnienia wsparcia dla wielu mobilnych platform jest obecnie dominujący. Liczba dostawców hybrydowych platform stale rośnie - można wspomnieć Mendix, Zingma, Kony czy Pega AMP. Tendencję potwierdza dołączenie do tego grona liderów, takich jak: Intel z XDK HTMLS Cross-platform Development Tool, SAP z Mobile Platform czy Oracle z... Mobile Platform (najwyraźniej trudno jest wymyślić coś oryginalnego). Jednak nie oznacza to, że z technologią hybrydową nie wiążą się już żadne wyzwania. Jakie one są i przede wszystkim jak wpływają na codzienność IT w przedsiębiorstwie? Z doświadczeń Sii wynika, że przy wielu z tych wyzwań dobry zespół IT może wydatnie pomóc, mądrze zarządzając architekturą przedsiębiorstwa i oczekiwaniami swojego klienta - biznesu.

Wydajność

Pierwszym narzucającym się wyzwaniem aplikacji mobilnych jest wydajność. Z jednej strony kontekst użytkownika (interakcja ad hoc) wymaga maksymalnej responsywności, z drugiej strony ograniczone zasoby urządzenia i niepewne połączenie z serwerem znacząco ją obniżają. Wydajność jest w szczególności istotna dla takich grup użytkowników, jak: przedstawiciele handlowi, logistyka, akwizycja czy służby utrzymania ruchu. Dodatkowo może pojawić się wymaganie wykorzystania urządzeń o zwiększonej odporności na uszkodzenia mechaniczne, kurz czy wodę, które z konieczności mają słabsze od czołowych smartfonów parametry techniczne. W takich przypadkach aplikacja musi zostać starannie przygotowana pod względem szybkości lokalnego przetwarzania danych. Trzeba również znaleźć kompromis pomiędzy ilością danych, które można przetworzyć na urządzeniu, a ilością odwołań do serwera. Najlepszym rozwiązaniem jest najczęściej specjalne przygotowanie przez IT danych dla aplikacji mobilnej już w systemach przedsiębiorstwa.

Z drugiej strony należy pamiętać o tym, że aplikacja powstaje nie na urządzenia dostępne dziś, ale na te za co najmniej pół roku. W przypadku mobile to cała era. Z wydajnością aplikacji mobilnych mamy podobne problemy jak z aplikacjami webowymi dla przedsiębiorstw 10-15 lat temu. Tak jak poradziliśmy sobie wtedy, tak poradzimy sobie i teraz - należy się jednak liczyć z przejściowym okresem, w którym zadowolenie użytkowników końcowych będzie mniejsze. A jeżeli szybkość działania aplikacji jest krytyczna, należy ją włączyć do całościowej analizy TCO, porównując technologie hybrydowe i naty wne.

Jak zrobić „pół-appkę" i nie wpaść w pułapkę?

Przyszywani krewni

Mniej oczywistym wyzwaniem jest, paradoksalnie, główna zaleta hybryd - czyli budowanie aplikacji z jednego kodu na wiele platform mobilnych oraz dla przeglądarek na PC. Występując zawsze jako czynnik redukcji kosztów, ma jeden minus: wiele bibliotek JavaScript, produkujących bardzo „sexy" GUI, nie jest optymalizowanych pod kątem wydajności. Budowane jako warstwa na warstwie ułatwiają życie programistom, ale i napełniają kieszenie producentom procesorów (dziękujemy, panie Gordonie!). Nawet jeżeli biblioteki te działają na telefonach, to wydajnością czasem odbiegają daleko od oczekiwań. IT musi więc umiejętnie zarządzać oczekiwaniami biznesu, pamiętając o możliwościach urządzeń. Na szczęście podejście RWD (Responsive Web Design) pozwala na wyświetlanie tej samej strony w różny sposób na różnych urządzeniach.

Inne niebezpieczeństwo związane z tą cechą hybryd to pokrewieństwo (czasem pozorne) z serwisem WWW. Samo „umo-bilnienie" istniejącego portalu informacyjnego może być bardzo dobrym pomysłem, gdyż dodaje mu możliwości powiadomień typu „push" czy pracy offline. Dobrym przykładem jest tu aplikacja do kontaktu spółki giełdowej z jej inwestorami. Jednak jeżeli kod HTML portalu nie był tworzony z myślą o przeniesieniu do RWD/mobile/ hybrid, może on zapewnić wiele upojnych nocy nad klawiaturą zespołowi programistów front-end.

Zadania zespołu IT

IT pełni kluczową rolę w oswajaniu i wyjaśnianiu biznesowi mobilnej rzeczywistości. Często samo stworzenie aplikacji mobilnej zlecane jest doświadczonemu dostawcy. Ale nawet w takiej sytuacji w projekcie pozostaje wiele do zrobienia dla IT. Dla każdego architekta enterprise jasne jest na przykład, że mobile to tylko cienki front dla systemów domenowych, a to nakłada zobowiązania na EA - SOA, BPM czy zapewnienie dostępności systemów, a przynajmniej danych za pomocą cache/proxy. IT jest również odpowiedzialne za zaprojektowanie wykorzystywanej architektury informacji, ale nie dla UX (to robi firma od app design), a Master Data Management - określenia domen, w których pracować będzie aplikacja, oraz systemów za nie odpowiedzialnych. Następnie należy się upewnić, że systemy te gwarantują interfejs w postaci usług biznesowych do łatwego wykorzystania - dla enkapsulacji i reużycia logiki biznesowej, dla minimalizacji komunikacji z urządzeniem mobilnym, wreszcie dla jak najsprawniejszego walidowania przesyłanych danych. Najlepszym przygotowaniem takiego API jest udostępnienie go kilku różnym partnerom do wykorzystania. Sytuacja, w której jeden dostawca kontroluje wszystkie integrowane systemy, nie sprzyja podnoszeniu jakości zarówno wykorzystywanego API, jak i jego dokumentacji.

Obserwujemy gwałtowny wzrost znaczenia aplikacji mobilnych, zwłaszcza hybrydowych. Coraz więcej programistów przesiada się na HTML5/CSS3. Powstaje coraz więcej narzędzi, bibliotek, frameworków. Mając dobrze ułożoną architekturę IT przedsiębiorstwa, ze wsparciem doświadczonego partnera, IT może z sukcesami surfować na tej fali.

PS: A skąd tytuł artykułu? Chciałem skrócić przydługawe określenie „hybrydowe aplikacje mobilne", a że są one pół aplikacjami a pół stronami HTML, wyszło mi: „pół-appki". Myślicie, że się przyjmie?

Grzegorz Kot
Dyrektor Działu Projektów w krakowskim oddziale Sii, odpowiedzialny zarówno za działania operacyjne, jak i wyznaczanie kierunków rozwoju i inwestycji w innowacje. W Sii, a wcześniej w Comarch, dostarczał rozwiązania z obszaru obsługi różnych elementów szeroko pojętego procesu sprzedaży, głównie do banków i operatorów telekomunikacyjnych. W czasie wolnym ostatnio szlifuje technikę jazdy na waveboardzie syna.