WEBAPPLICATIES VOOR DIGITAL SIGNAGE & JAVASCRIPT PERFORMANCE

WEB APPLICATIES VOOR DIGITAL SIGNAGE & JAVASCRIPT PERFORMANCE

WEBAPPLICATIES VOOR DIGITAL SIGNAGE & JAVASCRIPT PERFORMANCE STAGEPLAATS: DOOHAPPS | STAGEMENTOR: MEVR SOFIE EECKEMAN | STAGEBEGELEIDER: DHR. FREDERIK DE WACHTER PROJECT AANGEBODEN DOOR

BERNHARD MOSTREY VOOR HET BEHALEN VAN DE GRAAD VAN BACHELOR IN DE

NEW MEDIA AND COMMUNICATION TECHNOLOGY HOWEST | ACADEMIEJAAR 2014-2015


WEBAPPLICATIES VOOR DIGITAL SIGNAGE & JAVASCRIPT PERFORMANCE STAGEPLAATS: DOOHAPPS | STAGEMENTOR: MEVR SOFIE EECKEMAN | STAGEBEGELEIDER: DHR. FREDERIK DE WACHTER PROJECT AANGEBODEN DOOR

BERNHARD MOSTREY VOOR HET BEHALEN VAN DE GRAAD VAN BACHELOR IN DE

NEW MEDIA AND COMMUNICATION TECHNOLOGY HOWEST | ACADEMIEJAAR 2014-2015


WOORD VOORAF Deze bachelorproef is het resultaat van 3 maand samenwerking met DOOHapps. Tijdens die 3 maand werkte ik mee met het team aan alle opdrachten die binnenkwamen en aan de branding van het bedrijf zelf. Ik maakte verschillende demo-applicaties voor nieuwe klanten, maakte een nieuwe website voor DOOHapps samen met een email handtekening en visitekaartjes. Ik werkte ook mee aan de vernieuwing van de Toolbox en de Scheduler (zie later).

Op de stageplaats leerde ik hoe het is om in een startup te werken en hoe het is om in een team te werken. Het was een zeer goede ervaring en daarvoor wil ik hen ook bedanken.

Als hoofdproject mocht ik me ontfermen over een nieuwe soort apps die het bedrijf wil verkopen (webapps). Onderweg onderzocht ik de structuur van de DOOHapps apps en kwam ik meer te weten over performance bij Javascript. Deze bachelorproef is daarvan het resultaat.

Iedereen in het bedrijf is zeer tevreden met het resultaat en ik heb bijzonder veel bijgeleerd. Het volledige onderzoek was zeer interessant en leerrijk en is zeker een goede verrijking vóór ik het werkveld instap.

Ik wil iedereen bedanken die mij heeft geholpen tijdens de stageperiode en uiteraard Howest voor de fantastische opleiding.

Bernhard Mostrey


SAMENVATTING In opdracht van DOOHapps maakte ik een volledige, snelle en mooie citytrip webapplicatie. Met behulp van API’s (externe services) zoals Trip Advisor, Yelp en Foursquare worden gegevens van restaurants (of andere plaatsen) in de buurt opgehaald. Deze worden mooi weergegeven op een scherm waar bezoekers van hotels of publieke plaatsen snel kunnen zien waar ze naartoe kunnen. Het project kreeg de werknaam Tripler.

Een webapplicatie is in deze context een website afgebeeld op een Digital Signage scherm die in verbinding staat met verschillende services op het internet. Met webapps zijn er veel nieuwe mogelijkheden, bijvoorbeeld Social Media Apps, Live Photo Apps, …

Gedurende het onderzoek heb ik ondervonden dat de prestatie van de app heel belangrijk is. De app moest op alle apparaten afgespeeld kunnen worden (zelfs HDMI-sticks) en er was kans dat een oudere browser gebruikt zou worden. Zoals bij alle andere apps in het DOOHapps gamma moet de klant de mogelijkheid hebben om instellingen te maken en de app naar het scherm te sturen zonder dat ongewenste personen er toegang tot hebben.

Het onderzoek van deze bachelorproef bestond dus uit twee onderdelen: 1. Hoe maak ik een webapplicatie voor gebruik in een DOOH omgeving? 2. Hoe zorg ik ervoor dat die applicatie werkt op elk systeem zonder de user interface te verstoren? Als eerste ging ik kijken hoe de huidige apps van DOOHapps werken. Aanvankelijk waren er 2 soorten apps, namelijk native apps en de toenmalige web apps. De native apps bestaan uit bestanden die gekopieerd worden naar de pc en via een game-engine uitgevoerd worden. De webapps bestaan enkel uit een URL die in een browser wordt geopend. De nieuwe soort webapps moet de mogelijkheid hebben om via instellingen het gedrag aan te passen en de bestanden van de website moeten voor de veiligheid op de pc zelf staan. Er moest dus een nieuwe soort app ontwikkeld worden. Als tweede onderzocht ik de wereld van Javascript performance. Er is hierover heel veel te vinden en ik leerde heel veel nieuwe tips bij om toe te passen in de applicatie. Twee boeken van Kyle Simpson leggen heel diepgaand uit hoe Javascript werkt en hoe de prestaties verbeterd kunnen worden. Ik leerde tools kennen om de prestatie van mijn applicatie te meten en zag na alle tweaks grote veranderingen in de laadtijden.

Als resultaat werd een volledig nieuwe soort app ontwikkeld die nu gebruikt kan worden voor alle soorten webapps. De citytrip app werkt perfect op alle systemen (zowel mini-pc als game-pc) en is de eerste volledig werkende webapp die onder de naam DOOHapps in de App Store staat.


SYMBOLEN EN AFKORTINGEN 1. API: Application Programming Interface (plaats online waar je gegevens kan ophalen) 2. App: applicatie 3. B2B: Business To Business 4. B2C: Business To Consumer 5. C#: programmeertaal voor Windows applicaties. 6. CMS: Content Management System (back-end beheersysteem) 7. CSS: Cascading Style Sheet: taal die wordt gebruikt om de HTML pagina van opmaak te voorzien 8. DOOH: Digital Out Of Home 9. FPS: Frames per Second: het aantal beelden per seconde dat weergegeven wordt. Lage FPS veroorzaakt haperend (vastlopend) beeld 10. HTML: Hyper Text Markup Language: gestructureerde taal om webpagina’s te maken 11. JS: Javascript (programmeertaal) 1. JS: Javascript: programmeertaal gebruikt in heel veel verschillende applicaties (website, gsm, programma, …) 12. JSON: JS Object Notation: een vorm van gegevens schrijven om vlotte overdracht te verbeteren 13. POI: Point of Interest (interessante plaats) 14. Signage: gebruik maken van tekens of symbolen om te communiceren met een specifieke groep mensen


WOORDENLIJST 1. AngularJS: uitbreiding op HTML vooral gebruikt voor Single Page websites, om variabelen aan HTML waarden te koppelen en om lijsten eenvoudig naar HTML om te zetten. 2. Array: een lijst van waarden 3. Asynchroon: opdracht naast andere opdrachten laten uitvoeren 4. Branding: naam, logo, slogan en design geassocieerd met een product of service 5. Call: een aanvraag voor gegevens aan een API 6. Callback: functie die wordt opgeroepen als een taak volbracht is 7. Chrome: browser van Google 8. Configurator: plaats waar instellingen kunnen gemaakt worden 9. Dribbble: website waar designers hun werk tonen aan mede-designers 10. Firefox: browser van Mozilla 11. Functie: een stuk code dat opgeslaan wordt onder een naam, waarna het meerdere keren gebruikt kan worden door het oproepen van die naam 12. InfoWindow: de tekstballon met informatie die in Google Maps gebruikt wordt 13. Javascript: programmeertaal gebruikt in heel veel verschillende applicaties (website, gsm, programma, …) 14. Library: een bibliotheek of verzameling van JS functies 15. Loop: herhaling van een stuk code waarbij een nummer opgeteld wordt bij elke herhaling 16. Media Query 17. Synchroon: één actie tegelijk 18. Toolbox: deel van de DOOHapps App Store waar klanten hun apps zien, kunnen configureren en instellen wanneer ze waar gespeeld worden 19. Tweaks: aanpassingen aan code om het programma beter te maken 20. Value: een waarde 21. Variabele: een object waar een waarde kan in opgeslagen worden 22. View: wat er te zien is op het scherm, of een deel van wat er op het scherm staat 23. Workload: de zwaarte van het programma, hoe moeilijk het is om uit te voeren


