CROSS PLATFORM MOBILE APP DEVELOPMENT ALS NIEUW OLOD BINNEN HOGENT. Sander De Roover. Bachelor in de toegepaste informatica

Transcriptie

1 Faculteit Bedrijf en Organisatie CROSS PLATFORM MOBILE APP DEVELOPMENT ALS NIEUW OLOD BINNEN HOGENT Sander De Roover Bachelorproef voorgedragen tot het bekomen van de graad van Bachelor in de toegepaste informatica Promotor: Leen Vuyge Promotor: Tom Antjon Instelling: / Academiejaar Eerste examenperiode

2 2018, Sander De Roover. Niets uit deze uitgave mag worden verveelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand, of openbaar gemaakt, in enige vorm of op enige wijze, hetzij elektronisch, mechanisch, door fotokopieën, opnamen of enige andere manier, zonder voorafgaande schriftelijke toestemming van de auteur. Het gebruik of de reproductie van bepaalde informatie uit dit werk is enkel toegestaan voor persoonlijk gebruik en mits bronvermelding. Elk gebruik voor commerciële of publicitaire doeleinden is verboden. Deze bachelorproef is gemaakt door Sander De Roover, student aan de Hogeschool Gent, ter voltooiing van Bachelor in de toegepaste informatica. De standpunten die in deze bachelorproef zijn verwoord, zijn louter het persoonlijke standpunt van de individuele auteur en reflecteren niet noodzakelijkerwijs de mening, het officiële standpunt of het beleid van de Hogeschool Gent.

3 Faculteit Bedrijf en Organisatie Cross platform mobile app development als nieuw OLOD binnen HoGent Sander De Roover Scriptie voorgedragen tot het bekomen van de graad van professionele bachelor in de toegepaste informatica Promotor: Leen Vuyge Co-promotor: Tom Antjon Instelling: Academiejaar: Tweede examenperiode

4

5 Faculteit Bedrijf en Organisatie Cross platform mobile app development als nieuw OLOD binnen HoGent Sander De Roover Scriptie voorgedragen tot het bekomen van de graad van professionele bachelor in de toegepaste informatica Promotor: Leen Vuyge Co-promotor: Tom Antjon Instelling: Academiejaar: Tweede examenperiode

6

7 Woord vooraf De keuze om onderzoek te voeren naar cross platform mobile app development was niet evident. Ik kwam pas op het idee toen ik een stageplaats had en besefte dat ik op mijn stage met React Native ging moeten werken. Ik had enige onzekerheid omdat dit iets was waar ik nog niet met in aanraking gekomen was. Ik merkte dat ondanks onze grote hoeveelheid kennis die we door de jaren heen geleerd hadden, dat er nog veel dingen te leren vielen. Ik vond het dus interessant en een goed idee om eens iets te bekijken dat we niet geleerd hadden en om te onderzoeken of dit eventueel iets interessant zou zijn in de opleiding Toegepaste Informatica op de HoGent. Er zijn talloze mensen die ik wil bedanken maar de voornaamste mensen zijn mijn ouders die al jaren hard werken zodat ik een kwaliteitsvolle opleiding kan volgen en de kans krijg om een mooie toekomst op te bouwen. Ik zou graag ook mijn co-promotor bedank Tom Antjon voor alle feedback die ik gekregen heb gedurende mijn bachelorproef. Aan de hand van zijn wekelijkse stand up heeft hij er ook voor gezorgd dat ik elke week met mijn onderzoek bezig was. Natuurlijk wil ik ook mijn promotor Leen Vuyge bedanken voor het ondersteunen en begeleiden van mijn bachelorproef en tevens ook mij stage. Ook wil ik de docenten aan de HoGent bedanken die ik doorheen de jaren heb gehad. Zonder hen was dit allemaal niet mogelijk en zij zijn de bron van alle kennis die over de loop van de afgelope drie jaar heb mogen verwerven. Als laatste wil ik mijn vrienden bedanken die ik heb leren kennen tijdens de opleiding. Op hen kon ik altijd rekenen voor advies, uitleg en allerhande hulp. Zonder deze hierboven vernoemde mensen zou mijn opleiding er compleet anders hebben uitgezien en ik denk dat ik toch wel tevreden en dankbaar mag zijn voor hoe mijn opleiding er heeft mogen uitzien.

8

9 Samenvatting Op HoGent worden een heleboel studenten klaar gestoomd voor de arbeidsmarkt en dit is ook niet anders in de richting Toegepaste Informatica. Hier leren de studenten van alles en sommige studenten leren dan ook hoe mobiele applicaties gemaakt worden. Dit leren ze afhankelijk van het besturingssysteem, ook wel native development, maar is dit wel nodig? Er is namelijk de mogelijkheid om applicaties te maken onafhankelijk van het besturingssysteem en deze heet cross platform development. Dit zou dus veel veranderen voor de student. Maar is dit echter zo ideaal als het klinkt en is dit wel interessant voor de HoGent en zijn studenten. Het is dus interessant voor de HoGent om dit eens onder de loep te nemen. Het is namelijk belangrijk dat hier niet licht over gegaan wordt en dat alle mogelijkheden bekeken worden samen met zijn voor- en nadelen. Daarom werd er in deze bachelorproef onderzocht of dit effectief interessant was en werd eens kort vergeleken wat het verschil is tussen ontwikkelen afhankelijk aan besturingssysteem en onafhankelijk. Dit is gedaan door een extensieve literatuurstudie. Dit werd dan opgevolgd door het opstellen van twee demo applicaties en die zijn elk gemaakt op een andere manier. Op deze manier werd er gewerkt rond cross platform development en kon dit vergeleken worden met native development zoals gezien op HoGent. In deze bachelorproef staat dus beschreven hoe er te werk is gegaan bij het onderzoeken achter deze kwestie. Stap voor stap staat alles beschreven en wordt er afgesloten met een conclusie op de vragen die we ons in het begin stelde. Het resultaat was dat het in sommige gevallen interessanter is om cross platform te werk maar dat dit enkel het geval is bij kleinere applicaties. Cross platform development sluit dus niet de nood uit naar de kennis van native development bij de studenten van HoGent. We concluderen hier dus uit dat het interessant kan zijn voor de HoGent maar niet ter vervanging van de huidige leerwijze namelijk native development. We concluderen dus

10 ook dat het interessant is voor HoGent en eventueel wel opgenomen kan worden. Aan de hand van de grootte van nieuwe leerstof werd er dan afgeleid dat het opstellen van een nieuw keuzevak hieromtrent het interessantst en meest logische zou zijn. Er zijn veel zaken niet onderzocht geweest in deze bachelorproef die dus eventueel nog verder onderzocht zouden kunnen worden. Zo kunnen er nog demo applicaties geschreven worden in andere frameworks. Indien de HoGent cross platform interessant zou vinden en beslist op te nemen als keuzevak of dergelijke en er wordt een framework gekozen dan kan er gedetailleerder onderzocht worden.

11 Inhoudsopgave 1 Inleiding Probleemstelling Onderzoeksvraag Onderzoeksdoelstelling Opzet van deze bachelorproef 16 2 Stand van zaken Basis Native Web Hybrid Wat is cross platfrom? Frameworks

12 2.3 Aparte apps vs. cross platform Daarom cross platform Daarom aparte apps Conclusie Methodologie Voorbereiding Welk hybrid framework? Welk native cross platform framework? Demo applicatie Setup Homepage Navigatie Storage Lijst Form Native features User Interface Conclusie A Onderzoeksvoorstel A.1 Introductie 59 A.2 State-of-the-art 59 A.3 Methodologie 60 A.4 Verwachte resultaten 60

13 A.5 Verwachte conclusies 60 Bibliografie Bibliografie

14

15 Lijst van figuren 2.1 Architecture of a progressive web app (Kubala, 2017) Native, web or hybrid (IBM, 2012) Cross compiler (Furuskog & Wemyss, 2016) Populariteit hybrid frameworks op Github Populariteit hybrid frameworks op Stack Overflow Aantal vacatures voor hybrid developers in Vlaanderen Populariteit native cross platform frameworks op Github Populariteit native cross platform frameworks op Stack Overflow Aantal vacatures voor native cross platform developers in Vlaanderen Ionic asking to integrate cordova when creating application Newly initialized Ionic app in the browser The modify screen in Visual Studio Cross platform options in Xamarin An emulator chosen to run the android project in Xamarin Newly initialized Xamarin app on android Homepage in Ionic

