Ontwerp en ontwikkeling van een remote bedrijfsbeheerapp voor ios en Android

Transcriptie

1 Academiejaar 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

2

3 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

4 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

5 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

6 Inhoudsopgave Abstract Dankwoord Woord vooraf Inhoudsopgave Lijst van figuren Woordenlijst i ii iii v vi vii 1 Inleiding 1 2 Kunstcentrum Vooruit vzw Algemeen IT-afdeling Algemeen Systemen in de Vooruit Ontwikkelingsomgeving Apps ontwikkelen Soorten apps App Store of Android Market Ad-Hocdistributie Business 2 Business Apps ios Objective-C Xcode iphone- en ipademulator Android Android application lifecycle Java Eclipse Android emulator iv

7 INHOUDSOPGAVE v 4 Omschrijving masterproef Overzicht Doelstelling Bestaande situatie en probleemstelling Planning Uitwerking features Features samenbrengen Camerabewaking Mobotix camera s Axis camera s Uitwerking Somati remoter Website Uitwerking OPC-client Gebouwbeheersysteem Deurautomatisering Cisco Call Manager - VoIP AXL API Telefoondoorschakeling Mediascherm bediening Opensourcepakketten Hpple XML-parser: SMXMLDocument OpenOPC voor Python DejalActivityView GreenDAO JSoup Resultaten 50 7 Conclusie en toekomstperspectieven 52 Literatuurlijst 53

8 Lijst van figuren 3.1 Distributie van een app Multitasking op iphone 4S Xcode Interface Builder Startscherm Instruments Geheugenlekken en allocations Storyboard in Xcode iphone emulator ipad emulator Androidplatform versies - data verzameld op 1 mei Activity lifecycle Java broncode omzetting naar Dalvik bytecode Android SDK Manager Android Virtual Device Manager Android emulator - SDK 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 vi

9 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

10 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

11 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 activiteiten en bezoekers per jaar uit te baten in een gerestaureerd monument dat dateert van 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

12 HOOFDSTUK 2. KUNSTCENTRUM VOORUIT VZW 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 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 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.

13 HOOFDSTUK 2. KUNSTCENTRUM VOORUIT VZW. 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

14 HOOFDSTUK 2. KUNSTCENTRUM VOORUIT VZW. 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, voic 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üpload 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.

15 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

16 HOOFDSTUK 3. ONTWIKKELINGSOMGEVING 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.

17 HOOFDSTUK 3. ONTWIKKELINGSOMGEVING 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 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 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

18 HOOFDSTUK 3. ONTWIKKELINGSOMGEVING 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 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)

19 HOOFDSTUK 3. ONTWIKKELINGSOMGEVING 10 Figuur 3.2: Multitasking op iphone 4S Push en lokale notificaties Taken in de achtergrond uitvoeren (bv. downloaden) thumbnails in de achtergrond 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 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 ] ; o b j e c t. property =... ; [ o b j e c t sentmessage : parameter ] ;

20 HOOFDSTUK 3. ONTWIKKELINGSOMGEVING 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 withobject : ( id ) anargument a f t e r D e l a y : ( NSTimeInterval ) delay ; 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

21 HOOFDSTUK 3. ONTWIKKELINGSOMGEVING ( nonatomic, r e t a i n ) NSObject anobject ( nonatomic, copy ) NSString a S t r i n g property ( atomic, a s s i g n ) NSObject anthreadsafeobject ( readonly ) NSArray anarray ; // g e t t e r s en s e t t e r s implementeren anobject = anobject ; 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.

