Sencha Touch – hybrydowe aplikacje mobilne.

W artykule Tworzenie Aplikacji Mobilnych – 3 możliwości:  HTML5, natywna, hybryda opisywałem 3 możliwe podejścia do tematu implementacji aplikacji mobilnych. Dzisiaj napiszę kilka słów o Sencha Touch – frameworku dla języka JavaScript, który może służyć do implementacji nie tylko małych, ale także dużych i bardzo skomplikowanych aplikacji mobilnych. Sam framework Sencha Touch może być też użyty do stworzenia aplikacji HTML5, bez komponentów hybrydowych, jednakże wg mnie sama idea aplikacji stricte HTML5 jest na tyle mało praktyczna, że nie chce poświęcać jej swojej uwagi ani Twojego czasu.

Sencha Touch

No więc co to takiego ta cała Sencha? Sencha Touch to pochodna projektu Sencha, a ten z kolei to projekt powstały w 2010 roku, którego korzenie sięgają frameworka Ext JS. Sencha Touch składa się z gotowych komponentów, z których możemy zbudować aplikację jak z klocków. Demo możliwości frameworka można sprawdzić w aplikacji Kitchen Sink udostępnionej przez twórców Senchy Touch.

Kitchen Sink - Sencha Touch Demo
Kitchen Sink – Sencha Touch Demo

Jeśli już sprawdziłeś demo, polecam przeczytać Getting Started na stronie frameworka.

Tworzenie naszej aplikacji zaczynamy oczywiście od ściągnięcia frameworka stąd. Następnie używamy narzędzia Sencha Command i z linii komend generujemy szablon aplikacji.

Aplikację budujemy z widoków, kontrolerów operujących na tych widokach raz z modeli (i store’ów). Jak widać jest to klasyczny wzorzec MVC. Do testowania aplikacji i jej uruchamiania (poza specyficznymi przypadkami jak na przykład tryb offline) wystarcza normalna współczesna przeglądarka.

Sencha Touch – składniki aplikacji

Model View Controller

Widoki w aplikacji budujemy z gotowych komponentów jakie daje nam Sencha Touch. Jednak nie zamyka nam to w żaden sposób, aby zakodować jakiś nasz własny komponent w HTMLu i CSS i wyświetlić w aplikacji.

Widoki

Opis komponentów i ich lista dostępna jest tutaj. Poniżej dla wygody podaję listę – przyda się do rozpozniania możliwości.

xtype                   Class
-----------------       ---------------------
actionsheet             Ext.ActionSheet
audio                   Ext.Audio
button                  Ext.Button
component               Ext.Component
container               Ext.Container
image                   Ext.Img
label                   Ext.Label
loadmask                Ext.LoadMask
map                     Ext.Map
mask                    Ext.Mask
media                   Ext.Media
panel                   Ext.Panel
segmentedbutton         Ext.SegmentedButton
sheet                   Ext.Sheet
spacer                  Ext.Spacer
title                   Ext.Title
titlebar                Ext.TitleBar
toolbar                 Ext.Toolbar
video                   Ext.Video
carousel                Ext.carousel.Carousel
carouselindicator       Ext.carousel.Indicator
navigationview          Ext.navigation.View
datepicker              Ext.picker.Date
picker                  Ext.picker.Picker
pickerslot              Ext.picker.Slot
slider                  Ext.slider.Slider
thumb                   Ext.slider.Thumb
tabbar                  Ext.tab.Bar
tabpanel                Ext.tab.Panel
tab                     Ext.tab.Tab
viewport                Ext.viewport.Default
DataView Components
---------------------------------------------
dataview                Ext.dataview.DataView
list                    Ext.dataview.List
listitemheader          Ext.dataview.ListItemHeader
nestedlist              Ext.dataview.NestedList
dataitem                Ext.dataview.component.DataItem
Form Components
---------------------------------------------
checkboxfield           Ext.field.Checkbox
datepickerfield         Ext.field.DatePicker
emailfield              Ext.field.Email
field                   Ext.field.Field
hiddenfield             Ext.field.Hidden
input                   Ext.field.Input
numberfield             Ext.field.Number
passwordfield           Ext.field.Password
radiofield              Ext.field.Radio
searchfield             Ext.field.Search
selectfield             Ext.field.Select
sliderfield             Ext.field.Slider
spinnerfield            Ext.field.Spinner
textfield               Ext.field.Text
textareafield           Ext.field.TextArea
textareainput           Ext.field.TextAreaInput
togglefield             Ext.field.Toggle
urlfield                Ext.field.Url
fieldset                Ext.form.FieldSet
formpanel               Ext.form.Panel