LIJST VAN TABELLEN EN FIGUREN Figuur 1: DOOHapps Logo (DOOHapps) ................................................................................ 7 Figuur 2: DOOHapps ISE 2015 .............................................................................................. 11 Figuur 3: Tripler op straat ....................................................................................................... 14 Figuur 4: Wander (Dribbble) .................................................................................................. 16 Figuur 5: City Logo (Dribbble) ............................................................................................... 17 Figuur 6: Fonts ....................................................................................................................... 17 Figuur 7: Tripler logo .............................................................................................................. 17 Figuur 8: Mongoose webserver (Mongoose) ......................................................................... 20 Figuur 9: Function Declaration ............................................................................................... 21 Figuur 10: Globale Variabele (W3 Schools) ........................................................................... 22 Figuur 11: Lokale variabele (W3 Schools) ............................................................................. 22 Figuur 12: Auto globale variabele (W3 Schools).................................................................... 22 Figuur 13: Nested Scope (You Don’t Know JS) ..................................................................... 23 Figuur 14: Lexing 1 (You Don’t Know JS) .............................................................................. 24 Figuur 15: Lexing 2 (You Don’t Know JS) .............................................................................. 24 Figuur 16: Bubbles 1 (You Don’t Know JS) ............................................................................ 24 Figuur 17: Bubbles 2 (You Don’t Know JS) ............................................................................ 25 Figuur 18: Function Expression (You Don’t Know JS)............................................................ 26 Figuur 19: Closures (You Don’t Know JS) .............................................................................. 26 Figuur 20: Tripler Service ....................................................................................................... 27 Figuur 21: Tripler Settings ...................................................................................................... 28 Figuur 22: Arrays 1 ................................................................................................................. 29 Figuur 23: Arrays 2 ................................................................................................................. 30 Figuur 24: Loops 1 ................................................................................................................. 30 Figuur 25: Loops 2 ................................................................................................................. 30 Figuur 26: Console Time ........................................................................................................ 31 Figuur 27: Timeline 1 (Eigendom van Bhavin Patel) .............................................................. 31 Figuur 28: Timeline 2 (Eigendom van Bhavin Patel) .............................................................. 31 Figuur 29: Profiler Heavy (Eigendom van Bhavin Patel) ........................................................ 32 Figuur 30: Profiler Tree (Eigendom van Bhavin Patel) ........................................................... 32 Figuur 31: Timeline Result Pre ............................................................................................... 33 Figuur 32: Timeline Result Post .............................................................................................. 34 Figuur 33: Scripting Time ....................................................................................................... 34 Figuur 34: Console Time Resultaat ........................................................................................ 35 Figuur 35: Tripler resultaat ..................................................................................................... 35


INHOUDSOPGAVE WOORD VOORAF .............................................................................................................................. SYMBOLEN EN AFKORTINGEN ........................................................................................................... WOORDENLIJST ................................................................................................................................. LIJST VAN TABELLEN EN FIGUREN ...................................................................................................... SAMENVATTING ................................................................................................................................ INHOUDSOPGAVE ............................................................................................................................. 1. 1.1 1.2 1.3

INLEIDING .............................................................................................................................. 11 Wat is DOOHapps? ...................................................................................................................... 11 Collega’s ...................................................................................................................................... 12 Probleemstelling .......................................................................................................................... 12

1.3.1

Begrenzing ............................................................................................................................................................. 13

1.4 Methode ...................................................................................................................................... 13 2. 2.1 2.2 2.3

TRIPLER .................................................................................................................................. 14 Wat is Tripler? ............................................................................................................................. 14 Welk resultaat werd verwacht? .................................................................................................. 14 Welke bronnen worden gebruikt? .............................................................................................. 15

2.3.1 2.3.2 2.3.3

Trip Advisor ........................................................................................................................................................... 15 Foursquare ............................................................................................................................................................ 15 Yelp ........................................................................................................................................................................ 15

2.5.1 2.5.2

Naam ..................................................................................................................................................................... 16 Logo ....................................................................................................................................................................... 16

2.4 Welke mogelijkheden heeft de klant? ......................................................................................... 16 2.5 Visualisatie / Branding ................................................................................................................. 16 3. HOE WERKT HET MAKEN EN AFSPELEN VAN EEN APPLICATIE IN EEN DOOH OMGEVING ........ 18 3.1 Omkadering applicaties ............................................................................................................... 18 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5

Providers ............................................................................................................................................................... 18 App Store ............................................................................................................................................................... 18 Media Speler ......................................................................................................................................................... 18 Native Apps ........................................................................................................................................................... 18 Web Apps .............................................................................................................................................................. 18

3.2.1 3.2.2 3.2.3 3.2.4 3.2.5

Offline gebruik ....................................................................................................................................................... 19 Oude browser ........................................................................................................................................................ 19 Branding ................................................................................................................................................................ 19 Instellingen ............................................................................................................................................................ 19 4K ........................................................................................................................................................................... 19

3.2 Implementatie Tripler .................................................................................................................. 19

3.3 Ontwikkeling nieuwe web App .................................................................................................... 20 4. HOE ZORG JE ERVOOR DAT EEN APPLICATIE ZO VLOT MOGELIJK WERKT ................................ 21 4.1 Introductie Javascript Performance ............................................................................................ 21 4.1.1 Functies ................................................................................................................................................................. 21 4.1.2 Variabelen ............................................................................................................................................................. 21 4.1.3 DOM ...................................................................................................................................................................... 22 4.1.4 jQuery .................................................................................................................................................................... 22 4.1.5 Scope ..................................................................................................................................................................... 23 4.1.5.1 Wat is de ‘Scope’ .......................................................................................................................................... 23 4.1.5.2 Hoe werkt ‘Scope’ ........................................................................................................................................ 23 4.1.5.3 Nested Scope ............................................................................................................................................... 23 4.1.5.4 Lexical scope ................................................................................................................................................ 24 4.1.5.5 Function & Block scopes .............................................................................................................................. 25 4.1.5.6 Closures ........................................................................................................................................................ 26

WEB APPLICATIES VOOR DIGITAL SIGNAGE & JAVASCRIPT PERFORMANCE 4.1.6

Garbage collection ................................................................................................................................................ 26

4.2 Service ......................................................................................................................................... 27 4.2.1.1 Instellingen ................................................................................................................................................... 27 4.2.2 Gegevens ophalen ................................................................................................................................................. 28 4.2.2.1 Promise ........................................................................................................................................................ 28 4.2.2.2 Deffered object ............................................................................................................................................ 29 4.2.3 Gegevens verwerken ............................................................................................................................................. 29 4.2.3.1 Arrays ........................................................................................................................................................... 29 4.2.3.2 Loops ............................................................................................................................................................ 30

4.3 Kaart & Markers .......................................................................................................................... 30 4.4 Cycle ............................................................................................................................................ 30 4.5 Tools ............................................................................................................................................ 31 4.5.1 4.5.2 4.5.3

Console .................................................................................................................................................................. 31 Chrome Timeline ................................................................................................................................................... 31 Chrome Profiler ..................................................................................................................................................... 31

5. CONCLUSIES ........................................................................................................................... 33 5.1 Problemen & oplossingen ........................................................................................................... 33 5.2 Benchmarks ................................................................................................................................. 33 5.2.1 5.2.2 5.2.3

Timeline ................................................................................................................................................................. 33 Profiler ................................................................................................................................................................... 34 Console Time ......................................................................................................................................................... 34

