Ontwerp en ontwikkeling van een remote bedrijfsbeheerapp voor ios en Android

Academiejaar 2011–2012

Geassocieerde faculteit Toegepaste Ingenieurswetenschappen Valentin Vaerwyckweg 1, 9000 Gent

Ontwerp en ontwikkeling van een remote bedrijfsbeheerapp voor iOS en Android

Masterproef voorgedragen tot het behalen van het diploma van Master in de industriële wetenschappen: informatica

Elias DE CONINCK Promotoren: Jan CNOPS Wim ROOSE

Abstract De laatste jaren heeft Kunstencentrum Vooruit zwaar ge¨ınvesteerd in IT- en gebouwinfrastructuur. Een rechtstreeks gevolg hiervan is de stijgende techniciteit van de uitvoeringsaspecten van de dagelijkse werking (aanpassen inhoud mediascreens, bediening camera’s en gebouwbeheersysteem). Momenteel is er nog geen gebruiksvriendelijk computersysteem dat deze taken kan combineren en deze snel toegankelijk kan maken. Dit eindwerk heeft als doel om deze taken te bundelen in een proof-of-concept applicatie voor smartphones en/of tablets met een voor de hand liggende gebruikersinterface. Dankzij een overkoepelend Wifi-netwerk in het gebouw van de Vooruit kunnen de taken onafhankelijk van de locatie worden uitgevoerd. Om deze app te realiseren op beide platformen werden twee ontwikkelingsomgevingen gebruikt, namelijk Xcode en Android Development Tools. Een groot deel van dit eindwerk bevat het aanleren en het gebruik van deze omgevingen. Na het aanleren van een nieuwe programmeertaal (Objective-C) werd de app eerst ontworpen op iPhone/iPad (iOS) om later over te zetten naar Android. De app is zo ontworpen dat elke functie (bediening camera’s, brandalarm bevestiging, nummer doorschakeling, enz.) ook op zichzelf kan bestaan. De werknemers van de Vooruit krijgen door de uiteindelijke applicatie een goed beeld over wat de mogelijkheden en voordelen zijn van mobiele apparaten binnen de Vooruit. De app kan gebruikt worden als basis voor het verder ontwikkelen van een bepaalde feature.

i

Dankwoord Vooreerst mijn oprechte dank aan de volgende personen: Jan Cnops: docent HoGent en de interne promotor. Wim Roose: hoofd IT-afdeling in de Vooruit en de externe promotor. Dominique De Braeckeleer: gebouwbeheerder in de Vooruit. Wim Van den Breen: tweede lezer van de scriptie. Marc Heiremans: Werknemer bij Somati die mij heeft geholpen bij het onderzoeken van hun remoter. Cedric de Weer: Werknemer bij Schneider Electric die mij het gebouwbeheersysteem van de Vooruit heeft uitgelegd. Wesley Huyghe: Medestudent met een vergelijkbare masterproef waar ik meermaals code mee heb vergeleken. Daarnaast wil ik ook alle andere mensen danken die mij op de één of andere manier geholpen hebben met mijn project in de Vooruit of met het schrijven van deze scriptie.

ii

Woord vooraf Het doel van deze scriptie is aan te tonen wat ik onderzocht en ontwikkeld heb tijdens de masterproef in de Vooruit. Deze scriptie is geschreven in opdracht van “Hogeschool Gent” en “Kunstcentrum Vooruit vzw”. Het is een vereiste voor de gedeeltelijke vervulling van mijn studies “Master in de industriële wetenschappen: Informatica” in HoGent. Dit document behandelt de belangrijkste aspecten van het programmeren van apps voor mobiele toestellen zoals de iPhone, Android gebaseerde smartphones, maar ook tablets. Het eerste gedeelte geeft meer informatie over de gebruikte omgeving, de software en de programmeertaal. Het tweede gedeelte beschrijft de probleemstelling, het onderzoek en de uitwerking in detail.

Elias De Coninck, juni 2012

iii

Inhoudsopgave Abstract

i

Dankwoord

ii

Woord vooraf

iii

Inhoudsopgave

v

Lijst van figuren

vi

Woordenlijst

vii

1 Inleiding

1

2 Kunstcentrum Vooruit vzw. 2.1 Algemeen . . . . . . . . . . . . 2.2 IT-afdeling . . . . . . . . . . . 2.2.1 Algemeen . . . . . . . . 2.2.2 Systemen in de Vooruit

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

2 2 3 3 3

3 Ontwikkelingsomgeving 3.1 Apps ontwikkelen . . . . . . . . . . . 3.2 Soorten apps . . . . . . . . . . . . . 3.2.1 App Store of Android Market 3.2.2 Ad-Hocdistributie . . . . . . 3.2.3 Business 2 Business Apps . . 3.3 iOS . . . . . . . . . . . . . . . . . . . 3.3.1 Objective-C 2.0 . . . . . . . . 3.3.2 Xcode . . . . . . . . . . . . . 3.3.3 iPhone- en iPademulator . . . 3.4 Android . . . . . . . . . . . . . . . . 3.4.1 Android application lifecycle 3.4.2 Java . . . . . . . . . . . . . . 3.4.3 Eclipse . . . . . . . . . . . . . 3.4.4 Android emulator . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

6 7 8 8 8 9 9 10 15 20 20 22 24 24 26

iv

. . . .

. . . .

INHOUDSOPGAVE

v

4 Omschrijving masterproef 4.1 Overzicht . . . . . . . . . . . . . . . . . . . . 4.1.1 Doelstelling . . . . . . . . . . . . . . . 4.1.2 Bestaande situatie en probleemstelling 4.2 Planning . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

27 27 27 27 28

5 Uitwerking features 5.1 Features samenbrengen . . . . . . . . . . 5.2 Camerabewaking . . . . . . . . . . . . . 5.2.1 Mobotix camera’s . . . . . . . . 5.2.2 Axis camera’s . . . . . . . . . . . 5.2.3 Uitwerking . . . . . . . . . . . . 5.3 Somati remoter . . . . . . . . . . . . . . 5.3.1 Website . . . . . . . . . . . . . . 5.3.2 Uitwerking . . . . . . . . . . . . 5.4 OPC-client . . . . . . . . . . . . . . . . 5.4.1 Gebouwbeheersysteem . . . . . . 5.4.2 Deurautomatisering . . . . . . . 5.5 Cisco Call Manager - VoIP . . . . . . . 5.5.1 AXL API . . . . . . . . . . . . . 5.5.2 Telefoondoorschakeling . . . . . . 5.6 Mediascherm bediening . . . . . . . . . 5.7 Opensourcepakketten . . . . . . . . . . . 5.7.1 Hpple . . . . . . . . . . . . . . . 5.7.2 XML-parser: SMXMLDocument 5.7.3 OpenOPC voor Python . . . . . 5.7.4 DejalActivityView . . . . . . . . 5.7.5 GreenDAO . . . . . . . . . . . . 5.7.6 JSoup . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

29 29 30 30 32 32 36 37 38 39 40 41 41 42 44 44 45 45 46 46 47 48 48

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

6 Resultaten

50

7 Conclusie en toekomstperspectieven

52

Literatuurlijst

53

Lijst van figuren 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15

Distributie van een app . . . . . . . . . . . . . . . . . . Multitasking op iPhone 4S . . . . . . . . . . . . . . . . . Xcode 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . Interface Builder . . . . . . . . . . . . . . . . . . . . . . Startscherm Instruments . . . . . . . . . . . . . . . . . . Geheugenlekken en allocations . . . . . . . . . . . . . . Storyboard in Xcode 4 . . . . . . . . . . . . . . . . . . . iPhone emulator . . . . . . . . . . . . . . . . . . . . . . iPad emulator . . . . . . . . . . . . . . . . . . . . . . . . Androidplatform versies - data verzameld op 1 mei 2012 Activity lifecycle . . . . . . . . . . . . . . . . . . . . . . Java broncode omzetting naar Dalvik bytecode . . . . . Android SDK Manager . . . . . . . . . . . . . . . . . . . Android Virtual Device Manager . . . . . . . . . . . . . Android emulator - SDK 4.0.3 . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

8 10 16 17 18 18 19 21 21 22 23 24 25 25 26

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13

Androidproject pakketstructuur . . . . . . . . . . . . . . . . iOS en Android feature lijst . . . . . . . . . . . . . . . . . . Live stream van een videofoon . . . . . . . . . . . . . . . . . Lijst met camera’s en multiviews . . . . . . . . . . . . . . . iOS Core Data relationeel model . . . . . . . . . . . . . . . Opensourcepakket GreenDAO - SQLite connectie . . . . . . Opensourcepakket GreenDAO - Databank generatie project Somati remoter website . . . . . . . . . . . . . . . . . . . . Somati remoter lijst . . . . . . . . . . . . . . . . . . . . . . Gebouw automatisatie (iOS) . . . . . . . . . . . . . . . . . Deurautomatisatie via OPC-server . . . . . . . . . . . . . . Telefoon doorschakelen via VoIP server . . . . . . . . . . . . DjalActivityView - activiteit spinner . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

29 30 31 33 34 34 35 37 39 40 41 44 47

vi

. . . . . . . . . . . . . . .

Woordenlijst ADT AOSP API ARC AVD Manager B2B CM CUCM DCOM DOM FPS GPS GUI HTML IBBT IDE JVM OLE COM OPC DA ORM RPC SAX SDK SOAP VoIP XML

Android Development Tools. Android Open Source Project. Application programming interface. Automatic Reference Counting. Android Virtual Device Manager. Business 2 Business app. Call Manager. Cisco Unified Communications Manager. Distributed Component Object Model. Document Object Model. Frames Per Second. Global Positioning System. Grafische gebruikersinterface. HyperText Markup Language. Interdisciplinair Instituut voor breedbandtechnologie. Integrated Development Environment. Java Virtuele Machine. Component Object Model. Open Productivity & Connectivity Data Access Specification. Object-relational mapping. Remote Procedure Call. Simple API for XML. Software Development Kit. Simple Object Access Protocol. Voice over Internet Protocol. eXtensible Markup Language.

vii

Hoofdstuk 1

Inleiding Dit document beschrijft de ontwikkelingsomgevingen en het ontwikkelingsproces voor het ontwerpen en implementeren van twee mobiele applicaties: enerzijds Android en anderzijds iOS. Het ligt voor de hand dat er grote verschillen zijn tussen normale softwareprojecten en kleine, maar krachtige apps. Beide applicaties moeten dezelfde features bevatten en moeten de werknemers van de Vooruit een goede indruk geven. Het eerste deel situeert deze masterproef binnen Kunstcentrum Vooruit en er wordt extra informatie verleend over de structuur en de werking. Het is noodzakelijk om het ontwikkelde project te plaatsen in de Vooruit omdat het nergens anders kan gebruikt worden. In het tweede deel worden de gebruikte omgevingen besproken met een korte uitleg over de gebruikte programmeertaal. Dit deel heeft niet als doel om de taal aan te leren, wel om achtergrondinformatie te verschaffen die hulp biedt bij de verdere uiteenzetting van deze masterproef. Het derde deel gaat in op de doelstelling en uitwerking van het Android en iOS project. Er wordt verder behandeld hoe de features uitgewerkt zijn en hoe ze samen worden gebracht tot één enkele applicatie. De mobiele app moet uit elkaar getrokken kunnen worden om er aparte applicaties van te maken. De volgende features werden verwacht in het eindresultaat: • Camerabewaking • Brandalarm monitoring • Telefoon doorschakeling • Gebouwbeheer automatisatie • Aansturen mediaschermen Het laatste deel is een opsomming van de resultaten en ook het nut van deze projecten voor de Vooruit worden toegelicht. De gemaakte keuzes worden verklaard en er wordt een conclusie getrokken. 1

Hoofdstuk 2

Kunstcentrum Vooruit vzw. 2.1

Algemeen

Kunstcentrum Vooruit in Gent is uitgegroeid tot één van de bekendste en meest bezochte monumenten in België. Het gebouw dateert van 1913 en heeft reeds een lange levensweg achter de rug. Ferdinand Dierkens, de architect van het gebouw, heeft met dit gebouw zijn naam meer bekendheid gegeven. In de beginjaren van de Vooruit heeft het gebouw veel moeten doorstaan. De openingsfeesten hebben niet kunnen plaatsvinden wegens de Duitse bezetting in de Eerste Wereldoorlog en daarna heeft het gediend als socialistisch volkshuis. Ook de Tweede Wereldoorlog heeft het gebouw overleefd, maar de zalen werden geteisterd door slijtage en wegens gebrek aan onderhoud daalde het aantal activiteiten. Pas in de jaren ’90 is de Vooruit volledig gerestaureerd. Dit gebeurde zaal per zaal, zodat evenementen nog steeds konden doorgaan in de overige zalen. De Vooruit heeft in de loop der jaren ook enkele prijzen in de wacht gesleept. Zo kregen ze een “Europese prijs voor de instandhouding van architecturaal erfgoed” en na de restauratie in 2000 ontving de Vooruit de “Vlaamse Monumentenprijs van het jaar”. Het kunstcentrum brengt ook enkele nadelen met zich mee. Het is niet evident om een kunstcentrum met 2.000 activiteiten en 275.000 bezoekers per jaar uit te baten in een gerestaureerd monument dat dateert van 1913. Het huis wordt geconfronteerd met de zware opdracht van onderhoud, renovatie en aanpassing aan nieuwe noden op het vlak van veiligheid en milieu, podiumtechnische infrastructuur, publiekscomfort, ICT en nieuwe media. Nu wordt kunstcentrum Vooruit veel gebruikt voor allerlei kunstvoorstellingen, maar ook fuiven en optredens horen hier tegenwoordig bij. Door het gebouw en de infrastructuur te blijven vernieuwen kan men nog steeds concurreren met andere kunstcentra.

2

HOOFDSTUK 2. KUNSTCENTRUM VOORUIT VZW.

2.2 2.2.1

3

IT-afdeling Algemeen