Widoki mogą zawierać podwidoki, np na jednym panelu można umieścić inne panele, a formularze mogą zawierać wiele różnych pól, czy to tekstowych, czy innych. Same widoki nie powinny wykonywać większych operacji. Już sama konfiguracja widoku (np lista subwidoków, style, tworzenie widoku, itd.) zajmie sporo miejsca, dlatego kod odpowiedzialny za rekację na zdarzenia na widokach czy też operacje na modelach, umieszcajmy w Kontrolerach. Ponieważ widoki są bardzo powiązane z  wyświetlaniem danych Modelu, dobrym wzorcem jest używanie atrybutu

Record

, danego widoku i przy pomocy metod

applyRecord()

reagować na przypisanie rekordu i ustawiać dane wyświetlane na danym widoku.

 Kontrolery

Interakcję użytkownika z widokami obsługują Kontrolery. Kontroler to obiekt, którego zadaniem jest obsługa zdarzeń na widokach i dostarczenie danych widokom, aby te dane zwizualizować. W Senchy Touch zawsze istnieje 1 instancja danego kontrolera. Obiekty te tworzone są w czasie uruchamiania aplikacji. W kontrolerach powinniśmy umieścić część logiki biznesowej odpowiedzialnej za operacje związane z akcjami użytkownika. Operacje związane z zachowaniem obiektów reprezentowanych przez Modele, warto umieścić jako funkcje konkretnych instancji modeli.

Modele i Store’y

Model to klasa opisująca jakąś klasę obiektów rzeczywistości, którą modelujemy, np. Dom, Samochód, Użytkownik, Sesja, itd. Modele trzymane są w specjalnych zbiorach zwanych Store‚ami. A Store’y używają Proxy do ładowania i zapisywania danych lokalnie lub na zdalnym serwerze poprzez web service’y. Store’y dostarczają takich funkcjonalności jak sortowanie i  filtrowanie. Są odpowiednikami tabel w bazie danych, czyli przechowują zbiór instancji modeli. Są czasem też bezpośrednio połączone z widokami (np. listą) i porzez mechanizm Eventów powiadamiająć je o wszelakich zmianach dokonywanych na modelach, czy też filtrach bądź sorotwaniu. Model dostarcza pewnych mechanizmów transakcyjności. Zmiany wartości atrybutów modelu, można ujać w klamrę instrukcji

model.beginEdit();

oraz

model.endEdit();

albo

model.cancelEdit();

Dzięki powyższemy mamy możliwość zapisania wszystkich zmian wartości atrybutów lub anulowania ich, w zależności od kontekstu.

Profile

Profil to komponent w skrócie odpowiedzialny jest za rozdzielenie implementacji niektórych części aplikacji w zależności od typu urządzenia na którym działa aplikacja. Na przykład, tworząc aplikację, możemy zdefiniować sobie 2 profile: Telefon i Tablet, i potem zdefiniwać, że dla tabletów, uruchamiamy takie a takie komponenty, a dla telefonów inne. W ten sposób możemy wykorzystać maksymalnie duży ekran na tabletach jednoczęśnie dając maksymalną użyteczność na ekranie telefonu z uproszczonym widokiem.

Lokalna baza danych – wsparcie dla trybu offline

W dzisiejszym świecie, pomimo że niemal w każdej miejscowości jest zasięg telefonii komórkowej, jednak nie oznacza to automatycznie, że jest tam bardzo dobre połączenie z internetem. Używanie technologii słabszych niż 3G jest strasznie czasochłonne i powolne. Prędkość połączenia jest bardzo słaba. Dlatego chcąc dać użytkownikowi maksimum doświadczenia, możemy wbudować w aplikację jakąś lokalną bazę danych i umożliwić mu pracę w trybie offline. Niby nic, ale uwierzcie mi, że taki użytkownik biznesowy, np sprzedawca, idąc do kopalni/huty/magazyn i chcąc zaprezentować nowy produkt swojej firmy, lub zapisać zamówienie chce to zrobić szybko i pewnie, a nie chce czekać wieczności w połączeniu 2G czy też szukać zasięgu, żęby wykonać swoją pracę.