5.3 Resultaat ...................................................................................................................................... 35 5.4 Geleerde lessen ........................................................................................................................... 35 REFERENTIELIJST ............................................................................................................................ 37 1. 1.1 1.2 1.3 1.4

DIGITALE BRONNEN ............................................................................................................... 37 Websites ...................................................................................................................................... 37 Eindwerken .................................................................................................................................. 38 Tijdschriften ................................................................................................................................. 38 Ebooks ......................................................................................................................................... 38

2. VAKSPECIALISTEN .................................................................................................................. 38 BIJLAGEN ......................................................................................................................................... 1 1. SCOPE IN ANGULARJS ............................................................................................................... 1 1.1 Scopes & Digest cycle .................................................................................................................... 1 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5

Scopes ..................................................................................................................................................................... 1 $Watch .................................................................................................................................................................... 1 $Watchers ............................................................................................................................................................... 1 Digest cycle .............................................................................................................................................................. 1 $scope.$apply ......................................................................................................................................................... 1


1. INLEIDING 1.1 WAT IS DOOHAPPS? DOOHapps is een startup in Gent dat zich specialiseert in het verkopen/verspreiden van interactieve applicaties voor gebruik in een bedrijf of in de retail (Logo: figuur 1). Bedrijven/zelfstandigen die op een leuke manier bezoekers willen entertainen en tegelijk hun brand promoten kunnen bij DOOHapps terecht voor het volledige pakket (scherm, pc en applicatie).

Om zich volledig op het verkopen te kunnen specialiseren worden de apps niet binnenshuis gemaakt, daarvoor worden applicatieproviders aangesproken. Deze providers maken de apps en leveren ze samen met configuratiemogelijkheden aan bij DOOHapps.

Deze apps komen in de App Store te staan en worden verkocht onder de naam DOOHapps. De klanten kunnen zich registeren op de website, bladeren door de verschillende beschikbare apps en uiteindelijk een app kopen of huren om te gebruiken in hun bedrijf

Figuur 1: DOOHapps Logo (DOOHapps)

of winkel.

Hierna kan de app ook geconfigureerd worden met de Toolbox van DOOHapps om de foto’s, logo, animatie, etc… aan te passen.

Als bezoekers langskomen bij een opstelling van DOOHapps zien ze onmiddelijk animaties op het scherm en kunnen ze ermee interageren. Dit werkt veel beter dan een gewone poster aan de muur (figuur 2).

Figuur 2: DOOHapps ISE 2015

11


1.2 COLLEGA’S In de afdeling te Gent zijn er 3 vaste werknemers. Er wordt ook gebruik gemaakt van een team programmeurs in Riga waar ook de investeerders zitten.

Frederik De Wachter is de Innovation Manager van DOOHapps. Concreet houdt hij zich bezig met het algemeen bestuur van het bedrijf en prospectie van nieuwe klanten. Frederik Vroman is al jaren expert op het vlak van DOOH. Hij gebruikt zijn uitgebreid netwerk om klanten te vinden voor DOOHapps. Michaël Boone is de technische expert in Gent. Hij zorgt ervoor dat alle pc’s goed functioneren en alle apps vlot werken bij de klant. Hij staat ook in voor de communicatie met het team in Riga.

1.3 PROBLEEMSTELLING Als nieuwe uitdaging wil DOOHapps een nieuwe weg ingaan en starten met het maken en verkopen van webapplicaties, in tegenstelling tot alle native apps die nu verkocht worden. Een native app bestaat uit een map bestanden en een instellingenbestand. Nadat alle instellingen gemaakt zijn worden alle bestanden naar de pc gekopieerd en worden ze lokaal opgestart met behulp van een game-engine. Er is weinig communicatie met het internet, de app kan dus volledig offline werken. Het nadeel van native apps is dat externe services (API’s) minder gemakkelijk aanspreekbaar zijn vanuit zo’n app en zij moeilijker te ontwikkelen zijn dan een website. De huidige webapps hebben als enige instelling een URL die het programma opent en toont op het scherm. Dit is dus ook de enige instelling die mogelijk is met de huidige webapps. De webapp is handig om websites te tonen die geen instellingen vereisen of die op de server van DOOHapps staan, maar vanaf dat de gebruiker de mogelijkheid moet krijgen om aanpassingen te maken is er een probleem. Om dit op te lossen werd een nieuwe soort app gemaakt. Heel belangrijk bij deze nieuwe soort app is dat hij vlot werkt op een lichte pc, dat hij offline kan werken en dat hij aanpasbaar is. Verder is het ook belangrijk dat de klant de belangrijkste instellingen zelf kan aanpassen.

Er werden dus 2 onderwerpen onderzocht: 1. Hoe maak ik een webapplicatie voor gebruik in een DOOH omgeving? 2. Hoe zorg ik ervoor dat die applicatie werkt op elk systeem zonder de user interface te verstoren?

12


1.3.1 BEGRENZING Uiteraard kan ik in deze bachelorproef niet de volledige werking van Javascript onderzoeken. In dit onderzoek leg ik een paar van de begrippen uit die belangrijk zijn bij de performance van Javascript. Alle optimalisaties die ik bespreek werden toegepast in de citytrip app.

1.4 METHODE Als eerste leerde ik werken met de huidige apps van DOOHapps. Van aankoop tot instellingen tot uitvoeren. Ik leerde de verschillende soorten apps kennen en wat hun mogelijkheden zijn. Daarna ging ik stap voor stap kijken welke instellingen de klant zou nodig hebben in Tripler en hoe ik deze zou implementeren in de applicatie. Ik onderzocht ook welke extra functies de nieuwe webapps moesten hebben om te kunnen werken in een DOOH omgeving. Pas als die vragen opgelost waren kon een nieuwe soort app ontwikkeld worden. Als tweede onderzocht ik de wereld van Javascript performance. Er is hierover heel veel te vinden en ik leerde heel veel nieuwe tips bij om toe te passen in de applicatie. Twee boeken van Kyle Simpson leggen heel diepgaand uit hoe Javascript werkt en hoe de prestaties verbeterd kunnen worden. Stap voor stap kon ik veel tips toepassen op de applicatie en met behulp van verschillende tools meten of deze invloed hadden op de prestaties. Pas als alle optimalisaties toegepast waren kon de app getest worden in de DOOHapps omgeving.

13


2. TRIPLER 2.1 WAT IS TRIPLER?

Figuur 3: Tripler op straat

Tripler (figuur 3) kan je kort beschrijven als een citytrip app (denk aan de Trip Advisor app). Toeristen of bezoekers die naar de app kijken kunnen meer info krijgen over restaurants of winkels in de buurt samen met hun rating, laatste review en openingsuren. Aan de hand van een grote kaart zien ze snel waar ze zelf zijn en waar de POI’s (Point of Interest) zich bevinden. Ook is het mogelijk om details van een POI te bekijken, de rating te bekijken of zelf een rating te geven door de QR-code in te scannen. Eventueel komt er ook sociale media bij, evenementen in de buurt, etc... Er zijn heel veel mogelijkheden. Na onderzoek naar de meest bruikbare informatie kon duidelijk bepaald worden welke informatie precies getoond wordt.

2.2 WELK RESULTAAT WERD VERWACHT? De app zal uiteindelijk op een tv scherm getoond worden op publieke plaatsen of bedrijven (bv. hotels). Het doel is dat de toeristen gemakkelijk de app kunnen gebruiken en ook echt geholpen zijn met de informatie die ze krijgen. De informatie die een toerist verwacht moet ook te zien zijn op het scherm of moet kunnen opgevraagd worden. Daarbovenop moet de applicatie zoals de huidige native apps blijven werken bij verlies van een internetconnectie, mag deze niet toegankelijk zijn voor niet-klanten, 4K schermen ondersteunen, vlotte animaties tonen en langdurig blijven werken.

14


2.3 WELKE BRONNEN WORDEN GEBRUIKT? Vóór de ontwikkeling van de app kon starten onderzocht ik alle API’s, zodat beslist kon worden welke uiteindelijk gebruikt zouden worden.Vooral de informatie die beschikbaar is en welke limieten er zijn is belangrijk voor deze keuze.

