bernhard mostrey new media and communication

Transcription

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 WEB APPLICATIES VOOR DIGITAL SIGNAGE & JAVASCRIPT PERFORMANCE
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 WEB APPLICATIES VOOR DIGITAL SIGNAGE & JAVASCRIPT PERFORMANCE
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
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/
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/
5. Addy Osmani, Writing Fast, Memory-Efficient JavaScript [www], 05-11-2012,
SmashingMagazine
http://www.smashingmagazine.com/2012/11/05/writing-fast-memory-efficientjavascript/
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
7. Abraham Polishchuk, AngularJS Performance in Large Applications [www], xx-xxxxxx, Airpair
https://www.airpair.com/angularjs/posts/angularjs-performance-large-applications
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/
9. Jakob Jenkov, AngularJS $watch(), $digest() and $apply() [www], xx-xx-xxxx,
Jenkov.com
http://tutorials.jenkov.com/angularjs/watch-digest-apply.html
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

bernhard mostrey new media and communication

Transcription

Similar documents

NASIONALE SENIOR SERTIFIKAAT GRADE 12

GRAAD 12 NASIONALE SENIOR SERTIFIKAAT GRAAD 12

Examen VWO

NASIONALE SENIOR SERTIFIKAAT GRAAD 12

NASIONALE SENIOR SERTIFIKAAT GRAAD 12 GRAAD 12

NASIONALE SENIOR SERTIFIKAAT GRAAD 12 GRAAD 12

NASIONALE SENIOR SERTIFIKAAT GRAAD 12 GRAAD 12

onweer van 25/26 mei 2009

Tom van den Broek - Spotting NOS

outfit - Patrick Cycling