22 HOOFDSTUK 3. ONTWIKKELINGSOMGEVING 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 te gebruiken voor instantievariabelen, attributen en methodes, maar dit kan de duidelijkheid van de code verminderen. Listing 3.1: klasse.h k l a s s e : s u p e r k l a s s e <p r o t o c o l s > { // 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 ) instantiemethode ; + ( id ) klassemethodemetparameter : ( Type ) parameter 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. k l a s s e ( ) // p r i v a t e a t t r i b u t e n k l a s s attribuutnaam = attribuutnaam ; ( void ) instantiemethode { // implementatie i n s t a n t i e m e t h o d e } + ( id ) klassemethodemetparameter : ( Type ) parameter { // implementatie klassenmethode return s e l f ; Het implementatiebestand bevat het private gedeelte (declaraties en implementatie). De private interface specificeert men door de klassenaam te volgen door

23 HOOFDSTUK 3. ONTWIKKELINGSOMGEVING 14 (). Hierna kan men dan extra private properties en methodes declareren. Het implementeren van de klasse gebeurt in -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 ProtocolNaam // v e r p l i c h t e methodes ( void ) somemethod : ( id ) someparameter // o p t i o n e l e // v e r p l i c h t e Standaard is elke methodedeclaratie in een protocol verplicht, maar met het 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 k l a s s e : NSObject Listing 3.5: Doel van ( nonatomic, weak ) id<protocolnaam> o b j e c t ; // methode u i t het 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.

24 HOOFDSTUK 3. ONTWIKKELINGSOMGEVING 15 Categorieën 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 B a s i s K l a s s ( nonatomic, strong ) NSArray anarray ; ( void ) i n s e r t O b j e c t : ( NSObject ) Listing 3.7: BasisKlasse+InsertAndRemove.h (implementatie niet gegeven) #import B a s i s K l a s s e. 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 ) ; // vervangen bestaande 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 Basis- Klasse ondersteunt dan de twee extra methodes. Voor klassen die de juiste header niet importeren verandert er niets 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

25 HOOFDSTUK 3. ONTWIKKELINGSOMGEVING 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

26 HOOFDSTUK 3. ONTWIKKELINGSOMGEVING 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.

27 HOOFDSTUK 3. ONTWIKKELINGSOMGEVING 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.

28 HOOFDSTUK 3. ONTWIKKELINGSOMGEVING 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

29 HOOFDSTUK 3. ONTWIKKELINGSOMGEVING 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 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

30 HOOFDSTUK 3. ONTWIKKELINGSOMGEVING 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

31 HOOFDSTUK 3. ONTWIKKELINGSOMGEVING 22 Platform Codename API Level Distribution Android 1.5 Cupcake 3 0.3% Android 1.6 Donut 4 0.7% Android 2.1 Eclair 7 5.5% Android 2.2 Froyo % Android Android Gingerbread 9 0.5% Android Android % Android 3.0 Honeycomb % Android % Android % Android Android Ice Cream Sandwich % Android Android % 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 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.

32 HOOFDSTUK 3. ONTWIKKELINGSOMGEVING 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 ( ) { //... long p r o c e s s ( downoad images ) runonuithread ( new Runnable ( ) p u b l i c void run ( ) {

33 HOOFDSTUK 3. ONTWIKKELINGSOMGEVING 24 } }) ; } // update GUI 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 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.

34 HOOFDSTUK 3. ONTWIKKELINGSOMGEVING 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

35 HOOFDSTUK 3. ONTWIKKELINGSOMGEVING 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 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 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.

36 Hoofdstuk 4 Omschrijving masterproef 4.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 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

37 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 voor ingepland. Éénmaal de achterliggende gedachte volledig uitgeschreven en 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.

38 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

39 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 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: 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:

40 HOOFDSTUK 5. UITWERKING FEATURES 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: 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 customfunction&action=sigout&profile=so_door wordt de deur enkele seconden geopend. Figuur 5.3: Live stream van een videofoon

41 HOOFDSTUK 5. UITWERKING FEATURES 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 with_overlay_areazoom.htm. De HTTP GET request waarmee de beelden van deze camera s worden opgehaald is 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

42 HOOFDSTUK 5. UITWERKING FEATURES 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

43 HOOFDSTUK 5. UITWERKING FEATURES 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

44 HOOFDSTUK 5. UITWERKING FEATURES 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 ( version, PACKAGE) ; Entity tablerecord = schema. addentity ( TableRecord ) ; tablerecord. addidproperty ( ) ; Property cameraid = tablerecord. addlongproperty ( cameraid ). getproperty ( ) ; Property multiviewid = tablerecord. addlongproperty ( multiviewid ). getproperty ( ) ; tablerecord. addstringproperty ( name ) ;... // meerdere a t t r i b u t e n Entity camera = schema. addentity ( Camera ) ; camera. addidproperty ( ) ; Property r e c o r d I d 1 = camera. addlongproperty ( r e c o r d I d ). notnull ( ). getproperty ( ) ;