Jak zrobić „pół-appkę" i nie wpaść w pułapkę?
![Jak zrobić „pół-appkę" i nie wpaść w pułapkę?](/g1/news/thumbnails/2/9/290361_art_3_png_80_resize_435x162.webp)
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ę? Jak zrobić „pół-appkę" i nie wpaść w pułapkę?](/g1/news/thumbnails/2/9/290363_art_3_png_95_adaptiveresize_435x290.webp)
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ę? Jak zrobić „pół-appkę" i nie wpaść w pułapkę?](/g1/news/thumbnails/2/9/290362_art_8_png_95_adaptiveresize_450x299.webp)
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?