16 12 LIJST VAN FIGUREN 3.14 Create new content page in xamarin Homepage in Xamarin Installed settings plugin in NuGet solution Ionic lifecycle on push and pop events from official Ionic blog Overview page in Ionic Overview page in Xamarin Add page in Ionic Edit page in Ionic Add page in Xamarin Edit page in Xamarin Notification received when leaving homepage Toast received when edited recipe Speech Recognition to add step Notification received when leaving homepage The refresher appears when the view gets dragged down The options appear when swiping a recipe to the left Detail page in Ionic Refresher in Xamarin Context Actions in Xamarin Detail page in Xamarin

17 Lijst van tabellen 2.1 Native specifications

18

19 1. Inleiding Deze bachelorproef heeft de mogelijkheid tot cross platform mobile app development in de HoGent onderzocht. De HoGent heeft verschillende richtingen maar in deze bachelorproef focust zich op Toegepaste Informatica met als afstudeerrichting Mobile. In deze afstudeerrichting leren studenten hoe ze mobiele applicaties kunnen maken. De besturingssystemen waarvoor je de applicatie zijn elk een OLOD. Zo heb je een OLOD voor Android, Ios en Windows. Maar is dit wel Ideaal? 1.1 Probleemstelling De mobile app studenten binnen de HoGent volgen twee van deze mobile opleidingsonderdelen en leren dus hoe een mobiele applicatie kan gemaakt worden voor een bepaald besturingssyteem. Maar is dit wel efficiënt? Er zijn namelijk verschillende manieren om mobiele applicaties te maken voor verschillende besturingssystemen in één keer. Het zou wel eens interessant kunnen zijn voor de HoGent en zijn studenten om te weten welke manieren er juist zijn om dit waar te maken. Dit geldt natuurlijk niet enkel voor de HoGent en kan dus ook interessant zijn voor andere hogescholen. Hogescholen kunnen efficiëntere manieren aanbieden aan hun studenten en zijn hierdoor misschien wel aantrekkelijker voor studenten dan andere hogescholen. Het is ook interessant voor de student want de kennis die hij verwerft tijdens zijn studies zullen hem typeren op de arbeidsmarkt.

20 16 Hoofdstuk 1. Inleiding 1.2 Onderzoeksvraag Deze bachelorproef onderzoekt of het interessant zou zijn voor de HoGent om cross platform mobile app development aan te bieden aan zijn studenten. Er werd gezocht naar het antwoord op verschillende vragen die de HoGent zou kunnen stellen bij het considereren van cross platform als OLOD. Vragen zoals wat is het verschil met mobiele applicaties maken per apparaat/besturingssysteem en cross platform en welke manier is hier het interessantst voor de HoGent? Wat zijn de mogelijkheden om cross platform te gaan werken en welke is hier het interessantst? Wat zijn hybrid applicaties? 1.3 Onderzoeksdoelstelling Door het uitvoeren van dit onderzoek hebben we een duidelijk beeld kunnen creëren voor de HoGent in verband met cross platform mobile app development. Er werd een resultaat en een conclusie gevormd die alle voordelen en nadelen bevat in verband met cross platform aanbieden. Zij kunnen nu de verzamelde informatie eventueel verwerken en hopelijk hebben zij hier ook iets aan. 1.4 Opzet van deze bachelorproef De rest van deze bachelorproef is als volgt opgebouwd: In Hoofdstuk 2 wordt er een uitgebreide literatuurstudie gedaan in verband met de materie. Dit is om een beeld te schetsen in verband met de huidige stand van zaken op vlak van cross platform werken. In Hoofdstuk 3 staat de aanpak van het onderzoek besproken. Er wordt duidelijk in toegelicht hoe alle informatie verzameld is. Dit bevat ook de motivatie achter elk deel van het onderzoek en waarom dit deel juist van belang was en wat de meerwaarde was. In Hoofdstuk 4, tenslotte, staat er wat er uit de verzamelde informatie is gebleken. Dit hoofdstuk bevat alle antwoorden op de hierboven gestelde onderzoeksvragen. Dit is het eindpunt waarin alle informatie verzameld staat. Dit deel is de essentie van het hele onderzoek.

21 2. Stand van zaken Om compleet te begrijpen wat de mogelijkheden zijn en eventuele oplossingen voor het probleem uitgelegd in vorig hoofdstuk was er een literatuurstudie nodig. Het bekijken van de stand van zaken was zeer belangrijk om thuis te zijn in het milieu van cross platform mobile app development. Er kon al een algemene mening gevormd worden door het bekijken van reeds uitgevoerde studies. Door de conclusies uit deze studies te gaan bekijken werd er al een sceptisch antwoord gevormd op de vragen vanuit het vorige hoofdstuk. De antwoorden kwamen natuurlijk niet perfect overeen met de vragen gesteld in vorig hoofdstuk. Zo werd er geen rekening gehouden met de eisen en noden van de HoGent in enig voorgaand onderzoek. De verzamelde kennis uit dit hoofdstuk werd extensief gebruikt in het volgend hoofdstuk. Zo werd er zeer veel rekening gehouden in het volgende hoofdstuk met de verzamelde kennis uit dit hoofdstuk om te bepalen welke technologieën er gebruikt gingen worden om de twee demo applicaties te maken. 2.1 Basis Er zijn drie manieren om een mobiele applicatie te maken namelijk native, hybrid of web. Deze hebben allemaal hun voordelen en nadelen en kunnen met elkaar vergeleken worden. Maar eerst was het belangrijk te snappen wat deze drie manieren juist inhielden Native Bij native mobile app development wordt er geprogrammeerd specifiek voor een bepaald platform. Zo leren ze op HoGent een applicatie te maken specifiek voor Android devices

22 18 Hoofdstuk 2. Stand van zaken of specifiek voor ios devices. Bij native development kan ook enkel en alleen de native programmeertaal gebruikt worden van dat besturingssysteem. Apple ios Android Languages Swift Java Tools Xcode Android SDK Packaging format.app.apk App stores Apple App Store Google Play Tabel 2.1: Native specifications Dit geeft verschillende voor- en nadelen wanneer men een applicatie wilt maken voor 2 verschillende besturingssystemen (Brigance, 2017). Voordelen: Meer features te gebruiken Controle over alles Makkelijker om unieke UI s toe te passen Minder ongekende zaken voor developers Snellere code, mooiere UI... Nadelen: Gemaakt in verschillende tools Dubbele code Het gebruik van incompatibele programmeertalen... Het was duidelijk te zien dat er meer voordelen waren dan nadelen. Het was dan ook logisch waarom de HoGent voor native applicaties kiest. Voordelen zoals minder ongekende zaken voor developers is ook handig voor hen. Hoe meer documentatie hoe makkelijker voor de studenten bij nodig opzoekingen maar dit geldt natuurlijk ook voor de docenten Web Web apps zijn applicaties die bezocht kunnen worden via een web browser. Web apps worden geschreven in webtechnologieën zoals HTML, CSS en Javascript. Omdat ze via web browser bezocht kunnen worden zijn alle webapplicaties cross platform. Enkele bekende browser die voorkomen op zowel ios als Android devices zijn Safari, Google Chrome, Mozilla Firefox enzovoort. Webapplicaties kunnen heel uiteenlopend zijn en kunnen gaan van een website voor een lokale bende hobbyisten tot een zeer specifieke website die de gebruiker een gevoel geeft een app te gebruiken. Dit laatste heet een progressive web app. Progressive Web App Een progressive web app is een web app die de gebruiker het gevoel geeft alsof het een native app is. Dit doet het door enkele features te gebruiken zoals notificaties. Een

