Jedną z cech Angulara jest to, że nie jest on powiązany z obiektowym modelem dokumentu (DOM). Angular pozwala na wykorzystanie innych szablonów niż HTML do tworzenia interfejsu. Oznacza to, iż może zostać użyty w innych ekosystemach, które używają JavaScript oraz innych znaczników interfejsu takich jak XML. Jedną z takich platform jest NativeScript - pozwala używać kod Angulara do tworzenia aplikacji iOS oraz Android. Dzięki takiemu połączeniu oba typy aplikacji (natywne i webowe) mogą współdzielić kod do renderowania różnych szablonów.

Jeżeli zastanawiacie się jak osiągnąć zamierzony rezultat, tzn. wyjść poza obasz HTML korzystając z NativeScript spójrzcie poniżej:

Niestety z tym rozwiązaniem nie miałem żadnej styczności. Niezwykle atrakcyjne jednak wydaje się tworzenie aplikacji natywnych przy użyciu połączenia tych technologii. Kiedy już omówimy podstawy Angulara postaram się przygotować poradnik (również z korzyścią dla mnie) jak tworzyć takie aplikacje.

Przeanalizujmy jednak powyższy schemat. Aplikacja kliencka może zostać utworzona w oparciu o architekturę all-in-one lub Klient-Serwer - dodatkowym wymaganiem będzie utworzenie kolejnego projektu, aplikacji NativeScript korzystającej z Angulara w celu zapewnienia natywnej obsługi wyżej wymienionych systemów mobilnych. Szkielet naszej aplikacji możemy przygotować na dwa sposoby – tak jak miało to miejsce w przypadku Angulara. Możemy posłużyć się NativeScript CLI lub aplikacją NativeScript Sidekick.

Proces tworzenia oraz dodawania projektu do Visual Studio (jako aplikacja webowa) narazie pomijamy. Będziemy się skupiać na tym etapie nieco później, kiedy będziemy w stanie tworzyć aplikację w oparciu o Angulara.

Kod źródłowy NativeScript to Angular oraz TypeScript. Taka architektura pozwala nam na wymianę pewnej logiki pomiędzy aplikacją natywną oraz webową. Musimy jednak mieć świadomość działania każdej z tych platform. NativeScript nie korzysta z obiektowego modelu dokumentu – nie możemy zatem używać kodu aplikacji, który ma zależności do DOM. Z drugiej strony widoki napisane przy użycia języka XML nie mogą być użyte w aplikacji przygotowanej w oparciu o Angulara. Najważniejszym jednak punktem jest przygotowanie aplikacji w oparciu o ASP.NET Core API, której kod (logikę biznesową) możemy dzielić pomiędzy poszczególnymi aplikacjami. Możemy również wykorzystać interfejsy, podstawowe obiekty oraz dziedziczenie – to wszystko dlatego, że obie technologie wykorzystują w swojej architekturze TypeScript.

W tym miejsu mogilibyśmy wypisać wszystkie plusy, które dotyczą również architektury Klient-Serwer. Tutaj jednak dodajemy jeszcze współdzielenie kodu. Większość kodu po stronie klienta może zostać współdzielona przez natywne wersje aplikacji mobilnych. Z uwagi na fakt, że cały kod jest napisany przy użyciu technologii webowych (HTML, XML, CSS, TypeScript/JavaScript) programiści aplikacji webowych mają doskonałą możliwość tworzenia aplikacji na dużą skalę, które mogą być częścią ogromnego ekosystemu. Technika ta może zostać również połączona z architekturą all-in-one.

Nie możemy również zapomnieć o tym, że kod dzielimy nie tylko pomiędzy aplikacją webową i natywaną ale również pomiędzy systemami iOS oraz Android.

Możliwość przygotowania jednej aplikacji i używania jej na wielu urządzeniach zawsze była świętnym gralem dla programistów. Zwykle jednak pojawia się dodatkowa złożoność w tak przygotowywanym projekcie. Dodatkowo proces planowania powinien przebiegać całkowicie inaczej – każda z platform powinna oferować podobną funkcjonalność i być równo traktowana. Mimo, iż w naszym przypadku mamy możliwość dzielenia kodu nie dotyczy on interfejsu użytkownika. Niezależnie od tego, że kod TypeScript może obsługiwać logikę aplikacji internetowej oraz natywnej, interfejs użytkownika musi zostać napisany dwukrotnie – raz przy użyciu HTML dla aplikacji webowej, drugi raz w XML dla aplikacji natywnej. Samo dzielenie kodu również nie jest takie oczywiste. Wymagać będzie od nas dodatkowego kopiowania albo utworzenia paczki npm , która będzie współdzielona pomiędzy projektami.

Sam proces tworzenia i tesowania aplikacji mobilnych również może nieść pewne problemy. Wymagana będzie specjalna konfiguracja serwera logiki biznesowej tak, aby urządzenia mobilne i emulatory miały dostęp do naszej lokalnej usługi. W tym przypadku ponownie będziemy musieli przygotować odpowiednią konfigurację CORS, aby różni klienci mieli dostęp do naszego API.

Po serii 4 artykułów udało nam się dotrzeć do końca...

Tak naprawdę to dopiero początek, początek nowego cyklu i połączenia niezwykle popularnych technologii.

My jednak spójrzmy z perspektywy technologii ASP.NET Core. Angular nie jest tutaj jedynym architektonicznym wyborem ale nie ulega wątpliwości, że ma on swoje miejsce w przyszłości rozwoju aplikacji opartych o nasz główny stos technologiczny. Warto, abyśmy nie czuli się przytłoczeni możliwymi wyborami – ten wpis miał na celu pokazać różne drogi, ich plusy oraz minusy. Każdy z omawianych tutaj typów projektów może być dowolnie skalowany. My powinniśmy zacząć od tego w czym mocny jest nasz zespół, jaką wiedzę posiadamy na temat danych technologii a przede wszystkim jakie są oczekiwania i wymagania dotyczące projektu, który tworzymy.