Na de voltooiing van de ingrijpende restauratiewerken in 2000, investeerde het huis in een goed uitgerust ICT-netwerk en in controlepunten. Dit gebeurde in een intense samenwerking met het “Interdisciplinair Instituut voor breedbandtechnologie” (IBBT). Een van de projecten is Wireless Building Automation. Dankzij dit systeem kan het huis tot 30% besparen op het verbruik van gas en elektriciteit en een veilige exploitatie garanderen aan 2.500 gelijktijdige bezoekers. Ook digitale video deed zijn intrede in het centraal beheersysteem, met toepassingen zoals audiovisuele streaming en registratie, publieke informatie displaysystemen en camerabewaking. In het kader van het project “Virtual Arts Centre of the Future” lanceerde Kunstencentrum Vooruit in april 2007 als eerste culturele organisatie in Vlaanderen een nieuwe website die volledig op web 2.0-principes geënt is. Vooruit vindt het belangrijk om een technologisch-innovatief antwoord te formuleren op nieuwe en te verwachten behoeftes van kunstenaars, bezoekers, medewerkers en van het gebouw. Ook op het gebied van communicatie wil Vooruit inhaken op nieuwe en te verwachte behoeften van het publiek, de artiesten en de medewerkers. Met het digitaliseringsproject Kunstencentrum van de Toekomst (omtrent vernieuwde vormen van communicatie en interactie in het virtuele kunstencentrum van de toekomst) wil Vooruit investeren in een performante ICT-infrastructuur die het mogelijk maakt om informatie, kennis en cultuur op een digitale manier te beleven. Met de komst van tablets en de groei van de smartphonemarkt wil Vooruit niet achterblijven. Elke ruimte in Vooruit is gedekt door Wifi, dus de faciliteiten om volop in te zetten op mobiele applicaties zijn voorhanden. Op die manier kunnen heel wat applicaties intern beschikbaar gesteld worden zonder in te boeten aan mobiliteit. Dankzij de komst van mobiele apparaten is het mogelijk om de werknemers minder afhankelijk te maken van een vaste werkplek en de workflow te optimaliseren.

2.2.2

Systemen in de Vooruit

Somati remoter Somati is een bedrijf in Erembodegem dat een totaalpakket levert voor branden inbraakbeveiliging. In de Vooruit is hier ook nood aan en vooral het systeem kunnen bedienen aan de hand van een gebruiksvriendelijke interface. Elke ruimte in de Vooruit is voorzien van rookdetectoren en de nodige blusapparaten. Alle detectoren zijn verbonden met een centrale server die meldingen bijhoudt en doorstuurt naar de ge¨ınteresseerden. Soms moet men in een zaal de detectoren uitschakelen voor een bepaalde duur, omdat er tijdens een event of show veel rook wordt gevormd. Het in- en uitschakelen van de zones moet dan ook vlot kunnen gebeuren.


4

De Remoter van Somati be¨ınvloedt de workflow positief. Elke melding die binnenkomt kan bekeken worden op een lokale website en afzonderlijk worden bevestigd en worden gereset. Ook kan men zones die uit dienst zijn genomen terug in dienst nemen zodat de veiligheid steeds kan gegarandeerd worden. De remoter bevat echter te weinig mogelijkheden voor de werknemers. Een zaal of een component, van de brandbeveiliging, kan nog niet worden uitgeschakeld. Hiervoor moet er nog een oplossing gevonden worden. Schneider Electric gebouwbeheersysteem Schneider Electric biedt producten aan die het beheer van een gebouw makkelijker en efficiënter laat verlopen. Energiezuinigheid en energie-efficiëntie zijn heel belangrijk in het bedrijfsleven en daarom heeft Vooruit hier ook veel aandacht aan besteed. Deuren, lichten, ventilatie en andere componenten in de Vooruit zijn verbonden met een centraal gebouwbeheersysteem van Schneider. Hierdoor kan elke werknemer met gepaste rechten via een werkstation het gebouw gaan beheren. Ook de veiligheid wordt gegarandeerd door dit systeem. Met automatisatie kan men bijvoorbeeld de deuren vergrendelen op de sluitingsuren. Het systeem maakt gebruik van Open Productivity & Connectivity Data Access Specification (OPC DA), een protocol ontwikkeld door Microsoft en gebaseerd op het Component Object Model (OLE COM) en het Distributed Component Object Model (DCOM). Het protocol heeft veel gelijkenissen met Remote Procedure Call (RPC) en het heeft ook een continue verbinding waarover data wordt uitgewisseld. Werknemers die het gebouw willen beheren moeten een OPC-client installeren op hun computer. Dit brengt met zich mee dat toegang tot een computer een vereiste is, maar niet in elke ruimte is een computer ter beschikking. Hier kan men terug gebruikmaken van mobiele apparaten om de workflow te optimaliseren. Mobotix camera’s Mobotix AG is een Duits bedrijf dat bekent staat voor zijn netwerkcameratechnologie. De camera’s van Mobotix zijn kleine minicomputers met één of meerdere lenzen die verbonden zijn met het intern netwerk. Elke camera kan manueel en individueel ingesteld of beheerd worden met de meegeleverde software. Het renderen van de beelden en het presenteren van deze beelden gebeurt op de camera’s zelf. Hierdoor is extra software geen vereiste om beelden van camera’s te bekijken, enkel een browser en een computer die op het intranet is aangesloten is vereist. Elke Mobotix camera is uitgerust met drie verschillende ontwikkelniveaus zodat deze in alle omstandigheden kunnen ge¨ıntegreerd worden in softwarepakketten: • HTTP API • MxPEG ActiveX Component


5

• Open Source MxPEG Decoding Library (C++) Voor het ontwikkelen van een mobiele applicatie komt enkel het eerste niveau in aanmerking. Dit is ook veruit de meest gedocumenteerde en meest besproken API. In de Vooruit hangen verschillende type camera’s. Het meest voorkomende type heeft enkel één lens. Het tweede meest voorkomende type zijn de videofoons, dit type maakt het mogelijk om een deur te openen. Het is belangrijk dat elke soort dan ook ondersteund wordt via een mobiele applicatie, zodat men niet steeds een computer in de buurt moet hebben. Cisco Cisco Unified Communications Manager (Call Manager - VoIP) Cisco Unified Communications Manager (CUCUM) is een softwarepakket van Cisco Systems voor het verwerken van telefoongesprekken, videoconferenties, videogesprekken, voicemail en meer. Het systeem wordt beheerd via een webinterface of een softwarepakket van een ander bedrijf die gebruikmaakt van de API. Elke vaste telefoon in de Vooruit is verbonden met de callmanager waardoor gesprekken snel en makkelijk kunnen worden doorgeschakeld naar andere IPtelefoons of externe toestellen. Het doorschakelen naar een ander telefoonnummer moet op eender welke plaats kunnen verwezenlijkt worden. Mediaschermen In de gangen van de Vooruit hangen enkele mediaschermen waarop informatie over de komende activiteiten, huidige evenementen en een kalender te vinden is. De pagina’s op deze schermen worden ontworpen in een externe applicatie om later ge¨ upload te worden. Elk scherm is een minicomputer waarnaar commando’s gestuurd worden. Diverse Buiten de systemen waarmee in deze scriptie gewerkt wordt, bezit de Vooruit nog de meest voorkomende servers. Zo worden gebruikers beheerd via Active Directory en wordt bestandsdeling mogelijk gemaakt door de gepaste serverrollen.

Hoofdstuk 3

Ontwikkelingsomgeving Het ontwikkelen van software voor servers en clients vereist een omgeving die gepast is voor de taal waarin men ze schrijft. Er zijn verschillende Integrated Development Environments (IDE’s) zoals Netbeans en Eclipse, maar voor mobiele ontwikkeling is de keuze beperkter. iPad en iPhone werken op het iOS-besturingssysteem. In tegenstelling tot andere mobiele apparaten werkt iOS met zijn eigen ontworpen taal, Objective-C, die gebaseerd is op C en C++. Dit brengt met zich mee dat een ontwikkelaar een nieuwe taal moet leren en zich volledig moet inwerken in de nieuwe API van Apple. Programma’s ontwikkelen voor OS X (het besturingssysteem van Mac) en iOS gebeurt voornamelijk in Xcode. Xcode is de ontwikkelingsomgeving waarmee men code kan ontwerpen, schrijven en testen. Bij elke nieuwe versie van het besturingssysteem hoort dan ook een nieuwe versie van Xcode met de bijgeleverde Software Development Kits (SDK’s). Android is het besturingssysteem van Google waarmee de meeste smartphones bestuurd worden. Android kan gebruikmaken van een virtuele machine die Java-geoptimaliseerde code kan uitvoer en daarom zijn de meeste programma’s dan ook in Java geschreven. Hierdoor voldoet elke Java-ontwikkelingsomgeving, maar de meest voor de hand liggende keuze is Eclipse. Voor Eclipse bestaat namelijk een plug-in waarmee de juiste SDK kan geselecteerd worden en een Androidemulator kan ingesteld worden. Androidprogramma’s worden in Java geschreven, maar niet alle Java-code is geldige Android Java-code. Men moet zich houden aan de richtlijnen en aan de API van de gebruikte SDK-versie. In tegenstelling tot iOS-ontwikkeling gaat het hier niet om een nieuwe programmeertaal, wat het schrijven van Androidapplicaties makkelijker maakt. Ook het gebruik van een bekende omgeving kan het ontwikkelingsproces versnellen.

6

HOOFDSTUK 3. ONTWIKKELINGSOMGEVING

3.1

7

Apps ontwikkelen

Apps, of applicaties voor mobiele toestellen, ontwikkelen verloopt deels zoals elk ander softwareproject. Er zijn echter enkele belangrijke aspecten die in acht moeten genomen worden bij het ontwerpen van mobile apps, namelijk: • Grafische gebruikersinterface (GUI) • Geheugenbeperking • Draadloze verbinding (3G of Wifi) • Opslagruimte • Levensduur van de batterij De gebruikersinterface is één van de belangrijkste aspecten van een app. De toegang tot de software moet zo gebruiksvriendelijk en intu¨ıtief mogelijk worden gemaakt. Het is belangrijk dat een gebruiker de software kan gebruiken zonder eerst een handleiding door te nemen. Omdat het scherm veel kleiner is dan een desktop of laptop moet de getoonde informatie zo optimaal mogelijk gestructureerd zijn. Veel informatie op één scherm kan negatieve gevolgen hebben voor het gebruiksgemak en de duidelijkheid, daarom krijgt de GUI veel tijd en aandacht. Het tweede belangrijke aspect is het gebruik van het interne geheugen. Mobiele apparaten bezitten een beperkte hoeveelheid intern geheugen en wanneer een applicatie te veel van dit geheugen gebruikt, loopt de de applicatie vast. Het apparaat blijft wel verder functioneren. Objecten aanmaken en vernietigen gebeurt daarom best met veel aandacht en kan best zoveel mogelijk worden vermeden. Een ge¨ınstalleerde app komt terecht in een “sandbox” op het toestel. Een “sandbox” is een ge¨ısoleerde ruimte in het geheugen of de schijf waarin het programma draait. Dit zorgt ervoor dat een applicatie andere programma’s of data van andere programma’s niet kan aanpassen of gebruiken. Er zijn slechts enkele folders op een toestel die kunnen gedeeld worden tussen verschillende applicaties zoals bijvoorbeeld de folder waarin afbeeldingen worden opgeslagen. De verbinding van een mobiel apparaat gebeurt steeds via een draadloos netwerk. Dit heeft als voordeel dat men overal verbinding heeft met het internet en/of intranet, maar deze verbinding is niet feilloos dus kan ze kampen met verbindingsproblemen. Tijdens het onwikkelingsproces moet men steeds rekening houden met het wegvallen van de netwerkverbinding waarbij de werking van de applicatie niet zomaar mag falen. Vervolgens mag men niet vergeten dat de kostprijs van bijvoorbeeld 3G-netwerken niet goedkoop is. Data-uitwisseling tussen client en server moet dus worden beperkt.


3.2

8

Soorten apps

Tijdens het ontwikkelen van een applicatie is het belangrijk het doel en de doelgroep niet uit het oog te verliezen. Het gebruik van een applicatie kan voor iedereen toegankelijk zijn of enkel voor de werknemers van een bedrijf.

Figuur 3.1: Distributie van een app

3.2.1

App Store of Android Market (Google Play )

Distributie via een app store of officiële marketplace vereist een betaalde developers account voor zowel Android als iOS. Bij deze methode is het verplicht de richtlijnen te handhaven. De code wordt gecontroleerd door Apple of Google en wordt pas toegelaten nadat de functionaliteit werd gecontroleerd en de werking overeenkomt met de beschrijving. Dit is de enige methode dat een soort van veiligheidsnorm respecteert. Applicaties die niet doen wat ze beschrijven, worden niet toegelaten. Op deze manier worden de privacy en de gegevens van de gebruiker gegarandeerd. Via het officiële kanaal is het ook mogelijk om advertenties te laten verschijnen in je applicatie zonder hier zelf veel extra aan te coderen. Het doorverkopen en betalen doet Apple of Google zelf en een deel van de inkomsten wordt elke maand uitbetaald.

3.2.2

Ad-Hocdistributie

De tweede optie is een ad-hocinstallatie. Deze methode is voor zowel Android als iOS beschikbaar, al verschillen ze in uitvoering. Applicaties die worden gedistribueerd via de ad-hocmethode worden niet gecontroleerd door Apple of Google en worden meestal gebruikt door bedrijven die interne apps ontwikkelen. Bij Apple moet nog steeds een developers account worden aangeschaft. Met deze account kunnen maximaal 100 iPhones en/of iPads de applicatie installeren. Elk Apple-toestel heeft een uniek globaal nummer dat kan worden ingevoerd in een


9

beheerapplicatie op de developerswebsite. Hierdoor is dit een ideale methode voor kleine bedrijven om hun toestellen te beheren. Bij Google verloopt het proces eenvoudiger en geheel gratis. Enkel de gebruiker van het toestel moet extra stappen ondernemen om externe applicaties toe te laten. De applicaties zelf kunnen via elke site verspreid worden nadat het installatiebestand werd ondertekend. Het ondertekenen van een applicatie kan automatisch gebeuren met Eclipse en een self signed certificaat. Als extra kunnen applicaties ook uitgebracht worden op niet officiële marketplaces, maar dan wel geheel op eigen risico.

3.2.3

Business 2 Business Apps

Business 2 Business apps (B2B Apps) is een distributiemethode enkel toegankelijk voor Apple. Deze methode stelt een ontwikkelaar in staat om applicaties te schrijven die door meerdere bedrijven tegelijk worden gebruikt. Men kan een ander bedrijf dan de toegang verlenen om de applicatie een aantal keer te installeren. Deze methode maakt het mogelijk instellingen te wijzigen per bedrijf, maar wordt in mindere mate gebruikt.

3.3

iOS