23 2.1 Basis 19 progressive web app kan geïnstalleerd worden op een device zonder het gebruik van een app store. Deze werken aan de hand van een service worker. Dit is een script dat in de achtergrond werkt en geen gebruikersinteractie nodig heeft. In Figuur 2.1 is te zien hoe elk verzoek vanuit de webapplicatie eerst langs de service worker moet gaan indien er een service worker is. Dit is het verschil tussen een gewone web app en een progressive web app qua opbouw. Figuur 2.1: Architecture of a progressive web app (Kubala, 2017) Voor- en Nadelen Web applicaties bieden veel mogelijkheden maar hebben ook hun beperkingen. Grote voordelen zijn dat het cross platform is en dat er geen updates vereist zijn. Dit compenseert dan weer de nadelen zoals het beperkt gebruik van features. In Michaels (2016) zetten ze nog eens duidelijk onderstaande voor- en nadelen op een rijtje. Voordelen: Altijd Up-To-Date Cross platform Lage kosten Makkelijk onderhoudbaar Volledige vrijheid... Nadelen: Minder features te gebruiken Minder grafische mogelijkheden... Web apps in dit onderzoek? Omdat web apps vaak niet een native ervaring geven bij het gebruiken werd er besloten om deze mogelijkheid tot cross platform mobile app development niet verder te onderzoeken.

24 20 Hoofdstuk 2. Stand van zaken Hybrid Hybrid mobile app development is een manier van ontwikkelen dat tussen native en web ligt. Hier zijn bepaalde componenten gedeeld maar de applicatie zelf is native. Dit wordt vaak gedaan door het gebruik van webviews. Dit is een webapplicatie die gemaakt is in HTML en Javascript en dus cross platform is. Deze webapplicatie wordt dan geëmbed in de native applicatie en zij kunnen dan met elkaar communiceren. In Figuur 2.2 worden de opbouw van zowel native, web als hybrid apps getoond. Daar valt duidelijk te zien dat hybrid een combinatie van beide is. Het zijn herbruikbare componenten geschreven in webcode en weergegeven in webviews. Deze webview kan dan communiceren met het native gedeelte van de applicatie. Figuur 2.2: Native, web or hybrid (IBM, 2012) Hybrid apps zjin dus een duidelijke optie om cross platform te werken. U schrijft namelijk herbruikbare componenten die overal gebruikt kunnen worden. Enkel het native gedeelte is niet herbruikbaar en moet dus apart geschreven worden voor elk besturingssysteem dat de applicatie ondersteunt. In Gopisetty (2012) worden verschillende voor-en nadelen bekeken in verband met hybrid development. Voordelen: één basiscode geschreven in webcode Veel features te gebruiken Verkrijgbaar in app store Cross platform... Nadelen: Afhankelijk aan browser Minder grafische mogelijkheden...

25 2.2 Wat is cross platfrom? Wat is cross platfrom? In voorgaand onderzoek wordt er vaak de term cross platform aangehaald. Dit is ook één van de sleutelwoorden waar dit onderzoek over gaat. Het was dus niet onbelangrijk om eens te kijken wat cross platform development nu juist inhoudt. Cross platform development is het ontwikkelen van een applicatie die werkt op meerdere platforms of besturingssystemen. Zo moet een applicatie niet meerdere keren geschreven worden in native taal. Cross platform leeft onder de leuze Write once, Run anywhere. Dit slaat op het feit dat de applicatie maar eenmaal wordt geschreven en dat achteraf de applicatie werkt op alle mogelijke platformen. Hierboven zijn de drie manieren uitgelegd waarop men een applicatie kan maken. In dit onderzoek, zoals reeds vermeld, was er niet gekeken naar webapplicaties. Er is enkel onderzocht geweest naar cross platform development in hybrid en native. Dit developen gebeurt in bepaalde frameworks en op bepaalde manieren. Zo kan er gewerkt worden met een hybrid framework die dus een hybrid applicatie schrijft. Er zijn echter ook frameworks die native beschouwt kunnen worden. Zij kunnen op verschillende manieren dan een cross platform applicatie maken. Zo kan het zijn dat de componenten gerenderd worden naar native component of kan een cross compiler gebruikt worden. Figuur 2.3: Cross compiler (Furuskog & Wemyss, 2016) In Figuur 2.3 ziet u hoe zo n cross compiler te werk gaat. Er is één basiscode die in de cross compiler gaat en daar wordt alles gecompileerd voor de nodige platformen. Het resultaat zijn meerdere applicaties die elk gecompileerd zijn voor een bepaald platform. Voordelen: één basiscode geschreven in webcode Veel features te gebruiken Verkrijgbaar in app store Cross platform... Nadelen: Afhankelijk aan browser Minder grafische mogelijkheden...

26 22 Hoofdstuk 2. Stand van zaken Frameworks Zoals hierboven al vermeld wordt er een bepaald framework gebruikt om daarin een applicatie te schrijven. Er zijn verschillende frameworks die cross platform applicaties maken. Hieronder worden enkele frameworks opgehaald die eerder populair zijn en vaak gebruikt worden. Er wordt kort uitgelegd hoe deze werken en wat enkele voor- en nadelen zijn. Hybrid frameworks Hybrid frameworks gaan hybrid applicaties maken die werken op alle besturingssystemen. Enkele voorbeelden van zo n framework zijn PhoneGap, Framework 7, Ionic enzovoort. PhoneGap is een gratis open source framework van Adobe. In PhoneGap wordt de gekende webtechnologieën namelijk HTML, CSS en Javascript gebruikt. Er kan gebruik gemaakt worden van zeer veel plugins en heeft veel features. Nadeel is dat het gratis is zolang u maar één app maakt en niet groter dan 50MB, anders moet men een maandelijks bedrag betalen. Framework7 is net als Phonegapp gratis en open source en gebruikt dezelfde webtechnologieën. Framework7 is zeer gebruiksvriendelijk naar developers toe en heeft duidelijke documentatie en dat mag ook wel want de online community rondom Framework7 is eerder klein. Toch is het enige echte nadeel is dat het enkel ios en Android ondersteunt als mogelijk platform. Ionic is ook gratis en open source maar gebruikt in tegenstelling tot Phonegap en Framework7, AngularJS in plaats van Javascript. Er zijn veel voordelen zoals hopen aan documentatie en veel plugins. Waar Ionic wel niet voor geschikt is zijn grafisch zwaardere applicatie want dit kan Ionic niet goed aan. Native frameworks Native frameworks gaan native applicaties maken die werken op alle besturingssystemen. Enkele voorbeelden van zo n framework zijn React Native, Xamarin, Titanium, Nativescript enzovoort React Native is een gratis, open source framework ontwikkeld door Facebook. Het wordt geschreven in Javascript en gebruikt hetzelfde design als hun Javascript library, React. Voordelen zijn dat het snelle applicaties levert en dat bij wijzigingen er niet opnieuw gecompileerd moet worden. Nadelen zijn dat je afhankelijk bent aan Facebook en voor sommige stukken code nog altijd native stukken code moet schrijven. Appcelerator Titanium of kort gezegd Titanium is een gratis, open source framework dat gebruikt maakt van Javascript. Een voordeel bij titanium is dat de developers perfect applicaties kunnen maken zonder enige kennis van de native taal. Nadelen zijn dat het een eerder complex framework is en dat het maken van complexere applicaties niet goed ondersteund wordt door Titanium. Xamarin is een gratis, open source framework. Ze gebruiken één basiscode en die is

