Ionic – idealne narzędzie do tworzenia hybrydowych aplikacji mobilnych

1

Dzisiejszy wpis będzie poświęcony narzędziu do tworzenia hybrydowych aplikacji mobilnych – Ionic. Zostanie przedstawiony sposób działania narzędzia i przejdziemy przez cały proces – od instalacji do uruchomienia.

Ionic to rozbudowane narzędzie, które przy pomocy Cordovy umożliwia tworzenie bogatych i w pełni funkcjonalnych aplikacji mobilnych.

Do zbudowania aplikacji w Ionic’u wykorzystujemy technologie webowe – Angular, HTML, CSS. Cordova odpowiedzialna jest za natywną część aplikacji – platformy, wtyczki, webview.

Połączenie tych dwóch technologii daje nam możliwość tworzenia hybrydowych aplikacji mobilnych, czyli połączenie części natywnej z częścią webową.
 Zaletami takiego zastosowania jest bardzo duża uniwersalność naszych aplikacji – pisząc raz, możemy aplikacje uruchamiać na wielu platformach np. iOS, Android, Windows lub jako aplikację webową na serwerze.

1. Instalacja


Przejdziemy najpierw krok po kroku przez proces instalacji środowiska.

a) Node.js


brew install node


b) Cordova


sudo npm install -g cordova


c) Ionic


sudo npm install -g ionic

2. Tworzenie projektu


Aby utworzyć projekt wpisujemy podaną komendę w terminalu.


ionic start {nazwa_projektu} {starter}

starter – to szablon, który zostanie wykorzystany przez framework do stworzenia naszego projektu. Możemy utworzyć pusty projekt wpisując „blank”. Lub skorzystać z szablonu z wbudowanym menu (podając „sidemenu”) czy zakładkami („tabs”).

Przykład:

ionic start myAwesomeApp tabs

Po wykonaniu tej operacji zostaną zainstalowane wszystkie potrzebne zależności.

3. Podział aplikacji


Struktura projektu wygląda następująco:

1

Kod źródłowy naszego programu znajduje się w katalogu src, wyjściowe zbudowane pliki w www, ikona oraz ekran startowy w resources, biblioteki w node_modules, dodatkowe skrypty w hooks, wtyczki z cordovy w plugins oraz środowiska platform w platforms (2 ostatnie katalogi tworzone są podczas wywołania akcji „build” i „run” czyli podczas budowania projektu lub przy ręcznym dodaniu tych składników).

4. Budowanie aplikacji


Aby zbudować projekt, należy wywołać akcję build lub run jeśli chcemy go od razu uruchomić.

ionic cordova run ios/android –prod –release
lub

ionic cordova build ios/android –prod –release

Framework najpierw zbuduje nasze źródła (część webową) do plików wyjściowych, które będą uruchamiane przez konkretny webview, a następnie wykona się proces budowania części natywnej dla iOS (wymagany jest system operacyjny OSX oraz Xcode) lub Android (Wymagana jest platforma JDK oraz Android SDK).

Po wykonaniu tych operacji w katalogu platforms znajdziemy zbudowany projekt.

a) dla iOS’a

1

b) dla Android’a

1

Te pliki posłużą nam do wgrania aplikacji na dane urządzenie.

5. Uruchamianie na urządzeniu

a) iOS

– Otwieramy nasz wcześniej zbudowany projekt *.xcodeproj.
– Wybieramy urządzenie na jakim uruchomimy naszą aplikację (fizyczne urządzenie lub emulator).

1

– Następnie klikamy przycisk „Run” (cmd + r), który powoduje kompilacje projektu i uruchomienie na wybranym urządzeniu.

1

b) Android


– Wpisujemy komendę


ionic cordova run android

Framework przy pomocy Android SDK zbuduje aplikację (plik .apk) oraz zainstaluje ją na wybranym urządzeniu lub emulatorze.

1

Podsumowanie

Jak widzimy Ionic pozwala nam w łatwy i szybki sposób tworzyć aplikacje mobilne. W tym artykule został przedstawiony bardzo prosty przykład wykorzystania narzędzia, nie zmienia to jednak faktu, że dzięki rozbudowanemu ekosystemowi frameworka np. Ionic Cloud, możemy wykorzystać narzędzie do budowania wysoce zaawansowanych aplikacji :)

Praktyczne wykorzystanie Ionic’a możecie sprawdzić w naszej autorskiej aplikacji mobilnej dedykowanej ecommerce.

Android
https://play.google.com/store/apps/details?id=pl.isystems.isklep

iOS
https://itunes.apple.com/us/app/i-sklep/id1169416679

Po więcej informacji na temat działania framework’a odsyłam na stronę Ionic’a :)
http://ionicframework.com/docs/