W aplikacjach hybrydowych mamy do dyspozycji:

  1. window.localstorage – oferowany przez przeglądarkę sposób zapisy danych w pamięci przeglądarki. Jest to typowo słownikowa struktura, pozwalająca dla wybranego klucza zapisać jakąś tekstową wartość. Jeśli chcemy zapisać obiekty, możemy użyć funkcji
    JSON.stringify();

    to konwersji obiektu do łańcucha znaków. Poza tym, ilość miejsca do zapisu danych dla aplikacji jest raczej niewielka i domyślnie wynosi 5 MB. W zależności od przeglądarki limit ten może ulec podwyższeniu automatycznie co 5 MB, ale każdorazowo za zgodą użytkownika.

  2. Lokalną bazę danych której interfejs jest wystawiony poprzez natywne komponenty dla warstwy JavaScript. Możemy użyć do tego klasycznego SQLite’a albo też wykorzystać pomysł SmartStore’a (stworzonego jako część Salesforce Mobile SDK), który co prawda oparty jest o SQLite, ale daje bardzo ciekawe możliwości.

 

Cordova/Phonegap

Cordova Logo

Naszej świeżej aplikacji w Sencha Touch musimy dać możliwość wykorzystania sprzętu (aparatu, dostępu do galerii zdjęc, kalendarza, akcelerometru, GPSa). Inaczej nie nazywała by się hybrydową aplikacją. W tym celu musimy dostarczyć dla Senchy odpowiednie API w JavaScript, które umożliwi wykorzystanie zasobów urządzenia. Takie API jest już gotowe. Wystarczy ściągnąć źródła projektu Cordova (dawniej Phonegap) i użyć tego jako bazy naszej aplikacji. Dla projektu Cordova dostępna jest cała masa pluginów, więc jeśli kiedykolwiek będziesz potrzebować zrobić coś dodatkowego – sprawdź, czy ktoś przed Tobą nie rozwiązywał już takiego samego lub podobnego problemu i czy gotowy plugin nie czeka na GitHubie na pobranie i wykorzystanie (oczywiście, w ramach licencji zaproponowanej przez autora). Jeżeli jednak brakuje nam jakiegoś pluginu, z łatwością możemy sobie taki stworzyć, czy to w Objective-C na iOS, czy to  Javie na Android.

WKWebView w iOS 8

W systemie iOS 8 udostępniona zostanie nowy komponent WKWebView. Ale co to ma wspólnego z aplikacjami hybrydowymi? Jest to kolejna generacja komponentu, który odpowiedzialny jest za parsowanie i wyświetlanie konentu w HTML + JS + CSS. Nikogo taki komponent nie zaskoczy, bo przecież było już dostępne UIWebView, prawda? A jednak. Zmiany są i te zmiany są bardzo ważne. A tym kilka zadań poniżej.

WKWebView w końcu przynosi dla wszystkich pełną szybkość obsługi kontentu webowego dla wszsytkich aplikacji. Do tej pory w iOS była widoczna różnica w szybkości działania tego samego kodu aplikacji webowej/HTML5 w Safari w porównaniu to UIWebView. Wraz z udostępnieniem WKWebView, mamy poprawę wydajności o około 20%.

Dodatkowo, dostępny jest bardzo prosty i przyjazny mechanizm umożliwiający wymianę komunikatów (danych) między kodem JavaScript w aplikacji a jej częścią natywną. Do tej pory, do takiej wymiany należało użyć produktów typu Phonegap/Cordova, jeśli chcieliśmy mieć coś ustandaryzowanego, lub samemu napisać prosty wrapper przechwytujący requesty HTTP komponentu UIWebView.

Do przesyłania komunikatów do części natywnej trzeba użyć komponent

window.webkit.messageHandlers

 

Podsumowanie

Swoją przygodę z Senchą Touch najlepiej zacząć od przeklikania aplikacji demo Kitchen Sink a następnie od przeczytania wstępnego tutoriala Getting Started. Jeśli ktoś miał wcześniej doświadczenie z Ext JS, to przejście na Senchę nie powinno stanowić większego problemu, chociaż duża ilość doświadczenia w pisaniu na urządzenia mobilne i znajomość ich ograniczeń ma bardzo duże znaczenie. Sama Sencha Touch cudów nam nie dostarczy, ważna jest jeszcze ścisła współpraca z konkretnym urządzeniem mobilnym. Warstwę wypełniającą tę lukę jest na przykład projekt Cordova. Warstwa HTML5 to jednak nie wszystko. Należy być świadomym ograniczeń narzucanych przez urządzenia mobilne oraz różnic w implementacji komponentu wyświetlającego treść HTML na różnych platformach.