Het mobiele besturingssysteem iOS, voordien bekend als iPhone OS, is het besturingssysteem van de iPhone, de iPad, de iPod touch en de Apple TV. Het besturingssysteem is ontwikkeld door Apple Inc. en is gebaseerd op het eerder uitgebrachte Mac OS X, het desktopbesturingssysteem van de Macintosh computers. Dankzij de release van iOS, dat volledig is toegespitst op touch screen bediening, is de smartphone niet meer weg te denken uit de markt. Voordien was bediening door aanraken maar een extraatje dat meestal niet vlot werkte. Met de komst van iOS en later Android is hier veel verandering in gekomen. Het beginscherm, ook wel home screen of springboard genoemd, is duidelijk en intu¨ıtief te gebruiken door zelfs de minst technisch aangelegde persoon. De ontwikkelaar kan aan de hand van enkele hardwaresensoren informatie verschaffen over het toestel. In de iPhone bevinden zich enkele sensoren, namelijk: een accelerometer om de oriëntatie van de telefoon te bepalen, een afstandssensor, lichtsensor en een GPS-ontvanger. Deze sensoren kunnen in elke applicatie gebruikt worden, maar elke sensor gebruikt een extra percentage van de batterij. Sinds iOS 4 kan elke applicatie gebruikmaken van multitasking, dit is een manier om taken in de achtergrond uit te voeren. Het enige verschil met multitasking op een desktop is het feit dat Apple dit beperkt heeft tot enkele mogelijkheden: • Geluid afspelen in de achtergrond • Voice over IP (VoIP)


10

Figuur 3.2: Multitasking op iPhone 4S • Push en lokale notificaties • Taken in de achtergrond uitvoeren (bv. thumbnails in de achtergrond downloaden) • Snel wisselen tussen applicaties • Locatieveranderingen bepalen Gebruikmaken van multitasking moet wel met de nodige zorg gebeuren. Met objective-C kunnen attributen automatisch thread safe gemaakt worden, maar dit heeft wel een nadelig effect op de uitvoeringstijd. Om deze reden wordt het gebruik van thread safe properties meestal vermeden en wordt er getracht om het probleem te omzeilen.

3.3.1

Objective-C 2.0

Objective-C is een superset van C, wat inhoudt dat alle C-code ook geldig is in Objective-C. Maar in Objective-C kan men wel objectgericht programmeren. Objective-C wordt voornamelijk gebruikt op Apple’s Mac OS X en iOS in het Cocoa-framework. Basis Elk object of instantie van een klasse kan berichten ontvangen. In Objective-C wordt met een bericht het aanroepen van een methode op die instantie bedoeld. Bijvoorbeeld om een object aan te maken, roept men het volgende codefragment op: NSObject ∗ o b j e c t = [ [ NSObject a l l o c ] i n i t ] ; object . property = . . . ; [ o b j e c t s e n t M e s s a g e : parameter ] ;


11

Op de eerste lijn wordt het object gealloceerd en ingesteld met zijn beginwaarden. Attributen of properties van objecten worden bekomen of aangepast via de puntnotatie op dezelfde manier als in Java of C#. Het grote verschil met andere talen is dat elke bericht een pointer teruggeeft naar een object (een object zelf wordt niet teruggegeven). Enkel primitieve types mogen wel rechtstreeks doorgegeven worden als parameters van methodes. In de laatste lijn van het codefragment wordt een methode opgeroepen van het object met een parameter. De schrijfwijze of vormgeving van de methodes of berichten is ongewoon voor een Java- of C#-ontwikkelaar. Een methode kan gelezen worden als een zin en de parameters worden op de juiste plaats ingevuld zodat het lezen van de methode verklaart wat de implementatie doet. − ( void ) p e r f o r m S e l e c t o r : (SEL) a S e l e c t o r w i t h O b j e c t : ( id ) anArgument a f t e r D e l a y : ( NSTimeInterval ) d e l a y ; Deze methode is een voorbeeld van een bericht dat op elk object kan opgeroepen worden. Deze methode is ge¨ımplementeerd in de klasse NSObject en alle klassen in Objective-C erven rechtstreeks of onrechtstreeks van NSObject. Na het lezen van deze methode moet het, na een kleine uitleg, reeds duidelijk zijn wat deze methode zal doen. Er zijn twee soorten methodes: klassemethodes en instantiemethodes. Dit wordt aangegeven door een + of - teken voor de declaratie van een methode. Net zoals bij Java is void het lege type dat niets teruggeeft. Verder staat het type “SEL” voor een selectie van een methode. Op deze manier kan men aan berichten een methode meegeven die het moet uitvoeren. En als laatste is er nog het speciale type “id ” dat staat voor een object van elke klasse. Men zou dit type kunnen vergelijken met “NSObject * ”. Het is heel belangrijk in te zien dat het type id reeds een pointer is, dus een * vermelden geeft een pointer naar een pointer. Dus het enige wat de vorige methode doet is een andere methode uitvoeren met als parameter het meegegeven object en dit alles met een korte vertraging. Op deze manier kan men ook multitasking toepassen in iOS. Een langdurige methode kan men aanroepen met dergelijke methodes om de gebruikersinterface niet te verstoren. Properties In Objective-C zijn er twee alternatieven om attributen te beschrijven. Ofwel maakt men gebruik van instantievariabelen (ivar ), die men kan oproepen met berichten, ofwel gebruikt men properties. Vroeger werden ze ook samen gebruikt, maar dit werd onlangs overbodig gemaakt. // i v a r NSObject ∗ anObject ; // p r o p e r t y

HOOFDSTUK 3. ONTWIKKELINGSOMGEVING @property @property @property @property

12

( nonatomic , r e t a i n ) NSObject ∗ anObject ; ( nonatomic , copy ) NSString ∗ a S t r i n g ; ( atomic , a s s i g n ) NSObject ∗ anThreadSafeObject ; ( r e a d o n l y ) NSArray ∗ anArray ;

// g e t t e r s en s e t t e r s implementeren met @ s y n t h e s i z e anObject = a n O b j e c t ; Ivar -variabelen kunnen direct gebruikt worden zoals in Java of andere talen, maar om properties te laten werken moet men ze eerst synthetiseren of zelf een setter en getter implementeren. Het voordeel van properties is dat men hier meer controle op heeft. Door zelf een setter te schrijven kan er voor gezorgd worden dat een object nooit ledig kan zijn of een verkeerde waarde kan krijgen. Door “synthesize” te gebruiken zal de compiler zelf bepalen hoe de setter en getter ge¨ımplementeerd worden. Zo kan men “atomic” gebruiken als optie van het attribuut om deze veilig te maken voor multithreading. Het tweede deel na de = van het “synthesize” commando geeft de gelijknamige instantievariabele die enkel gebruikt wordt in de setter en de getter van het attribuut. // i n s t a n t i e v a r i a b e l e n , p r o p e r t i e s en methodes id var1 = [ anObject a t t r i b u u t ] ; id var2 = [ [ [ anObject a t t r i b u u t 1 ] a t t r i b u u t 2 ] a t t r i b u u t 3 ] ; // e n k e l p r o p e r t i e s id var3 = anObject . a t t r i b u u t ; id var4 = anObject . a t t r i b u u t 1 . a t t r i b u u t 2 . a t t r i b u u t 3 ; In dit voorbeeld wordt duidelijk dat properties de voorkeur krijgen, want bij geneste attributen of methodes wordt het al gauw onduidelijk bij welk deel de vierkante haken horen. Maar wat als “anObject” nu geen waarde heeft, dus “nil ” is? Dan is er geen enkel probleem en krijgt var gewoon de waarde “nil ” Dit is een mechanisme waarop veel Objective-C programmeurs steunen. In Java en andere programmeertalen bevat gelijkaardige code meestal een controle op een null -waarde wat in Objective-C overbodig is.

Retain, assign en copy properties Elk attribuut van een klasse is een pointer naar de data van een ander object. In Objective-C is er geen garbagecollection of reference counting (wel sinds Xcode 4, wat later wordt uitgelegd), hierdoor is men verplicht zelf de objecten vrij te geven of ervoor te zorgen dat ze niet verdwijnen. Retain properties zijn dan ook attributen die worden bijgehouden tot ze weer worden vrijgegeven. Dit kan aan de hand van de retain en release methodes. Copy properties worden enkel gebruikt bij NSString-objecten en worden volledig gekopieerd naar een nieuwe locatie. Ze worden automatisch als retain behandeld. Een assign property is een attribuut dat men zelf niet moet vrijgeven. Het assign attribuut moet wel verwijzen naar een waarde die nog steeds strong pointers heeft, anders bevindt het zich in een ongeldige staat.


13