27 2.3 Aparte apps vs. cross platform 23 geschreven in C#. Het grootste voordeel van Xamarin is dat het alle features heeft die een native app ook heeft. Dit heeft als gevolg wel dat Xamarin applicaties groter zijn en hierdoor kan het dus ook de zwaardere applicaties niet aan. Nativescript is een gratis, open source framework. Al direct een voordeel is het feit dat nativescript zowel AngularJS, Typescript als Javascript ondersteunt. Een nadeel is dan weer dat er nog maar een gelimiteerd aantal componenten zijn. Er zijn dus bepaalde zaken die nog niet gemaakt kunnen worden met Nativescript. 2.3 Aparte apps vs. cross platform Er is al duidelijk uitgelegd wat de verschillende manieren zijn om applicaties te maken. Tot nu toe wordt er op de HoGent geleerd hoe men een web applicatie kan maken en hoe men native apps kan maken. Dit is zeer belangrijke kennis omdat dit de bekendste en puurste vormen van mobile app development zijn. Maar is dit genoeg? Er is ook getoond in voorgaande literatuurstudie dat er nog andere manieren zijn van app ontwikkeling. De HoGent vertelt zijn studenten niks in verband met hybrid apps of wat deze juist zijn. Het grootste voordeel van hybrid applicaties zijn dat ze cross platform gebruikt kunnen worden. Dit is iets dat ontbreekt binnen de HoGent of is hier bewust voor gekozen? Laten we eens cross platform en native naast elkaar zetten en kijken of het interessant zou kunnen zijn om cross platform te werken. Bij zowel de uitleg in verband met native app ontwikkeling als in de uitleg over cross platform ontwikkeling, worden de voor- en nadelen opgesomd. Door deze naast elkaar te leggen is het duidelijk wat voor developers het interessantst zou kunnen zijn Daarom cross platform Zo is het duidelijk en logisch dat het aantal code een groot voordeel is voor cross platform development. Een developer moet zijn code slechts één maal schrijven en dat bespaart een boel werk. Een developer kan dus meer projecten afwerken en sneller werken in het algemeen indien deze op een cross platform manier te werk gaat. Nog een nadeel bij native dat dan weer in het voordeel werkt van cross platform is het gebruik van tools. Omdat men bij native ontwikkeling meerdere verschillende talen gebruikt zal de developer ook meerdere verschillende tools moeten gebruiken. Er wordt dus een grotere kennis vereist want tools zijn vaak zeer uiteenlopend. Bij cross platform kan alle code geschreven worden in één tool. Qua kennis is cross platform veel makkelijker voor een developer. Soms maar niet altijd is er voor het maken van een cross platform app zelf geen kennis nodig van beide native programmeertalen Zo kan een gebruiker dus een app maken voor meerdere besturingssystemen terwijl hij maar één taal kent. Bij native zijn meerdere talen nodig en wordt er meer kennis verwacht.

28 24 Hoofdstuk 2. Stand van zaken Daarom aparte apps Wat native dan weer in zijn voordeel heeft is dat het veel meer toegang heeft en mogelijkheden. Zo kan ik bij native alle features gebruiken. Dit kan zeer soms ook bij een cross platfrom framework zoals Xamarin maar niet bij alle. Hierdoor kunnen we dus met native te werken veel meer dingen waarmaken. We kunnen complexere applicaties gaan maken die op een niveau zijn waar we met cross platform niet geraken. Ook op visueel vlak heeft native development een voordeel want hier zijn ook veel meer mogelijk. het is makkelijker om de user interface zo uniek en mooi mogelijk te maken. De gebruikers hebben bij native ook nog altijd 100% een native gevoel wat de meeste mensen toch verwachten. Sommige cross platform applicaties focussen zich soms meer op één besturingssysteem dan het andere zoals Framework7 dat visueel beter aansluit bij ios. Hierdoor kan soms op bepaalde besturingssystemen het native gevoel niet optimaal zijn Conclusie Er is geen overduidelijke winnaar of verliezer. Beide manieren van ontwikkelen heeft zijn voor- en nadelen. Wat juist te gebruiken hangt eerder af van wat ontwikkeld dient te worden. Zo zullen complexe applicaties die zeer groot en zwaar zijn beter ontwikkeld worden door een native developer omdat deze meer complexere zaken kan verrichten in de native talen. Maar wanneer het de bedoeling is om een kleinere applicatie te ontwikkelen die zo snel mogelijk gereleased dient te worden en geen zotte dingen moet kunnen, is cross platform eventueel het interessantst. Dus het is wellicht geen goed idee of slimme zet van de HoGent om cross platform voor te stellen in plaats van native apps. Maar wat wel interessant zou kunnen zijn om ze beide aan te bieden aan hun studenten. Zo zijn zij extra voorbereid voor de professionele wereld en hebben ze nog meer bagage. Wat nu juist de mogelijkheden zijn en wat interessant zou zijn voor de HoGent binnen het aspect van cross platform wordt in volgend hoofdstuk ruim uitgelegd. Daar werden de frameworks die we reeds besproken hebben en welke het interessantst zouden zijn voor de HoGent en zijn studenten bekeken.

29 3. Methodologie In vorig hoofdstuk werd aangetoond op welke verschillende manieren een applicatie gemaakt kan worden. De studenten bij de HoGent hebben al ervaring met zowel native development als web development. Toch werd er ook gesproken over hybrid development en cross platform development in vorig hoofdstuk. Dit zijn manieren die onbekend zijn voor de HoGent student. Het bekijken welk framework eventueel interessant zou zijn voor de HoGent student was dus zeer belangrijk. Bijna even belangrijk als het grootste deel van dit hoofdstuk namelijk de demo applicatie. Hier werden twee voorbeeld applicaties gemaakt die de werking tonen van een framework. Het ene framework is puur hybrid terwijl het andere native is maar toch cross platform ondersteund. 3.1 Voorbereiding Om te bepalen in welk framework de demo applicatie werd gemaakt werd er rekening gehouden met twee delen. Het eerste deel was technisch. Er werd rekening gehouden met wat de frameworks juist konden op technisch vlak. Waren er veel plugins ter beschikking? Was het in een taal die de studenten van de HoGent reeds kenden? Dit was belangrijk omdat het onderzoek toch specifiek rond de HoGent draaide. Langs de andere kant werd er ook veel rekening gehouden met de populariteit van het framework. Dit woog misschien zelf het zwaarst door in de eindbeslissing. De populariteit van frameworks op bepaalde netwerken zoals Stack Overflow en Github zijn zeer belangrijk voor studenten. Bij enige twijfel in verband met leerstof is dit samen met de docent de grootste bron aan antwoorden. Ook werd de populariteit op de werkvloer bekeken. De studenten worden opgeleid om kwalitatief sterk te staan op de arbeidsmarkt. Dit zijn ze niet indien ze leren werken met een framework dat amper wordt gebruikt in de bedrijfswereld. Als laatste deel werden

30 26 Hoofdstuk 3. Methodologie de twee aspecten van informatie gecombineerd en werd er op deze manier een knoop doorgehakt welk framework het interessantst leek voor de HoGent student Welk hybrid framework? Bij de hybrid frameworks werden de frameworks vergeleken die reeds vermeld waren in Dit waren PhoneGap, Framework7 en Ionic. De technische informatie die gebruikt werd komt dan ook rechtstreeks uit Technisch Op technisch vlak waren de frameworks zeer gelijkaardig. Ze gebruikten allen dezelfde technologieën behalve Ionic die AngularJS gebruikt in plaats van Javascript. Dit is echter geen probleem aangezien de HoGent studenten bekend zijn met AngularJS. Op vlak van beschikbare plugins is het wel opvallend dat Framework7 onderdoet voor Ionic en PhoneGap. Deze twee frameworks (Ionic en PhoneGap) zijn technisch dus aan elkaar gewaagd. Toch hebben ze allebei nog één verschillend nadeel en hangt de technische keuze dus af van de ernst van dit nadeel. Bij PhoneGap is dat simpelweg dat er een limiet staat op de grootte van uw applicatie. Dit mag namelijk niet groter zijn dan 50MB. Bij Ionic is het nadeel dat het grafisch zware applicaties niet aankan. Populariteit In verband met populariteit werd er rekening gehouden met drie verschillende platformen. Er werd gekeken naar de vacatures op de VDAB over heel Vlaanderen, de stars op de Github repository en het aantal vragen op Stack Overflow met een tag identiek aan de naam van het framework. Alle data werd verzameld op 1 mei 2018 en is op moment van lezen wellicht al veranderd. Github Toen er naar de Github repositories werd gekeken van de verschillende hybrid frameworks viel direct iets op. Ionic had namelijk meer stars gekregen dan de andere twee frameworks tezamen Framework7 deed het ook niet slecht met zo n stars. Enkel en alleen PhoneGape stelde teleur met maar een magere stars. De populariteit op Github is dus zonder twijfel vooral in het voordeel van Ionic met zijn stars.