Niniejszy post jest częścią serii postów pod tytułem: Jak stworzyć aplikację mobilną? Jeżeli zainteresowała Cię ta tematyka, to zachęcam do przeczytania pozostałych artykułów powiązanych z tworzeniem aplikacji mobilnych.


 

2 myśli do „Sencha Touch – hybrydowe aplikacje mobilne.”

  1. 2 lata temu tworzyłem aplikacje mobilne w połączeniu z Sencha Touch 2 i phonegap. Wszyscy chwalą tą technologię, ja uważam, że jeśli ktoś ma zamiar robić dynamiczne listy to już jest powód, aby sobie darować tą technologię. A wygenerowanie z ST natywnej paczki np dla androida(poprawnej paczki) graniczy z cudem. Zachowanie transakcyjności oraz pracy w czasie rzeczywistym daje dużo do życzenia. Plusem jest szybkość – pisania. Pierwszą aplikację budowałem pół roku. Drugą opartą na store’ach odwzorującą pierwszą aplikację dwa tygodnie. Porzuciłem tą technologię. Dedykowana natywna technologia jest zawsze najlepszym rozwiazaniem. Do czego bym użył ST? Gdy któryś z moich portali będzie potrzebował mobilnego site’u to jest to szybki sposób zbudowania zaawansowanej pięknej mobilnej strony www. Co więcej pozwala ukryć pasek url w przegladarce. Gdy pokazuje aplikację napisaną w ST z ukrytytm paskiem to każdy mysli, że moje strony to aplikacje natywne 🙂 plusy i minusy. Wystarczy pobrać kilka aplikacji ST2 z marketplace np na androida i sami zobaczycie, że to kicha.

    1. Witaj. Dziękuję za komentarz. Częściowo mamy podobną opinię, ale pozwól że pokażę kilka innych argumentów.
      1. Wygenerowanie paczki – prawda, nie jest to łatwe, ale zawsze można w łatwy sposób zrobić sobie pustą aplikację Androidową opartą o Phonegap, i po prostu senchą przetwarzać JS i kopiować do katalogu www w projekcie Androidowym. Podobnie z iOS. Nie jest to automatyczny proces, ale tworzysz taką kontenerową appkę raz i z głowy. Aczkolwiek tak jak Ty, wolałbym, żeby to było prostsze.

      2. Szybkość… Nie taki prosty temat. Na pewno skraca trochę development. Ile? To zależy od konkretnej aplikacji. Jeśli chcesz zrobić appkę na Android i iOS, to na natywna Android + natywna iOS zajmie więcej niż hybryda, chyba że to jakieś kosmicznie skomplikowane appki i potem można zwariować próbująć ogarnąć dziwne przypadki w JS. Android sam demonem prędkości nie jest niestety. Aplikacje w ST działające względnie dobrze na iOS, nie radzą sobie np na Androidzie (np brak sprzętowego wsparcia dla webview w starszych wersjach, mniej wydajny web view, mniej wydajny system, słabszy procesor graficzny). Np kilerem są przezroczystosci użyte w aplikacji. Miałem kiedyś taki przypadek, że po wyłączeniu cieni i przezroczystości przyśpieszenie aplikacji było miażdżące… Z pnktu widzenia iOS appki ST działają OK i będą działać jeszcze lepiej. Sprzętowe wsparcie dla web view, mega wydajna platforma no i nowa konktrolka WKWebView w iOS8 – dająca kolejny boost o jakieś 20% w stosunku do tego co jest teraz. Obie platformy mają co raz lepsze urządzenia, co raz bardziej wydajne. Koszt pracy ludzi nie będzie malał. Cena urządzeń tak. Robiąc duży projekt łatwo policzyć co jest bardziej opłacalne.

      3. Kicha? Nie do końca. Jak masz biznes i Twoi ludzie mają do zrobienia X rzeczy w terenie, to pisząc appke w ST jesteś w stanie pokryć większość urządzeń, co jest dobre jeśli firma postawiła na politykę BYOD (Bring Your Own Device).

      Podsumowując: osobiście zdecydowanie bardziej preferuję natywne aplikacje (świetny UX, pixel perfect UI) ale w pełni rozumiem potrzebę aplikacji hybrydowych 🙂 Mam nadzieję, że nasze komentarze i post pokażą właśnie też tą drugą stronę.

Dodaj komentarz

This site uses Akismet to reduce spam. Learn how your comment data is processed.