2.3.1 TRIP ADVISOR Aan het gebruik van de Trip Advisor API zijn een paar regels verbonden. Deze mag niet gebruikt worden voor applicaties bestemd voor Data Analysis of Academic Research en niet voor websites die niet B2C (Business To Consumer) gericht zijn. Na inschrijven op de API kunnen er 1000 ‘calls’ per dag gemaakt worden. Wanneer een werkend prototype gemaakt is, kan Trip Advisor gecontacteerd worden om 10000 ‘calls’ per dag te krijgen. De informatie die we van de API krijgen: •

Tot 10 restaurants, attracties of accommodaties (POI)

•

Business details voor elke POI

De Business Details bestaan uit: •

Locatie ID, naam, adres, latitude en longitude

•

Link om reviews lezen en schrijven

•

Rating, ranking, sub ratings, awards, aantal reviews, rating image

•

Prijs level symbool, categorie en subcategorie, attractietype en keuken

•

Drie meest recente review snippets van maximum 200 karakters

De resultaten kunnen gefilterd worden op categorie, subcategorie, keuken en attractietype.

2.3.2 FOURSQUARE Foursquare is losser in de toegang van de API. Er zijn verschillende zoekmethodes, in dit project wordt vooral ‘Venue Explore’ gebruikt. ‘Venue Search’ kan eventueel ook gebruikt worden om naar specifieke locaties te zoeken. Zonder in te loggen is er een limiet van 5000 ‘calls’ per uur wat voldoende is voor Tripler. Volgende gegevens zijn beschikbaar bij ‘Venue Explore’: •

Venue: ID, naam, contact

•

Locatie: Adres, latitude en longitude

•

Categorie + icoon

•

Aantal check-ins & tips

•

Rating

•

Openingsuren

•

Foto’s

2.3.3 YELP 15


Yelp gebruikt Oauth autorisatie voor alle API requests wat moeilijker is om te implementeren maar dan wel geen limieten oplegt. Via de Search API kan gezocht worden naar ‘Businesses’ in de buurt. Er kan gezocht worden op locatie, zoekterm, categorie en deals. Volgende gegevens krijgen we in de response: •

ID, is claimed, closed, naam, image, URL, telefoon

•

Aantal reviews, categorieën, afstand, rating

•

Snippet

•

Adres

•

Deals

•

Gift

•

Menu

2.4 WELKE MOGELIJKHEDEN HEEFT DE KLANT? De klant heeft de mogelijkheid om de applicatie aan te passen naar zijn wensen met behulp van de Toolbox. Hier kan de klant zijn eigen branding toepassen en zal hij onder ander kunnen kiezen welke API gebruikt wordt en of zijn eigen bedrijf op de kaart getoond wordt. Uiteindelijk zullen er nog meer instellingen toegevoegd worden.

2.5 VISUALISATIE / BRANDING 2.5.1 NAAM Na een inside brainstormsessie was het beste resultaat Tripler. Dit ligt in het verlengde van veel nieuwe start-ups die gelijkaardige methodes gebruiken (onder andere Hoplr).

2.5.2 LOGO Voor het logo werd de inspiratie gehaald uit onderstaande shots van Dribbble. Heel minimalistisch design (figuur 4) en werken met felle kleuren (figuur 5) is nu in.

Figuur 4: Wander (Dribbble)

16


Figuur 5: City Logo (Dribbble)

Het is dus een combinatie van twee designtrends geworden: figuur 4 minimalisme en figuur 5 flat / material design. Voor de tekst die bij het logo hoort werd Proxima Nova gebruikt, van de 19 onderstaande lettertypes (figuur 6) werd deze er als beste uitgekozen.

Figuur 6: Fonts

Het logo en de tekst werden gecombineerd om de branding van Tripler te demonstreren (figuur 7).

Figuur 7: Tripler logo

17


3. HOE WERKT HET MAKEN EN AFSPELEN VAN EEN APPLICATIE IN EEN DOOH OMGEVING 3.1 OMKADERING APPLICATIES 3.1.1 PROVIDERS Alle applicaties die te koop zijn in de DOOHapps App Store worden gemaakt door ‘App Providers’ (een professioneel team van programmeurs). De apps worden aanpasbaar gemaakt en geïmplementeerd in de App Store.

3.1.2 APP STORE De DOOHapps App Store is vergelijkbaar met de Apple App Store. Er is een mooi overzicht te zien van alle beschikbare apps en hun prijs. Na aankoop van een app kan deze geconfigureerd worden in de Toolbox.

3.1.3 MEDIA SPELER Elke klant dient naast zijn app ook te beschikken over een pc waar de app op zal draaien. Hiernaar wordt verwezen als media speler. Nadat de app geconfigureerd is kan deze naar het aangesloten scherm gestuurd worden voor een bepaalde tijd op een bepaald tijdstip.

3.1.4 NATIVE APPS De huidige apps in het DOOHapps gamma zijn Native apps. Dit wil zeggen dat de app bestaat uit een map bestanden en een instellingenbestand. Nadat alle instellingen gemaakt zijn worden alle bestanden naar de pc gekopieerd en worden ze lokaal opgestart met hulp van een game engine. Eens alle bestanden gekopieerd zijn is er meestal geen communicatie meer met het internet en kan de app dus volledig offline werken. Het nadeel van native apps is dat externe services (API’s) minder gemakkelijk aanspreekbaar zijn vanuit zo’n app.

3.1.5 WEB APPS De huidige webapp heeft als enige instelling een URL die het programma opent en toont op het scherm. Dit is dus de enige instelling die mogelijk is met de web app. De web app is handig om websites te tonen die geen instellingen vereisen of die op de server van DOOHapps staan. Maar vanaf dat de gebruiker de mogelijkheid moet krijgen om aanpassingen te maken is er een probleem. Om dit op te lossen werd een nieuwe soort app gemaakt. Heel belangrijk bij die nieuwe soort app was dat hij vlot werkt op een lichte pc, dat hij offline kan werken en dat hij aanpasbaar is. Verder is het ook belangrijk dat de klant de belangrijkste instellingen zelf kan aanpassen.

18


3.2 IMPLEMENTATIE TRIPLER 3.2.1 OFFLINE GEBRUIK Omdat internet niet altijd beschikbaar is bij de opstelling van een klant moeten alle apps ook zonder internet kunnen werken. Dit is wat moeilijker bij een web app omdat alle gegevens van externe services komen. Om dit op te lossen werd er in het instellingen bestand een array toegevoegd (genaamd Businesses). Deze wordt ingevuld bij de eerste opstart van de website en zal gebruikt worden indien er geen internet beschikbaar is.

3.2.2 OUDE BROWSER Het is mogelijk dat de webapp in een oudere browser zal moeten werken. Hierdoor kan het zijn dat bepaalde functionaliteiten niet ondersteund worden of dat de website trager werkt. Om dit tegen te gaan gebruikte ik alleen functies die in alle browsers werken en pastte ik alle prestatietips toe uit het performance onderzoek.

3.2.3 BRANDING De klant moet mogelijkheid hebben om de website aan te passen naar de branding van het bedrijf. Daartoe zijn het logo en de kleuren over heel de webapp instelbaar.

3.2.4 INSTELLINGEN De klant moet de mogelijkheid hebben om veel instellingen te maken. Dit is zo bij de huidige apps van DOOHapps en moet doorgetrokken worden naar de webapps. Instellingen die zeker mogelijk moeten zijn: •

Map Locatie

•

Map Zoom Level

•

Map Zoekterm

•

Map POI Limiet

•

Klant Logo

•

Klant Kleuren

•

Klant Slogan

•

Eigen Bedrijf Op Kaart

•

Reviews Geven

3.2.5 4K Bij sommige klanten worden apps getoont op een 4K scherm. Het is dus belangrijk dat de website ook goed getoond wordt op zo’n grote resolutie. Hiervoor worden Media Queries gebruikt.