31 3.1 Voorbereiding 27 Figuur 3.1: Populariteit hybrid frameworks op Github Stack Overflow Bij het kijken naar de vragen op Stack Overflow werd makkelijk geconcludeerd dat ook hier Ionic de winnaar was. Er waren namelijk zo n vragen op Stack Overflow met Ionic als tag. Bij Github lag het resultaat van Framework7 nog boven PhoneGap maar hier is dit niet het geval met een teleurstellende 580 vragen. PhoneGap was dan populairder dan Framework7 op Stack Overflow maar het had nog altijd een gigantisch verschil met Ionic. Figuur 3.2: Populariteit hybrid frameworks op Stack Overflow

32 28 Hoofdstuk 3. Methodologie Vacatures Bij de vacatures binnen Vlaanderen voor developers in een bepaald framework was Ionic nogmaals het sterkst. Er waren namelijk 18 vacatures voor Ionic developers. Dit was veel ten opzichte van de nul vacatures voor Framework7. In het algemeen valt op dat er zeer weinig jobaanbiedingen zijn voor developers die in een hybrid framework kunnen ontwikkelen. Het feit van zo n laag aantal vacatures kon aantonen dat hybrid development niet zo populair is bij de Vlaamse ondernemingen. Figuur 3.3: Aantal vacatures voor hybrid developers in Vlaanderen Conclusie Nu zowel de technische aspecten als de populariteit van de frameworks is bekeken was het tijd voor een beslissing. Op technisch en populair vlak is Framework7 altijd de ultieme verliezer geweest. Dit was dus redelijk snel geen optie meer. Dan restte er nog enkel Ionic en PhoneGap. Deze waren technisch zeer gewaagd aan mekaar. Daarom was de beslissing gemaakt op basis van de populariteit, die zonder enige twijfel was gewonnen door Ionic. De conclusie was dus dat de demo applicatie in een hybrid framework in Ionic gemaakt ging worden Welk native cross platform framework? Bij de native cross platform frameworks werden de frameworks vergeleken die reeds vermeld waren in Dit waren React Native, Appcelerator Titanium, Xamarin en Nativescript. De technische informatie die gebruikt werd komt dan ook rechtstreeks uit

33 3.1 Voorbereiding 29 Technisch Als we de technische aspecten gaan bekijken van de hierboven vernoemde frameworks dan zien we dat de basis gelijkaardig is. Elk framework heeft zijn eigen voordelen en nadelen. Er werd gekeken aan de hand van hun nadelen welke het gebruiksvriendelijkst is en welke geschikt zou zijn voor de HoGent studenten. Zo viel het op dat Appcelerator Titanium een eerder complex framework is en dat nadeel woog zwaarder door dan het voordeel dat er geen native taal gekend moest zijn. De HoGent studenten kennen namelijk al verschillende talen dus dit voordeel had geen invloed op hen. Ook Nativescript had een eerder groot nadeel. Omdat dit een relatief nieuw framework was waren nog niet alle mogelijkheden geïmplementeerd in het framework. De twee overblijvende frameworks waren React Native en Xamarin. Bij beide frameworks waren hun nadelen niet zo ernstig en werd er dus eens naar de voordelen gekeken. Daar viel op dat Xamarin veel aantrekkelijker was omdat dit framework gebruik kan maken van alle features waarvan een native applicatie ook gebruik van kan maken. Populariteit In verband met populariteit werd er rekening gehouden met drie verschillende platformen. Er werd gekeken naar de vacatures op VDAB over heel Vlaanderen, de stars op de Github repository en het aantal vragen op Stack Overflow met een tag identiek aan de naam van het framework. Alle data werd verzameld op 1 mei 2018 en is op moment van lezen wellicht al veranderd. Github Toen de frameworks werden opgezocht op Github werd het al snel duidelijk wie de meeste stars had. Dit was React Native met zo n stars. De andere frameworks konden hier zelf niet aan tippen. Het framework met de tweede meeste aantal stars was Nativescript met zo n stars. Dit kwam dus zelf nog niet in de buurt van React Native, laat maar staan dat de andere twee frameworks dit wel deden.

34 30 Hoofdstuk 3. Methodologie Figuur 3.4: Populariteit native cross platform frameworks op Github Stack Overflow Bij de resultaten op Stack Overflow was het dan wel wat spannender. Hier kreeg React Native namelijk concurrentie van Xamarin. React Native moest zelf kopje onder doen voor Xamarin. Stack Overflow had namelijk vragen in verband met Xamarin en maar in verband met React Native. De overige twee frameworks deden het net iets minder goed en konden niet tippen aan de superioriteit van React Native en Xamarin. Figuur 3.5: Populariteit native cross platform frameworks op Stack Overflow

35 3.2 Demo applicatie 31 Vacatures Op vlak van vacatures is het ongeveer hetzelfde als bij Stack Overflow. Hier gaat het dus ook tussen React Native en Xamarin. Ook hier overheerst uiteindelijk Xamarin met zo n 48 vacatures ten opzichte van de 33 vacatures van React Native. Het valt dus ook direct op dat er veel meer vacatures zijn voor native cross platform development dan voor hybrid development. Figuur 3.6: Aantal vacatures voor native cross platform developers in Vlaanderen Conclusie De keuze maken voor het native cross platform framework was veel moeilijker dan voor het hybrid framework. Hier hadden we namelijk een gelijke oppermacht tussen React Native en Xamarin. Op vlak van populariteit is Xamarin in twee van de drie gevallen net iets beter maar bij één op de drie is React Native wel veel populairder. Op technisch vlak gaat het ook ongeveer gelijk op. Toch werd er voor Xamarin beslist omdat het technisch voordeel in verband met de features te aantrekkelijk was om af te slaan. De conclusie was dus dat de demo applicatie in een native cross platform framework in Xamarin ging gemaakt worden. 3.2 Demo applicatie Zoals gezien in & wordt de demo applicatie gemaakt in Ionic & Xamarin. Maar wat houdt deze demo applicatie nu juist in? De demo applicatie is een voorbeeld applicatie waarin alle basiscomponenten zitten. Dit was dus eerder geen geavanceerde applicatie maar een basis. De applicatie bestaat dus niet uit een prachtig grafisch ontwerp en nieuwe complexe features. Er werd gewoon voor gezorgd dat de functionaliteit correct zat en overeenkwam met iets dat een student zou kunnen afleveren na één semester te werken in dit framework. Er zijn dus vier applicaties als je het correct bekijkt. Er is één applicatie

36 32 Hoofdstuk 3. Methodologie voor Android gemaakt in Ionic, één voor ios in Ionic, één voor Android in Xamarin en één in ios in Xamarin. Wat dat deze applicatie praktisch is? De applicatie is een soort van receptenboekje. Als de applicatie geopend wordt dan zie je de eerste keer een welkom scherm en anders een overzicht van al uw recepten. Je kan bestaande recepten verwijderen en bewerken. Je kan ook nieuwe recepten toevoegen aan de hand van een formulier Setup Het maken van de applicatie begon met het creëren van het project. Dit was zeer uiteenlopend bij beide frameworks. Ionic Bij Ionic werd Visual Studio Code gebruikt als Editor. Dit was handig want studenten van de HoGent hebben deze editor normaal gezien reeds door webapplicaties 5. Om te beginnen werd Ionic geïnstalleerd en dit gebeurde met het commando: 1 npm install - g ionic@ latest cordova Zoals je kan zien werd niet enkel Ionic geïnstalleerd maar ook cordova. Dit is de native container zoals in 2.2. Dit gaat dus rondom uw webcode en zorgt ervoor dat alles crossplatform werkt. Nadat Ionic geïnstalleerd is kan je het project aanmaken. Dit kan gedaan worden met het commando: 1 $ ionic start $appname $template Hier is $appname de naam van de applicatie. Dit wordt gevolgd door een template. Dit geeft mogelijkheden tot veel mooie user interfaces zonder al te veel werk. In onze demo applicatie werd gekozen voor geen template. Dus werd er blank getypt op de plaats van de template. Figuur 3.7: Ionic asking to integrate cordova when creating application Tijdens het aanmaken gaat Ionic ook vragen of het de applicatie moet wrappen met cordova. Het antwoord hierop is dus ja, zodat onze applicatie cross platform werkt. De laatste vraag is in verband met Ionic Pro SDK. Dit was echter niet nodig dus hier mag nee op geantwoord worden.