Klassen In Objective-C worden klassen in twee blokken beschreven en ge¨ımplementeerd. Net zoals in C++ worden deze twee blokken over twee bestanden verdeeld. De declaratie of de interface van de klasse wordt in de header file geplaatst met extensie .h en de implementatie van de klasse in een implementatiebestand met suffix .m. In de nieuwe standaard komen in de headerbestanden enkel properties en methodes die toegankelijk zijn voor het publiek. Methodes en attributen die enkel in de klasse zelf worden gebruikt moeten worden beschreven in het implementatiebestand. Het is nog steeds mogelijk om “@public”, “@private” en “@protected ” te gebruiken voor instantievariabelen, attributen en methodes, maar dit kan de duidelijkheid van de code verminderen. Listing 3.1: klasse.h #import ” . . . ” @interface k l a s s e : s u p e r k l a s s e
{ // i n s t a n t i e v a r i a b e l e n } @property ( nonatomic , s t r o n g ) Type ∗ attribuutNaam ; − ( void ) i n s t a n t i e M e t h o d e ; + ( id ) klasseMethodeMetParameter : ( Type ∗ ) parameter ; @end Het headerbestand bevat de volledige interface van de klassen en kan gezien worden als de API van die klasse. Instantievariabelen worden in de interface nog weinig gebruikt omdat deze de bekende puntnotatie niet toelaten. In plaats daarvan worden properties gebruikt die een bepaald attribuut van de klasse voorstellen. Properties en variabelen hebben bij het aanmaken van een instantie van de klasse de waarde “nil ” of 0. Zoals reeds eerder vermeldt wil “nil ”, in Objective-C, hetzelfde zeggen als “null ” in Java. Listing 3.2: klasse.m #import ” k l a s s e . h” @interface k l a s s e ( ) // p r i v a t e a t t r i b u t e n en methodes @end @implementation k l a s s e @ s y n t h e s i z e attribuutNaam = attribuutNaam ; − ( void ) i n s t a n t i e M e t h o d e { // i m p l e m e n t a t i e i n s t a n t i e m e t h o d e } + ( id ) klasseMethodeMetParameter : ( Type ∗ ) parameter { // i m p l e m e n t a t i e k l a s s e n m e t h o d e return s e l f ; } @end Het implementatiebestand bevat het private gedeelte (declaraties en implementatie). De private interface specificeert men door de klassenaam te volgen door


14

(). Hierna kan men dan extra private properties en methodes declareren. Het implementeren van de klasse gebeurt in een “@implementation”-blok. Protocollen Een protocol wordt in Objective-C gebruikt om een soort van meervoudige overerving toe te staan. Men kan een klasse verplichten om bepaalde methodes te implementeren zodat instanties luisteren naar berichten die beschreven staan in het protocol. Listing 3.3: Declaratie protocol (meestal boven bijhorende klasse) @protocol ProtocolNaam // v e r p l i c h t e methodes − ( void ) someMethod : ( id ) someParameter ; @optional // o p t i o n e l e methodes @required // v e r p l i c h t e methodes @end Standaard is elke methodedeclaratie in een protocol verplicht, maar met het sleutelwoord “@optional ” maakt men optionele berichten ook mogelijk. Implementaties van de methodes gebeurt in de klassen die het protocol gebruiken. Listing 3.4: protocol gebruiken en implementatie in implementatiebestand @interface k l a s s e : NSObject @end

Listing 3.5: Doel van protocollen @property ( nonatomic , weak ) id o b j e c t ; // methode u i t h e t p r o t o c o l u i t v o e r e n [ o b j e c t someMethod :@” someNSString ” ] ; Elke klasse die het protocol implementeert, kan de methodes uit het protocol probleemloos uitvoeren. In de code 3.5 wordt het doel van protocollen aangetoond. Het object kan een antwoord geven op de methodes gedeclareerd in het protocol “ProtocolNaam”, hierdoor is het niet nodig het object te casten naar een ander type. Op deze manier vangt Objective-C het probleem van meervoudige overerving deels op. Ontwikkeling voor iOS maakt veelvoudig gebruik van protocollen, een view heeft dan een delegate namelijk de controller die moet luisteren naar bepaalde berichten. De compiler weet aan de hand van de declaratie van een klasse direct naar welke methodes ze luistert.


15

Categorie¨ en Categorieën worden minder vaak gebruikt, hoewel ze soms een grote hulp kunnen zijn. Een categorie kan een bestaande klasse uitbreiden, zelfs wanneer de toegang tot de broncode geblokkeerd is. Extra methodes schrijven voor NSString of NSObject is zeker niet uitgesloten. Categorieën laten ook toe om bestaande methodes van bestaande klassen te overschrijven zonder die klasse te moeten herschrijven of hercompileren. De methodedeclaratie moet dan identiek zijn aan de methode in de basisklasse. De klasse die uitgebreid wordt met een nieuwe methode of waarin een methode vervangen wordt in een categoriebestand heeft geen weet van deze nieuwe categorie. Listing 3.6: BasisKlasse.h (implementatie niet gegeven) @interface B a s i s K l a s s e @property ( nonatomic , s t r o n g ) NSArray ∗ anArray ; − ( void ) i n s e r t O b j e c t : ( NSObject ∗ ) ; @end Listing 3.7: BasisKlasse+InsertAndRemove.h (implementatie niet gegeven) #import ” B a s i s K l a s s e . h” @interface B a s i s K l a s s e ( InsertAndRemove ) − ( void ) removeObject : ( NSObject ∗ ) ; // nieuwe methode − ( void ) i n s e r t O b j e c t : ( NSObject ∗ ) ; // v e r v a n g e n b e s t a a n d e methode @end Dit fragment voegt een extra methode toe om een object te verwijderen en vervangt de methode om een object toe te voegen. In het implementatiebestand wordt dan zelf gekozen hoe deze methodes ge¨ımplementeerd worden. De naamconventie voor categorieën is voor de hand liggend en verduidelijkt wat de categorie juist doet. De naam van de basisklasse wordt uitgebreid met de naam van de categorie en deze naam beschrijft wat deze toevoegt. Overmatig gebruik van dit mechanisme maakt de projectcode onduidelijk en veroorzaakt verwarring. In sommige gevallen is dit echter onmisbaar. Een goed voorbeeld hiervoor is uitbreiden van automatisch gegenereerde code met eigen methodes. Op deze manier gaat er geen code verloren wanneer de klasse, waarop een categorie van toepassing is, opnieuw wordt gegenereerd. Om een categorie te kunnen gebruiken wordt de categorie ge¨ımporteerd en worden objecten aangemaakt zoals gewoonlijk. Elk object van de klasse ”BasisKlasse” ondersteunt dan de twee extra methodes. Voor klassen die de juiste header niet importeren verandert er niets.

3.3.2

Xcode

De ontwikkelingsomgeving voor iOS en Objective-C is Xcode. Xcode is net zoals Netbeans en Eclipse een IDE. Deze omgeving stelt de ontwikkelaar in staat


16

om projecten te beheren, te testen en te debuggen. Xcode is echter veel uitgebreider dan een doodgewone IDE. Er zijn twee zeer handige extra programma’s beschikbaar, namelijk: Instruments om de performantie te meten en Interface Builder om interfaces te ontwerpen.

Figuur 3.3: Xcode 3 De Xcode-suite is gratis te downloaden vanuit de Mac App Store en is enkel bruikbaar op het Mac OS-besturingssysteem. Vooraleer men kan starten met het ontwerpen van iOS-applicaties moeten de gepaste SDK’s ge¨ınstalleerd worden. Voor nieuwe projecten wordt aangeraden om de laatste SDK-versie te gebruiken. De versie, die in deze scriptie gebruikt wordt, is iOS SDK versie 5. Xcode is ontworpen met het oog op optimalisatie van de werktijd. Alles is met enkele muisklikken bereikbaar of met één enkele toetsencombinatie uitvoerbaar. Eén van de vele handige features is om het headerbestand en het implementatiebestand op hetzelfde moment op het scherm te zien. Een project uitvoeren kan op twee verschillende manieren. Ofwel aan de hand van een emulator die een iPhone of iPad nabootst of rechtstreeks op een mobiel toestel. Beide methodes werken vlot voor zowel debuggen als uitvoeren. Wat men hieruit kan besluiten is dat het gebruik van een toestel in het ontwikkelingsproces niet verplicht is. Enkel wanneer er getest wordt op geheugenlekken kan het voorkomen dat de emulator zelf lekken vertoont. Interface Builder Interface Builder is het programma waarmee snel en overzichtelijk een gebruikersinterface kan worden aangemaakt. Het programma is volledig grafisch en


17

het is niet vereist om code te schrijven om een view aan te maken. Elk nieuw scherm is een nib-bestand. Dit bestand bevat alle informatie over het uitzicht van de view. Wanneer men een nieuw bestand aanmaakt, creëert Xcode drie nieuwe bestanden: een .xib file, een .h header file en een .m implementatie file. Deze drie bestanden samen vormen meestal een viewcontroller. Elk scherm bezit één hoofd viewcontroller waar objecten worden aangemaakt en behandeld. Op een iPhone is het uitzonderlijk om verschillende viewcontrollers tegelijk af te beelden, maar niet geheel uitgesloten. Op de iPad komt dit meer voor, omwille van het grotere scherm.

Figuur 3.4: Interface Builder Een handige functie van Interface Builder zorgt ervoor dat men knoppen, tekstvelden of andere componenten kan koppelen aan code door deze componenten te verbinden met zijn controller object. Het koppelen van een actie aan een bepaalde knop gebeurt net op dezelfde manier, de knop selecteren en verbinden met de juiste plaats in de code en deze actie een naam geven. Dit is handig om bijvoorbeeld een nieuw scherm te laten verschijnen wanneer de knop wordt aangeraakt. Verder kunnen ook stijlattributen van views en/of subviews snel worden aangepast naar de noden van de klant. Dit heeft als gevolg dat het uitzicht van de grafische interface niet noodzakelijk door een programmeur moet gedaan worden. Ook een grafisch designer kan dit ontwerpen. Instruments Instruments is een tool van de Xcode-suite die een ontwikkelaar in staat stelt om een project grondig te debuggen. Objective-C werkt aan de hand van pointers en deze kunnen zich in een ongeldige staat bevinden. Deze problemen opsporen is een tijdrovend proces, maar met deze tool kan het opsporen geoptimaliseerd worden. Aan de hand van Instruments kunnen geheugenlekken opgespoord worden, zombieprocessen worden achterhaald en gecreëerde objecten worden gevolgd.


18

Figuur 3.5: Startscherm Instruments Het opsporen en oplossen van deze problemen is zeer belangrijk omdat een mobiel apparaat een beperkt geheugen heeft. Wanneer deze problemen niet opgelost worden, kan een app vastlopen omdat deze steeds meer en meer geheugen vraagt of zelfs verkeerde acties onderneemt op verkeerde objecten.

Figuur 3.6: Geheugenlekken en allocations

Instruments kan zowel met de emulator als met een echt toestel gebruikt worden. In de beginfase van een project is het zeker niet vereist om steeds te controleren op een mobiel toestel, maar naarmate het project vordert kan de emulator bugs of geheugenlekken vertonen. Hierdoor is het toch aangeraden om, wanneer men lekken vindt in Instruments, maar deze nergens teruggevonden worden in de code, dit eens te testen op een iPhone of iPad. Hiervoor is wel een betaalde developers account nodig.


19

Nieuwe features in Xcode 4 Xcode 4 brengt enkele nieuwe features en beter ge¨ıntegreerde tools met zich mee. Elke nieuwe versie van Xcode is volledig neerwaarts compatibel met voorgaande versies, maar zorgt voor meer mogelijkheden en versnelt het ontwikkelingsproces. • Ingebouwde Interface Builder • StoryBoards • Eén scherm met meerdere tools • Automatisch pointers tellen • Nieuwe tool voor datamodellering • Versie editor compatible met GIT • Automatisch aanvullen en herstellen van broncode • Nieuwe opensource compiler en debugger

Figuur 3.7: Storyboard in Xcode 4

Hieruit worden drie heel belangrijke wijzigingen verder besproken. Als eerste wijziging wordt nu de Interface Builder niet als apart programma meegeleverd, maar wordt het volledig in Xcode ge¨ıntegreerd. Dit brengt met zich mee dat de code nog dichter bij het ontwerp van de grafische interface aansluit. Het is nu heel eenvoudig om vanuit de views (zie fig:3.7), connecties te slepen in de broncode. Op deze manier kan de ontwikkelaar goed volgen welke code er gegeneerd wordt. De tweede wijziging heeft veel te maken met de eerste, het storyboard is een nieuwe manier om de verschillende schermen aan elkaar te koppelen. Een app bestaat meestal uit verschillende schermen of views en voordien was het moeilijk om de flow van een applicatie te volgen. Met de toevoeging van storyboards ligt


20

dit voorgoed in het verleden. De storyboards en interface builder zijn samen ge¨ıntegreerd in Xcode en vormen ze samen een perfecte tool om een grafische interface snel te maken. Ze zijn ook te vergelijken met een bestaand ontwerp. Als laatste is er nog de toevoeging om automatisch pointers te tellen ofwel “Automatic Reference Counting (ARC)”. In de vorige versie van Xcode was het verplicht om zelf code te schrijven zodat objecten worden behouden en nadien ook worden opgekuist. In de plaats van retain-, assign- en copy-properties worden nu weak en strong pointers gebruikt. Een strong pointer is een pointer die zijn waarde steeds bijhoudt of beter het object waarnaar de pointer wijst weet dat er nog een sterke verbinding bestaat. Weak pointers daarentegen wijzen naar objecten, maar deze objecten weten hier niets van. Wanneer een weak pointer verdwijnt, gebeurt er niets. Als een klasse met één of meerdere strong pointers verdwijnt of wordt verwijderd, zal een teller, van het object waar de pointer naar verwees, verlagen. Als deze teller nul wordt, wijst geen enkele strong pointer nog naar dit object en mag het opgekuist worden. Vooraleer dit object volledig opgekuist wordt zal de runtimeomgeving alle weak pointers een nulwaarde geven. Alle nieuwe toevoegingen hebben tot gevolg dat er minder fouten of lekken worden aangemaakt. In het optimale geval zouden er zelfs geen lekken meer mogen ontstaan.

3.3.3

iPhone- en iPademulator

Xcode bevat ook de nodige tools om een programma uit te voeren zoals het op een echt toestel zou functioneren. Sinds Xcode 4 zijn er steeds vier emulators bruikbaar: twee voor de iPhone en twee voor de iPad. Er zijn juist twee emulators per toestel om de verschillende versies te blijven ondersteunen. Eén versie is voor de oudere niet-retinaschermen en de andere voor een retinascherm. Als men steeds beide toestelen correct wil ondersteunen moet elke afbeelding in twee resoluties aanwezig zijn. Het retinascherm heeft namelijk veel meer pixels dan het oudere gewone scherm. De snelheid en de functionaliteit van de emulators kan men vergelijken met de echte toestellen. Hierdoor is een toestel zeker niet vereist tijdens de ontwikkeling van een project.

3.4

Android

Het Android besturingssysteem is een opensource pakket ontwikkeld voor smartphones en tablets. Android’s kernel is gebaseerd op de Linux kernel en wordt ontwikkeld door “Open Handset Alliance” onder leiding van Google. De Android broncode wordt door Goolge als opensource pakket vrijgegeven onder de Apache licentie. Het “Android Open Source Project” (AOSP) zorgt voor het onderhoud en de verdere ontwikkeling van het Android besturingssysteem. Android wordt als besturingssysteem op vele verschillende toestellen gebruikt. De meest bekende toestellen zijn deze van HTC, LG, Samsung en Google. Elke


21

Figuur 3.8: iPhone emulator

Figuur 3.9: iPad emulator fabrikant kan broncode wijzigingen doorvoeren of het uiterlijk van het besturingssysteem wijzigen. Hierdoor ontstaan er honderden verschillende versies van het besturingssysteem, maar de kernel zelf blijft nagenoeg ongewijzigd. Dit toont het grootste nadeel van opensource pakketten en het Androidsysteem. Niet alle toestellen ondersteunen de laatst uitgebrachte versies en meestal opteert de fabrikant om de update niet door te voeren, maar uit te stellen naar

HOOFDSTUK 3. ONTWIKKELINGSOMGEVING Platform Android 1.5 Android 1.6 Android 2.1 Android 2.2 Android 2.3 - Android 2.3.2 Android 2.3.3 - Android 2.3.7 Android 3.0 Android 3.1 Android 3.2 Android 4.0 - Android 4.0.2 Android 4.0.3 - Android 4.0.4

Codename Cupcake Donut Eclair Froyo Gingerbread Honeycomb

Ice Cream Sandwich

22 API Level 3 4 7 8 9 10 11 12 13 14 15

Distribution 0.3% 0.7% 5.5% 20.9% 0.5% 63.9% 0.1% 1.0% 2.2% 0.5% 4.4%

Tabel 3.1: Androidplatform versies - data verzameld op 1 mei 2012 een volgend toestel.

Figuur 3.10: Androidplatform versies - data verzameld op 1 mei 2012 Figuur 3.10 en tabel 3.1 tonen aan dat er heel wat verschillende versies in de omloop zijn. Deze data is verzameld door 14 dagen lang het aantal Android toestellen te tellen die een verbinding maken met Google Play. Hoe nieuwer de versie hoe meer mogelijkheden een ontwikkelaar heeft, maar de doelgroep wordt steeds kleiner. Omdat androidgebruikers niet verplicht worden om hun toestel up-to-date te houden moet een ontwikkelaar rekening houden met de grootte van zijn doelgroep. Om een zo groot mogelijke ondersteuning te bieden is het aangeraden om SDK versie 2.3 te gebruiken. In deze masterproef wordt gebruik gemaakt van 2.2 zodat ook de oudere smartphonetoestellen in de Vooruit de applicatie vlot kunnen draaien.

3.4.1

Android application lifecycle

Een android applicatie bestaat uit één of meerdere Activityklassen. Een Activity is een Javaklasse die één scherm voorstelt en dat zich kan bevinden in verschillende staten. De interactie tussen broncode en de gebruiker verloopt via de Activity klassen en wordt bepaald door de ontwikkelaar.


23

Figuur 3.11: Activity lifecycle Het verloop of de levenscyclus van een applicatie verloopt zo goed als lineair, behalve als er multitaskservices worden opgestart. Een Service is een Javaklasse die achtergrond processen behandelt en dit proces blijft uitvoeren zolang de applicatie in het geheugen is geladen. Een Activity wordt opgestart wanneer dit in beeld komt en afgesloten/verwijderd als het uit beeld gaat. De gehele levenscyclus van een Activity kan samengevat worden als volgt (zie ook figuur 3.11): • De applicatie start op en creëert de eerste Activity. (1, onCreate) • Het scherm is aangemaakt en wordt voorbereid. (2, onStart) • De Activity komt in beeld en behandelt interactie. (3, onResume) • Bij een pop-up of notificatie wordt de activiteit gepauzeerd. Geen interactie meer. (onPause) • Een Activity wordt gestopt als het uit beeld verdwijnt, maar wordt nog steeds in het geheugen bewaard. (onStop) • Bij geheugengebrek worden applicaties één voor één uit het geheugen verwijderd. (onDestroy) Deze levenscyclus verbiedt een Activity om langdurige methodes uit te voeren als het scherm getoond of verwijderd wordt. De lineariteit van deze cyclus wordt ook in de broncode duidelijk. Elke grafische handeling, interactie met de gebruiker of aankondiging van een wijziging moet op de mainthread worden behandeld. In veel android applicaties zal men het volgende fragment tegenkomen: p r i v a t e void doInBackground ( ) { // . . . l o n g p r o c e s s ( downoad images ) runOnUiThread ( new Runnable ( ) { @Override p u b l i c void run ( ) {


24

// u p d a t e GUI } }) ; }

3.4.2

Java

Android apps worden voornamelijk geschreven in Java, maar worden niet uitgevoerd in een Java Virtuele Machine (JVM) op het toestel. Hiervoor maakt Android gebruik van een opensource virtuele machine genaamd Dalvik, dat gebaseerd is op een register. Dalvik software is een VM die elke applicatie in een apart proces opstart en niet één VM die verschillende applicaties draait zoals op een computer. Deze VM is geoptimaliseerd om gebruik te maken van toestelen met weinig geheugen en weinig rekenkracht. Java broncode wordt in de eerste plaats omgezet naar JVM compatibele code namelijk Java bytecode (.class bestanden) aan de hand van een Java compiler. Nadien worden deze bestanden omgezet naar Dalvik executable-bytecode (een .dex bestand die de klassen beschrijft). Een Dalvik bestand kan rechtstreeks op een Android toestel worden uitgevoerd, maar eerst moet de applicatie ge¨ınstalleerd kunnen worden. Hiervoor dient men de applicatie eerst te bundelen tot een apk-installatiebestand. Dit bestand kan dan gebruikt worden om de app te distribueren.

Figuur 3.12: Java broncode omzetting naar Dalvik bytecode Zonder het gebruik van een IDE moeten deze stappen handmatig uitgevoerd worden op de command line en moet het apk-bestand handmatig worden overgedragen op een ontwikkelingstoestel. Een IDE maakt het volledige ontwikkelingsproces eenvoudiger en sneller. Het gebruik van een toestel is niet vereist, maar wel aangeraden.

3.4.3

Eclipse

Java broncode schrijven kan in verschillende IDE’s of zelf in tekstverwerkers. De keuze is hier aan de ontwikkelaar, al heeft Eclipse wel het grootste voordeel.


25

Google heeft een Eclipse Android plug-in geschreven die het ontwikkelen en testen van een Android app aanzienlijk verkort. Android plug-in De Android Development Tools (ADT) stelt een ontwikkelaar in staat snel Android projecten te creëeren , grafische interfaces te ontwerpen, projecten te debuggen en apk-installatiebestanden te genereren. Deze tools worden volledig ge¨ıntegreerd in de Eclipse IDE en voelen meteen vertrouwd aan voor de meeste mensen.

Figuur 3.13: Android SDK Manager

Het eerste deel van het ADT pakket heet Android SDK Manager. Deze manager zorgt ervoor dat de ontwikkelingsomgeving steeds beschikt over de laatste tools en maakt het mogelijk om verschillende versies van de Android SDK te downloaden. Android applicaties moeten getest worden op verschillende versies van het besturingssysteem en daarvoor kunnen andere versies gedownload worden.

Figuur 3.14: Android Virtual Device Manager

Het tweede deel is Android Virtual Device Manager (AVD Manager). Een SDK alleen is niet genoeg. Om een Android project te kunnen testen heeft men een toestel nodig of een emulator met een bepaalde SDK versie. Met de AVD Manager kan met een oneindig aantal emulator toestellen aanmaken met de gewenste hardware eigenschappen. Als ontwerper is het namelijk heel belangrijk om zo veel mogelijk toestellen te ondersteunen en deze ook allemaal te testen. Dankzij deze manager kan dit aan de hand van verschillende emulators. Het meest voor de hand liggende, maar wel meest aangename feature van de tools is de mogelijkheid om Android projecten op identieke manier te starten


26

als Java projecten. Met de plug-in is er geen tussenkomst van de command line nodig. Het opkuisen, builden en debuggen kan uitgevoerd worden in Eclipse op een emulator of een toestel. Het loggen van systeemfouten wordt ook afgebeeld in Eclipse.

3.4.4

Android emulator

De Android emulators meegeleverd met de ADT plug-in kunnen gebruikt worden om een applicatie in ontwikkeling te testen en debuggen. Deze emulator vertoont in tegenstelling tot deze van iPhone enkele tekortkomingen. De snelheid waarmee applicaties draaien kan men niet vergelijken met een fysiek toestel. Standaard is de emulator bijna onbruikbaar wegens de performantie, maar na enige optimalisaties en het verhogen van het beschikbare geheugen kan het een grote hulp zijn.

Figuur 3.15: Android emulator - SDK 4.0.3

Het gebruik van de emulator is niet vereist, maar wel aangeraden als er meerdere versies ondersteund moeten worden. Bij elke nieuwe update van het besturingssysteem kan de layout van de applicatie lichtjes wijzigen. Hierdoor is het zeker aangeraden om enkele versies op voorhand uit te testen.

Hoofdstuk 4

Omschrijving masterproef 4.1 4.1.1

Overzicht Doelstelling

Elk bedrijf of instelling tracht om de workflow te optimaliseren. Dankzij de opkomst van mobiele apparaten is het mogelijk om de werknemers minder afhankelijk te maken van een vaste werkplek. De taak omvat een softwareapplicatie onderzoeken, het ontwerpen en te ontwikkelen voor zowel iOS als Android. De software moet via een gebruiksvriendelijke interface bediend kunnen worden, maar de focus ligt wel op het tonen van zoveel mogelijk features. Het project moet het mogelijk maken om de werknemers taken te laten uitvoeren zonder zich te moeten terugtrekken naar hun werkplaats. Met dit project trachten we de werknemers van de Vooruit de mogelijkheden en voordelen van mobiele apparaten binnen de werkomgeving te tonen. De interface is ondergeschikt en de nadruk ligt dan ook op het tonen van zoveel mogelijk features. De uiteindelijke doelstelling van de masterproef is het ontwerpen en uitwerken van een app voor iOS en Android dat kan dienen als proof-of-concept voor het ontsluiten van bestaande software en services op mobiele toestellen. Dit is nodig om het spanningsveld tussen vaste werkplek en interne mobiliteit van heel wat Vooruitwerknemers te ontmijnen.

4.1.2

Bestaande situatie en probleemstelling

De laatste jaren heeft Kunstencentrum Vooruit zwaar ge¨ınvesteerd in IT- en gebouwinfrastructuur. Een rechtstreeks gevolg hiervan is de stijgende techniciteit van de uitvoeringsaspecten van de dagelijkse werking (aanpassen inhoud mediascreens, bediening camera’s, gebouwbeheersysteem) en dus de noodzaak aan een gebruiksvriendelijk computersysteem dat de taken vanuit één centraal punt (in het bijzonder de smartphone of tablet) op zich kan nemen. In de huidige situatie moet een werknemer steeds gebruikmaken van een desktop 27

HOOFDSTUK 4. OMSCHRIJVING MASTERPROEF

28

of laptop om taken uit te voeren die hij/zij ook onderweg zou kunnen uitvoeren. Dat neemt in de eerste plaats tijd in beslag, maar kost ook geld. Enkele beperkingen in de huidige situatie: • Camera’s en videotelefoons zijn enkel toegankelijk vanop een desktop/laptop. • Brandalarm bevestigen of storing controleren kan enkel via onhandige webinterface. • Beheer van het gebouw gebeurt enkel via het gebouwbeheersysteem ontworpen door Schneider Electric wat enkel toegankelijk is voor Windows desktops. • Telefoon doorschakelen naar een ander telefoonnummer gebeurt op de werkplaats zelf. • Een nieuwe pagina op een mediascherm plaatsen gebeurt met een applicactie geschreven voor desktop computers of met scripts uitvoerbaar op elke vaste computer. Al deze taken vereisen dat de werknemer een vast toestel of laptop heeft dat verbonden is met het intranet. Een laptop heeft al een grotere mobiliteit, maar is nog steeds te log om bij alle activiteiten mee te nemen. Lichte en kleine apparaten komen hier voor beter in aanmerking, maar er is nood aan nieuwe software die deze taken van een gepaste interface voorziet.

4.2

Planning

Zoals bij alle softwareprojecten moet er in de eerst plaats een planning opgesteld worden. De twee projecten verlopen volgens dezelfde planning, maar worden onafhankelijk van elkaar ontwikkeld. Alles is vooral ontwikkeld voor iOS, omdat dit een nieuwe programmeertaal met zich mee bracht en het gebruik van een nieuwe IDE verplicht. De features werden één voor één behandeld en ge¨ımplementeerd zodat het resultaat voldoende werkt. Beide projecten hebben als doel een concept te tonen en de mogelijkheden binnen de Vooruit te testen. Omdat het afgeleverde resultaat geen eindproduct wordt is er geopteerd om Software Prototyping te gebruiken. Deze ontwikkelingsmethode stelde de Vooruit in staat om snel in te spelen op projectwijzigingen of het toevoegen van extra features. Wekelijks werden er dan ook afspraken gepland om de projecten te bekijken en bij te sturen. Omdat het iOS-project als eerste werd ontwikkeld, werd hier ook veel meer tijd ´ enmaal de achterliggende gedachte volledig uitgeschreven en voor ingepland. E´ ge¨ımplementeerd is op het ene systeem kan het sneller overgezet worden op het andere systeem. Door deze aanpak te gebruiken wordt de gespendeerde tijd aan het Android project geminimaliseerd. De totaal gespendeerde tijd werd gelogd via een handige webapplicatie toggl. com.

Hoofdstuk 5

Uitwerking features De masterproef omvat twee mobiele softwareprojecten, maar in dit hoofdstuk zullen vooral de gemeenschappelijke delen besproken worden. Als elk deel apart wordt omschreven voor iOS en Android zou dit document te repetitief en te uitgebreid worden.

5.1

Features samenbrengen

De applicaties omvatten verschillende en erg uiteenlopende features, maar moeten het werk in de Vooruit wel versnellen. Voor deze masterproef worden deze features samen gebundeld tot één mobiele applicatie, maar het moet zo ontworpen zijn dat in de toekomst de features ook op zichzelf kunnen bestaan. Het is namelijk zo dat niet elke gebruiker of medewerker toegang mag krijgen of de nood heeft aan alle features.

Figuur 5.1: Androidproject pakketstructuur

De beide projecten (iOS en Android) worden aan de hand van dezelfde naamconventies ingedeeld. De twee hoofdpakketten zijn be.vooruit.android en be.vooruit.ios en worden dan verder ingedeeld met de features. In elke hoofdmap is er ook een gedeeld pakket (shared ) aanwezig die gebruikt wordt door de meeste features. Op deze manier is het makkelijk om enkel de nodige pakketten te behouden en één feature te extrageren tot één applicatie. 29

HOOFDSTUK 5. UITWERKING FEATURES

30

Figuur 5.2: iOS en Android feature lijst In Android en iOS is het heel makkelijk om de initiële view aan te passen. In beide projecten wordt de feature lijst als eerste initiële view aangeduid (zie fig. 5.2). Dit zorgt voor een duidelijk onderscheid tussen de mogelijkheden en geeft de gebruiker een simpel selectiemenu. Omdat de applicatie eerst is ontworpen op iOS is er getracht de Look & Feel zo goed mogelijk over te brengen naar Android.

5.2

Camerabewaking

Camerabewaking is niet meer weg te denken uit het bedrijfsleven. Elke ruimte wordt gecontroleerd op illegale praktijken of onbevoegde toegang. In de Vooruit maken ze gebruik van IP-camera’s. Deze camera’s zijn kleine minicomputers die kunnen communiceren aan de hand van een beschikbare API. De Vooruit maakt gebruik van verschillende type camera’s en van verschillende fabrikanten waarvan de API verschillend is. Dit bemoeilijkt het ontwikkelen van een applicatie, maar verplicht de ontwikkelaar om generisch te programmeren. De beelden van een IP-camera zijn bij de meeste fabrikanten toegankelijk via een HTTP API. Dit maakt het mogelijk om via een HTTP request een afbeelding stream op te vragen. De ontvangen stream is van het type motion jpeg (mjpg) dat ondersteund is op alle mobiele apparaten.

5.2.1

Mobotix camera’s

Elke Mobotix camera heeft lokale hulppagina’s waar men de HTTP API kan bekijken en onderzoeken. Deze pagina’s zijn beschikbaar via de volgende url: http://ip-adres/cgi-bin/faststream.jpg?help. De streams hebben een aantal opties die kunnen meegegeven worden aan de hand van GET request parameters. Om de streams aan de praat te krijgen op mobiele apparaten moeten de volgende parameters ingevuld worden:


31

• preview: moet gebruikt worden als men meer optie parameters wil gebruiken. • previewsize=640x480: als de preview parameter actief is, moet er een afbeeldingsgrootte worden gespecifieerd. • needlength: verplicht de camera om de lengte met elke frame door te sturen (fix voor Android). • camera=auto: sommige camera types hebben meerdere lenzen. Via deze parameter wordt de juiste lens geselecteerd. De mogelijke waarden zijn: auto, both, left en right. Met de volgende HTTP GET request kan de mjpg stream bekomen worden: http://ip-adres/cgi-bin/faststream.jpg?preview&previewsize= 640x480&needlength&camera=auto. De manier waarop deze stream ontvangen wordt op Android en iOS is verschillend in uitwerking, maar de hoofdgedachte blijft wel gelijk. Dankzij de parameter “needlength” wordt in elke frame van de stream de lengte van de bijhorende data meegestuurd. Deze lengte wordt dan gebruikt om een afbeeldingsobject te creëeren dat met elke nieuwe frame opnieuw wordt getekend. In de Vooruit maken ze ook nog gebruik van een tweede type Mobotix camera. Deze camera’s worden naast een deur geplaatst en maken het mogelijk de deur te openen. Dit zijn dan de parlofoons of videofoons aan de hoofdingangen. Het openen van de deur is ook via dezelfde HTTP API beschikbaar, net zoals bij de videostream. Met de url http://ip-adres//control/rcontrol?action= customfunction&action=sigout&profile=SO_Door wordt de deur enkele seconden geopend.

Figuur 5.3: Live stream van een videofoon


5.2.2

32

Axis camera’s

De Axis camera’s zijn van hogere kwaliteit en sturen meer afbeeldingen door gedurende dezelfde tijdspanne. Zo is de gemiddelde frames per second (fps) van een Mobotix camera slechts 3fps en deze van de Axis camera kan oplopen tot 15fps. Nog een groot verschil is dat de Axis camera’s zich wel houden aan de standaard voor IP-camera’s en dat ze de afbeeldingslengte doorsturen met elke frame. Dit heeft als voordeel dat er minder parameters moeten worden doorgestuurd. De HTTP API is niet lokaal toegankelijk op de camera, maar wordt wel meegeleverd in de handleiding en is ook beschikbaar op het web via http://www.axis.com/techsup/cam_servers/dev/cam_http_api_2_copy_ with_overlay_areazoom.htm. De HTTP GET request waarmee de beelden van deze camera’s worden opgehaald is http://ip-adres/mjpg/video.mjpg.

5.2.3

Uitwerking

Motion jpeg streamen met Android en iOS is mogelijk op beide besturingssystemen omdat dit type standaard ondersteund is. Maar om de connectie af te handelen en de afbeeldingen correct in te lezen, wordt er gebruik gemaakt van third party libraries. Op iOS wordt “MotionJpegImageView” gebruikt, geschreven door Matthew Eagar. Het gaat hier om een klasse die de connectie volledig zelf regelt. De aanvraag, authenticatie en afhandeling van het antwoord gebeurt in de klasse zelf en vergt minimale wijzigingen om in het project toe te voegen. Anderzijds is er voor Android geen kant en klare library die streams kan inlezen. Hier verloopt de connectie en authenticatie onafhankelijk van de stream en behoort deze niet tot dezelfde klasse. Het afhandelen van de stream gebeurt aan de hand van een uitbreiding op “DataInputStream” die de streamframes van elkaar scheidt en doorstuurt naar het scherm. Problemen bij Android Android heeft meer informatie nodig om de stream op te stellen dan iOS. Zo is het verplicht dat elke frame de “Content-Length” specificeert, maar niet alle fabrikanten houden zich aan de standaarden waardoor er kleine verschillen zijn tussen Mobotix en Axis. De schrijfwijze van “Content-Length” is bijvoorbeeld verschillend en kan men opvangen door beide alternatieven te proberen. Het streamen van een camerabeelden was niet de enige vereiste. De volgende aspecten zijn ook één voor één uitgewerkt in het eindproduct: • Deur openen bij videofoons • Wijzigen van de geselecteerde lens • Meervoudige schermen (multiviews): 2 of 4 livestreams tegelijk bekijken • Voorgedefinieerde cameralijst en multiviewlijst die kan worden geupdatet


33

• Handmatig toevoegen en verwijderen van camera’s De eerste twee aspecten zijn al kort aan bod gekomen en zijn zonder extra codeerwerk toegankelijk via de HTTP API van de IP-camera’s. Het derde aspect zorgt er voor dat er een overzicht kan getoond worden van maximaal 4 livestreams. Het ontwerp van de klassen die één stream toont, is hiervoor aangepast zodat de layout wordt aangemaakt op basis van het aantal te tonen streams. Dit maakt het mogelijk om in de toekomst meer streams toe te laten. De laatste twee aspecten kan men groeperen als de persistente data in een databank. Op het toestel wordt een databank gecreëerd met de juiste relaties tussen camera’s en multiviews. Deze data kan dan gebruikt worden om een lijst te genereren zonder verbonden te zijn met het intranet. Op basis van output van een cgi-script op een Vooruit server worden de camera’s en multiviews opgesteld in de databank van de telefoon.

Figuur 5.4: Lijst met camera’s en multiviews

iOS - Core Data en Stanford University klasse Core Data is een onderdeel van het Cocoa framework dat toegankelijk is vanaf iOS SDK 3.0. Het is een module om data te organiseren volgens het Entiteitattribuut-waarde model om vervolgens geserialiseerd te worden in XML, binary of SQLite data. De databank tabellen en relaties kunnen worden aangemaakt via een grafische interface beschikbaar in Xcode. Deze structuur en de tabellen kunnen nadien klassen genereren in Objective-C. De nieuwe gegenereerde klassen erven over van “NSManagedObject” wat staat voor een object dat wordt gecontroleerd door Core Data. Figuur 5.5 beeldt de huidige structuur uit van de persistente data van de camera feature. Elke tabel wordt een entiteit genoemd met zijn attributen. De


34

types en standaardwaarden van deze attributen kunnen ingesteld worden via de grafische databank editor in Xcode. De reden waarom Camera en Multiview entiteit overerft van TableRecord is omdat een tabel in iOS slechts één entiteit kan afbeelden. Door deze overerving is het mogelijk om een lijst te tonen van TableRecords gesorteerd volgens type en naam. Elke entiteit in figuur 5.5 wordt omgezet naar een Objective-C klasse waarmee objecten kunnen aangemaakt, bewerkt en verwijderd worden.

Figuur 5.5: iOS Core Data relationeel model

CoreDataTableViewController is een klasse, die vrij te gebruiken is in alle soorten applicaties, ontworpen door Standford universiteit voor de lessen “CS193p Developing Apps for iOS”. Deze klasse zorgt voor een snelle en makkelijke toegang tot Core Data vanuit een tabel. Door enkele parameters van de klasse in te stellen, wordt de data gesorteerd, opgehaald, getoond en wordt er een cache van gecreëerd. Deze klasse stelt een ontwikkelaar in staat om objecten vanuit een databank te tonen zonder enige moeite. Android - GreenDAO Bij Android is er standaard geen framework of library aanwezig waarmee een databank aangemaakt en beheerd wordt. Er zijn wel vele Object-relational mapping (ORM) tools ontwikkeld door third party ontwikkelaars, maar ze zijn niet zo gebruiksvriendelijk als Core Data in iOS. Voor dit project is er gekozen voor GreenDAO. Het is een gratis open-source project dat Android ontwikkelaars helpt Java-objecten om te zetten naar SQLite tabellen en relaties. Het is deels een library voor een Android project dat moet toegevoegd worden aan het project, maar ook een apart Java project dat Android klassen genereert.

Figuur 5.6: Opensourcepakket GreenDAO - SQLite connectie


35

GreenDAO is een mechanisme om zo weinig mogelijk SQL te schrijven maar toch SQLite te gebruiken. Het is de tussenlaag tussen Java-objecten en de SQLite databank. Nieuwe objecten kunnen aangemaakt worden via een hoofdklasse die gegenereerd wordt via het externe Java GreenDAO project. De gegenereerde code is volledig afhankelijk van de structuur van de databank die opgegeven wordt in het externe project. Op deze manier wordt de voetafdruk van de library zo klein mogelijk gehouden. Het grootste voordeel van GreenDAO heeft betrekking tot het aanmaken van de databank. Normaal moet de programmeur zelf controleren of de data reeds bestaat en indien dit niet het geval is moet hij de structuur en relaties met SQL opbouwen.

Figuur 5.7: Opensourcepakket GreenDAO - Databank generatie project Het project waarmee de Android Code wordt gegenereerd is een normaal Java project met in de main-methode de beschrijving van de entiteiten met hun attributen en hun relaties. Dit project genereert enkele klassen die kunnen gebruikt worden in Android projecten voor communicatie met de databank. Voor elke entiteit worden twee klassen aangemaakt; één om het object te beschrijven en één voor de communicatie met de data. Er worden ook nog twee extra hoofdklassen gegenereerd om de initiële connectie met de databank aan te maken. Aan de hand van volgend codefragment worden de structuur en de relaties beschreven in het Java project: Listing 5.1: Broncode databank generatie project. Schema schema = new Schema ( v e r s i o n , PACKAGE) ; E n t i t y t a b l e R e c o r d = schema . addEntity ( ” TableRecord ” ) ; t a b l e R e c o r d . a dd IdP rop er ty ( ) ; P r o p e r t y cameraId = t a b l e R e c o r d . addLongProperty ( ” cameraId ” ) . getProperty () ; P r o p e r t y m u l t i v i e w I d = t a b l e R e c o r d . addLongProperty ( ” multiviewId ” ) . getProperty () ; t a b l e R e c o r d . a d d S t r i n g P r o p e r t y ( ”name” ) ; . . . // meerdere a t t r i b u t e n E n t i t y camera = schema . addEntity ( ”Camera” ) ; camera . a dd IdP ro per ty ( ) ; P r o p e r t y r e c o r d I d 1 = camera . addLongProperty ( ” r e c o r d I d ” ) . notNull () . getProperty () ;


36

camera . a d d S t r i n g P r o p e r t y ( ” l e n s ” ) ; . . . // meerdere a t t r i b u t e n camera . addToOne ( t a b l e R e c o r d , r e c o r d I d 1 ) ; // hack ( e x t e n d s tablerecord ) t a b l e R e c o r d . addToOne ( camera , cameraId ) ; E n t i t y multiView = schema . addEntity ( ” MultiView ” ) ; multiView . add Id Pro pe rty ( ) ; P r o p e r t y r e c o r d I d 2 = multiView . addLongProperty ( ” r e c o r d I d ” ) . notNull () . getProperty () ; multiView . addToOne ( t a b l e R e c o r d , r e c o r d I d 2 ) ; // hack ( extends tablerecord ) t a b l e R e c o r d . addToOne ( multiView , m u l t i v i e w I d ) ; E n t i t y multiViewToCamera = schema . addEntity ( ” MultiViewToCamera ” ) ; multiViewToCamera . a ddI dP rop er ty ( ) ; P r o p e r t y cameraNr = multiViewToCamera . a d d I n t P r o p e r t y ( ” cameraNr ” ) . g e t P r o p e r t y ( ) ; P r o p e r t y cameraId2 = multiViewToCamera . addLongProperty ( ” cameraId ” ) . g e t P r o p e r t y ( ) ; ToMany cameraToMultiViews = camera . addToMany ( multiViewToCamera , cameraId2 ) ; cameraToMultiViews . o r d e r A s c ( cameraNr ) ; P r o p e r t y multiViewId = multiViewToCamera . addLongProperty ( ” multiViewId ” ) . g e t P r o p e r t y ( ) ; ToMany multiViewsToCameras = multiView . addToMany ( multiViewToCamera , multiViewId ) ; multiViewsToCameras . o r d e r A s c ( cameraNr ) ; new DaoGenerator ( ) . g e n e r a t e A l l ( schema , ” . . / RemoteControllApp / gen ” ) ;

5.3

Somati remoter

Somati, een bedrijf te Erembodegem, combineert en integreert verschillende veiligheidssystemen voor de totaalbeveiliging van gebouwen. In de Vooruit maken ze gebruik van verschillende van deze systemen. De remoter is hier één van, het is een webinterface waarmee storingen en alarmen bekeken kunnen worden. De bedoeling van deze feature is webinterface beschikbaar te maken via mobiele apparaten en er nog extra functionaliteit aan toe te voegen. De volgende items zijn momenteel beschikbaar via de webinterface van de remoter: • Lijst van storingen en zones of adressen uit dienst. • In dienst nemen van uitgeschakelde zones of adressen.


37

• Uit dienst nemen van zones of adressen in storing. • Bevestigen van een storing of alarm. • Resetten van bevestigde storingen of alarmen. Maar de mobiele applicatie moet ook extra functionaliteit toevoegen om een zone in zijn geheel te kunnen uitschakelen. In een kunstcentrum is het niet uitgesloten dat er voorstellingen zijn met rookontwikkeling, hiervoor moet het mogelijk zijn een bepaalde zaal of zone uit dienst te nemen. Volgende items voegen extra functionaliteit toe aan de remoter van Somati: • Lijst van zalen met bijhorende adressen. • Ingeven van starten eindtijd van de uitdienstname. • Overzicht van de geprogrammeerde uitdienstnames.

5.3.1

Website

De website van de remoter is een simpele html-pagina met frames. Via http://ip-adres/stat.html wordt een html-tabel bekomen die de storingen en alarmen bevat. Omdat deze html-code niet 100% volgens de regels is, is het onmogelijk om de gewoonlijke html-parsers te gebruiken voor iOS en Android. Om dit probleem op te lossen wordt er gebruik gemaakt van opensource pakketten die html-fouten kunnen oplossen. Enerzijds is dit JSoup (Java html-parser) voor Android en anderzijds TFHpple voor iOS, maar hier wordt later verder op ingegaan in sectie 5.7.

Figuur 5.8: Somati remoter website

De werking van deze webinterface is met reverse engineering ontdekt. Door de broncode te bekijken en met Wireshark de pakketstructuur te bestuderen is de webapplicatie volledig gekend en is het mogelijk om na te bootsen. Het bevestigen en resetten van storingen verzendt een enkelvoudige HTTP GET request zonder parameters. Het uit of in dienst nemen van een adres of zone wordt via forms behandeld. Elke tabelrij (storing of adres uit dienst) is een form op zich met één of twee inputvelden. Aan de hand van het verzenden van


38

een HTTP POST request met parameters uit de inputvelden kan een zone of adres in of uit dienst genomen worden. Listing 5.2: Broncode voorbeeld adres uit dienst.
Uit d i e n s t P an ee l 2 a d r e s 1 0 . 0 2 1 u i t d i e n s t
Het versturen van een POST request met de parameter ed en waarde value uit het verborgen inputveld naar http://ip-adres/ed.cgi voert een commando uit op de webserver. Dit commando is afhankelijk van de waarde aanwezig in het value veld. In het voorbeeld heeft deze de waarde “Z1879046072 07020A000015”. Het eerste deel voor de spatie is hier een teller en wordt ook gebruikt als cookie en het tweede deel als een combinatie van hexadecimale waarden die een commando selecteren en het adres bepalen. Het tweede deel wordt samengesteld als volgt: • 07 of 03 = commando selecteren. Respectievelijk in dienst nemen en uit dienst nemen. • 02 = centrale nummer. • 0A = het net nummer. • 00 00 = het zone nummer waar het adres zich in bevindt. Mag nul zijn als het adres in dienst wordt genomen. • 15 = het adres nummer. Moet steeds verschillend zijn van nul.

5.3.2

Uitwerking

De implementatie voor Android en iOS ligt voor de hand. Het gaat hier om simpele HTTP request waarvan het antwoord slechts in één geval belangrijk is. De initiële lijst ophalen en de ontvangen broncode converteren naar objecten die kunnen gebruikt worden in een lijst. De extra functionaliteit toevoegen aan de somati remoter gebeurt aan de hand van een Perl-script. Dit script kan opgeroepen worden via een HTTP request omdat het zich bevindt in de cgi-bin folder van de Apache webserver van de Vooruit. Listing 5.3: Linux commando - uit dienst nemen zaal echo ’ . / s o m a t i P o s t R e q u e s t . p l −d −r ” $var {room} ” ’ | a t −q b $var { s t a r t } ‘ ;


39

Figuur 5.9: Somati remoter lijst Het Perl-script wordt gebruikt om een zone of adres uit dienst te nemen op een bepaald tijdstip. Omdat een mobiel toestel niet altijd verbonden is met het intranet kan de verantwoordelijkheid voor een zone in of uit dienst te nemen niet op het toestel zelf worden uitgevoerd. Elk Linux systeem heeft het commando “at” dat een meegeleverde string uitvoert op een gegeven tijdstip. Het fragment (code: 5.3) is het onderdeel van dit script dat een commando voor latere executie klaarstelt. “somatiPostRequest.pl” is een tweede script dat een zaal (optie -r) in dienst neemt (optie -e), uit dienst neemt (optie -d). Dit tweede script is ontwikkeld zodat de server niet blokkeert tijdens de HTTP aanvraag.

5.4

OPC-client

OPC is een serie van standaarden voor automatisering van de industrie. De eerste standaard ontwikkeld door OPC Foundation in samenwerking met Microsoft en automatiseringsfabrikanten is de Data Access Specification (DA), dat eerder bekend stond als de OPC specificatie. Het is deze specificatie die verder gebruikt wordt in de OPC-client voor de mobiele toestellen. De OPC Servers werken enkel op Windows toestellen omdat deze gebruikmaken van Distributed Component Object Model (DCOM) objecten. Dit heeft ook een rechtstreeks gevolg voor het ontwikkelen van een opc-client voor smartphones. Het verplicht de ontwikkelaar om via een gateway te communiceren met de OPC Server. OpenOPC voor Python is een toolkit die kan gebruikt worden om van nietWindows computers te communiceren met een OPC server. Dit pakket bevat een OPC Gateway voor communicatie tussen Win32 COM/DCOM objecten en Python-aanroepen te verzorgen. Deze gateway kan op elk systeem gebruikt worden waarop Python ge¨ınstalleerd is. Python en OpenOPC installeren op smartphones is mogelijk, maar niet aangeraden voor leken, daarom wordt geopteerd om aanroepen te versturen naar een Linux server die de OpenOPC commando’s uitvoert. Door dit extra script kunnen enkele instellingen aan-


40

gepast worden zonder aan de applicatie te sleutelen (OPC server adres, OPC gateway adres, commando’s, ...).

5.4.1

Gebouwbeheersysteem

Figuur 5.10: Gebouw automatisatie (iOS)

Het gebouwbeheersysteem van Schneider Electric werkt door middel van een centrale OPC-server waar verschillende OPC-clients verbinding mee maken. Dit systeem automatiseert de dagdagelijkse handelingen in de Vooruit. Zoals het aanpassen van de temperatuur, ventilatiesnelheid, openen van deuren en zo veel meer. Elk apparaat of component dat geautomatiseerd kan worden staat in verbinding met de OPC-server en kan voorgesteld worden als een object, maar wordt eerder een Data Point genoemd. Elk data point op de server bevindt zich in een hiërarchische boomstructuur aangemaakt door Scheider Electric en bezit enkele attributen en een waarde. Deze boomstructuur kan aan de hand van OpenOPC op elk mobiel toestel doorlopen worden en de waarden kunnen aangepast worden. Dit simpelweg door HTTP aanvragen te versturen naar een zelf geschreven cgi-script die de bijhorende OpenOPC commando’s uitvoert en een antwoord terugstuurt. De uitgewerkte feature op iOS heeft aangetoond dat communicatie met een OPC-server vlot verloopt en het mogelijk is om alles te beheren wat in connectie staat met de server. Omdat deze feature zo uitgebreid is dat de gebruiksvriendelijkheid van de interface in het gedrang komt, heeft de Vooruit een deel van de data points vooropgesteld. In de volgende sectie wordt aangetoond dat het selecteren van één bepaalde set van data points kan helpen tot een overzichtelijkere applicatie. De objecten in een OPC-server worden gegroepeerd volgens type en aansluitingspunt, maar dit is niet altijd de gepaste groepering. Daarom is er een XML-bestand opgesteld om componenten (zoals deurpompen) te groeperen volgens zaal.


41

Figuur 5.11: Deurautomatisatie via OPC-server

5.4.2

Deurautomatisering

Om een beter beeld te geven aan de medewerkers van de Vooruit en vooral aan de medewerkers van de afdeling permanentie is er een groep van data points geselecteerd waarmee de deuren kunnen geopend worden. Dankzij het OPC script en de OpenOPC toolkit is het schrijven van een feature die enkele voorgedefinieerde data points ophaalt heel snel en makkelijk te bekomen. De gegevens van de deuren worden gegroepeerd volgens zaal en opgeslagen op een server van de Vooruit in de vorm van een XML-bestand. Aan de hand van dit bestand kan de volledige lijst opgesteld worden. Zonder enige aanpassing aan de applicatie kan men deuren toevoegen aan het XML-bestand en eventueel de deuren anders groeperen. Deze feature heeft veel minder functionaliteit dan de gebouwbeheerfeature, maar kan wel zonder kennis van ICT gebruikt worden door Vooruit werknemers. De grafische interface en de gebruiksvriendelijkheid van een mobiel softwareproject is altijd belangrijker dan het overdrijven van informatie en mogelijkheden. Het selecteren van een gesloten slot opent de deur en bij een open slot sluit het de deur. Af en toe kan het zich voor doen dat een data point zich in een foutieve staat bevindt. Dit wordt aangeduid met een vraagteken icoon en bij het selecteren hiervan wordt er gevraagd welke waarde geldig is.

5.5

Cisco Call Manager - VoIP

De “Cisco Unified Communications Manager ” (CUCUM) is een softwarepakket in ontwikkeling door Cisco Systems. Het stelt een bedrijf in staat internet telefoongesprekken te routeren, op te nemen, door te verwijzen enzovoort. Door het gebruik van een Call Manager (CM) kunnen interne telefoonnummers (directorynummers) losgekoppeld worden van een toestel. In de Vooruit heeft elke werknemer een nummer waarmee deze kan inloggen op een bepaald toestel.


42

Het beheer van gebruikers en toestellen gebeurt aan de hand van een webinterface beschikbaar voor de administratoren. Deze interface kan gebruikt worden om algemene opties te wijzigen, maar ook om attributen van gebruikers zelf te wijzigen. Zo kan de administrator een directorynummer doorschakelen naar een intern of extern telefoonnummer of een voicemail instellen. Dezelfde handelingen kunnen ook via een vast telefoontoestel zelf bekomen worden. Elk commando, zoals het doorverwijzen naar extern nummer, komt overeen met een speciaal telefoonnummer. Bij het ontwikkelen van de communicatie tussen smartphones en een VoIP server wordt het al snel duidelijk dat de eerste twee manieren geen opties zijn. Het inladen van de webinterface van de CUCUM geeft geen goede resultaten en heeft te veel functionaliteit. Anderzijds is het niet de bedoeling dat het gebruikte mobiele toestel verplicht in het VoIP systeem wordt ingeladen waardoor de communicatie met de VoIP server handmatig moet gebeuren. Het CUCUM (versie 6.1.2.1000-13) systeem in de Vooruit bezit over een extra AXL API. De communicatie verloopt hier via Simple Object Access Protocol (SOAP) berichten.

5.5.1

AXL API

De AXL API is een hulpmiddel voor de Call Manager om instellingen te kunnen wijzigen over het netwerken zonder de webinterface. Elke optie die een administrator in de webinterface kan aanpassen, is ook te veranderen via de AXL API. Het is een communicatiesysteem op basis van de uitwisseling van SOAP berichten. De volledige api staat beschreven in de Cisco AXL Programming Guide for Cisco Unified CallManager. In het document kan men de structuur en de opbouw van afzonderlijke SOAP berichten bestuderen. Een normale SOAP service heeft een volledige beschrijving van de methodes en structuur via een Web Services Description Language (WSDL) bestand, maar de CM van Cisco heeft deze functie niet ge¨ımplementeerd. Hierdoor is de ontwikkelaar verplicht de SOAP berichten in XML-formaat door te sturen met de correcte inhoud die bekomen wordt vanuit de documentatie. De url https://ip-adres:8443/axl/axlapi.wsdl is degene die een antwoord voorziet op alle verzonden SOAP berichten. Listing 5.4: Voorbeeld SOAP bericht - status directorynummer 875 opvragen <s o a p : E n v e l o p e x m l n s : x s i=” h t t p : //www. w3 . o r g /2001/XMLSchema−i n s t a n c e ” x m l n s : x s d=” h t t p : //www. w3 . o r g /2001/XMLSchema” x m l n s : s o a p=” h t t p : // schemas . xmlsoap . o r g / soap / e n v e l o p e / ”> <soap:Body>
875


43

De XML-code in 5.4 is een voorbeeld van een SOAP bericht waarmee de status van een directorynummer kan worden opgevraagd. Het directorynummer is de enige noodzakelijk parameter om de gewenste info op te halen. Het verzenden van een SOAP bericht gebeurt aan de hand van een HTTP POST aanvraag met als body de XML-inhoud en drie extra headervelden: • SOAPAction = De stringwaarde van de actie (opzoeken in AXL documentatie). • Content-Type = text/xml; charset=utf-8 • Content-Lengt = Lengte van het XML-bericht.

Listing 5.5: Verkort antwoord van 5.4 <SOAP−ENV:Envelope xmlns:SOAP−ENV=” h t t p : // schemas . xmlsoap . o r g / soap / envelope /” SOAP−ENV:encodingStyle=” h t t p : // schemas . xmlsoap . o r g / soap / e n c o d i n g / ”> <SOAP−ENV:Header/> <SOAP−ENV:Body>
875 Wim Roose D ev ic e ... f a l s e ... 00419929323 ... Het verkregen antwoord (zie 5.5) bevat alle informatie beschikbaar voor het meegeleverde directorynummer. Dit antwoord kan men vervolgens analyseren


44

en de juiste informatie wordt er uitgehaald om in een mobiele applicatie te gebruiken. Het volledige antwoord bevat veel informatie die meestal overbodig is en deze is dan ook weggelaten uit het voorbeeld. Het antwoord is altijd een XML/SOAP formaat, zelfs wanneer er een fout gebeurd tijdens het opvragen.

5.5.2

Telefoondoorschakeling

Slechts één functie van de call manager wordt gebruikt, en dat slechts sporadisch. Hierdoor is het enkel nodig om die ene feature te implementeren als een feature in de mobiele applicatie. Het doorschakelen van een vaste telefoon naar een extern of intern nummer kan reeds op verschillende manieren bekomen worden, maar er is slechts één manier die momenteel door de werknemers gebruikt wordt. Op een vast toestel kan het huidige directorynummer worden doorgeschakeld aan de hand van een code. Hiervoor is wel toegang vereist tot een toestel wat de mobiliteit beperkt.

Figuur 5.12: Telefoon doorschakelen via VoIP server

In het ontvangen antwoord 5.5 staat de bestemming waarnaar het directorynummer wordt doorgeschakeld. Dit kan aangepast worden door een SOAP bericht te sturen dat een actie onderneemt op de CM server. Op deze manier kan een werknemer zijn directorynummer doorschakelen naar zijn eigen mobiel toestel of gelijk welk ander nummer van op eender welke locatie.

5.6

Mediascherm bediening

De mediaschermen in de Vooruit zijn gewone schermen of schermen met een ge¨ıntegreerde computer. Elk scherm toont een pagina afkomstig van een centrale server. Deze centrale server beheert de pagina’s en het schema wanneer deze pagina’s vertoond moeten worden op een bepaald scherm.


45

Het is mogelijk via de commandline een nieuwe pagina te plaatsen op een scherm. De centrale server heeft namelijk een tekstbestand die het controleert wanneer er wijzigingen worden aan gebracht. Aan dit bestand moeten de uit te voeren commando’s worden toegevoegd. Listing 5.6: Commando om mediascherm uit te schakelen echo ” [ a ( scherm−ip−a d r e s ) ] srvDeviceSendCommand ( \ ” [ gtSYSTEM TERMINAL ] g t T e r m i n a l I n i t ( 1 ) ; \ ” ) ; ” > /mnt/ GT2/GT2\ P r o j e c t s /IDS−m o n i t o r s c r i p t . t x t Wegens tijdgebrek is deze feature niet verder uitgewerkt, maar er is wel bekeken of dit mogelijk is. De volgende gevraagde features zijn onderzocht en kunnen ontworpen worden voor mobiele toestelen: • Voorgedefinieerde pagina’s klaarzetten op de centrale server. • Lijst weergeven van alle beeldschermen in contact met centrale server. • Pagina verzenden naar mediascherm via centrale server. Deze taken kunnen worden uitgevoerd aan de hand van een cgi-script op de call manager zelf of eventueel nog op een andere linux server. Dit script voert dan een gelijksoortig commando uit als in het codefragment 5.6. Alle mogelijke commando’s zijn beschreven in de GT2 API documentatie van de server. Deze documentatie is niet voor het publiek beschikbaar, maar kan wel bekomen worden door ontwikkelaars.

5.7

Opensourcepakketten

Opensourcepakketen zijn niet meer weg te denken uit softwareprojecten, ook niet bij apps. In de loop van deze masterproef zijn er enkele gratis bibliotheken gebruikt om de werklast te verminderen. Een ontwikkelaar moet steeds stilstaan bij elke actie om te controleren of een taak niet uitgevoerd kan worden door opensourceprojecten. Dit omdat het minder tijd en moeite kost om deze te gebruiken en implementeren dan zelf geschreven code.

5.7.1

Hpple

Hpple is een bibliotheek voor iOS geschreven door Geoffrey Grosenbach, Topfunky Corporation en PeepCode Screencasts. Het stelt een ontwikkelaar in staat incorrecte html-pagina’s te parsen naar een TFHpple object. Dit object kan dan onderzocht en doorlopen worden via tags, attributen of volgorde. De ondersteuning voor foutieve html-code heeft gezorgd dat dit pakket gekozen werd. Op is heel belangrijk om foutieve html te ondersteunen, want op het internet zijn er weinig websites die zich volledig aan de standaard houden.


46

Listing 5.7: Hpple documentatie afkomstig van Github projectpagina NSData ∗ data = ; TFHpple ∗ doc = [ [ TFHpple a l l o c ] initWithHTMLData : data ] ; NSArray ∗ e l e m e n t s = [ doc s e a r c h :@” // a [ @ c l a s s =’ t i t l e ’ ] ” ] ; TFHppleElement ∗ e l e m e n t = [ e l e m e n t s o b j e c t A t I n d e x : 0 ] ; [ e content ] ; // Tag ’ s innerHTML [ e tagName ] ; // ”a” [ e a t t r i b u t e s ] ; // NSDictionary o f h r e f , c l a s s , id , e t c . [ e objectForKey :@” h r e f ” ] ; // a c c e s s t o s i n g l e a t t r i b u t e

5.7.2

XML-parser: SMXMLDocument

SMXMLDocument is een DOM XML-parser voor iOS geschreven door meridianapps. Het bestaat uit slechts één klasse die het gebruik van de standaard SAX XML-parser makkelijker maakt. De standaard SAX XML-parser van iOS is heel efficiënt, maar is allesbehalve gebruiksvriendelijk. De SMXMLDocument klasse maakt ook gebruik van de standaard parser (NSXMLParser), maar neemt niet de volledige functionaliteit over en zorgt voor een efficiënte en snelle toegang tot alle tags en attributen van een xmlbestand. Listing 5.8: SMXMLDocument documentatie afkomstig van Github projectpagina // c r e a t e a new SMXMLDocument SMXMLDocument ∗ document = [ SMXMLDocument documentWithData : data e r r o r :& e r r o r ] ; // P u l l o u t t h e node SMXMLElement ∗ books = [ document . r o o t childNamed :@” books ” // Look t h r o u g h c h i l d r e n o f t y p e f o r (SMXMLElement ∗ book in [ books childrenNamed :@” book ” ] ) { // d e m o n s t r a t e common c a s e s o f e x t r a c t i n g XML−d a t a // XML−a t t r i b u t e NSString ∗ i s b n = [ book attributeNamed :@” i s b n ” ] ; // c h i l d node v a l u e NSString ∗ t i t l e = [ book valueWithPath :@” t i t l e ” ] ; // show o f f some KVC magic NSArray ∗ a u t h o r s = [ [ book childNamed :@” a u t h o r s ” ] . c h i l d r e n valueForKey :@” v a l u e ” ] ; }

5.7.3

OpenOPC voor Python

OpenOPC is een toolkit dat onrechtstreeks gebruikt wordt voor de Android en iOS-projecten. Beide platformen kunnen geen DCOM/COM objecten aanspreken op een Windows toestel en hebben hiervoor een gateway service nodig. Het gebruik van de OpenOPC toolkit is ook niet rechtstreeks mogelijk vanop het


47

toestel zelf, hiervoor wordt gebruikt gemaakt van een extra Linux server die een Perl of Python-script gebruikt. Dit script kan met behulp van de commandline tool in de OpenOPC toolkit in verbinding staan met de gateway service. Er zijn twee methodes om de tools te gebruiken. De ene methode maakt enkel gebruik van Python en is dan ook de meest performante manier van verbinding. Hiervoor worden de bibliotheken ge¨ımporteerd in Python om de OpenOPC commando’s vervolgens te kunnen gebruiken als methodes in Python. De andere manier is maken van een Perl-script die de commandlinetool gebruikt. Deze manier is minder performant maar wel beter begrijpbaar en makkelijker in gebruik. Omdat Perl de taal is waarvoor er reeds kennis is verworven is de eerste versie ontwikkeld voor Perl. Later kan deze nog geoptimaliseerd worden door enkel gebruik te maken van Python. Listing 5.9: Minimale Python-code voor communicatie met lokale OPC server import OpenOPC opc = OpenOPC . c l i e n t ( ) opc . c o n n e c t ( ’ Matrikon .OPC. S i m u l a t i o n ’ ) print opc [ ’ Square Waves . Real8 ’ ] opc . c l o s e ( )

5.7.4

DejalActivityView

Figuur 5.13: DjalActivityView - activiteit spinner DejalActivityView, ontwikkeld door Dejal, is een grafisch hulpmiddel om de gebruiker te laten weten dat er een actie aan de gang is. In het iOS-project wordt dit vaak gebruikt wanneer er een langdurig proces wordt opgestart waar de gebruiker moet op wachten. Er zijn verschillende types, maar voor dit project was het de bedoeling dat het volledige scherm ontoegankelijk werd voor de gebruiker waardoor het DejalBezelActivityView type is gebruikt.


48

Listing 5.10: Tonen en verwijderen van view [ D e j a l B e z e l A c t i v i t y V i e w a c t i v i t y V i e w F o r V i e w : s e l f . view w i t h L a b e l :@” Loading ” ] // n e t w e r k i n d i c a t o r i n de s t a t u s b a r [ DejalActivityView currentActivityView ] . s h o w N e t w o r k A c t i v i t y I n d i c a t o r = YES ; [ D e j a l B e z e l A c t i v i t y V i e w removeViewAnimated : YES ] ;

5.7.5

GreenDAO

GreenDAO is een Android ORM tool voor de SQLite databank. Het bevat een bibliotheek om te importeren in een Android project en een apart Java project om Android code te genereren die gebruikt kan worden bij databank aanvragen. GreenDAO probeert de Android SDK aan te vullen met een ORM tool zoals Core Data bij iOS. Momenteel is het product nog steeds in ontwikkeling en er komen steeds extra functies bij. • Snelste ORM voor Android. • Makkelijk aan te leren API. • Geoptimaliseerd voor Android. • Minimaal interngeheugen verbruik. • Voetafdruk van bibliotheek zeer klein (codegeneratie niet inbegrepen in bibliotheek)

5.7.6

JSoup

JSoup is de bekendste html-parser voor Android. Deze bibliotheek is uitgebreider dan de gebruikte html-parser in iOS (Hpple, zie 5.7.1). Met JSoup kan de connectie zelf ook worden geregeld al brengt dit enkele beperkingen met zich mee. Het gebruik van deze bibliotheek heeft de zelfde reden als bij iOS namelijk opgehaalde website bezitten geen geldige html-code. Bovendien kan JSoup ook gebruikt worden als DOM XML-parser waardoor de nood voor een extra XML-bibliotheek of standaard XML-parser vervalt. Listing 5.11: Inlezen html en ophalen tags Document doc = Jsoup . c o n n e c t ( ” h t t p : / / t e s t . com/ ” ) . g e t ( ) ; // o f Document doc = Jsoup . c o n n e c t ( ” h t t p : / / t e s t . com” ) . data ( ” query ” , ” Java ” ) . userAgent ( ” M o z i l l a ” ) . c o o k i e ( ” auth ” , ” token ” ) . timeout (3000) . post () ;


// n a v i g a t i e Element c o n t e n t = doc . getElementById ( ” c o n t e n t ” ) ; Elements l i n k s = c o n t e n t . getElementsByTag ( ” a ” ) ; f o r ( Element l i n k : l i n k s ) { String linkHref = link . attr (” href ”) ; String linkText = link . text () ; }

49

Hoofdstuk 6

Resultaten Het doel van deze masterproef werd verwezenlijkt. Er zijn twee onafhankelijke projecten ontwikkeld: het ene voor iOS en het andere voor Android. Beide applicaties hebben dezelfde uitgewerkte features, maar de iOS versie is iets verder uitgewerkt. Wegens tijdgebrek en problemen bij het overzetten naar Android is het Android gedeelte minder in detail uitgewerkt. De afgewerkte projecten maken het de medewerkers van de Vooruit makkelijker om in te zien welke mogelijkheden mobiele toestellen hebben in de werkomgeving. De gerealiseerde features zijn in de volgende lijst samengevat: • Camerabewaking – Lijst van camera’s en multiviews – Voorgedefinieerde data (camera-adressen, gebruikersnamen, paswoorden) via xml ophalen – Bekijken live stream – Openen deur via videofoon – Lens selecteren bij camera’s met meerdere lenzen – Camera’s verwijderen uit lijst – Fullscreen – In- en uitzoomen (enkel iOS) – Camera handmatig toevoegen (enkel iOS) – Camera eigenschappen bewerken (enkel iOS) • Somati remoter - brandalarm monitoring – Parsen van Somati webinterface - tonen van informatie – In en uit dienst nemen van adressen of zones – Een uitdienstname op voorhand inplannen – Ingeplande uidienstnames beheren • Telefoondoorschakeling via Call Manager 50

HOOFDSTUK 6. RESULTATEN – Bekijken doorschakeling status van Vooruit medewerker – Aanpassen doorschakelingsnummer via netwerk • Gebouwbeheersysteem automatisatie via OPC (enkel iOS) – Tonen van automatisatie componenten – Aanpassen van schrijfbare automatisatie parameters – Eigenschappen tonen van elke automatisatie groep of component • Deur automatisatie via OPC – Lijst van deuren geordend volgens zaal (XML bestand) – Deurstatus weergeven – Gebruiksvriendelijke manier om deuren te openen • Mediaschermen (Enkel mogelijkheden onderzocht)

51

Hoofdstuk 7

Conclusie en toekomstperspectieven Het ontwikkelen van twee onafhankelijke apps (Android en iOS) is tijdrovend en vergt een grondige kennis van beide programmeertalen. Bij deze aanpak zijn er voor- en nadelen. De voordelen hebben te maken met het feit dat alles toegankelijk is en er extra bibliotheken aan de projecten kunnen worden toegevoegd. Bij het gebruik van bijvoorbeeld PhoneGap, een alternatief om twee projecten te ontwikkelen, zijn er al snel enkele beperkingen qua layout en gebruik. De nadelen zijn minder belangrijk in kleine projecten, maar komen al snel tot uiting in grote projecten. De ontwikkeltijd wordt niet verdubbeld, maar er komt wel meer dan de helft bij. De meeste tijd wordt gespendeerd aan het aanleren en opzoeken van de juiste handelingen en structuren. Een nieuwe taal aanleren is nooit vanzelfsprekend, maar omdat het ontwikkelen voor mobiele toestellen toch erg verschilt van gewone softwareprojecten is de kost van het aanleren groter. Eenmaal men goed vertrouwd is met de ontwikkelstructuur en de juiste methodes gaat het ontwikkelen een pak vlotter. In de toekomst kunnen de applicaties, na verdere ontwikkeling, gebruikt worden in zijn geheel of worden opgesplitst naar de jobfunctie binnen de Vooruit. Niet alle werknemers hebben toegang nodig tot elke ontwikkelde feature. Het ontwikkelde product is niet meer slechts een proof-of-concept, want het is deels operationeel en foutloos. Het is wel een hele goede basis om verdere ontwikkelingen in de Vooruit goed te keuren en er delen van over te nemen.

52

Literatuurlijst Websites [1] A lightweight XML parser for iOS (2011). Geraadpleegd op 29 mei 2012 via http: // nfarina. com/ post/ 2843708636/ a-lightweight-xml-parser-for-ios [2] Axis HTTP API (2007). Geraadpleegd op 2 maart 2012 via http: // www. axis. com/ techsup/ cam_ servers/ dev/ cam_ http_ api_ 2_ copy_ with_ overlay_ areazoom. htm [3] Apple Developer (2012). Geraadpleegd op 23 maart 2012 via http: // developer. apple. com [4] Apple Developer distribution (2012). Geraadpleegd op 23 maart 2012 via https: // developer. apple. com/ programs/ ios/ distribute. html [5] Cisco AXL Programming Guide for Cisco Unified CallManager 4.2 (2012).Geraadpleegd op 24 april 2012 via http: //www.cisco.com/en/US/docs/voice_ip_comm/cucm/devguide/axl_ prg/4_2_x/axlpg423.html [6] Cisco Unified Communications Manager (2012). Geraadpleegd op 29 mei 2012 via http: // www. cisco. com/ en/ US/ products/ sw/ voicesw/ ps556/ index. html [7] DejalActivityView: open source iOS project to display an activity indicator with adjustable text (2012). Geraadpleegd op 3 maart 2012 via http: // www. dejal. com/ blog/ 2012/ 02/ dejalactivityview [8] Github: Hpple (2012). Geraadpleegd op 27 februari 2012 via https: // github. com/ topfunky/ hpple [9] Github: Xmldocument (2011). Geraadpleegd op 14 maart 2012 via https: // github. com/ nfarina/ xmldocument [10] Google Developer (2012). Geraadpleegd op 23 maart 2012 via http: // developer. google. com [11] JSoup - Java HTML-parser (2009). Geraadpleegd op 1 mei 2012 via http: // jsoup. org/ 53

LITERATUURLIJST

54

[12] Kunstcentrum Vooruit (2012). Geraadpleegd op 22 maart 2012 via http: // vooruit. be [13] Mobotix (2012). Geraadpleegd op 22 maart 2012 via http: // mobotix. com [14] Mobotix developer (2012). Geraadpleegd op 22 maart 2012 via http: // developer. mobotix. com [15] OPC Foundation (2012). Geraadpleegd op 30 maart 2012 via http: // www. opcfoundation. org/ [16] OpenOPC for Python (2012). Geraadpleegd op 14 april 2012 via http: // openopc. sourceforge. net/ [17] Schneider-Electric (2012). Geraadpleegd op 22 maart 2012 via http: // schneider-electric. com [18] Somati (2012). Geraadpleegd op 22 maart 2012 via http: // somati. be [19] Wikipedia: Android (2012). Geraadpleegd op 16 mei 2012 via http: // en. wikipedia. org/ wiki/ Android_ ( operating_ system) [20] Wikipedia: Cisco Unified Communications Manager (2011). Geraadpleegd op 29 mei 2012 via http: // nl. wikipedia. org/ wiki/ Cisco_ Unified_ Communications_ Manager [21] Wikipedia: Core Data (2012). Geraadpleegd op 12 maart 2012 via http: // en. wikipedia. org/ wiki/ Core_ Data [22] Wikipedia: Dalvik (2012). Geraadpleegd op 17 mei 2012 via http: // en. wikipedia. org/ wiki/ Dalvik_ ( software) [23] Wikipedia: iOS Apple (2012). Geraadpleegd op 24 maart 2012 via http: // nl. wikipedia. org/ wiki/ IOS_ ( Apple) [24] Wikipedia: Objective-C (2012). Geraadpleegd op 24 maart 2012 via http: // nl. wikipedia. org/ wiki/ Objective-C [25] Wikipedia: Xcode (2012). Geraadpleegd op 24 maart 2012 via http: // en. wikipedia. org/ wiki/ Xcode [26] VMs and Dalvik VM (2011). Geraadpleegd op 19 mei 2012 via http: // santhosh0705. wordpress. com/ 2011/ 08/ 25/ vms-and-dalvik-vm/

Videos [27] Stanford University (2011). Videos on itunes U: Developing Apps for iOS - CS193P, School of Engineering.

LITERATUURLIJST

55

Boeken [28] Rogers, R., Lombardo, J., Mednieks, Z. & Meike, G.B. (20 Mei 2009). Android Application Development: Programming with the Google SDK. O’REILLY. ISBN13: 978-0-5965-2147-9. [29] Bennett, G., Fisher, M. & Lees, B. (25 Augustus 2010). ObjectiveC for Absolute Beginners: iPhone, iPad and Mac Programming Made Easy, ISBN13: 978-1-4302-2832-5. [30] Meier, R. (1 Mei 2012). Professional Android 4 Application Development (Wrox Professional Guides). ISBN-13: 978-1-1181-0227-5 [31] Neuburg, M. (2 Juni 2011). Programming iOS 4: Fundamentals of iPhone, iPad, and iPod Touch Development. O’REILLY. ISBN13: 978-14493-8843-0.

Ontwerp en ontwikkeling van een remote bedrijfsbeheerapp voor ios en Android

Recommend Documents