19


3.3 ONTWIKKELING NIEUWE WEB APP Een combined app bestaat uit twee delen: •

Een lokale map met alle HTML, CSS, JS, … bestanden.

•

Een lokale server waar enkel het instellingenbestand op staat.

Verschillende browsers (zoals Chrome) kunnen geen JSON bestanden inlezen die niet op een server staan. Hierdoor zal het JSON bestand met alle instellingen dus van een lokale webserver gelezen moeten worden. In Firefox werkt het lokaal inlezen van JSON bestanden echter wel. Indien er met Firefox gewerkt wordt om de website te openen is de lokale server dus overbodig.

3.3.1 WERKING Op de servers van DOOHapps wordt een kopie gemaakt van alle bestanden van de website. Nadat een klant de citytrip app gekocht en geconfigureerd heeft worden alle instellingen opgeslagen naar een JSON bestand en wordt het samen met de andere bestanden naar de media speler gekopieerd. Als lokale webserver wordt Mongoose (figuur 8) gebruikt. Dit is een lightweight webserver die als één bestand gedownload kan worden. Dit bestand wordt dus ook naar de media speler gekopieerd. Wanneer de applicatie moet worden opgestart, start Mongoose ook op in dezelfde map als de website en wordt een browser geopend die naar de Mongoose webserver verwijst. Daarna wordt de browser in full screen gezet en is de applicatie volledig opgestart.

Figuur 8: Mongoose webserver (Mongoose)

20


4. HOE ZORG JE ERVOOR DAT EEN APPLICATIE ZO VLOT MOGELIJK WERKT Om ervoor te zorgen dat de applicatie perfect blijft werken in oudere browsers of op lichte pc’s werd onderzoek gedaan naar performance in Javascript en AngularJS. Eerst werd er gekeken naar enkele basistechnieken die kunnen worden toegepast bij het schrijven van Javascript om de code sneller/minder zwaar te maken. Hierbij wordt aangetoond hoe variabelen het best gedeclareerd worden, hoe best wordt omgegaan met data en wat ‘garbage collection’ is.

Daarna volgen we de structuur van het programma. Eerst wordt er een ommanteling gemaakt om de code in te bewaren. Daarna wordt er gecommuniceerd met de verschillende API’s en worden de teruggegeven gegevens verwerkt. Dit alles gebeurt met de hulp van ‘Promises’ of een ‘Deferred object’. Achteraf worden de gegevens gelinkt met de Google Maps kaart en worden markers aangemaakt. Als laatste wordt de snelheid van het programma gemeten met verschillende tools.

4.1 INTRODUCTIE JAVASCRIPT PERFORMANCE 4.1.1 FUNCTIES Als een deel code meerdere malen gebruikt wordt, steek je deze best in een functie. Zo kan je de code altijd oproepen zonder ze opnieuw aan te maken. Functies kunnen ook gelinkt worden aan variabelen. Dit kan nodig zijn in sommige gevallen, maar dat zorgt er voor dat de functie niet opgeruimd kan worden (figuur 9).

Figuur 9: Function Declaration

4.1.2 VARIABELEN Eerst en vooral zijn er variabelen. Een variabele is een object waar men waarden in kan opslaan. Een variabele kan als lokale of globale variabele aangemaakt worden. Een variabele kan gemaakt worden als globale variabele. Dit wil zeggen dat ze toegankelijk is over het gehele programma. In dit geval wordt de variabele aangemaakt buiten alle functies (figuur 10).

21


Figuur 10: Globale Variabele (W3 Schools)

Wanneer een variabele enkel nodig is in de huidige functie is het beter om er een lokale variabele van te maken. In dit geval wordt ze binnen de functie aangemaakt (figuur 11).

Figuur 11: Lokale variabele (W3 Schools)

Let wel op. Indien er geen ‘var’ voor de variabelenaam staat, wordt het direct een globale variabele (figuur 12).

Figuur 12: Auto globale variabele (W3 Schools)

4.1.3 DOM De invoer van het DOM of Document Object Model heeft HTML bestanden veranderd van tekst met opmaak naar gestructureerde documenten met afzonderlijke objecten. Door het DOM is het mogelijk om vanuit Javascript toegang te krijgen tot die objecten in je HTML document. Toegang tot het DOM is echter heel traag en wordt dus best zo weinig mogelijk gedaan. Ook inline stijlen toewijzen bij het aanpassen van het DOM is afgewezen. Hier komt AngularJS van pas. AngularJS zorgt voor heel veel communicatie met de DOM en doet dit waarschijnlijk ook beter dan als je het zelf zou doen met bijvoorbeeld: jQuery.

4.1.4 JQUERY JQuery is een bibliotheek van verschillende functies als toevoeging aan Javascript. Door jQuery te gebruiken kunnen vaak complexe taken heel gemakkelijk uitgevoerd worden, maar is wel belastend.

22


4.1.5 SCOPE Om meer inzicht te krijgen in de diepe werking van Javascript en zijn performance moest ik eerst weten wat de ‘Scope’ is. Kyle Simpson beschrijft in zijn boek (2014) wat scopes zijn, hoe ze werken en hoe je ze gebruikt. Het belangrijkste is hier samengevat.

4.1.5.1 Wat is de ‘Scope’ In veel programmeertalen zoals Javascript worden variabelen gebruikt om gegevens op te slaan en weer op te halen. Zonder dit proces is een programma maken zo goed als onmogelijk. Hierbij zijn er twee ultieme vragen: waar worden deze variabelen opgeslagen en hoe vindt ons programma ze terug? Het antwoord zit in de ‘Scope’. De ‘Scope’ is een set regels voor het opslaan in een locatie en ophalen op een later tijdstip van variabelen.

4.1.5.2 Hoe werkt ‘Scope’ Om te leren hoe de ‘Scope’ werkt kijken we eerst naar het proces dat de code aflegt alvorens ze uitgevoerd wordt. Bij Javascript wordt de code niet op voorhand gecompileerd zoals C#. De code wordt net vóór het uitvoeren gecompileerd in enkele milliseconden. Bij dit proces zijn er 3 grote spelers: •

Engine (verantwoordelijk voor compilatie en executie van begin tot eind)

•

Compiler (verantwoordelijk voor al het werk i.v.m. code-generatie)

•

Scope (verzamelt en onderhoudt een lijst van variabelen met behoud van de regels voor het ophalen van die variabelen)

In het kort, bij het overlopen van de code converseert de engine constant met de scope over variabelen die de compiler tegenkomt.

4.1.5.3 Nested Scope In sommige gevallen vindt de Scope de gevraagde variabele niet in de huidige functie. In dat geval moet er in de scope van de omringende functie gekeken worden. Dit kan de global scope of een andere functie zijn. Bekijk dit voorbeeld (figuur 13):

Figuur 13: Nested Scope (You Don’t Know JS)

Hier is variabele b niet gedeclareerd binnen de functie, dus wordt deze niet gevonden bij de eerste look-up, maar wel bij de 2e look-up waar hij wel gedeclareerd staat.

23


4.1.5.4 Lexical scope De meest gebruikte manier om variabelen te beheren is ‘Lexical Scope’ (de andere is ‘Dynamic Scope’). Dit verwijst naar Lexing of Tokenizing. Dit is het proces dat de compiler als eerste uitvoert bij het overlopen van de code. Bij Tokenizing wordt een string van karakters opgedeeld in ‘tokens’ die meningsvol zijn. Bijvoorbeeld:

Figuur 14: Lexing 1 (You Don’t Know JS)

Wordt omgezet naar:

Figuur 15: Lexing 2 (You Don’t Know JS)

Zo weet de compiler veel duidelijker wat er met elk deel moet gebeuren.

De ‘Lexical Scope’ past hetzelfde systeem toe op grote delen code. Bijvoorbeeld:

Figuur 16: Bubbles 1 (You Don’t Know JS)

Wordt opgedeeld in 3 ‘Bubbles’.