37 3.2 Demo applicatie 33 Bij het openen van het aangemaakt project is te zien dat er een hele boel bestanden en mappen aangemaakt zijn. Dit ziet er op het eerste zicht zeer onoverzichtelijk uit. Toch mag dit er niet onbekend uitzien voor een HoGent student. Het grootste deel van het project is namelijk een Angular 4 project dat reeds gezien is in webapplicaties 5. Zaken zoals de app component in de src is dus niks onbekend voor de HoGent student. Nu het volledige project is aangemaakt kan je bekijken hoe de applicatie er juist uitziet. De makkelijkste manier om dit te doen is door naar de locatie te gaan van het project en daar volgende commando te runnen. 1 $ ionic serve Dit gaat uw applicatie runnen in uw browser. We zien een soort van hello world scherm. Dit is echter nog geen applicatie maar we krijgen al een preview hoe het er gaat uitzien. Vanaf dit punt kon de applicatie echt gemaakt worden. Er zijn echter nog andere commands die ons de applicatie op een andere manier kunnen doen testen. Zo kunnen we ook de applicatie gaan testen in een emulator of op een real device. Om het te testen in een emulator moet we eerst het project builden en dan pas kunnen we dit runnen. Volgende commands worden hiervoor gebruikt. De $platform moet dan veranderd worden naar het gewenst platform zoals ios of Android. 1 $ ionic cordova build $platform 2 $ ionic cordova emulate $platform Je kan ook testen op een real device. Dit is echter wel moeilijker voor ios want om dit te doen moet je Apple Developer zijn en wanneer uw device onder ios9 ligt moet je zelf betalen hiervoor. Bij Android gaat het wel makkelijk want daar is enkel het volgende commando nodig terwijl een device is verbonden via usb en usb debugging aan staat op dit device. 1 $ ionic cordova run android Je kan bijna alles testen op de browser maar natuurlijk kunnen de native features niet goed getest worden in de browser. Een gebruiker kan wel de native plugins mocken zodat de app niet crasht in de browser. Toch wordt aangeraden om native features te testen op een real device of emulator. Hier komt dan het nadeel dat dit platform gebonden is. Je kan dus enkel een ios build testen vanop een Mac. Dit geeft het nadeel dat twee computers toch nog aangeraden worden.

38 34 Hoofdstuk 3. Methodologie Figuur 3.8: Newly initialized Ionic app in the browser Xamarin Voor het maken van een Xamarin applicatie kan men simpel weg Visual Studio gebruiken. Dit is een editor die de studenten reeds kennen door webapplicaties uit het tweede jaar. Onze demo applicatie werd gemaakt in de 2017 editie van Visual Studio. Eerst moet men Xamarin toevoegen aan Visual Studio, dit kan door Xamarin te installeren op het moment dat Visual Studio wordt geïnstalleerd. Xamarin kan ook achteraf worden toegevoegd door de Visual Studio installer te openen en daar de geïnstalleerde versie van Visual Studio aan te passen en Xamarin aan te duiden. Figuur 3.9: The modify screen in Visual Studio Wanneer Xamarin geïnstalleerd is kan de developer beginnen met het maken van een applicatie. Om dat te doen maakt hij een nieuw project en selecteert Xamarin Forms uit

39 3.2 Demo applicatie 35 de lijst van Visual C# projecten. Bij het volgende venster kiest de developer de gewenste platformen, het type van beginnersapp en kiest hij.net Standaard als sharing option. In het geval van de demo applicatie werd er gekozen voor ios en Android en werd er begonnen van een blank app. Figuur 3.10: Cross platform options in Xamarin Als alle informatie is doorgegeven kan er een applicatie gemaakt worden door Xamarin. Dit resulteert in meerdere projecten. Zo krijgt de developer één algemeen project en dan nog één project per gekozen platform. Om het aangemaakte project te testen zijn hiervoor meerdere mogelijkheden. Er wordt namelijk eerst gekozen welk platform er getest wordt. Ook hier is het zo dat om een ios build te testen een Mac nodig is. Het probleem dat twee computers nodig zijn is dus nog niet geweken. Het voordeel is wel bij Xamarin dat het testen van ios wel op Windows gaat maar hiervoor moet mijn vanuit de Windows pc dan wel remotely ingelogd worden op de Mac. Als het platform gekozen is kan men bovenaan in de toolbar van Visual Studio dat project kiezen. Indien dit gedaan is kan men naast hun project een lijst zien met geïnstalleerde emulators en real devices. Men kiest hier het gewenste device en klikt op de start knop. Figuur 3.11: An emulator chosen to run the android project in Xamarin Wanneer u dan voor de eerste maal een project runt ziet u een soort van hello world van Xamarin. Dit is één regel gecentreerde tekst die zegt Welcome to Xamarin Forms. U ziet een voorbeeld hiervan in onderstaande afbeelding.

40 36 Hoofdstuk 3. Methodologie Figuur 3.12: Newly initialized Xamarin app on android Homepage Onze demo applcatie bestaat uit een Homepage. Hier staat uitgelegd wat de applicatie juist inhoudt. Dit was om te kijken hoe er een standaard pagina gemaakt kon worden met gewoon wat uitleg in. Dit is dus een zo eenvoudig mogelijke pagina. Ionic In het gegenereerd project aangemaakt in zat al een Homepage. Deze was dus eerst verwijderd zodat gekeken kon worden hoe we zo n eenvoudige pagina maken. Een klein verschil dat direct opviel is dat er geen componenten zijn zoals bij Angular 4. Dit was omdat Ionic niet met component werkt maar met pages. De functionaliteit hierachter is echter identiek. Het maken van de Homepage begon met het aanmaken van de page en dat gebeurt aan de hand van het commando: 1 $ ionic g page $pagename Op de plaats van $pagename komt de naam van uw page. Dat was in dit geval home. Als onze pagina aangemaakt is moet deze worden toegevoegd aan de app.module. Bij Angular 4 gebeurt dit vanzelf. Jammer genoeg is dit niet het geval bij Ionic en moet dit handmatig gebeuren. Omdat dit onze Homepage was en de user hier naartoe moet gestuurd worden bij het openen van de app moet dit ook aangeduid worden in de app.component

41 3.2 Demo applicatie 37 door de regel: 1 rootpage : any = HomePage ; Nu onze Homepage aangemaakt was werd deze opgevuld. Hier werd dus in HTML een intro geschreven wat de applicatie inhield. Qua functionaliteit was het enigste, dat er een knop was en wanneer hier op gedrukt werd dan werd de rootpage veranderd naar een lijst met alle recepten. Dit gebeurt via de navcontroller, informatie hierover vindt u in Resultaat Figuur 3.13: Homepage in Ionic Xamarin Net zoals bij Ionic zit er in het net aangemaakt project al een start pagina met daarin één regeltje tekst. Om te begrijpen hoe zo n pagina aangemaakt kan worden verwijderen we dus eerst de reeds bestaande homepage. Het valt direct op dat de homepage de XAML extensie heeft en dit staat voor Extensible Application Markup Language. Dit houdt de frontend in en bevat dus de layout van de homepage. In deze XAML zit nog een ander bestand met de extensie CS en hierin vindt men de corresponderende domein logica van een pagina. Er werd een nieuwe homepage aangemaakt door op het algemene project te gaan staan en rechter muisklik te doen gevolgd door add en new item. Daar kiest men een content page en dit maakt een nieuwe pagina aan.