Autorem tekstu jest Kamil Moroń.

Zobacz również artykuły o podobnej tematyce

B2E, czyli skuteczne wsparcie organizacji pracy
B2E banner

Jak sprawić, by organizacja efektywnie funkcjonowała na współczesnym rynku? Każdy kto prowadzi firmę wie, że kwestia ta potrafi spędzać sen...

Aplikacja mobilna brakującym ogniwem omnichannel?
aplikacja mobilna

W 2018 r. strategia omnichannel wydaje się standardem. Wszystkie liczące się marki posiadające sieć sklepów stacjonarnych połączyły w większym lub...

Czy człowiek może być kolorem? Kapitał ludzki, jako największa wartość w organizacji
ludzie-1

Chcąc prowadzić innowacyjną i ponadczasową firmę należy bacznie obserwować indywidualne predyspozycje pracowników. Nie każdy z nich nadaje się do pracy...

Zobacz więcej wpisów
  • http://oferownik.pl Robert Marketingowiec

    Nie da się być mocnym we wszystkich kanałach komunikacji, trzeba sobie wypracować te które najbardziej się wybijają i się ich trzymać.

  • Marcin

    „Dawno temu skupialiśmy się na ważnych rzeczach, czyli rozwiązywaniu problemów i logice biznesowej. Dzisiaj jesteśmy prawie całkowicie skoncentrowani na abstrakcji i generalizacji.” – i to wszystko wina frameworków? Czy to wina cegieł i zaprawy że murarze krzywo wybudowali mur, czy jednak problemem było nieprofesjonalne podejście fachowców, którzy ubzdryngoleni przyszli do pracy? Nie możemy zrzucać winy na narzędzia, za to że źle tworzymy aplikacje. Powinniśmy raczej starać się dostrzec fakt, że problem leży w nas samych i spróbować go zrozumieć… oraz coś z nim zrobić. I na pewno nie jest metodą na ów problem podejście, że „powinniśmy używać PHP, a nie architektury do budowania aplikacji” – taki tok rozumowania jest idealnym dowodem na to jak wiele osób nie rozumie czym jest architektura. Architektura to nie framework! Posłużę się kolejnym odwołaniem do budownictwa: czy patrząc na kościół pierwsze co widzimy to to, z czego jest on zbudowany czy raczej jakie jest jego przeznaczenie. Albo: czy widząc bramę pierwszą naszą myślą jest „użyli cegieł z Castoramy i wkrętarki boscha” czy raczej „to jest brama – służy do tego by gdzieś wejść lub skądś wyjść”?
    To prawda – we współczesnym programowaniu zapominamy o logice biznesowej, ale nie jest to wina architektury, tylko raczej braku dyscypliny w nas samych – nie interesuje nas to, nas jara głównie fakt że piszemy np. w kotlinie bo to jest teraz modne. „Zrobię to na symfony, zapytania puszczę doctrinem a obiekty będę serializować jms’em” – to nie jest opis architektury, to lista zakupów – jakich narzędzi potrzebuję by zrealizować cel. Szkoda tylko, że przez to cel ląduje na drugim (albo i nawet dziesiątym) miejscu – a celem jest np. zbudowanie aplikacji do przechowywania dokumentów. Ale to nie decyzja twórców bibliotek/frameworków, że cel staje się dla nas mało istotny. To nie Fabien Potencier każe nam całą logikę wrzucać do akcji w kontrolerze, to nie Jonathan Wage podpowiada nam, by nasze biznesowe obiekty bezpośrednio wywoływały doctrine’a! To my, my programiści sami doprowadzamy do tego, że nasze aplikacje przypominają niestrawione resztki pokarmu które codziennie zostawiamy w porcelanowym ekspresie. I póki nie nauczymy się odseparowywać logiki biznesowej od narzędzi to dalej będziemy tworzyć legacy code.
    Co do argumentu, że niektóre z zależności mogą zostać po kilku latach porzucone i nie będą dalej rozwijane… serio? I proponujesz phpti jako alternatywę do twiga albo smarty? Wszystko może zostać po kilku latach porzucone, to do obowiązków programisty należy m.in. nie pozwolić na to, by moduły/komponenty nie były sprzężone z innymi elementami czy zewnętrznymi bibliotekami.
    A co do bogactwa wiedzy i tego co się dzieje pod maską – ogólnie nie powinno się używać narzędzi, których się nie rozumie: jak działają, dlaczego tak działają itp. By potem nie było sytuacji w stylu senior piszący od 5 lat w laravelu nie potrafi odpowiedzieć na rozmowie kwalifikacyjnej na pytanie „Co robi funkcja die()?”…

    TL;DR: nie zgadzam się 😉