24


Figuur 17: Bubbles 2 (You Don’t Know JS)

Elke ‘Bubble’ heeft zijn eigen scope en heeft toegang tot variabelen in zijn scope en de omringende scope. Maar niet omgekeerd. Zo heeft Bubble 1 geen toegang tot variabele b en dat is waar scopes net zo belangrijk zijn. Delen code die niet direct leesbaar mogen zijn voor het hele programma kunnen dus ‘verstopt’ worden in een functie.

4.1.5.5 Function & Block scopes Een scope wordt meestal gedefinieerd door het maken van een functie. Dit is in de meeste gevallen voldoende, maar soms kan een scope ook expliciet gemaakt worden. Dit kan op twee manieren: •

Delen code verzamelen in een namespace.

•

Delen code verzamelen in een module.

Dat laatste is verwant met wat gebruikt wordt in Tripler, maar dan als het Angular alternatief (Angular Service). Functies maken om je code meer privaat te maken lijkt dus een goed idee, en dat is het ook. Elke functie die wordt gemaakt krijgt een naam (function declaration) en daarmee vul je de scope, wat dan weer slecht is voor de performance. Om dit te voorkomen is er een systeem genaamd ‘function expression’ (figuur 18). Hiermee kan je een functie maken (en direct uitvoeren) zonder het een naam te geven. Dit ziet er zo uit:

25


Figuur 18: Function Expression (You Don’t Know JS)

Een ‘function expression’ wordt meestal direct uitgevoerd (door () achteraan toe te voegen) omdat het oproepen van de functie alleen maar kan met verouderde taken. Alles hangt er dus van af of de functie op een later tijdstip nog opgeroepen moet worden of niet.

4.1.5.6 Closures Een ‘closure’ wordt automatisch gemaakt bij de code die geschreven wordt. Bekijk onderstaand voorbeeld:

Figuur 19: Closures (You Don’t Know JS)

De functie ‘bar’ wordt direct teruggestuurd bij het einde van de functie ‘foo’. Bij het oproepen van de functie ‘foo’ in variabele ‘baz’ wordt dus eigenlijk de functie ‘bar’ gebruikt. Door de functie op te slaan in een variabele zal de functie niet verwijderd worden als de garbage collector gepasseerd is. Op die manier kan de functie ‘bar’ dus steeds aan alle variabelen in zijn scope. Dit noemt men een closure.

4.1.6 GARBAGE COLLECTION Garbage collection is een vorm van geheugen opruimen bij Javascript. Je kan het gemakkelijker voorstellen als een poetsman die constant bezig is (namelijk de collector). De collector houdt bij welke objecten gebruikt en niet meer gebruikt worden en verwijdert diegene die niet meer nodig zijn. Hierin komen functies, variabelen en scopes tezamen. Wanneer code in een bepaalde scope niet meer gebruikt wordt kan deze opgeruimd worden, maar als er objecten van buiten de huidige scope gebruikt worden, kan er veel minder gekuist worden. De collector weet echter niet of je nog iets van plan bent met die code.

26


Hetzelfde geldt met globale of lokale variabelen. Lokale variabelen kunnen veel sneller opgeruimd worden dan globale omdat hiervan beter bepaald kan worden of het nog nodig is of niet.

4.2 SERVICE Om de volledige code leesbaar, overzichtelijk en beter afgeschermd te maken wordt een Angular Service gemaakt. Services zijn objecten die verschillende stukken code bevatten die georganiseerd en gedeeld kunnen worden. Het is vergelijkbaar met een Javascript module.

Hierin worden alle taken samengevat die het programma nodig heeft om te werken. Korte inhoud: •

Arrays

•

Instellingen ophalen en opslaan

•

Bronnen ophalen en verwerken

•

Foto’s toevoegen, url verkorten, eigen bedrijf toevoegen

Hieronder een voorbeeld van de Tripler Service (figuur 20).

Figuur 20: Tripler Service

4.2.1.1 Instellingen Zoals eerder vermeld heeft de klant de mogelijkheid om verschillende instellingen te maken. Deze instellingen worden via de Toolbox gemaakt en worden mee gekopieerd met de website. Om de instellingen gemakkelijk in en uit te lezen met Javascript wordt JSON gebruikt. JSON is een manier om gegevens te noteren in Javascript. Omdat altijd dezelfde structuur gevolgd wordt verloopt het in- en uitlezen veel sneller. Hieronder een voorbeeld van het instellingenbestand van Tripler (figuur 21).

27


Figuur 21: Tripler Settings

4.2.2 GEGEVENS OPHALEN Na het ophalen van de instellingen kunnen de gegevens van de geselecteerde API opgehaald worden. Omdat dit grote lijsten zijn zou dit normaal de interface voor enkele seconden blokkeren. Om dit te voorkomen worden de gegevens asynchroon opgehaald. Vanaf de 6e versie van de Javascript Engine worden nieuwe functies toegevoegd om acties asynchroon uit te voeren, namelijk Promises. Normaal verloopt de code in een Javascript bestand synchroon (na elkaar). Wat niet wil zeggen dat dit exact van boven naar onder is (functies komen altijd eerst). Dit kan ervoor zorgen dat je programma even vast lijkt te zitten bij grote taken. En dat is storend voor de gebruiker. Om de opdracht naast andere taken te doen lopen, gebruiken we asynchrone functies, waaronder Promises. In 2015 schrijft Kyle Simpson een boek over asynchrone code en performance bij Javascript, hier heb ik heel veel uit geleerd. Alle communicatie met externe services verloopt asynchroon om de user interface niet te verstoren. Bij het initieel laden van de gegevens wordt een laad-animatie getoond.

4.2.2.1 Promise Stel, je bent in een snackbar en bestelt een hamburger. Meestal is de hamburger (noemen we ‘future value’) niet direct klaar en moet je wachten. Om te bevestigen dat je wel degelijk recht hebt op een hamburger krijg je een ticket (‘promise’). Dus houd je je ticket bij en wacht je op de hamburger, in tussentijd kan je nog verschillende andere taken doen, zoals even iemand bellen, of de krant lezen. Je weet dat de hamburger er ooit komt dus moet je niet blijven wachten zonder iets te doen. Na een paar minuten word je ticketnummer afgeroepen en kan je je bestelling gaan afhalen (resolve). Dit is een alledaags concept, maar was voor de invoering van Promises moeilijk te bereiken in Javascript.

28


Er zijn 3 hoofdconcepten bij een Promise. 1. Promise: er wordt beloofd om ooit (onbepaald wanneer) een waarde terug te geven 2. Resolve: de taak is gelukt en een waarde wordt teruggegeven 3. Reject: er is ergens iets verkeerd gegaan, maar je krijgt wel een waarde terug Heel belangrijk aan een Promise is dat er ALTIJD een waarde wordt teruggegeven. De variant van Promises in jQuery noemt men een Deferred Object.

4.2.2.2 Deffered object Een deferred object is de variant van een ‘promise’ in jQuery. Het object kan verschillende callback queues registeren, callback queues starten en het succes of falen van elke synchrone of asynchrone functie doorgeven. Een deferred object wordt heel veel gebruikt wanneer data van een andere server wordt opgehaald en wanneer men niet weet wanneer de data zal toekomen. Door een deferred object te gebruiken in de code is er veel meer controle over de interface. Er kan zelf gekozen worden wanneer en wat er op het scherm getoond wordt en er wordt feedback gegeven als er iets misloopt. In onze service gebruik ik een deferred object voor het ophalen van gegevens bij elke API.

4.2.3 GEGEVENS VERWERKEN De grote lijst die van de API is opgehaald wordt best eerst verwerkt voor ze naar de Scope wordt gestuurd. Pas nadat alle POI’s opgehaald zijn en alle bewerkingen voltooid zijn wordt de array toegevoegd aan de scope. Dit opdat de scope niet telkens aangesproken zou worden. Abraham Polishchuk beschrijft in zijn blog verschillende tips voor prestatieverbetering in Javascript, samen met nog andere leg ik hieronder de belangrijkste uit die ik heb toegepast op de citytrip app.