42 38 Hoofdstuk 3. Methodologie Figuur 3.14: Create new content page in xamarin Net zoals bij de Ionic applicatie is het de bedoeling dat de net aangemaakte pagina als root wordt gebruikt. Dit kon door de MainPage van de App.xaml.cs in te stellen. Dit kon door onderstaande regel in de constructor van de App.xaml.cs: 1 MainPage = new Homepage () ; Nu onze Homepage aangemaakt was werd deze opgevuld. Hier werd dus in HTML een intro geschreven wat de applicatie inhield. Qua functionaliteit was het enigste, dat er een knop was en wanneer hier op gedrukt werd dan werd de rootpage veranderd naar een lijst met alle recepten. Dit gebeurt via de Navigation klasse, informatie hierover vindt u in 3.2.3

43 3.2 Demo applicatie 39 Resultaat Figuur 3.15: Homepage in Xamarin Navigatie In een applicatie is het zeer belangrijk om een bepaalde flow te hebben. Een gebruiker kan doorheen de applicatie navigeren en zo alle mogelijke pagina s bezoeken die worden aangeboden. In dit onderdeel werd er bekeken hoe dit werd aangepakt. Ionic In Ionic is er een navigatiecontroller. Die is een object die elke pagina standaard heeft in zijn constructor. Deze beschouwt de navigatie als een array van pagina s. De applicatie toont altijd de laatste pagina uit de array. Het toevoegen en verwijderen van pagina s kan dan ook gewoon via push en pop. push wordt gebruikt om een nieuwe pagina te openen. pop wordt dan weer gebruikt om de huidige pagina te verwijderen en naar de vorige pagina te gaan. In onderstaande code snippets zijn beide methodes te zien. 1 this. navctrl. push ( RecipeDetailPage, { ' recipe ': recipe }) ; 1 this. navctrl. pop () ; In de push zijn duidelijk twee attributen te zien. De eerste is welke pagina er juist gepusht moet worden. De tweede is een key-value object. Dit object komt in de navparams terecht van de gepushte pagina. Op deze manier kunnen pagina s data uitwisselen. In de gepushte pagina kan dan via onderstaande code de data uit de navparams gehaald worden. 1 this. navparams. get ( ' recipe ') ;

44 40 Hoofdstuk 3. Methodologie Op de homepage in onze applicatie is er ook een knop die in plaats van een pagina toevoegt of verwijdert gewoon de rootpagina aanpast. De rootpagina is zogezegd de pagina die helemaal onderaan in de array ligt en dus de basispagina is van onze applicatie. De rootpagina veranderen kan via setroot zoals in onderstaande code. 1 this. navctrl. setroot ( RecipeOverviewPage ) ; Xamarin Bij xamarin kan er genavigeerd worden door uw rootpagina in een navigationpage te steken. Deze rootpagina wordt in Xamarin de MainPage genoemd. Deze is in de app.xaml.cs direct verkrijgbaar en op andere plaatsen moet er gebruik gemaakt worden van Application.Current.MainPage. Het maken van de rootpagina gebeurt aan de hand van onderstaande code. 1 MainPage = new NavigationPage ( new Overviewpage () ) ; Er kan dan net zoals bij Ionic pagina s gepopt en gepusht worden. Dit doe je door gebruik te maken van de globale Navigation klasse. Het pushen en poppen zijn async functies en moeten dus geawait worden. In onderstaande code snippet zie je een voorbeeld van beide methodes. 2 await Navigation. PushAsync ( new Detailpage (( Recipe ) e. Item ) ) ; 3 await Navigation. PopAsync () ; In push is te zien dat er één parameter meegegeven wordt en dat is de pagina zelf. Wanneer er data meegegeven moet worden naar de nieuwe pagina dan is het de bedoeling om een nieuwe constructor te maken voor die pagina. In die constructor kan je dan het element gebruiken zoals gewenst. Ook in deze demoapplicatie was het de bedoeling om een éénmalig welkomscherm te zien en hierin staat dus een knop die de root wijzigt. 4 Application. Current. MainPage = new NavigationPage ( new Overviewpage () ) ; Storage In onze applicatie werd er gewerkt met data namelijk de recepten en alle informatie die dit inhoudt. Deze data moet natuurlijk opgeslagen worden anders heeft de gebruiker hier niet veel aan. Er was dus nood aan storage. Ionic Bij Ionic viel al direct op dat storage een probleem was. In Ionic kan er namelijk niet een directe connectie gelegd worden tussen de applicatie en een databank. De enigste manier om gebruik te maken van een online databank is via een API en hier dan requests naar te doen.

45 3.2 Demo applicatie 41 Omdat een API opzetten en een connectie leggen vanuit de API naar een databank niet prioritair was, werd dit niet gedaan. Er is dan gebruik gemaakt geweest van lokale storage. Om dit te doen moest er in de app.module de StorageModule toegevoegd worden als module. De imports van onze app.module zag er dus nu zoals onderstaand uit. 1 imports : [ 2 BrowserModule, 3 IonicModule. forroot ( MyApp ), 4 IonicStorageModule. forroot () 5 ], Wanneer dit gebeurd was konden de andere pagina s een Storage object in hun constructor steken en via een get en set methode kon de data toegevoegd, opgevraagd en gewijzigd worden. In onderstaande code ziet u een voorbeeld van beide. 1 this. storage. get ( ' recipes '). then (( val ) = > { 2 this. recipes = val ; 3 }) ; 1 storage. set ( ' notfirsttime ', true ) ; De get methode is async en heeft dus nood aan een then functie met daarin wat er juist moet gebeuren wanneer de data ontvangen is. De get methode verwacht ook een string als parameter. Deze string is de key waarvan de value moet worden opgehaald. In de set methode worden twee parameters gegeven, de eerste is een string die de key voorstelt en de tweede is eender wat en stelt de value voor. Xamarin Net zoals bij Ionic is Xamarin niet gemaakt om rechtstreekse een databankverbinding te maken. Dit was echter geen probleem aangezien dit ook al zo was bij de Ionic demo applicatie. In Xamarin moedigen ze dus ook aan om via een API te werken die in verbinding staat met een databank en op die manier met storage te werken. Zelf heeft Xamarin properties waarin bepaalde zaken opgeslagen kunnen worden. Deze properties vervallen helaas bij het afsluiten van de applicatie en was dus niet ideaal. Er werd dus geopteerd voor het installeren van een plugin. Aangezien er gewerkt werd in visual studio kon er dus gebruik gemaakt worden van de NuGet plugins. De gebruikte plugin heet Settings en zorgt voor lokale storage die niet vervalt bij het sluiten van de applicatie.

46 42 Hoofdstuk 3. Methodologie Figuur 3.16: Installed settings plugin in NuGet solution Nu de plugin geïnstalleerd is kon deze gebruikt worden. Dit kon door de plugin te importeren waar nodig en dan kon men de klasse CrossSettings oproepen en daar kon dan een set of get gedaan worden. Hier wordt dan een key-value object aangemaakt. In onderstaande code kunt u een voorbeeld zien van beide. 1 CrossSettings. Current. Get < bool >( " notfirsttime " ) 1 CrossSettings. Current. Set ( " recipes ", recipes ) ; Geen van beide zijn async en ze hebben dus geen nood aan een await. Bij get geef je gewoon een string mee dat de key voorstelt. bij de set zijn er twee parameters namelijk eerst een string die de key voorstelt en de tweede is de value die bij de key hoort Lijst Nu er met data gewerkt kon worden was het tijd om deze data ook eens te tonen. Er werd enkele dummydata in de storage gestoken. In dit onderdeel werd er gewerkt aan hoe deze dummydata getoond kon worden aan de gebruiker. Ionic Als lijst werd er gebruik gemaakt van de <ion-list> tag in de html. Dit is een tag die verschillende <ion-item> tags heeft als kinderen. Voor de overview in onze applicatie met alle recepten werd dus één ion-list voorzien en per recept werd er een ion-item aangemaakt. Om per recept een ion-item aan te maken was zeer eenvoudig. Dit was namelijk puur Angular 4 en er werd dus gewerkt met een ngfor. Hoe een ion-item er dus uitzag moest maar eenmaal geschreven worden. Hier werd ook alle informatie getoond aan de hand van Angular 4. Bij onze applicatie werd een ion-item-sliding gebruikt, dit is hetzelfde als een ion-item maar dan met de mogelijkheid om slide options toe te voegen. Meer info over deze options staat in 3.2.8

47 3.2 Demo applicatie 43 Het enigste wat dus nog moest gebeuren was namelijk het ophalen van de data en deze toewijzen aan een attribuut. Hoe dit juist moest gebeuren is al uitgelegd geweest in Maar het speciale hier was dat dit niet mocht opgehaald worden in de constructor. Deze pagina was namelijk onze rootpagina waardoor deze nooit gepopt werd en dus de constructor ook maar eenmaal werd opgeroepen. Toch was het de bedoeling dat elke keer wanneer deze pagina op de voorgrond kwam dat de data gerefresht werd. Daarom werd de Ionic lifecycle bekeken en zo werd er afgeleid dat de functie ionviewwillenter hiervoor perfect zou zijn. Figuur 3.17: Ionic lifecycle on push and pop events from official Ionic blog

48 44 Hoofdstuk 3. Methodologie Resultaat Figuur 3.18: Overview page in Ionic Xamarin Bij Xamarin wordt een ListView gebruikt om een lijst te tonen met data. In het xaml bestand kreeg de aangemaakte ListView een naam. Door deze naam kon de ListView gebruikt worden in de backend. Daar kon dan de ItemSource van de ListView ingesteld worden. In het xaml bestand was dan ook één ViewCell aangemaakt. Dit is de weergave van elk element in de ItemSource. Er kan gebruik gemaakt worden van een TextCell of een ImageCell maar de developer kan ook gewoon een ViewCell maken en daarin kan hij zelf bepalen hoe de cell eruit ziet. Net zoals bij Ionic was er een actie achter de ViewCells gestoken. Dit heet in Xamarin een ContextAction. Dit is echter toch net iets anders dan in Ionic. Bii Ionic is dit namelijk een slider op zowel Android als ios. Bij Xamarin is dit enkel een slider op ios, op Android is dit een ViewCell lang ingedrukt houden en dan komen de mogelijkheden bovenaan tevoorschijn. Meer info en een afbeelding van hoe dit er juist uitziet kan je terugvinden in Net zoals bij Ionic werden de lifecycle events bekeken van een content page. Dit was namelijk omdat onze data niet toegewezen mocht worden in de constructor. Doorheen de navigatie blijft namelijk dezelfde pagina de rootpagina in de array van navigatie. Hierdoor werd de constructor dus maar één maal opgeroepen en werd de data dus ook niet bijgewerkt. Een oplossing voor dit probleem was door de OnAppearing methode te overriden. Deze methode werd namelijk elke keer getriggerd wanneer de rootpagina op de voorgrond kwam.

49 3.2 Demo applicatie 45 Resultaat Figuur 3.19: Overview page in Xamarin Form Onze gebruiker zal natuurlijk ook nieuwe recepten willen toevoegen. Om de data te weten te komen zal onze gebruiker een formulier moeten invullen en deze informatie kan dan omgezet worden naar de data die nodig was. In dit onderdeel werd bekeken hoe zo n formulier gemaakt wordt. Ionic Ook een form in Ionic bestaat grotendeels uit Angular 4. Er werd dus gebruik gemaakt van een FormBuilder die een FormGroup maakt met voor elk onderdeel van dit formulier één of meerdere Validators. Enkel wanneer alle onderdelen van het formulier in orde zijn kan de gebruiker het formulier indienen. In onze applicatie zijn er twee formulieren namelijk een formulier voor een gloednieuw recept en een formulier voor het wijzigen van data in verband met een reeds bestaand recept. Om code te besparen is dit één pagina die kijkt of hij een recept meekrijgt of niet en aan de hand van dit antwoord wordt de pagina opgemaakt.

50 46 Hoofdstuk 3. Methodologie Resultaten Figuur 3.20: Add page in Ionic Figuur 3.21: Edit page in Ionic Xamarin Bij Xamarin viel al snel op dat het maken van een form een probleem ging worden. In de docs viel namelijk snel op dat hierover niks werd aangehaald. Er waren wel input velden beschikbaar die in Xamarin Entries heten maar er was niks vergelijkbaar met een

51 3.2 Demo applicatie 47 FormBuilder zoals in Angular 4. De validatie van al de velden moesten dus handmatig geschreven worden. Om alle inputs dan te valideren is er gebruik gemaakt van het Text-property van de Entry velden. Deze werden een naam gegeven in het xaml-bestand zodat deze in de backend opgeroepen konden worden en de waarde hiervan opgehaald maar ook ingesteld kon worden. We hebben ook gebruik gemaakt van datatriggers voor de validatie. data triggers gaan aan de hand van data een tag een bepaald attribuut toekennen. Dit was dus nodig om bepaalde buttons te disablen wanneer de nodige Entries niet waren ingevuld. Ook viel op dat er maar een beperkt aantal mogelijkheden waren om data te registreren. Zo werd er in de Ionic demo applicatie gewerkt met radio buttons om te vragen wat het type is van het recept. Dit bestaat wonder boven wonder echter niet in Xamarin. Hier is dus een Picker nodig geweest met een lijst van twee mogelijkheden. Dit werkt natuurlijk ook maar was minder ideaal want het is redelijk omslachtig en niet zo zeer gebruiksvriendelijk als er gewoon een beslissing moet gemaakt worden tussen twee mogelijkheden. Figuur 3.22: Add page in Xamarin

52 48 Hoofdstuk 3. Methodologie Figuur 3.23: Edit page in Xamarin Native features Alle voorgaande onderdelen maken tezamen al een mooi applicatie. Enigste nadeel is dat tot en met nu de applicatie eigenlijk een standaard webapplicatie is. Het enigste voordeel momenteel is dat de applicatie aangeboden kan worden in de appstore en een native feel heeft. Om de applicatie naar een hoger niveau te tillen was er de mogelijkheid om enkele native features te gebruiken. Maar hoe gebeurt dit? Ionic Om in Ionic gebruik te maken van enkel native features moest de native docs van Ionic gehanteerd worden. Daar staan namelijk alle native features die Ionic ondersteunt. Een developer kan daar dus inspiratie op doen voor welke native features hij dus wil gebruiken. In het geval van onze applicatie zijn er drie features gekozen namelijk Local Notifications, Toast en Speech Recognition. Elke feature die toegevoegd wordt is een plugin die we gaan gebruiken. We gaan dus deze plugin moeten installeren en moeten toevoegen aan ons project. Het installeren doen we door 2 commands. 1 $ ionic cordova plugin add $pluginname 1 $ npm install -- save $plugindirectory wat er juist moet komen op de plaats van $pluginname en $plugindirectory kan je terugvinden op de native docs van Ionic want dit verschilt van plugin tot plugin. Als de plugin

53 3.2 Demo applicatie 49 geïnstalleerd is kan deze toegevoegd worden aan het project door deze toe te voegen aan de providers van app.module. In onderstaande code ziet u wat de providers zijn in onze applicatie. 1 providers : [ 2 StatusBar, 3 SplashScreen, 4 { provide : ErrorHandler, useclass : IonicErrorHandler }, 5 Toast, 6 SpeechRecognition, 7 L ocalnotifications 8 ] Het bespreken van hoe zo n plugin werkt is echter onrealistisch. Elke plugin heeft namelijk een verschillende manier van werking en deze kan ook veranderen van versie tot versie. Als u dus wil weten hoe u juist gebruik kan maken van de plugin die u hebt toegevoegd zult u nogmaals de native docs moeten bezoeken van Ionic. Resultaten Figuur 3.24: Notification received when leaving homepage

54 50 Hoofdstuk 3. Methodologie Figuur 3.25: Toast received when edited recipe Figuur 3.26: Speech Recognition to add step Xamarin Tot grote verbazing en geheel onverwacht was het grootste probleem bij Xamarin de native features. Er werd namelijk een poging gedaan tot zoals bij Ionic het toevoegen van speech recognition, local notifications en toasts. Maar ondanks dat dit een native cross platform applicatie is, was dit toch geen evidentie. Het toevoegen van native features tot een Xamarin werkomgeving is zeer eenvoudig. Er