4.2.3.1 Arrays Grote arrays verbruiken meer. Hou ze dus zo klein mogelijk. Laadt bij het inladen van data (extern of intern) alleen de nodige objecten in. Definieer je array ook zoveel mogelijk op voorhand. Zo weet JS direct welke performance tweaks hij kan uitvoeren op de array. Een array gebruiken (figuur 22) werkt sneller dan een object met verschillende waarden (figuur 23).

Figuur 22: Arrays 1

29


Figuur 23: Arrays 2

4.2.3.2 Loops Elke loop in JS heeft een grote invloed op de performance van de code. Het is dus belangrijk om zo weinig mogelijk loops te schrijven en om ze zo klein mogelijk te houden. Elke call die buiten de loop gemaakt kan worden wordt best erbuiten gemaakt. Ook variabelen die niet binnen de loop veranderen maakt je best erbuiten (figuur 24 & 25).

Figuur 24: Loops 1

Figuur 25: Loops 2

4.3 KAART & MARKERS De integratie van Google Maps in de webapp gebeurt met ‘Angular Google Maps’. Dit is een set van directives om de integratie van Google Maps vlot te doen verlopen in Angular en om de objecten (die we ophalen van de API) te integreren in de kaart als markers. Markers zijn de kleine icoontjes die je op de kaart ziet. Doordat we Angular gebruiken kan op een efficiënte manier een marker toegewezen worden voor elk object in onze lijst. Het logo van de marker kan gedefinieerd worden bij het verwerken van de lijst in de vorige stap. Wanneer op een marker geklikt wordt, komt een InfoWindow tevoorschijn. Hier tonen we de meest relevante informatie die we van de API’s krijgen. De inhoud van dit venster wordt ook bepaald bij het verwerken van de lijst.

4.4 CYCLE Omdat er geen besturing is met muis of beweging moesten we op zoek naar andere mogelijkheden om zoveel mogelijk informatie te tonen op het scherm. Opdat het scherm niet té gevuld zou zijn koos ik ervoor om om de beurt een InfoWindow te openen. Bij het laden van de kaart wordt de lijst van POI’s in willekeurige volgorde gebracht. Daarna opent een AngularJS interval functie om de 10 seconden de volgende InfoWindow. Dit noem ik de ‘cycle’.

30


4.5 TOOLS Bij het toepassen van alle prestatietips wou ik natuurlijk weten of het een positieve invloed had op de app. Om de prestaties van je website te meten zijn er veel tools die gebruikt kunnen worden. De 3 tools hieronder werken zonder extra installaties in Google Chrome.

4.5.1 CONSOLE De console is al een zeer krachtige tool, maar wat velen niet weten is dat je hem ook kan gebruiken als performance checking tool. Met behulp van Console.Time en Console.TimeEnd kan je heel snel zien hoeveel tijd een stuk code nodig heeft om uitgevoerd te worden (figuur 26).

Figuur 26: Console Time

4.5.2 CHROME TIMELINE De timeline toont overzichtelijk welke processen de website vertragen. Om een vlotte website te hebben is het aangeraden om rond de 60 fps lijn te blijven. JS optimalisaties en optimalisatie van je loops kunnen hierbij helpen. Een goed voorbeeld uit de blog van Bhavin Patel uit 2015 hieronder (figuur 27 & 28). Eerst vóór de optimalisaties, als tweede na de optimalisaties. Natuurlijk verbruiken sommige stukken code gewoon veel en zullen die voor enkele milliseconden de website belasten.

Figuur 27: Timeline 1 (Eigendom van Bhavin Patel)

Figuur 28: Timeline 2 (Eigendom van Bhavin Patel)

4.5.3 CHROME PROFILER In de profiler kan nog beter gezien worden op welke lijn in welk bestand een stuk code wordt uitgevoerd en hoeveel tijd het inneemt. Er zijn 3 views. De chart view die veel op de timeline lijkt maar het gemakkelijker maakt om naar een stuk code te navigeren. De Heavy (bottom up) view identificeert de zware user functies en toont de call stack omgekeerd (figuur 29). Dit om gemakkelijk de origine van de functie terug te vinden

31


Figuur 29: Profiler Heavy (Eigendom van Bhavin Patel)

De Tree (top down) view toont de functies van boven naar beneden. Op die manier kan snel gezien worden vanwaar de zware functie origineert (figuur 30).

Figuur 30: Profiler Tree (Eigendom van Bhavin Patel)

32


5. CONCLUSIES 5.1 PROBLEMEN & OPLOSSINGEN 5.1.1 NIEUWE APP Omdat de oude webapp geen mogelijkheid had om instellingen te maken en de website op een externe server moest staan was het niet mogelijk om daarmee verder te werken. In samenwerking met het team in Riga en Michaël werd een volledig nieuwe app ontwikkeld die alle nodige bestanden naar de media speler kopieert en daarna de website opstart vanaf een lokale webserver (Mongoose). Deze app kan vanaf nu gebruikt worden voor alle webapps die door het team of door externe bedrijven gemaakt worden.

5.1.2 INSTELLINGEN De native applicaties kunnen gemakkelijk fysieke bestanden uitlezen, met Javascript is dit wat moeilijker. Dus werd besloten om alle instellingen die in de Toolbox gemaakt worden om te zetten naar een JSON bestand dat mee gekopieerd wordt naar de media speler. Met behulp van de lokale webserver kan dit JSON bestand uitgelezen worden.

5.1.3 ZWAAR BELASTENDE APP Bij de eerste versie van Tripler werd snel duidelijk dat het een zware app is. Er moest dus duidelijk veel optimalisatie gebeuren om de app compatibel te maken met mini-pc’s. Na het volledig performance onderzoek was duidelijk verbetering te zien in de metingen. Bij het testen op de mini-pc was ook te zien dat de app nu veel vlotter werkt.

5.1.4 LOKALE WEBSERVER Als lokale webserver werd gekozen voor Mongoose. Dit is een heel lichte webserver die als één enkel bestand gedownload kan worden. Dit maakt het de perfecte partner om te gebruiken in de webapps. Het Mongoose bestand kan gemakkelijk mee gekopieerd worden met de andere bestanden en daarna opgestart worden.

5.2 BENCHMARKS 5.2.1 TIMELINE Hieronder ziet u de timeline van de citytrip app vóór en na optimalisatie. Bij de eerste metingen worden gedurende bijna de hele meettijd bewerkingen gemaakt (figuur 31).

Figuur 31: Timeline Result Pre

33


Na alle optimalisaties worden enkel bewerkingen gemaakt op het moment van de cycle. De impact van de bewerkingen is dan ook nog eens kleiner op het piekmoment (figuur 32).

Figuur 32: Timeline Result Post

Door de optimalisaties is de workload een stuk minder. Tussen de cycles in is er daarbovenop zo goed als geen verwerking nodig.

5.2.2 PROFILER Hieronder een meting van 33,5 minuten. Er is goed te zien dat er een grote hoeveelheid van de tijd niets gebeurt. Amper 48 seconden wordt besteed aan scripting, omgerekend is dit 0,238 seconden of 238 milliseconden per cycle (figuur 33). Dit resulteert in een vlotte user interface en weinig haperingen tijdens de cycle.

Figuur 33: Scripting Time

5.2.3 CONSOLE TIME Hieronder de resultaten van de Console Time implementaties voor de verschillende delen van het laden (figuur 34). Zoals u kan zien neemt het laden van de applicatie zelf weinig tijd in. Door alle optimalisaties hangt de laadtijd nu vooral af van de externe services en van de verwerking van de POI objecten.

34


Figuur 34: Console Time Resultaat

5.3 RESULTAAT De citytrip applicatie is volledig klaar en de eerste webapp in de DOOHapps App Store is een feit. Iedereen is zeer tevreden over het resultaat, alles werkt voorlopig perfect. Of de applicatie ook echt gebruikt zal worden is nog niet geweten maar het is alleszins een goed voorbeeld voor geïnteresseerde klanten (figuur 35). De nieuwe soort app is ontwikkeld door het team in Riga, Michael en mezelf en kan nu gebruikt worden voor alle toekomstige webapps eventueel met toepassing van de prestatietips die in dit document beschreven staan.

Figuur 35: Tripler resultaat

5.4 GELEERDE LESSEN Gedurende mijn drie maanden stage leerde ik vooral hoe het is om te werken in een startup en om in een team te werken. Iedereen in het bedrijf heeft zijn eigen specialisatie. Als iedereen goed samenwerkt resulteert dit in een goed vooruitgaand bedrijf. Tijdens het performance onderzoek ontdekte ik dat performance ook een heel belangrijk onderdeel is bij het maken van een website bestemd voor productie. Ik leerde heel veel tips bij over hoe ik gemakkelijk mijn code sneller kan maken.

35


Door de boeken van Kyle Simpson leerde ik ook hoe Javascript werkt ‘under the hood’. Het is zeer interessant om te weten hoe je code gelezen, opgeslagen, opgeroepen en opgekuist wordt. Het zal me later zeker helpen om betere code te schrijven.

36


REFERENTIELIJST 1. DIGITALE BRONNEN 1.1 WEBSITES 1. Eventplanner, 12 Innovative TIPS to Attract More People to Your Trade Booth [www], 15-10-2013, Eventplanner.tv https://www.eventplanner.tv/news/5808_12-innovative-tips-to-attract-more-people-toyour-trade-booth.html Gezien op 22-02-2015 2. MarketingDonut, Ten ways to attract visitors to your exhibition stand [www], xx-xxxxxx, MarketingDonut http://www.marketingdonut.co.uk/marketing/exhibitions-and-events/exhibiting/tenways-to-attract-visitors-to-your-exhibition-stand Gezien op 22-02-2015 3. The Display Hub, 8 Sneaky Ways to Attract People to Your Exhibition Stand [www], 01-08-2014, Display Wizard https://www.displaywizard.co.uk/display-hub/8-sneaky-ways-attract-peopleexhibition-stand/ Gezien op 22-02-2015 4. Skyline Whitespace, 4 Effective Ways to Attract People to Your Exhibition Stand [www], xx-xx-xxxx, Skyline Whitespace http://www.skylinewhitespace.com/latest-news/blog/4-effective-ways-attract-peopleexhibition-stand/ Gezien op 22-02-2015 5. Addy Osmani, Writing Fast, Memory-Efficient JavaScript [www], 05-11-2012, SmashingMagazine http://www.smashingmagazine.com/2012/11/05/writing-fast-memory-efficientjavascript/ Gezien op 07-05-2015 6. Todd Motto, Speeding up AngularJS apps with simple optimizations [www], 06-082014, Binpress https://www.binpress.com/tutorial/speeding-up-angular-js-with-simpleoptimizations/135 Gezien op 07-05-2015 7. Abraham Polishchuk, AngularJS Performance in Large Applications [www], xx-xxxxxx, Airpair https://www.airpair.com/angularjs/posts/angularjs-performance-large-applications Gezien op 07-05-2015 8. Bhavin Patel, 11 Tips to improve AngularJS performance [www], 05-05-2015, Bhavin Patel https://itsmebhavin.wordpress.com/2015/05/05/11-tips-to-improve-angularjsperformance/ Gezien op 07-05-2015 9. Jakob Jenkov, AngularJS $watch(), $digest() and $apply() [www], xx-xx-xxxx, Jenkov.com http://tutorials.jenkov.com/angularjs/watch-digest-apply.html Gezien op 08-05-2015

37


10. AngularJS, AngularJS Developer Guide, AngularJS https://docs.angularjs.org/guide Gezien op 04-2015

1.2 EINDWERKEN 1. Feys, Kristof. (2012). Wordpress framework : Mr. Duke. [bachelorproef]. Hogeschool West-Vlaanderen, NMCT. http://search.ugent.be/meercat/x/embed/howestview?q=type%3A%22dissertation%22+library%3A%22GKG%22+wordpress&start= 1&filter=&count=50&sort=&rec=rug01:001940308 2. De Geest, Jonas. (2007). Webdeveloping en graphical design. [bachelorproef]. Hogeschool West-Vlaanderen, NMCT. http://search.ugent.be/meercat/x/embed/howestview?q=type%3A%22dissertation%22+library%3A%22GKG%22+design&start=4&fil ter=&count=50&sort=&rec=rug01:001938415 3. Dewilde, Alexander (2011). Webdesign en -development bij Black and White Company. [bachelorproef]. Hogeschool West-Vlaanderen, NMCT. http://search.ugent.be/meercat/x/embed/howestview?q=type%3A%22dissertation%22+library%3A%22GKG%22+webdesign&start= 0&filter=&count=50&sort=&rec=rug01:001939986

1.3 TIJDSCHRIFTEN 1. Creative Bloq. Net Magazine. http://www.creativebloq.com/net-magazine 2. Creative Bloq. Computer Arts. http://www.creativebloq.com/computer-arts-magazine 3. Web Designer Magazine. http://www.webdesignermagazine.nl/

1.4 EBOOKS 1. Kyle Simpson (2014), You Don’t Know JS: Scope & Closures, Sebastopol: O'Reilly Media 2. Kyle Simpson (2015), You Don’t Know JS: Async & Performance, Sebastopol: O'Reilly Media

2. VAKSPECIALISTEN 1. Frederik De Wachter 2. Michael Boone

38


BIJLAGEN 1. SCOPE IN ANGULARJS Op zijn blog beschrijft Todd Motto de scope en watchers in Angular. Er is echter nog veel meer te vinden over het onderwerp op de officiele Angular website.

1.1 SCOPES & DIGEST CYCLE 1.1.1 SCOPES Angular gebruikt scopes om aan de hand van expressies verschillende opdrachten uit te voeren. Scopes zijn eigenlijk gewoon JS objecten die een voorgedefinieerd protoype schema volgen. Elke verandering aan een scope wordt bijgehouden door $watch.

1.1.2 $WATCH Een watch bestaat uit een value functie en een listener functie. De value functie geeft de waarde van de watch value terug, de listener functie doet wat het moet doen als de value veranderd. Elke variabele die maar één keer gebonden moet worden aan je DOM wordt best gebonden met ‘One-time binding’. Dit wordt gedaan door twee dubbele punten voor de value te zetten ({{::value}}). Wat zeker niet mag is een functie direct binden aan een $watch. Dit zorgt voor grote performance problemen.

1.1.3 $WATCHERS Elke scope houdt een array van functies bij ‘$$watchers’. Elke keer dat een $watch gecalled wordt op een scope value of als een value gelinkt wordt aan het DOM door ‘ng-repeat’, ‘ng-if’, ‘ng-switch’, enz… wordt een functie toegevoegd aan $$watchers.

1.1.4 DIGEST CYCLE Elke keer dat een value in een scope verandert worden alle functies in $$watchers uitgevoerd, als een van die watchers weer een verandering aanbrengen worden alle functies opnieuw uitgevoerd. Dit loopt zo door tot een volledige doorloop van $$watchers geen wijzigingen meer aanbrengt. Dit is de digest cycle. Het is dus de opdracht om $$watchers zo klein mogelijk te houden door er zo weinig mogelijk aan te binden (door ng-repeat, ng-if, …). Als je $watchers gebruikt probeer dan je lijst met data te beperken door gebruik van Track By.

1.1.5 $SCOPE.$APPLY Deze cycle kan manueel gestart worden door $scope.$apply() uit te voeren.

1


In plaats van $scope.$apply te gebruiken die heel de cycle uitvoert kan beter $scope.$digest gebruikt worden. Deze start vanaf de huidige scope en loopt de lijst af tot beneden en overloopt dus minder functies.

2

WEBAPPLICATIES VOOR DIGITAL SIGNAGE & JAVASCRIPT PERFORMANCE

Recommend Documents