Ontwikkelen van een mobiele betaaloplossing

Maat: px
Weergave met pagina beginnen:

Download "Ontwikkelen van een mobiele betaaloplossing"

Transcriptie

1 owered by TCPDF ( Academiejaar Faculteit Ingenieurswetenschappen en Architectuur Valentin Vaerwyckweg Gent Ontwikkelen van een mobiele betaaloplossing Masterproef voorgedragen tot het behalen van het diploma van Master in de industriële wetenschappen: informatica Dieter LAMBRECHT Promotoren: Geert VAN HOOGENBEMT Joury GOKEL (J4S BVBA) Begeleider: Christof AMEYE (J4S BVBA)

2 Woord vooraf Vooreerst mijn oprechte dank aan mijn interne promotor Geert Van hoogenbemt. Met zijn wijze raad en waardevolle commentaar leidde hij dit project in goede banen en werd het op tijd inleveren van deze scriptie haalbaar. Verder wil ik ook mijn dank betuigen aan het bedrijf J4S zonder wie dit leervolle en boeiende onderwerp niet mogelijk was. Mijn dank gaat speciaal uit naar mijn externe promotor Joury Gokel voor zijn waardevolle raad en suggesties die voor een meerwaarde zorgden. Zijn bijzondere kennis over de betalingswereld leidde ook tot verrassende achtergrondinformatie. Daarnaast wil ik ook mijn begeleider Christof Ameye bedanken bij wie ik steeds terecht kon met problemen. Met zijn deskundige begeleiding heeft hij mij fantastisch geholpen en zijn ervaring leidde vaak tot interessante besprekingen. Ook aan de rest van het team in Kortrijk een woord van dank voor de toffe werksfeer en de vele leuke momenten. Het team in Hasselt wil ik ook bedanken voor de tips en informatie in verband met betaalkaarttransacties. Ten slotte nog een speciaal woord van dank aan mijn familie voor de niet te onderschatten morele steun en taaltips. Dieter Lambrecht Anzegem

3 Abstract Het doel van dit project is om een mobiele betaaloplossing te ontwikkelen die toelaat om een virtuele eenheid tussen twee partijen te verhandelen. Deze eenheid heeft een bepaalde waarde. Dit kan echt geld zijn, maar ook evengoed spaarpunten of een eigen bedachte valuta voor bijvoorbeeld een drankbonnetjessysteem. Iedere partij moet op een veilige, gebruiksvriendelijke manier kunnen betalen en ontvangen. De consument kan met de mobiele applicatie op websites betalen (e-commerce-transacties) en/of in de winkel direct betalen (commerce-transacties) aan de handelaar die ook zo n applicatie heeft. De consumenten kunnen onderling ook eenvoudig (kleine) bedragen uitwisselen wanneer ze elkaar tegenkomen (face-to-face-transacties). Voor de handelaar wordt het een all-in-one-oplossing. De applicatie biedt namelijk ook de mogelijkheid om op de klassieke manier via betaalkaarten geld te ontvangen van de klanten die de mobiele toepassing nog niet gebruiken. Overview The main goal of this project is to develop a mobile payment solution which allows two parties to trade a virtual amount. This amount has a certain value. It can be real money, savings, or even a self-invented currency for a beverage ticket system. Each stakeholder has to be able to pay and receive in a secure and user-friendly way. The consumer can pay with the mobile app on websites (e-commerce transactions) and/or directly in a store (commerce transactions) to the merchant who also has such an app. The consumers can easily pay small amounts to each other when they meet (face-to-face transactions). It s an all-in-one solution for the merchant. The same application also offers the opportunity to let customers pay with regular payment cards when they don t have the mobile app yet.

4 Inhoudsopgave Woord vooraf... I Abstract... II Inhoudsopgave... III Lijst met afkortingen... V Inleiding Elektronisch betalingsverkeer in België Analyse Structuur van het bestaande platform Algemeen Back end Online Banking e-payments-principe Transactie- versus Transferobjecten Person-To-Person-betalingen Veiligheid Front end Algemeen Spelers in het verhaal Model van de mobiele applicatie Value- versus item-transfer Functionaliteit van de handelaar Functionaliteit van de consument Implementatie van de back end Algemeen Transferlogica Sms-service en notificatieregistratie Protobuf Flyway Implementatie van de front end HTML 5- versus native applicatie Algemeen Support library... 21

5 4.4 Data Access Object Navigatie tussen activities Asynchrone taken ZXing Opslag van data op het toestel Notificaties ProGuard Europay Mastercard Visa-ondersteuning Android Wear ibeacons Overgang naar ios Testen Retrospectie Eigen beoordeling Extra mogelijke uitbreidingen en verbeteringen Conclusie Lijst met figuren Lijst met tabellen Lijst met codefragmenten Referentielijst... 49

6 Lijst met afkortingen APACS API AJAX B2C BC/MC BCC BTC C2B CRUD CSS CTAP DAO EMV GICC GUI GUID HTML HTTPS ID JPA JSON MPOS NFC OBeP ORM P2P PC PKI PTP QR SD SDK SSL SQL SVA TCP UI URL USB VO XML Association for Payment Clearing Services Application Programming Interface Asynchronous JavaScript and XML Business-To-Consumer Bancontact/Mister Cash Bank Card Company Business-To-Consumer Consumer-To-Business Create, Read, Update and Delete Cascading Style Sheet Common Terminal Acquirer Protocol Data Access Object Europay MasterCard Visa German ISO 8583 Credit Card Graphical User Interface Global Unique Identifier HyperText Markup Language HyperText Transfer Protocol Secure Identificatie Java Persistence API JavaScript Object Notation Mobile Point Of Sale Near Field Communication Online Banking e-payments Object-Relational Mapping Person-To-Person Protocol Converter Public Key Infrastructure Person-To-Person Quick Response Secure Digital Software Development Kit Secure Socket Layer Structured Query Language Stored Value Account Transmission Control Protocol User Interface Uniform Resource Locator Universal Serial Bus Value Object extensible Markup Language

7 Inleiding De huidige betalingsmethoden zijn complex en niet gebruiksvriendelijk. Bovendien vereisen ze soms extra hardware en/of vragen ze confidentiële informatie van de klant. Denk hierbij aan volgende probleemsituaties. Wanneer iemand cash wil betalen, heeft die persoon muntstukken nodig om het bedrag exact te kunnen passen of krijgt hij vaak veel wisselgeld terug. Dit is niet gebruiksvriendelijk. Bij elektronisch betalen heeft een handelaar meerdere (dure) betaalapparaten nodig indien hij verschillende betalingsmogelijkheden wil aanbieden. Ook bij online-betalingen is er extra hardware nodig, namelijk een digipass of een kaartlezer. Bij sommige webwinkels wordt er rechtstreeks om kredietkaartgegevens gevraagd (confidentiële informatie). Een betalingsmethode moet veilig en gebruiksvriendelijk zijn. De huidige methodes voldoen echter maar aan één van deze twee criteria. Een veilige methode is meestal niet echt gebruiksvriendelijk en een gebruiksvriendelijke methode is minder veilig. In deze masterproef wordt er geprobeerd om een betaaloplossing te ontwikkelen die toch aan beide criteria voldoet. Op dit moment heeft een groot deel van de wereldbevolking bijna altijd een smartphone bij de hand. Het Europees gemiddelde is 48 procent (Smartphonegebruik, 2013). In de toekomst zullen mobiele technologieën steeds meer invloed op ons leven hebben. Een gebruiksvriendelijke en veilige betaaloplossing ontwikkelen voor zo n apparaat is dan ook een ideale keuze. Deze masterproef gebeurt in samenwerking met J4S [jforce]. Het is een bedrijf dat zich specialiseert in betalingssoftware. Sinds 2009 is het begonnen met het ontwerpen van elektronische betaaloplossingen. Het bedrijf heeft onder andere een eigen platform ontworpen voor het verwerken van betaalterminaltransacties en biedt dit aan als een service aan zijn klanten. Hierbij aansluitend heeft het een anti-fraudesysteem ontwikkeld dat op basis van een berekening een risicoprofiel bepaalt en beslist of de transactie doorgelaten wordt of niet. Het bedrijf biedt ook een eigen e-wallet-platform aan. Bij dit platform sluit dit project aan. (J4S, 2013) Het e-wallet-platform, Stored Value Account (SVA), bevat de accountgegevens en de virtuele waardebalans van de gebruikers. Het ondersteunt de omzetting van echt geld naar de virtuele eenheid en omgekeerd. Een mogelijk toepassingsgebied is bijvoorbeeld een festival: de gebruiker kan drankbonnetjes (virtuele waarde) aankopen met echt geld. Dit geld komt op een bankrekening van de aanbieder van de software. De gebruiker krijgt hiervoor virtuele bonnetjes op zijn virtuele waarderekening in de plaats en kan hiermee dan aan de organisator van het festival betalen. Momenteel is het op dit platform enkel mogelijk om een Business-To-Consumer- (B2C-) en Consumer-To-Business-betaling (C2B-betaling) uit te voeren. Dit wil zeggen dat het enkel mogelijk is om als consument aan een handelaar of omgekeerd te betalen. Deze twee termen worden verder onder de naam B2C of BTC (in programmacode) gebruikt. De consument heeft hierbij een account met een virtuele waardebalans, maar de handelaar niet. Een device (= een betaalapparaat van de handelaar) zorgt ervoor dat het te betalen bedrag van de rekening van de 1

8 betaler wordt afgetrokken. Periodiek wordt dan berekend hoeveel eenheden een handelaar ontvangen heeft en wordt dit omgerekend en uitbetaald op zijn bankrekening. De opdracht bestaat uit twee grote delen. Het eerste deel is het uitbreiden van het SVA-platform zodat het mogelijk wordt om op een eenvoudige en veilige manier mobiel te betalen en om Person-To-Person-betalingen (P2P-betalingen) uit te voeren op het platform. Bij een P2P-betaling wordt een virtuele waarde van de account van de betaler afgetrokken en opgeteld bij de account van de ontvanger. In het voorbeeld van het festival wordt het bijvoorbeeld mogelijk om toe te laten dat gebruikers drankbonnetjes doorgeven aan elkaar. Het tweede deel is de ontwikkeling van een mobiele applicatie die van de nieuwe functionaliteit van de back end gebruik maakt en meteen de gebruiksvriendelijkheid van de uitgewerkte betaaloplossing aantoont. Het is de bedoeling dat de mobiele applicatie wordt gebruikt door zowel handelaars als consumenten. De consumenten kunnen onderling (P2P) en ook aan handelaars (C2B) via de virtuele waarde (e-money) betalen. De handelaar heeft hierbij extra functionaliteit ter beschikking. Zo kan hij met de app ook betaalkaarten accepteren door een kaartlezer aan zijn smartphone te koppelen. De mobiele applicatie is modern en vernieuwend. Zo is er gekeken of het mogelijk is om de applicatie onmiddellijk via webtechnologieën cross-platform te maken. De net aangekondigde preview van Android Wear wordt ook onder de loep genomen. Hierbij is er gekeken welke stappen er nodig zijn om de notificaties op een smartwatch weer te geven. Om de gebruiksvriendelijkheid nog te verhogen, wordt er slim gebruik gemaakt van ibeacons en sms. Indien handelaars een beacon aan de kassa plaatsen, wordt de app automatisch opgestart en afgesloten wanneer de gebruiker het bereik van de beacon binnen- en buitenwandelt. Een gebruiker kan er ook voor kiezen om via sms op de hoogte te worden gehouden van de status van de betaling. Het eerste hoofdstuk van deze scriptie bevat een beschrijving van het elektronisch betalingsverkeer in België en vervolgens een situering van dit project binnen dat verhaal. Het tweede hoofdstuk bevat een grondige analyse van de te verrichten uitbreidingen aan het SVA-platform en van de te ontwikkelen mobiele applicatie. Er wordt ook dieper ingegaan op de veiligheid van het ontwerp. De implementatie van beide delen wordt in hoofdstuk 3 en 4 behandeld. Hierbij worden ook enkele nieuwe technologieën uitgelegd, wordt er verantwoording van implementatiekeuzes gegeven en worden er enkele problemen en hun oplossing behandeld. In het laatste hoofdstuk is er ten slotte nog een eigen beoordeling van het resultaat en worden enkele mogelijke uitbreidingen voorgesteld. 2

9 1 Elektronisch betalingsverkeer in België In dit hoofdstuk wordt er aandacht besteed aan het elektronisch betalingsverkeer in België (Figuur 1.1). Een consument vraagt bij zijn bank naar keuze een betaalkaart aan. Een Belgische bank is, in tegenstelling tot in het buitenland, echter niet de issuer die de betaalkaartnummers verdeelt. Hiervoor is er in België een extra partij, namelijk Bank Card Company (BCC), ondertussen overgenomen door Atos. Een handelaar sluit een contract af met een acquirer om kaartbetalingen te kunnen ontvangen. Betalingen worden via een betaalterminal verricht. Dit kan een fysiek toestel zijn, of softwarematig bijvoorbeeld op een smartphone worden nagebootst. De betaalterminals spreken met de acquirer via een bepaald protocol dat meestal verschilt per land. Dit is natuurlijk voor terminalmakende bedrijven en handelaars niet praktisch. Voor iedere regio moet er een specifieke terminal gemaakt worden. Sommige acquirers in België zijn ook in andere landen actief en hebben als standaard een ander protocol gekozen. Hierdoor worden er verschillende protocollen actief gebruikt in België en heeft de handelaar een andere terminal nodig indien hij wenst te veranderen van acquirer of verschillende acquirers wil ondersteunen. Een oplossing hiervoor is om te werken met een extra tussenliggende partij. Het specifieke protocol dat de terminal ondersteunt wordt bij die partij omgezet naar het gebruikte protocol van de acquirer. Een voorbeeld van zo n partij is J4S met Protocol Converter (PC). Hierdoor kan er ook dynamisch worden omgeschakeld naar een andere acquirer indien bijvoorbeeld de eerste offline is. De handelaar heeft hiervoor wel contracten met verschillende acquirers nodig. Er zijn twee mogelijke geldstromen. Ofwel is de betaalterminal Atos-specifiek en kan hij rechtstreeks met de Atos-acquirer spreken ofwel is hij dit niet. Indien wel, blijft het betalingsverkeer volledig binnenlands via Bancontact/Mister Cash (BC/MC). Indien niet, loopt het via de PC naar een acquirer waarmee de handelaar een contract heeft. De acquirer wil controleren of er genoeg geld op de rekening van de betaler staat. Hiervoor moet hij zich bij de bank van de betaler gaan informeren. De acquirer kan enkel via de issuer te weten komen bij welke bank het kaartnummer hoort. In België heeft Atos hierbij het voordeel dat het ook de issuer is (Banksys en BCC, 2007), dus kan het rechtstreeks aan de bankgegevens voor nationaal verkeer. Voor internationaal verkeer doet het wel een beroep op de brands (Mastercard of Visa) om de bankgegevens van de kaart te weten te komen. De andere acquirers gaan echter altijd via de brands voor deze informatie. Van zodra de acquirer de bank van de betaler weet, kan hij nagaan of er genoeg geld op de rekening staat en de betaaltransactie laten doorgaan. In de laatste stap (niet meer weergegeven op de figuur) wordt door de acquirer het verschuldigde bedrag aan de bank gevraagd zodat het geld van de rekening van de klant op de rekening van de acquirer komt. Uiteindelijk betaalt de acquirer periodiek een totaalsom terug op de rekening van de handelaar. 3

10 Ter vergelijking is in de figuur ook nog eens het SVA-platform opgenomen. De consument kan kiezen of hij wil betalen via e-money (virtuele waarde) met de mobiele applicatie waarbij de communicatie met het SVA-platform verloopt of via een betaalkaart. De handelaar kan met dezelfde applicatie ook betalingen via betaalkaarten aanvaarden. De app communiceert hiervoor via het Mobile Point Of Sale-protocol (MPOS-protocol) van J4S naar de PC en zo gaat de Europay MasterCard Visa-transactie (EMV-transactie) verder naar de acquirer. Figuur 1.1: Elektronisch betalingsverkeer in België 4

11 2 Analyse 2.1 Structuur van het bestaande platform 2.2 Algemeen 2.3 Back end Online Banking e-payments-principe Transactie- versus Transferobjecten Person-To-Person-betalingen Veiligheid 2.4 Front end Algemeen Spelers in het verhaal Model van de mobiele applicatie Value- versus item-transfer Functionaliteit van de handelaar Functionaliteit van de consument 5

12 3 Implementatie van de back end 3.1 Algemeen Tijdens de implementatiefase wordt er zoveel mogelijk gebruik gemaakt van de reeds bestaande SVA-API om dubbele code te vermijden. De API om te authenticeren (inloggen) en om de waardebalans op te vragen bestaat al en wordt dus opnieuw gebruikt. Ook de topdown-service om een B2C-transactie te verrichten en een logobject weg te schrijven wordt opnieuw gebruikt bij een B2C-transfer. Voor de logica rond het OBeP-principe en P2P-betalingen is er echter nog niets aanwezig in het systeem. Er is voor gezorgd dat de geschreven code zo goed mogelijk aansluit bij de stijl van het bestaande project. 3.2 Transferlogica Domeinmodel Voor alle logica rond transferobjecten zijn er nieuwe klassen toegevoegd. Een eerste soort zijn de transferdomeinklassen. Voor het persisteren van de objecten van deze klassen, wordt er gebruik gemaakt van de Java Persistence API (JPA) en als implementatiebibliotheek Hibernate. Alle domeinklassen zijn geannoteerd met JPA-annotaties. Zo kan er gemakkelijk van Object- Relational Mapping-implementatie (ORM-implementatie) = public abstract class Transfer extends GenericEntity private String private Account private Date private TransferDetails details; private String private TransferState state; // Codefragment 3.1: Implementatie van de transferklasse De transferklasse (Codefragment 3.1) erft over van GenericEntity. Deze laatste zorgt ervoor dat overervende klassen een attribuut id met krijgen. Dit attribuut wordt ge- 6

13 bruikt door Hibernate om het primaire ID van het databankrecord in op te slaan. Om dit databank-id niet te hoeven blootstellen aan de buitenwereld, wordt er een Global Unique Identifier (GUID) aangemaakt bij creatie van het transferobject (shareduniqueid-attribuut). Dit is een random, uniek ID dat gebruikt wordt om informatie over het transferobject op te vragen. Het is dan ook dit ID dat door de ontvanger aan de betaler wordt doorgegeven. Het gebruik van een GUID is veiliger omdat databank-id s meestal incrementeel gegenereerd worden door de databanksoftware. Door nu gewoon bijvoorbeeld het getal een of twee bij een huidig ID te tellen, zou iemand informatie van de volgende transfer, die nog niet voltooid is, kunnen opvragen. Business-logica Om operaties op de transferdomeinobjecten uit te voeren (bv. creatie van een nieuw object en objecten ophalen), wordt er een transferrepository, transferservice en transferresource aangemaakt (Figuur 3.1). Dit zijn respectievelijk repository-, service- en resource-klassen. Hierbij wordt er actief gebruik gemaakt van het Spring Framework. De transferresource en de transferservice gebruiken dependency injection (Codefragment 3.2). Bij het opstarten van de serverapplicatie worden de geannoteerde klassen geïnstantieerd en op de Spring context geplaatst. Hierbij worden de autowired-attributen ook ingevuld met de overeenkomstige referenties. In het codefragment wordt bijvoorbeeld het transferrepository-attribuut automatisch ingevuld met een referentie naar het juiste implementatieobject door het Spring Framework. In de transferresource wordt dit ook toegepast om een verwijzing te krijgen naar het transferserviceobject. Figuur 3.1: Implementatieschema van de transferlogica De transferresource klasse zelf is ook geannoteerd Dit zorgt ervoor dat iedere methode (webservice-aanvraag) van de klasse in een aparte transactie wordt behandeld. Pas wanneer de aanvraag succesvol is afgehandeld, worden de wijzigingen effectief gecommit naar de databank. Dit vermijdt inconsistentie van data bij complexe operaties die halverwege onderbroken worden door een opgetreden fout. 7

14 @Repository public class JpaTransferRepository extends JpaGenericRepository<Transfer> implements TransferRepository { public class TransferServiceImpl implements TransferService TransferRepository transferrepository; // Codefragment 3.2: Dependency injection met annotaties Transferrepository De transferrepository is verantwoordelijk voor het persisteren en ophalen van de transferobjecten. Data persisteren is met de hulp van Hibernate zeer eenvoudig, maar doordat de transferdomeinobjecten een redelijk complexe klassenstructuur hebben, is data ophalen ingewikkelder. Afhankelijk van het feit of het om een B2C-transfer of om een P2P-transfer gaat, is de ontvanger (Codefragment 3.3) een device van de handelaar (een handelaar dus) of een rekening van de betaler (een consument). Om compatibiliteitsredenen met het bestaande systeem wordt er nog altijd over een device van de handelaar gesproken. Dit komt er in de praktijk op neer dat een handelaar zijn smartphone registreert op het SVA-platform als een geldig toestel waarmee B2Ctransfers aangemaakt mogen worden. Bij het ophalen van de transfergeschiedenis zorgt het zonet genoemde verschil = "sva_btctransfer") public class BTCTransfer extends Transfer private Device = "sva_ptptransfer") public class PTPTransfer extends Transfer private Account goodsreceiveraccount; // Codefragment 3.3: Implementatie van de B2C-transfer en de P2P-transfer klasse 8

15 Als voorbeeld schetsen we de volgende situatie. Een consument wil zijn recentste transfers bekijken. Mogelijke transferobjecten die aan deze situatie voldoen zijn P2P-transfers waarin hij zelf de ontvanger of de betaler is of B2C-transfers waarin hij de betaler is. Op het eerste gezicht zou de eenvoudige query (Codefragment 3.4) moeten werken. In het codefragment verwijzen de twee parameters userr en users naar hetzelfde userobject van de aanvrager. SELECT t FROM Transfer t WHERE t.goodsreceiveraccount.user = :userr OR t.goodssenderaccount.user = :users Codefragment 3.4: Niet-werkende transfergeschiedenisquery Hibernate kan echter het attribuut goodsreceiveraccount niet vinden. Dit komt omdat er een transfer opgevraagd wordt en deze heeft dit attribuut niet omdat dit is gedefinieerd in P2Ptransfer. Er zou met andere woorden iets moeten bestaan zoals een instanceof-operator en een downcast zoals in Java om de query te kunnen uitvoeren. Een tweede mogelijke weg naar het einddoel is via een native Structured Query Languagequery (native SQL-query). Deze complexe query (Codefragment 3.5) joint zelf de nodige tabellen en bevat alle informatie om een transferobject samen te stellen. Er wordt nu niet meer op objectniveau gewerkt, maar rechtstreeks op databankniveau. SELECT * FROM sva_transfer transfer LEFT JOIN sva_btctransfer btctransfer ON transfer.id = btctransfer.id LEFT JOIN sva_ptptransfer ptptransfer ON transfer.id = ptptransfer.id LEFT JOIN sva_transferdetails transferdetails ON transfer.details_id = transferdetails.id LEFT JOIN sva_emoneytransferdetails emoneytransferdetails ON transferdetails.id = emoneytransferdetails.id LEFT JOIN sva_account senderaccount ON senderaccount.id = transfer.goodssenderaccount_id LEFT JOIN sva_account receiveraccount ON receiveraccount.id = ptptransfer.goodsreceiveraccount_id LEFT JOIN sva_device receiverdevice ON receiverdevice.id = btctransfer.goodsreceiverdevice_id WHERE (ptptransfer.id IS NOT NULL AND receiveraccount.userid =?) OR senderaccount.userid =? Codefragment 3.5: Native SQL-query voor de transfergeschiedenis van een consument 9

16 Het probleem hierbij is echter dat er verschillende kolommen zijn met dezelfde naam (bv. ID) zodat Hibernate niet meer weet welke kolom bij welk objectattribuut hoort. Dit is ook zo wanneer er enkele kolommen opnieuw worden benoemd zodat er geen dubbele namen zijn. Een oplossing hiervoor is om bij de klassen zelf een mapping te definiëren via een complexe annotatienotatie waarbij iedere kolom aan het juiste attribuut gekoppeld wordt. Deze werd echter niet doorgevoerd omdat dit een globale configuratie is op de klasse zelf. De uiteindelijke oplossing bestaat uit het uitvoeren van twee eenvoudige query s na elkaar. De ene haalt de P2P-transfers op en de andere de B2C-transfers. Deze worden dan uiteindelijk samengevoegd. De query s voor de transfergeschiedenis worden dynamisch gecreëerd via een CriteriaBuilder. Deze laat toe om objectsgewijs een query samen te stellen. Deze manier van werken maakt het mogelijk om gemakkelijk meer of minder predicaten in de where-clausule van de query toe te voegen. Zo kan er strenger en minder streng worden gefilterd zonder voor ieder scenario een individuele query te moeten opstellen. Bij de standaardquery voor een consument die de P2P-transfers ophaalt, is er echter nog een probleem. Als de query de bovenste whereclauses (Codefragment 3.6) gebruikt, worden niet alle juiste resultaatrijen teruggegeven. // Predicaat die te weinig rijen oplevert. Predicate whereclauses = cb.or( cb.equal(rootp.get("goodsreceiveraccount").get("user"), userparamr), cb.equal(rootp.get("goodssenderaccount").get("user"), userparams) ); // Predicaat die alle rijen oplevert. whereclauses = cb.or( cb.equal(rootp.join("goodssenderaccount", JoinType.LEFT).get("user"), userparams), cb.equal(rootp.get("goodsreceiveraccount").get("user"), userparamr) ); Codefragment 3.6: Foutieve (bovenste) en juiste (onderste) predicaten van de transfergeschiedenisquery Een diepere analyse van de achterliggende werking van Hibernate leidde tot het ontdekken van de volgende oorzaak. Als een consument al zijn transfers opvraagt, bevatten deze ook de door hem geannuleerde transfers waarvan de zender nog niet gekend is in het systeem. Op het eerste gezicht, leidt dit niet echt tot een probleem. De query kijkt of de user van de ontvangende rekening gelijk is aan de aanvrager en of de aanvrager gelijk is aan de user van het verzendende rekening. Het eerste deel van de of-uitdrukking zou moeten true geven als resultaat. In de databank bevat de ontvangende rekening-kolom echter de waarde null. Door die null-waarde behoort de rij niet tot het eindresultaat omdat de volledig where-uitdrukking in de Hibernate query onderbroken wordt. De reden hiervoor is dat Hibernate de query achter de schermen omvormt tot een SQL-query. 10

17 De uitdrukking rootp.get("goodssenderaccount").get("user") wordt vervangen door een inner join (op gelijke ID s van het goodssenderaccount_id-veld van de transfertabel en het ID-veld van de accounttabel) en een where-uitdrukking om de gebruikers te vergelijken. Bij een SQL-query worden joins eerder uitgevoerd dan de where-clausule. Aangezien het een inner join is, verdwijnt de rij uit het resultaat omdat de on-voorwaarde niet voldaan is (wegens de null-waarde). Pas na de join-fase, wordt de where-uitdrukking op de resterende rijen uitgevoerd. Het hierboven geschetste probleem kan als volgt opgelost worden. Er moet specifiek aan Hibernate meegedeeld worden dat de query naar een left join moet worden omgezet (onderste clausule in het codefragment) in plaats van naar een normale inner join. Zo wordt de rij wel behouden en kan probleemloos de where-clausule worden uitgevoerd. Transferservice en transferresource In de transferservice gebeurt er foutcontrole. Indien er een fout is opgetreden zoals bijvoorbeeld als een verplicht attribuut van een object niet is ingevuld, wordt er een service-exceptie opgegooid. Dit is een object van de klasse ServiceException. Deze bevat de informatie over de fout onder de vorm van een enum. Deze heeft verschillende foutconstantes, elk met een specifieke betekenis. Een voorbeeld hiervan is ServiceError.TRANSFER_NOT_FOUND. Dit betekent dat een transfer niet kan gevonden worden op basis van het meegegeven transfer-guid. Deze service-excepties worden opgevangen en gemapt op een Protobuf-foutbericht. Dit wordt dan als antwoord naar de aanvrager teruggestuurd. Authorisatiecontrole gebeurt op twee plaatsen. Enerzijds wordt er gebruik gemaakt van Spring Security bij de transferresource en anderzijds gebeurt er in de services zelf nog een fijnere selectie. Iedere gebruiker in het systeem is aan een bepaalde rol gekoppeld. De twee gebruikte rollen in dit project zijn visitor (de consument) en vendor (de handelaar). Aan een rol worden er rechten toegekend zoals bijvoorbeeld create_transfer en accept_transfer. Diezelfde rechten worden ook afgedwongen bij de webservice-methodes (Codefragment 3.7) via Bij een aanvraag gaat de server na of de geauthenticeerde gebruiker de juiste rechten heeft, dan kan de server op basis hiervan de aanvraag weigeren of deze verderzetten. Soms is er een fijnere selectie nodig zoals bijvoorbeeld bij de creatie van een transfer. Zowel een visitor als een vendor hebben het recht om een transfer aan te maken. Wanneer een werknemer bij een handelaar een nieuwe transfer probeert aan te maken, moet er gecontroleerd worden of dit gebeurt via een geldig geregistreerd toestel van de handelaar en of de werknemer wel effectief werkt bij die handelaar. Deze verfijnde controle gebeurt in de transferservice en kan eventueel de aanvraag via een ServiceError weigeren. 11

18 = + RightConstants.CREATE_TRANSFER + "')") public CreateTransferResponse createtransfer(@context HttpServletRequest httpservletrequest, CreateTransferRequest request) { // Codefragment 3.7: Authorisatie van een webservicemethode 3.3 Sms-service en notificatieregistratie Een van de mogelijkheden voor notificaties in de mobiele applicatie (zie 4.9) is dat de gebruiker via sms wordt verwittigd wanneer een transfer voltooid is. Het SVA-platform moet deze berichten dus kunnen versturen. De gebruiker moet zich ook kunnen inschrijven om sms-notificaties te ontvangen bij een transfer. Deze twee implementaties worden hieronder verder besproken. Voor het versturen van de sms en, wordt er een nieuwe service aan SVA toegevoegd, namelijk de sms-service. Deze is verantwoordelijk voor het verzenden van de sms-berichten naar de gebruikers. De service verstuurt zijn sms en via Clickatell. Dit is een sms bulk provider die toelaat om sms en over de hele wereld te versturen. Dit kan zeer eenvoudig en programmatisch via hun HTTPS XML API (Clickatell, 2013). Om een sms-bericht te versturen moet de sms-service van SVA gewoon een HTTPS-aanvraag naar Clickatell sturen. In de HTTP-body van de aanvraag worden identificatiedetails, gsm-nummer van de ontvanger en het te versturen bericht via een exensible Markup Language-structuur (XML-structuur) vermeld (Codefragment 3.8). De identificatievariabelen en instellingen zijn in een properties-bestand ingevuld. Bij het opstarten van de server wordt deze configuratie via autowiring in een resource bundle voor de sms-service beschikbaar gemaakt. data=<?xml version="1.0"?> <clickapi> <sendmsg> <api_id>%s</api_id> <user>%s</user> <password>%s</password> <to>%s</to> <text>%s</text> </sendmsg> </clickapi> Codefragment 3.8: HTTP-body van de sms-aanvraag Een gebruiker moet ook kunnen aangeven dat hij een sms-bericht wil ontvangen wanneer de transfer voltooid is. Deze informatie wordt opgeslagen in een nieuw koppelobject, namelijk 12

19 TransferObservation (Codefragment 3.9). Een TransferObservation bevat een verwijzing naar de gebruiker, de transfer en om algemeen te blijven, naar de wijze waarop hij op de hoogte wil gehouden worden. Dit kan bijvoorbeeld via een of via een sms zijn. Als laatste is er een TransferObservationRepository toegevoegd. Deze ondersteunt de mogelijkheid om alle observatieobjecten die aan een bepaalde transfer gekoppeld zijn, op te vragen. De transferservice overloopt deze dan en bepaalt aan de hand van het type of er een sms of een moet verzonden worden via de sms- = "sva_transferobservation") public class TransferObservation extends GenericEntity private User private Transfer private NotificationType notificationtype; // Codefragment 3.9: De klasse TransferObservation 3.4 Protobuf Protobuf is een mechanisme om gestructureerde data te serialiseren en te deserialiseren zodat ze gemakkelijk via communicatiekanalen verstuurd kunnen worden. Het is taal- en platformonafhankelijk. De gestructureerde data worden eenmalig gedefinieerd in een zogenaamd proto -bestand. Dit stelt een protocol buffer message type voor. Het is een beschrijving van de structuur van een bericht. De Protobuf-compiler genereert hieruit de overeenkomstige klasse in een gekozen taal. Via deze klassen kunnen dus protocol buffer messages (binaire streams) aangemaakt worden. Eerst wordt er een object van de klasse gecreëerd. Ten tweede worden de attributen ingevuld en als laatste wordt er gevraagd om dit object te serialiseren tot een stream. Deze binaire stream stuurt men bijvoorbeeld door via het Transmission Control Protocol (TCP) of plaatst men in de body van een HTTP-bericht. Aan de ontvangstzijde zet men de gegenereerde stream weer om tot een object en kan men de data gemakkelijk lezen. Een protocol buffer message is gelijkaardig aan een XML- of JavaScript Object Notation-bericht (JSON-bericht). Het stelt een geserialiseerd object voor. Bij XML en JSON is dit een lange tekststring terwijl dit bij een protocol buffer message een binaire string is. Parsen van de stream tot een object gaat hierdoor bij Protobuf zeer snel, want parsen van tekst is veel trager dan parsen van binaire strings. De grootte van het verstuurde bericht is ook kleiner dan bij XML 13

20 en JSON. Bij de laatste twee gaan er veel tekstbits verloren aan indicatie van de meegestuurde data. Denk hierbij aan de <element>-tags bij XML en de objectnotatie {attribuutnaam:, bij JSON. Hieronder nog even een kleine vergelijking (Codefragment 3.10). <!-- XML voorbeeld --> <person> <name>john Doe</name> </person> <!-- JSON voorbeeld --> {name: "John Doe", <!-- Protobuf voorbeeld --> 0A 08 4A 6F 68 6E F A 64 6F D 70 6C 65 2E 63 6F 6D Codefragment 3.10: Vergelijking van een XML-, JSON- en Protobuf-bericht (eigen bewerking van Protocol Buffers, 2012) Het eerste voorbeeld is een XML-bericht. Er wordt een persoonsobject met twee attributen over het netwerk verstuurd. In het tweede voorbeeld is hetzelfde in een JSON-bericht voorgesteld. In het derde voorbeeld is het voorgesteld als een protocol buffer-bericht (hier hexadecimaal voorgesteld, ieder groepje is een byte). Het XML-bericht is 69 bytes lang zonder witruimte, het JSON-bericht is zonder witruimte 42 tekens lang en het Protobuf-bericht is slechts 28 bytes lang. Parsen van het Protobuf-bericht duurt ongeveer nanoseconden terwijl de XMLversie nanoseconden duurt. Een groot voordeel aan Protobuf is dat de berichtenstructuur onafhankelijk van een specifieke taal wordt vastgelegd. De Protobuf-compiler genereert de gewenste klassen in een willekeurige taal. Zo kan bijvoorbeeld een webservice geschreven in Java communiceren met een client die geschreven is in c++ zonder dat er zelf platformspecifieke code moet geschreven worden. Nog een voordeel is dat er gemakkelijk aan een berichttype nieuwe velden kunnen toegevoegd worden zonder dat bestaande code breekt. Niet gebruikte velden worden simpelweg genegeerd. Soms kan de mindere leesbaarheid van de berichten als een nadeel gezien worden. Dit komt omdat een Protobuf-bericht een binaire string is. Voor publieke webservices kan dit een nadeel zijn naar gebruiksvriendelijkheid toe. Snel even naar een antwoord van een API-call kijken is hier moeilijk. Bij de SVA-API is dit toch een voordeel omdat berichten lezen en schrijven naar de SVA-webservice moeilijker wordt voor buitenstaanders. (Protocol Buffers, 2012) In de uitbreiding van SVA is er dus gebruik gemaakt van Protobuf aangezien het niets anders dan voordelen met zich meebrengt. Hieronder (Codefragment 3.11) is de protobuf message type beschrijving van een transferobject weergegeven. Bij een attribuut kan worden aangegeven of 14

21 het verplicht of optioneel is. In de documentatie van Protobuf wordt aangeraden om ieder attribuut optioneel te maken en een eigen validatie te voorzien voor de verplichte attributen. Een verplicht attribuut in de toekomst naar optioneel veranderen kan voor problemen zorgen. Sommige (oudere) Protobuf-lezers beschouwen het bericht dan als incompleet en kunnen het weigeren. Daarom is in de implementatie van de uitbreiding ieder attribuut als optioneel aangeduid. Als protobuf bibliotheek/compiler is er gebruik gemaakt van Protostuff. Deze software is een specifieke Javabibliotheek en genereert eenvoudiger Javaklassen dan de officiële compiler. Bij de Protostuff-klassen kan er gewoon met setters worden gewerkt terwijl bij de officiële compilergegenereerde klassen de data via een builderobject ingevuld moeten worden. Protobuf biedt geen ondersteuning voor overerving bij klassen. Er zijn twee goede oplossingen hiervoor (Protocol Buffer Polymorphism, 2010). Eén ervan maakt echter gebruik van het extend keyword van Protobuf, maar dit wordt niet ondersteund door de Protostuff compiler. Daarom wordt deze oplossing ook niet verder behandeld. De tweede oplossing is wel mogelijk en is als volgt toegepast. Er wordt voor zowel Transfer, BTCTransfer en PTPTransfer een Protobuf-bericht type aangemaakt, namelijk TransferVO, BTCTransferVO en PTPTransferVO. De laatste twee Value Objects (VO s) bevatten hun eigen specifieke attributen die niet in TransferVO voorkomen. Er wordt in TransferVO een optioneel attribuut voorzien voor zowel BTCTransferVO en PTPTransferVO. Op eenzelfde moment is er maar één van deze twee attributen bij een bericht ingevuld. Om gemakkelijk onderscheid te maken wordt er een attribuut toegevoegd dat het ingevulde attribuut aanduidt. Hiervoor wordt er een enum gebruikt. 15

22 package be.j4s.payment.products.sva.backend.cc.common.protomessages; option optimize_for = LITE_RUNTIME; import "LoggedInUser.proto"; import "LoggedInMerchant.proto"; import "TransferState.proto"; import "TransferDetails.proto"; import "PTPTransfer.proto"; import "BTCTransfer.proto"; message TransferVO { optional string shared_unique_id = 1; optional LoggedInUserVO goods_sender = 2; optional TransferDetailsVO details = 3; optional int64 timestamp = 4; optional string description = 5; optional TransferStateVE state = 6; // inheritance enum TransferTypeVE { PTPTRANSFER = 1; BTCTRANSFER = 2; optional TransferTypeVE transfer_type_ve= 7; optional PTPTransferVO PTP_transfer_VO = 8; optional BTCTransferVO BTC_transfer_VO = 9; Codefragment 3.11: Inhoud van het transfer proto-bestand 3.5 Flyway Bij grote projecten wordt er voor de geschreven programmacode vaak gebruik gemaakt van versiebeheersoftware zoals Subversion en Git. Zo is er exact geweten welke code bij welke versie van de software hoort. Bij grote projecten met een databank, is de databankstructuur dynamisch. Updates of patches zorgen voor uitbreidingen/wijzigingen van de databank en uiteindelijk weet niemand meer welke staat/versie de databankstructuur heeft. Flyway is een databankmigratiebibliotheek die zorgt voor versiebeheer van de structuur van een databank. Flyway maakt gebruik van een eigen metadata-tabel met de naam SCHEMA_VERSION. Deze tabel wordt door de bibliotheek gebruikt om de staat van de databankstructuur bij te houden. Bij de start van de applicatie moeten enkel deze codelijnen (Codefragment 3.12) helemaal vooraan vermeld worden. Bij het opstarten van het programma, wordt de logica van Flyway uitgevoerd. Iedere versie/migratie van de databankstructuur wordt in een SQL-script vastgelegd. De naam van het script is van de vorm: Vx y.sql waarbij x een versienummer en y een beschrijving is. Alle migratiescripts worden in de src/main/resources/db/migration map geplaatst. Tijdens het opstarten scant Flyway deze map en sorteert alle scripts op versienummering. Deze 16

23 wordt vergeleken met de huidige versie van de databank en indien er nieuwe scripts zijn, worden de migraties uitgevoerd zodat de databank de meest recente structuur heeft. Iedere nieuwe update wordt in de metadata tabel vemeld. (Flyway, 2014) Flyway flyway = new Flyway(); flyway.setdatasource(url, user, password); flyway.migrate(); Codefragment 3.12: Code om Flyway te gebruiken in een programma (Flyway, 2014) In SVA wordt er gebruik gemaakt van Flyway. De tabellen worden dus niet automatisch via Hibernate gegenereerd. Voor de tabellen in verband met de Transferobjecten is er een nieuw migratie SQL-bestand met een verhoogd versienummer aangemaakt en in de migration-map geplaatst. Dit bestand bevat als inhoud de SQL-query s om de transfertabellen aan te maken en om de nieuwe rechten met hun koppelingen aan rollen toe te voegen. 17

24 4 Implementatie van de front end 4.1 HTML 5- versus native applicatie Tijdens de analysefase is er onderzocht of het mogelijk is om de applicatie via webtechnologieën al onmiddellijk cross-platform te maken. Het is niet direct mogelijk om de mobiele applicatie als een normale website te bouwen omdat de applicatie toegang nodig heeft tot de hardware van het apparaat (bv. sms, camera, EMV-device) en een browser niet al deze mogelijkheden ter beschikking kan stellen. Het gebruik van hardware verloopt altijd via native code en is platformafhankelijk. Dit komt omdat ieder mobiel platform (ios, Android, Windows Phone) deze functionaliteit via een eigen framework ter beschikking stelt. Het is echter wel mogelijk om via een hybride methode te werken (Building Cross-Platform Apps, 2013). Bij de hybride methode worden enkel de zaken die native toegang vereisen in platformafhankelijke code geschreven. De rest wordt zoveel mogelijk met behulp van webtechnologieën gebouwd. Het voordeel om de applicatie in HyperText Markup Language 5 (HTML 5), Cascading Style Sheet (CSS) en JavaScript te bouwen, is dat ieder mobiel platform hiervoor ondersteuning biedt. De web-bestanden en de native code worden samen in één native applicatie gebundeld. De web-bestanden worden in een native webview getoond en via JavaScript is het mogelijk om te interageren met de native geschreven componenten. Deze techniek is veelbelovend naar de toekomst toe omdat ontwikkelaars in tegenstelling tot nu, op een algemene manier de UI en de interactie met de applicatie kunnen beschrijven onafhankelijk van een specifiek platform. Om het hierboven geschreven proces toch zoveel mogelijk te automatiseren, wordt er gebruik gemaakt van een platform, namelijk Apache Cordova. Hiermee kan men een algemeen project aanmaken dat onder andere een www -map bevat (Apache Cordova, 2014). Het is de bedoeling dat alle webspecifieke bestanden in deze map komen. Via de commandline tools van Apache Cordova is het mogelijk om dan de platformspecifieke bundels geautomatiseerd aan te maken. Hiervoor gebruikt het achter de schermen de platformspecifieke Software Development Kit s (SDK s) om een overeenkomstig project aan te maken met een webview en deze te builden tot een native uitvoerbare applicatie. Apache Cordova biedt ook heel wat standaard plug-ins aan. Dit zijn native geschreven klassen waarmee vanuit JavaScript wordt geïnterageerd. Deze voeren dan platformspecifieke code uit om bijvoorbeeld de hardware aan te spreken. Een voorbeeld hiervan is de camera plug-in. Zonder zelf iets van native code te moeten schrijven, kan de camera via deze plug-in vanuit Javascript worden aangesproken. Het is ook mogelijk om eigen plug-ins te schrijven. Deze moet dan wel zelf voor elk gewenst platform geschreven worden. Zo zou voor de mobiele applicatie een eigen plug-in moeten geschreven worden die met de EMV-lezer interageert. De UI van de applicatie is niet zomaar een normale website. Mobiele toestellen hebben verschillende schermformaten met verschillende pixeldichtheden. Hierdoor moet er bijvoorbeeld rekening gehouden worden met schalen en responsive layout. Dit wordt gemakkelijk opgelost 18

25 door gebruik te maken van een UI-framework zoals jquery Mobile. Deze voorziet in allerlei lay-out componenten (bv. knoppen, navigatiemenu s, panelen). Om gemakkelijk browseronafhankelijk Asynchronous JavaScript and XML-aanroepen (AJAX-aanroepen) te kunnen uitvoeren, wordt er gebruik gemaakt van jquery. In theorie is het dus mogelijk om de volledige applicatie zoveel mogelijk platform onafhankelijk te maken. In de praktijk brengt het toch enkel nadelen met zich mee. Het aanspreken van een eigen Cordova plug-in is complexer dan in een native applicatie. De applicatie heeft ook niet de platformafhankelijke native look and feel. Door de zware HTML-rendering oogt de applicatie niet vloeiend en start ze ook trager op dan de native applicatie. Omwille van performantie is bijvoorbeeld Facebook naar platformspecifieke native applicaties overgeschakeld (King, 2012). In het ontwerp van de mobiele applicatie is er redelijk wat hardwaretoegang nodig. Hierom en omwille van performantieredenen is er uiteindelijk gekozen om de mobiele client als een native Androidapplicatie uit te werken. 4.2 Algemeen De ontwikkeling van de mobiele applicatie is een nieuw project. Er is gekozen voor een native Android applicatie. Hierbij is er veel aandacht besteed aan de mogelijkheid tot uitbreiden en de flexibiliteit van de app. Zo zijn alle geschreven klassen in Java packages geordend. Alle tekststrings worden vanuit een XML-bestand geladen. De app is daardoor al onmiddellijk bruikbaar voor meerdere talen. Het enige dat er nog moet gebeuren is nieuwe XML-bestanden aanmaken met daarin de vertalingen. Android selecteert dan automatisch het juiste XML-bestand (met de juiste taal) afhankelijk van de ingestelde lokale instellingen van het toestel. De GUI-lay-out van de applicatie is ook zoveel mogelijk in XML-bestanden beschreven. Dit zorgt voor een goede scheiding van de GUI en de code behind. Alle gebruikte icoontjes zijn beschikbaar in verschillende groottes zodat ze er op ieder scherm ongeveer even groot uitzien en performant kunnen gerendered worden. Het heeft bijvoorbeeld geen zin om een afbeelding te renderen waarvan maar de helft van het aantal pixels effectief op het scherm kan worden getoond. Het ontwerp en de implementatie van de GUI volgen zoveel mogelijk de algemene stijlregels van Android. Deze worden de laatste tijd door Android sterk gepromoot (Design, 2014) zodat alle apps een gezamenlijke native look and feel hebben. Dit is ook gebruiksvriendelijker voor de eindgebruiker. Het hoofdscherm (Figuur 4.1) is het startpunt van de volledige applicatie (na het inloggen). Het bevat alle nuttige informatie op een enkel scherm. De swipable tabbladen en de navigation drawer zorgen ervoor dat alle nuttige informatie op een enkele activity (scherm) beschikbaar is zonder daarbij de gebruiker met allerlei details te overladen. Verder is er door heel de applicatie up-navigatie voorzien en wordt er actief gebruik gemaakt van de actionbar (Figuur 4.2). 19

26 De applicatie is ontwikkeld om op zoveel mogelijk verschillende Androidversies te kunnen draaien. De vereiste minimumversie voor de betalingsapplicatie is Android 2.3 (API-niveau 9). Dit komt doordat de gebruikte bibliotheek om QR-codes te detecteren dit vereist. Google verzamelt statistieken in verband met de Androidversies via zijn Google Play Store app (Dashboards, 2014). Ruw geschat kan worden afgeleid dat de applicatie op 97 % van de Androidtoestellen zou moeten draaien. Figuur 4.1: Hoofdscherm voor de consument (links) en de uitgeklapte navigation drawer (rechts) Figuur 4.2: Voorbeeld van up-navigatie (1) en een spinner (2) in de actionbar (3) 20

27 4.3 Support library Iedere Androidversie brengt nieuwe features met zich mee. In de algemene stijlregels zoals nu beschreven, wordt aangeraden om bepaalde componenten zoals een actionbar en notificaties (Figuur 4.10) te gebruiken. Het probleem is dat sommige van die componenten pas in latere Androidversies zijn ingevoerd en dus niet werken op oudere versies. Een voorbeeld hiervan is de actionbar. Die is pas beschikbaar vanaf Android 3.0. Om toch de meest recente stijlkenmerken te kunnen gebruiken bij oudere Androidversies zijn er support libraries beschikbaar. Er zijn verschillende ondersteuningsbibiliotheken. Iedere bibliotheek biedt een aantal functionaliteiten aan van nieuwere Androidversies tot aan een bepaalde oudere versie. In de app is er gebruik gemaakt van de v4- en v7 support library. Dit betekent dat de v4-bibliotheek compatibiliteit biedt voor een aantal componenten tot aan Android API level 4. De v7 support library biedt functionaliteit aan teruggaand tot aan API level 7. Uit de v4-bibliotheek worden onder andere de klassen Fragment en NotificationCompat gebruikt om gemakkelijk met fragments en notificaties te kunnen werken. De v7-library is gebruikt om de actionbar met de daaraan gekoppelde acties te kunnen gebruiken. (Support Library, 2014) Hieronder wordt als voorbeeld nog eens kort het gebruik van de v7-bibliotheek gedemonstreerd. Een nieuwe activity erft nu niet meer over van de klasse Activity, maar van de klasse Action- BarActivity uit de ondersteuningsbibliotheek (Setting Up the Action Bar, z.j.). Om in code zaken aan de actionbar te wijzigen, kan er bijvoorbeeld in de oncreate-methode getsupport- ActionBar() in plaats van getactionbar() opgeroepen worden. Als laatste instelling moet er verwezen worden naar een comptabiliteitsthema voor de activity in de Android manifest. Dit kan globaal voor de hele applicatie in één keer worden ingesteld zodat iedere activity daarvan gebruik maakt. (Codefragment 4.1). <application <!-- --> <!-- --> </application> 4.4 Data Access Object Codefragment 4.1: Verwijzen naar een support library thema De mobiele applicatie maakt gebruik van een Data Access Object (DAO). Het is een object dat alle logica bevat om gegevens op te halen en weg te schrijven. De applicatie is hierdoor volledig ontkoppeld van het domeinmodel van SVA. Dit heeft als voordeel dat de applicatie los van SVA kan ontwikkeld worden. Wijzigingen zoals bijvoorbeeld weglaten van attributen of hervormingen in het domeinmodel van SVA hebben geen impact op de globale werking van de mobiele applicatie. De applicatie steunt volledig op een interface van een DAO en een eigen 21

28 klassenmodel. De interface ligt eenduidig vast en het is de DAO-implementatie die ervoor zorgt dat de data aangeleverd en verwerkt worden zoals afgesproken. Hoe en op welke manier die implementatie aan deze informatie komt, weet de applicatie dus niet. Het gebruik van een interface zorgt er ook voor dat er gemakkelijk van DAO-implementatie kan gewijzigd worden. Zo kan de app bijvoorbeeld aan een ander platform gekoppeld worden en is het alleen de DAOimplementatie die moet gewijzigd worden. Wijzigingen aan bestaande SVA-code leiden ook enkel tot aanpassen van de DAO-implementatie. De app haalt zijn data van het SVA-platform. Hiervoor is er een implementatie van de DAOinterface geschreven die communiceert met SVA en de antwoorden daarvan omzet naar de eigen modelklassen. In de code (Codefragment 4.2) is de geïmplementeerde methode te zien om de info van een transfer op te halen. De te versturen data worden eerst naar een Protobuf-object omgezet. De logica om dit te doen, zit gescheiden in een aparte klasse, namelijk TransferAssembler. De kennis om een aanvraag te verrichten aan de SVA-server zit in de klasse RESTRequester. Deze heeft een methode requestpost die de aanvragen verstuurt. Als laatste wordt het ontvangen Protobuf-object naar een modelobject omgezet en aan de applicatie teruggegeven. De requestpost-methode is een generieke geparametriseerde methode die een POST HTTPSaanvraag naar de SVA-server verzendt. De twee parameters P en R zijn het invoer- en uitvoer Protobuf-object. Om een HTTPS-request te versturen maakt deze methode gebruik van de in Java voorziene klasse HttpsURLConnection. De RESTRequester is gemakkelijk configureerbaar via een properties-bestand zodat de klasse zelf niet opnieuw moet gecompileerd public Transfer gettransfer(string transferid) throws DAOException { try { GetTransferRequest requestdataobject = TransferAssembler.buildGetTransferRequest(transferID); GetTransferResponse responsedataobject = new GetTransferResponse(); restrequester.requestpost(restconstants.gettransfer_abs_path, requestdataobject, responsedataobject); return TransferAssembler.buildTransfer(responseDataObject); catch (RESTRequesterException e) { throw new DAOException("Server access error", e); Codefragment 4.2: Een geïmplementeerde methode van de DAO-interface 22

29 4.5 Navigatie tussen activities In de applicatie wordt er tussen verschillende schermen genavigeerd. In Android wordt een scherm met de klasse Activity voorgesteld. Alles begint dus bij de login-activity (Figuur 4.3). Hierin kan de gebruiker zijn logingegevens invullen. Na authenticiteitscontrole wordt er naar het hoofdscherm genavigeerd. Voor de rest van de app is het hoofdscherm het centrale gedeelte. Na een bepaalde reeks handelingen wordt er altijd terug naar dit scherm genavigeerd. Activities worden constant aangemaakt en afgebroken. Eerste probleem Figuur 4.3: Login activity Sommige objecten hoeven slechts eenmalig aangemaakt te worden en moeten op verschillende plaatsen in de applicatie toegankelijk zijn. Denk hierbij aan het DAO-object en een user-object met informatie over de ingelogde gebruiker. Deze objecten constant doorgeven van de ene activity naar de andere is niet echt een optie. Er zijn twee verschillende oplossingen voor dit probleem. Een eerste oplossing is dat Android toelaat om een globaal contextobject te creëren dat vanuit elke activity in de applicatie bereikbaar is. Dit object is van het type Application. Door nu via overerving van de Application-klasse een nieuwe klasse met eigen functionaliteit aan te maken, wordt het mogelijk om het DAO en userobject ergens in de applicatie aan te spreken. In de Android Manifest-file wordt naar de nieuwe klasse verwezen en bij initialisatie van de app, zorgt Android ervoor dat er één object van dit type aangemaakt wordt. 23

30 De tweede oplossing is om gebruik te maken van een eigen geschreven singleton-klasse met dezelfde extra toegevoegde functionaliteit. Door het statische instantie-attribuut van de singleton-klasse, is er ook een object met de eigen functionaliteit beschikbaar over heel de applicatie. In deze applicatie is voor de eerste oplossing gekozen omdat het gebruik van singletons subtiele problemen met zich meebrengt en afgeraden wordt (Singletons vs. Application Context in Android, 2010). Tweede probleem Bepaalde schermen zoals bijvoorbeeld het keuzescherm van een betalingswijze worden opnieuw gebruikt in verschillende schermen flows. Dit wil zeggen dat de zonet opgesomde activity een verschillend ouderscherm kan hebben naargelang de handelingen van de gebruiker. Standaard up -navigatie in Android werkt als volgt (Codefragment 4.3). Ten eerste moet de up-knop in de actionbar in de oncreate-methode zichtbaar gemaakt worden. Vervolgens wordt er code aan het klikevent van deze knop gekoppeld. Het is de navigateupfromsametask-methode die ervoor zorgt dat de ouder-activity opnieuw wordt geladen en dat de huidige activity wordt afgesloten. Hiervoor wordt er gekeken naar de klassennaam van de ouderactivity die gespecificeerd is in de manifest-file. Het probleem is nu als er daar twee ouders zouden gedefinieerd zijn, Android niet kan weten welke activity nu juist als ouderactivity moet geladen worden. // Code in een Activity public void oncreate(bundle savedinstancestate) { public boolean onoptionsitemselected(menuitem item) { switch (item.getitemid()) { case android.r.id.home: NavUtils.navigateUpFromSameTask(this); return true; return super.onoptionsitemselected(item); <!-- Code toevoegen in de manifest file --> <activity <!-- --> android:parentactivityname="com.example.myfirstapp.mainactivity"> <meta-data android:name="android.support.parent_activity" android:value="com.example.myfirstapp.mainactivity" /> </activity> Codefragment 4.3: Code voor standaard up-navigatie (Providing Up Navigation, z.j.) 24

31 De oplossing is om de up-navigatie in code na te maken zodat meerdere ouders wel mogelijk zijn. Het volgende codefragment (Codefragment 4.4) geeft de code die nodig is om van een activity naar een andere activity te gaan (voorwaarts navigeren). In dit voorbeeld bevindt deze code zich in de loginactivity en zorgt ze ervoor dat de hoofdactivity geladen wordt. De oplossing voor het probleem van meerdere ouders maakt gebruik van deze standaardnavigatie, maar ze bevat nog wat extra lijnen code en een extra instelling. Intent intent = new Intent(this, ActivityMain.class); startactivity(intent); Codefragment 4.4: Code voor standaardnavigatie tussen activities Als voorbeeld (Codefragment 4.5) van de uiteindelijke oplossing wordt er naar de activity ActivityChooseMethod gekeken. Deze bevat een lijst van knoppen waarmee de gebruiker een betaalwijze kan selecteren. Deze activity kan de gebruiker van uit de hoofdactivity (Activity- Main) en vanuit de activity om een nieuwe transfer aan te maken (ActivityNewTransfer) oproepen. De ene flow is dus van de betaler en de andere flow is van de ontvanger. Het eerste stukje code (Codefragment 4.5) moet in ActivityMain toegevoegd worden. Dit is code voor standaardnavigatie van ActivityMain naar ActivityChooseMethod. Bij de overgang wordt er nu echter een gegeven meegestuurd, namelijk een constante die de naam bevat van de activity die ActivityChooseMethod oproept. In ActivityChooseMethod wordt deze parameter opgehaald en in een variabele callingactivityname gestoken. Wanneer nu op de up-knop geklikt wordt, wordt het onderste stukje code van het codefragment in ActivityChooseMethod uitgevoerd. Deze bevat opnieuw een standaard navigatiemanier via een intent en er wordt afhankelijk van de waarde van callingactivityname naar de juiste klasse genavigeerd. Als we nu deze code zouden uitvoeren zonder de intent-vlag, dan zou er gewoon verder naar een nieuwe instantie van ActivityMain genavigeerd worden. Om dit te vermijden wordt met een vlag aangegeven dat Android pas een nieuwe instantie mag aanmaken wanneer het alle tussenliggende activities en de ouderactivity zelf heeft afgesloten. Via deze methode wordt exact hetzelfde resultaat nagebootst als met de navigateupfromsame- Task-methode. Op dezelfde manier is het bijvoorbeeld ook mogelijk om van het allerlaatste scherm in de flow (betalingsbevestiging-activity) naar het hoofdscherm terug te keren. 25

32 // Code voor in ActivityMain Intent intent = new Intent(this, ActivityChooseMethod.class); intent.putextra(basicconstants.intent_extra_key_calling_activity_name, BasicConstants.ACTIVITY_NAME_MAIN); startactivity(intent); // Code voor in ActivityChooseMethod Class c; if (BasicConstants.ACTIVITY_NAME_MAIN.equals(callingActivityName)) { c = ActivityMain.class; else { c = ActivityNewTransfer.class; Intent intent = new Intent(this, c); intent.setflags(intent.flag_activity_clear_top); startactivity(intent); Codefragment 4.5: Oplossing voor up-navigatie met meerdere ouderactivities 4.6 Asynchrone taken Een activity wordt in de oncreate-methode van de Activity-klasse aangemaakt. Op die plaats wordt normaal gezien de lay-out uit het XML-bestand geladen en aan de view van de activity toegevoegd. Dit gebeurt op de User Interface-thread (UI-thread) van de applicatie. Die is verantwoordelijk voor de UI en voor het verwerken van gebruikersinvoer. In de applicatie moeten vaak nog data van de SVA-server worden opgehaald en dynamisch in de View van de Activity worden ingevuld (denk hierbij aan een scherm dat de laatste 10 transfers toont). Aangezien data ophalen van een server een blokkerende operatie kan zijn (de internetverbinding kan wegvallen) leidt dit tot een niet-vlotreagerende GUI en kan dit zelfs tot niet-reagerende activities leiden (Keeping Your App Responsive, z.j.). Android controleert of applicaties altijd responsief zijn. Indien gebruikersinvoer niet binnen de vijf seconden wordt verwerkt (doordat er een zware berekening bezig is of een blokkerende operatie), wordt er een boodschap op het scherm getoond (Figuur 4.4) en wordt aan de gebruiker gevraagd of hij de app wil sluiten. De oplossing voor dit probleem is dus om zware/mogelijke blokkerende taken op een aparte thread te laten uitvoeren. In de mobiele applicatie wordt tijdens de oncreate-methode eerst een bezig-met-laden-indicator (Figuur 4.5) getoond en daarna wordt de data-aanvraag op een aparte thread gestart. De gebruiker kan zien aan de loading-indicator dat er nog een taak in de achtergrond bezig is en dat hij eventjes moet wachten. Wanneer de asynchrone taak afgewerkt is (wanneer de data van de server afgehaald zijn), wordt dan de loading-indicator door de effectieve data vervangen. 26

33 Figuur 4.4: Melding wanneer de applicatie niet meer reageert (Keeping Your App Responsive, z.j.) Figuur 4.5: Hoofdactivity met loading indicator Om eenvoudig een nieuwe achtergrondthread aan te maken, voorziet de Android API in een AsyncTask-klasse. Deze klasse bevat al volledig de logica om een nieuwe thread aan te maken. Eigen functionaliteit kan beschreven worden door gewoon van deze klasse over te erven en de template methods in te vullen. Er zijn drie belangrijke methodes die hier van toepassing zijn. De doinbackground-methode, onpostexecute-methode en de oncancelled-methode. De eerste bevat de code die in de aparte thread wordt uitgevoerd. De tweede methode bevat de code die wordt uitgevoerd nadat de doinbackground-methode succesvol is afgerond. De returnwaarde van de doinbackground-methode wordt als parameter aan de onpostexecute-methode meegegeven. Indien de taak geannuleerd is, wordt de derde methode aangeroepen in plaats van de tweede. Deze krijgt ook de returnwaarde van de eerste methode als parameter. Zowel de on- PostExecute-methode als de oncancelled methode worden weer op de UI-thread uitgevoerd. 27

34 In de app zijn er redelijk veel taken die op de achtergrond voltooid moeten worden. Een bepaalde taak kan ook op verschillende plaatsen worden opgeroepen en de acties die op de UIthread uitgevoerd moeten worden, verschillen dus ook per plaats wanneer de taak voltooid is. Om dit gemakkelijk te laten verlopen en te implementeren is er een nieuwe abstracte klasse toegevoegd, namelijk TaskCallbackTask(Codefragment 4.6). De nieuwe klasse erft over van AsyncTask. De klasse AsyncTask is een geparameteriseerde klasse. Ze bevat drie parameters. De eerste is het type van de parameter van de doinbackground-methode. De tweede is het type van de parameter van de onprogressupdate-methode. Deze wordt hier niet gebruikt. Het doel van deze methode is om de status in de UI aan te geven. De parameter is een zelf afgesproken waarde van een bepaald type die de status voorstelt. Een voorbeeld van een type zou een integer kunnen zijn die van 0 tot 100 gaat. De derde parameter is het type van de teruggeefwaarde van de doinbackground-methode. De klasse TaskCallbackTask heeft een attribuut van het type TaskCallback. Dit is een interface (Codefragment 4.7) die twee methodes beschrijft. De eerste methode wordt opgeroepen wanneer de taak succesvol afgewerkt is en de tweede indien er een fout is opgetreden. Door andere TaskCallback-implementaties aan de constructor van TaskCallbackTask mee te geven, kan dus het gewenste gedrag bij voltooiing of bij het falen van een taak worden ingevuld. Iedere nieuwe DAO-taak moet nu enkel nog de doinbackground-methode en het parametertype invullen. public abstract class TaskCallbackTask<P> extends AsyncTask<P, Integer, Object> { private TaskCallback callback; public TaskCallbackTask(TaskCallback callback) { this.callback = protected abstract Object doinbackground(p... protected void onpostexecute(object result) { if (callback!= null) { protected void oncancelled(object error) { if (callback!= null) { callback.taskfailed((exception) error); Codefragment 4.6: De abstracte klasse TaskCallbackTask 28

35 public interface TaskCallback { void taskcallback(object result); void taskfailed(exception exception); Codefragment 4.7: De interface TaskCallback De meeste van de asynchrone taken in de applicatie zijn serveraanvragen die over het netwerk worden verstuurd. Daarom is er speciaal voor deze groep taken nog een abstracte klasse (Codefragment 4.8) gedefinieerd. Deze voegt nog een extra attribuut toe, namelijk een verwijzing naar het DAO-object dat iedere overervende klasse sowieso nodig heeft als het een aanvraag wil doen. public abstract class DAOTask<P> extends TaskCallbackTask<P> { protected DAO dao; public DAOTask(TaskCallback callback, DAO dao) { super(callback); this.dao = protected abstract Object doinbackground(p... param); Codefragment 4.8: De abstracte klasse DAOTask Als laatste is er nog een voorbeeld (Codefragment 4.9) van een implementerende klasse van DAOTask. De klasse GetTransferDetailsTask haalt asynchroon de gegevens van een bepaalde transfer op. De parameter die wordt meegegeven is het gedeelde unieke ID van de transfer. Via de constructor krijgt het taskobject een referentie naar een callback en een referentie naar een willekeurige DAO-object. Het enige dat de implementatie van de klasse nog moet voorzien, is de code die in de doinbackground-methode uitgevoerd moet worden. In een activity zelf kan nu een taak zeer eenvoudig gestart worden (Codefragment 4.10). Om de transferdetails op te vragen wordt er gewoon een nieuw object van de taakklasse aangemaakt. In de constructor wordt een referentie naar een callbackobject en het DAO-object meegegeven. Wanneer de taak voltooid is of wanneer er een fout is opgetreden, wordt de juiste overeenkomstige methode opgeroepen. 29

36 public class GetTransferDetailsTask extends DAOTask<String> { public GetTransferDetailsTask(TaskCallback callback, DAO dao) { super(callback, protected Object doinbackground(string... param) { try { return dao.gettransfer((string) param[0]); catch (DAOException e) { cancel(false); return e; Codefragment 4.9: De klasse GetTransferDetailsTask new GetTransferDetailsTask(this, appcontext.getdao()).execute(transferid); 4.7 ZXing Codefragment 4.10: Code om een asynchrone taak te starten Voor het genereren, scannen en decoderen van QR-codes is er gebruik gemaakt van de ZXingbibliotheek. Dit is een Java bibliotheek die naast QR-codes ook nog met heel wat andere barcodes kan werken. Omdat coderen en decoderen zware berekeningen zijn, worden deze op een aparte thread (via een implementatie van TaskCallbackTask) uitgevoerd. Het gedeelde unieke ID wordt bij het aanmaken van een transfer naar een QR-code omgezet (Figuur 4.6). Bij het scannen van de QR-code, wordt deze opnieuw gedecodeerd. 30

37 Figuur 4.6: Activity met de QR-code 4.8 Opslag van data op het toestel De meeste informatie in de applicatie is afkomstig van de SVA-server. Er is echter ook nood aan lokale persistente opslag in de mobiele applicatie. Android biedt verschillende mogelijkheden (Storage Options, z.j.) aan voor het opslaan van data op het toestel. Afhankelijk van de soort en de hoeveelheid data is de ene manier beter dan de andere. Shared Preferences Een eerste mogelijkheid is het gebruik van Shared Preferences. Via deze manier kunnen er gemakkelijk key-value-paren van een primitief type worden opgeslagen. Iedere activity heeft zijn eigen Shared Preference. Deze kan binnen een activity via de getpreferences-methode worden opgevraagd. Om een globale Shared Preference tussen verschillende activities te creëren, moet dit opslagobject via de getsharedpreferences-methode worden opgevraagd waarbij als parameter een unieke naam wordt meegegeven. In het voorbeeld (Codefragment 4.11) wordt er gebruik gemaakt van een globale SharedPreference die een paar specifieke instellingen van de applicatie op het toestel bijhoudt. De code demonstreert hoe de laatst gebruikte gebruikersnaam van een SharedPreference kan worden opgevraagd en daarin worden weggeschreven. Nog iets 31

38 wat in de settings SharedPreference wordt opgeslagen, is de device serial van de handelaar. Dit is een extra beveiliging zodat enkel geregistreerde toestellen B2C-transfers kunnen aanmaken. // Opvragen waarde van een sleutel SharedPreferences preferences = getsharedpreferences(basicconstants.shared_preferences_file_name_settings, MODE_PRIVATE); String usernamevalue = preferences.getstring(basicconstants.shared_preferences_key_username, ""); // Opslaan van een waarde bij een sleutel SharedPreferences.Editor editor = preferences.edit(); editor.putstring(basicconstants.shared_preferences_key_username, edit- TextUsername.getText().toString()); editor.commit(); Bestand Codefragment 4.11: Gebruik van Shared Preferences voor opslag van de username Een tweede manier voor persistente opslag is data rechtstreeks naar een bestand op het toestel wegschrijven. Android maakt onderscheid tussen interne opslag en externe opslag (Saving Files, z.j.). Externe opslag werd vroeger gezien als opslagruimte op een verwijderbaar medium zoals bijvoorbeeld een Micro Secure Digital-kaartje (Micro SD-kaartje). Tegenwoordig wordt er nu vaak ook al externe opslag, die niet verwijderbaar is, op de toestellen voorzien. Kleine app specifieke, private data worden het best op de interne en grote (publieke) bestanden op de externe opslagruimte opgeslagen. Data die op de interne opslagruimte opgeslagen zijn, worden mee verwijderd wanneer de gebruiker de applicatie van het toestel verwijdert. Ten slotte is er ook nog de interne en externe cache. Dit is een speciale map die bedoeld is om tijdelijke bestanden op de interne of de externe opslagruimte op te slaan. Wanneer Android opslagruimte tekort komt of als de app wordt verwijderd, dan worden bestanden in deze cache mappen verwijderd. In de applicatie wordt zowel interne als externe opslag gebruikt. De interne opslag wordt gebruikt om een lokale geschiedenis van EMV-transacties bij te houden. Zo kan de handelaar informatie over de laatste tien EMV-transacties bekijken. Deze informatie wordt in een bestand op de interne opslagruimte opgeslagen, want het bestand mag niet leesbaar zijn door derden en andere applicaties aangezien het betaalinformatie bevat. Toegang krijgen tot deze bestanden in de applicatie kan via de methodes openfileinput en openfileoutput. Deze methodes geven als returnwaarde een FileInputStream en een FileOutputStream waarmee dan gewerkt kan worden zoals in normale Java applicaties. Op het QR-codegenereerscherm, is er een actie toegevoegd om de QR-code te delen. Dit maakt het mogelijk om een betaling uit te voeren waarbij beide personen zich niet meer in dezelfde ruimte bevinden. Deze actie opent via een impliciete intent een willekeurig gekozen (door de gebruiker) applicatie die in staat is om een afbeelding te delen. Het is echter niet mogelijk (Sending Simple Data, z.j.) om de QR-code als bitmapobject met de intent naar de andere applicatie 32

39 mee te geven. De afbeelding wordt eerst naar de externe opslagruimte (toegankelijk voor andere applicaties) geschreven. Aangezien de afbeelding tijdelijk is en steeds overschreven wordt wanneer een nieuwe QR-code wordt gedeeld, is er gekozen voor de externe cache map. Het is nu het pad naar de afbeelding dat bij de intent bijgevoegd wordt. De gekozen applicatie kan nu via dit pad aan de afbeelding geraken. Om in de applicatie een verwijzing naar de cachemap te krijgen, wordt de getexternalcachedir-methode gebruikt. Deze geeft een object terug van het type File dat het pad bevat. Nu kan er weer een FileOutputStream voor een bestand in die map aangemaakt worden en kan de afbeelding naar deze stream geschreven worden. Databank Voor de volledigheid wordt er nog even vermeld dat er ook een derde mogelijkheid is. Android biedt volledige ondersteuning voor SQLite databanken. Deze zijn enkel toegankelijk via een gekozen naam binnen de applicatie. SQLite is een zeer kleine databankbibliotheek. Het maakt geen gebruik van een apart serverproces, maar leest en schrijft rechtstreeks naar het databankbestand (About SQLite, z.j.). 4.9 Notificaties Wanneer de betaler op betalen duwt, krijgt hij onmiddellijk feedback (Figuur 4.7) als de betaling succesvol is. Een ontvanger blijft echter vastzitten op het QR-codescherm omdat er zich een tijdsperiode bevindt tussen de generatie van de QR-code en het inscannen en accepteren door de betaler. Dit kan van lange duur zijn indien de ontvanger beslist heeft om de QR-code te delen (bv. via ). Hiervoor worden er twee verschillende notificatieoplossingen ingebouwd. Figuur 4.7: Bevestigingsscherm van een betaling 33

40 Een eerste mogelijkheid is specifiek voor de situatie wanneer beide personen zich in dezelfde ruimte bevinden. Betalen duurt dan zeker niet langer dan een (halve) minuut. Op het QR-code scherm wordt er periodiek nagegaan of de betaling voltooid is. Dit wordt met een timer gerealiseerd. Een timer voert periodiek de run-methode van een object op een aparte thread uit. In deze methode wordt er nagegaan of de transfer voltooid is of niet. Er wordt opnieuw met een callback interface gewerkt om het gedrag gemakkelijk te kunnen aanpassen. Wanneer de betaling voltooid is, wordt er automatisch naar het betalingsbevestigingsscherm overgegaan. De tweede implementatie is er een voor langere tijdsperiodes. De ontvanger kan aanduiden dat hij via een sms wil verwittigd worden wanneer de betaling voltooid is. Er is specifiek voor een sms-bericht gekozen omwille van de gebruiksvriendelijkheid van de applicatie. De app zou even goed een service kunnen starten die periodiek in de achtergrond controleert (ook wanneer de applicatie niet meer actief is) of de betaling al voltooid is en indien wel, een notificatie tonen. Dit zorgt echter voor een bijkomende en blijvende vertraging van het systeem, ook wanneer de gebruiker de app al heeft afgesloten. Daarom is er voor de volgende elegante oplossing gekozen. Wanneer de gebruiker op de sms-knop duwt, registreert hij zich op de server zodat hij verwittigd wordt. Daarna mag de gebruiker gewoon verder werken met de applicatie en zelfs de applicatie afsluiten. Wanneer de betaling voltooid is, stuurt de SVA-server een sms-bericht (Figuur 4.8) naar alle personen die zich geregistreerd hebben. De inhoud van het sms-bericht is een URL die als parameter het gedeelde unieke ID bevat. Figuur 4.8: Sms-bericht van SVA met daarin het transfer-id In de Androidapplicatie is er een activity aangemaakt die een overzicht van de betaling weergeeft (Figuur 4.9). Deze activity kan nu aan de URL gekoppeld worden (Codefragment 4.12) zodat de overzichtsactivity wordt opgestart als de gebruiker op de URL klikt. Dit is mogelijk omdat de sms-applicatie een willekeurige activity start via een impliciete intent met een URL. Android selecteert hierbij de best passende activity die URL s kan verwerken. Door filters bij de overzichtsactivity in de manifest te specificeren, wordt aangegeven welke URL s deze kan verwerken en of die dus al dan niet mag opgestart worden. De URL heeft als schema (protocolaanduiding) HTTPS. Oorspronkelijk was het de bedoeling om een eigen schema te gebruiken (bv. de naam van de applicatie). Dan zou de URL er als volgt uitgezien hebben. paynow://shareduniqueid 34

41 Bij Android werd deze URL echter in sommige applicaties niet als URL herkend en was hij dus niet meer aanklikbaar. Er is nog een bijkomend gebruiksvoordeel van HTTPS. Indien de binding op een of andere manier toch zou falen, wordt de browser geopend en komt de gebruiker op een online versie van het overzicht terecht. Figuur 4.9: Transferoverzichtscherm <activity <!-- --> <intent-filter> <action android:name="android.intent.action.view" /> <category android:name="android.intent.category.default"/> <category android:name="android.intent.category.browsable"/> <data android:scheme="https" android:pathprefix=" /> </intent-filter> </activity> Codefragment 4.12: Intentfiltering op de HTTPS-URL in de manifest file Omdat een notificatie tonen nog altijd mooier is dan een URL in een sms-bericht is het volgende aan de applicatie toegevoegd. Wanneer er een sms-bericht op een toestel toekomt, kondigt Android dit via een broadcast-bericht aan. Er is aan de applicatie een overervende broadcast receiver klasse toegevoegd (Codefragment 4.13) die getriggerd wordt op zo een broadcastbericht van Android. Wanneer nu een sms-bericht binnenkomt, worden alle broadcast receivers een voor een uitgevoerd. De toegevoegde klasse controleert of het sms-bericht voldoet aan de notificatie-url. Indien wel, wordt het broadcasten onderbroken en wordt er een notificatie (Figuur 4.10) getoond. Indien niet, wordt het bericht gewoon aan de volgende broadcast receiver doorgegeven. Aan een broadcast receiver kan er ook een prioriteit toegekend worden. Door 35

42 deze de hoogste prioriteit (integerwaarde 999) te geven, wordt deze SMSBroadcastReceiver als eerste uitgevoerd. Aan de notificatie is uiteindelijk een pendingintent gekoppeld met een intent dat ook het betalingsoverzichtsscherm toont wanneer op de notificatie wordt gedrukt. Figuur 4.10: De notificatie die verschijnt wanneer een betaling voltooid is <receiver android:name="be.j4s.payment.products.paynow.classes.smsbroadcastreceiver" android:enabled="true" android:exported="true"> <intent-filter android:priority="999"> <action android:name="android.provider.telephony.sms_received" /> </intent-filter> </receiver> 4.10 ProGuard Codefragment 4.13: Aankondiging van de SMSBroadcastReceiver in de manifest file Bij Android worden de gecompileerde code, de gebruikte bibliotheken en andere resources in een apk-bestand gebundeld. Het is dit bestand dat manueel of via Google Play wordt verspreid en geïnstalleerd. ProGuard is een tool die de code verkleint, optimaliseert en minder leesbaar maakt. Het verwijdert niet-gebruikte klassen en methodes en vervangt lange namen van bijvoorbeeld klassen en methodes door korte, betekenisloze namen zoals a, b en c. Dit maakt reverse enginering moeilijker en zorgt voor een kleinere bestandsgrootte (ProGuard, z.j.). Als voorbeeld wordt de ongetekende applicatie voor en na het gebruik van ProGuard vergeleken. De grootte van het apk-bestand is van 2,6 naar 0,8 MB gedaald. De tool wordt standaard enkel gebruikt bij de release-modus van de applicatie. Het heeft immers in de meeste gevallen geen zin om code onleesbaar te maken aangezien dit enkel het debuggen vermoeilijkt. De uitvoering van deze tool genereert onder andere een bestand met de gebruikte mapping tussen de oude en nieuwe namen. Deze is nodig indien een gebruiker van een release-versie een stacktrace doorstuurt. Die is onleesbaar en kan met behulp van ProGuard en het mapping-bestand weer leesbaar gemaakt worden zodat de ontwikkelaar eenvoudig kan zien waar de applicatie gecrasht was. Er is ook een betalende variant, namelijk DexGuard (Saikoa, 2014). Deze biedt nog meer mogelijkheden zoals bijvoorbeeld encryptie van hardgecodeerde strings, encryptie van belangrijke klassen en detectie van codewijzigingen, maar deze is hier niet gebruikt. 36

43 4.11 Europay Mastercard Visa-ondersteuning De handelaar kan met de mobiele applicatie ook geld via betaalkaarten ontvangen. Hiervoor wordt er een EMV-lezer (Figuur 4.11) aan de smartphone gekoppeld. De smartphone communiceert bidirectioneel met dit toestel via de audio jack. Om antwoorden te kunnen ontvangen, heeft de Androidapplicatie de record audio-permissie nodig. De app functioneert nu als een betaalterminal. Om het betalingsproces vlot te laten verlopen wordt er visuele feedback op het scherm (Figuur 4.12) gegeven. Om het inpluggen van het device te detecteren wordt er gebruik gemaakt van een broadcast receiver. Er wordt namelijk door Android een broadcast intent verstuurd bij in- en uit pluggen van een audio jack. In tegenstelling tot de sms-broadcast receiver, wordt de audio jack broadcast receiver dynamisch geregistreerd en geannuleerd in de onresume en onpause methodes. Het heeft geen zin om deze broadcast receiver door Android te laten uitvoeren indien het betalingsscherm niet op de voorgrond draait. Voor de rest wordt er een luisterklasse geregistreerd als luisteraar bij de MPOSbibliotheek en wordt het EMV-betalingsproces gestart. Wanneer de klant zijn betaalkaart insteekt en zijn pincode intoetst worden er verschillende callback-methodes opgeroepen die de GUI aanpassen. Figuur 4.11: De EMV-lezer (PAYware Mobile e105, 2013) 37

44 Figuur 4.12: Het EMV-betalingsscherm 4.12 Android Wear Android Wear is een verbreding van het Android platform met nieuwe functionaliteit specifiek voor draagbare accessoires zoals bv. een smartwatch. Het platform (Android Wear, z.j.) is tijdens deze masterproef aangekondigd en er is een beperkte preview beschikbaar gesteld. In deze versie is het enkel mogelijk om de notificatiefunctionaliteit te testen. Hieronder wordt er onderzocht welke stappen en wijzigingen er nodig zijn om de betalingsnotificatie van de mobiele applicatie op een smartwatch te laten weergeven. Op het moment van schrijven zijn er nog geen smartwatches die werken op Android Wear beschikbaar. Gelukkig is er wel een bijgeleverde emulator om bepaalde zaken uit te testen. Een smartwatch (hier nu de emulator) moet gekoppeld worden aan een smartphone. Dit is zeer eenvoudig via de instellingenapplicatie (Figuur 4.13). De app zorgt ervoor dat de smartphone met de smartwatch kan communiceren. Figuur 4.13: Android Wear Preview applicatie 38

45 Standaard kunnen notificaties van de smartphone automatisch al op de smartwatch worden getoond (Figuur 4.14). De gebruiker moet hiervoor deze optie in de instellingenapplicatie van Android Wear aanvinken. Een notificatie wordt aan de main stream (of ook context stream) toegevoegd (Design Principles, 2014). Deze bestaat uit verschillende cards die elk interessante informatie tonen. Door eenvoudige, verticale swipe-bewegingen, kan er tussen de verschillende cards worden genavigeerd. De eerste is deze van de mobiele betalingsapplicatie (Figuur 4.15). Aan een card kunnen er ook acties gekoppeld worden. Bij een notificatie-card is dit de open - actie en deze voert de meegeleverde intent uit. Acties zijn bereikbaar door naar links te swipen. Om nu het betalingsoverzicht op de smartphone op te starten, volstaat het om op het cirkelvormige icoon (Figuur 4.15) te klikken. Om een card/notificatie te verwijderen wordt er op het linkse scherm (Figuur 4.15) naar rechts geswipet. Figuur 4.14: Android Wear emulator met een notificatie van de applicatie zichtbaar op het hoofdscherm Figuur 4.15: Een card uit de main stream met bijhorende actie De Android Wear notificatie API voorziet heel wat nieuwe mogelijkheden om normale smartphone notificaties te verfijnen zodat ze speciaal voor de smartwatch gebruiksvriendelijker worden. Zo is het mogelijk om verschillende notificaties te groeperen zodat ze individueel via 39

NHibernate als ORM oplossing

NHibernate als ORM oplossing NHibernate als ORM oplossing Weg met de SQL Queries Wat is ORM? ORM staat in dit geval voor Object Relational Mapping, niet te verwarren met Object Role Modeling. ORM vertaalt een objectmodel naar een

Nadere informatie

General info on using shopping carts with Ingenico epayments

General info on using shopping carts with Ingenico epayments Inhoudsopgave 1. Disclaimer 2. What is a PSPID? 3. What is an API user? How is it different from other users? 4. What is an operation code? And should I choose "Authorisation" or "Sale"? 5. What is an

Nadere informatie

Sparse columns in SQL server 2008

Sparse columns in SQL server 2008 Sparse columns in SQL server 2008 Object persistentie eenvoudig gemaakt Bert Dingemans, e-mail : info@dla-os.nl www : http:// 1 Content SPARSE COLUMNS IN SQL SERVER 2008... 1 OBJECT PERSISTENTIE EENVOUDIG

Nadere informatie

API...1 Identificatie...1 Opties...2 Acties...3 Webserver...6 Heartbeat...6 Buffer groottes...8

API...1 Identificatie...1 Opties...2 Acties...3 Webserver...6 Heartbeat...6 Buffer groottes...8 API API...1 Identificatie...1 Opties...2 Acties...3 Webserver...6 Heartbeat...6 Buffer groottes...8 Identificatie Alle programma's communiceren met elkaar door gebruik te maken van JSON objecten. Het normale

Nadere informatie

Technisch Ontwerp W e b s i t e W O S I

Technisch Ontwerp W e b s i t e W O S I Technisch Ontwerp W e b s i t e W O S I WOSI Ruud Jungbacker en Michael de Vries - Technisch ontwerp Website Document historie Versie(s) Versie Datum Status Omschrijving / wijzigingen 0.1 20 nov 2008 Concept

Nadere informatie

Technical Note. API Beschrijving Aangetekend Mailen

Technical Note. API Beschrijving Aangetekend Mailen AUTHOR APPROVED Technical Note API Beschrijving Referentie: API beschrijving AM Versie: 0.0.7 Datum: 2015-07-24 Aangetekend Bellen B.V. Computerweg 5 Postbus 8307 3503 RH Utrecht T: +31 346 581 731 support@aangetekendmailen.nl

Nadere informatie

HANDLEIDING EXTERNE TOEGANG CURAMARE

HANDLEIDING EXTERNE TOEGANG CURAMARE HANDLEIDING EXTERNE TOEGANG CURAMARE Via onze SonicWALL Secure Remote Access Appliance is het mogelijk om vanaf thuis in te loggen op de RDS omgeving van CuraMare. Deze handleiding beschrijft de inlogmethode

Nadere informatie

React en React Native voor websites en apps

React en React Native voor websites en apps React en React Native voor websites en apps H A N S-PE T E R H ARMSEN HEEFT DI T GE SCH R E V EN IN APRI L 2017 Deze whitepaper is bedoeld voor product owners en beslissers. Hij gaat over React, een JavaScript

Nadere informatie

Secure File Sync - Quick Start Guide

Secure File Sync - Quick Start Guide Secure File Sync - Quick Start Guide Secure File Sync Quick Start Guide 1. Installatie van de applicatie op een computer; 2. Gebruik van de applicatie; 3. Bestanden delen vanuit de applicatie; 4. Gebruik

Nadere informatie

Kleine cursus PHP5. Auteur: Raymond Moesker

Kleine cursus PHP5. Auteur: Raymond Moesker Kleine cursus PHP5 Auteur: Raymond Moesker Kleine cursus PHP PHP is platform en CPU onafhankelijk, open source, snel, heeft een grote userbase, het is object georiënteerd, het wordt omarmd door grote bedrijven

Nadere informatie

Technisch Ontwerp VISSIM-PPA Koppeling

Technisch Ontwerp VISSIM-PPA Koppeling 1 Technisch Ontwerp VISSIM-PPA Koppeling Revisie Versie Datum Omschrijving 1.0 25 juli 2013 Initiële versie 1.1 26 juli 2013 Toevoeging van TDI regeltoestand. Toevoeging van bestandsnaam filtering. 1.2

Nadere informatie

Project plan. Erwin Hannaart Sander Tegelaar 61849 62407

Project plan. Erwin Hannaart Sander Tegelaar 61849 62407 Project plan Erwin Hannaart Sander Tegelaar 61849 62407 I4C2 I4C1 1 Inhoudsopgave Doel en doelgroep van het project... 3 Beschrijving van het project... 4 Benodigde materialen... 5 Te verwachten resultaten,

Nadere informatie

icafe Project Joeri Verdeyen Stefaan De Spiegeleer Ben Naim Tanfous

icafe Project Joeri Verdeyen Stefaan De Spiegeleer Ben Naim Tanfous icafe Project Joeri Verdeyen Stefaan De Spiegeleer Ben Naim Tanfous 2006-2007 Inhoudsopgave 1 2 1.1 Programmeertaal PHP5..................... 2 1.2 MySQL database......................... 3 1.3 Adobe Flash...........................

Nadere informatie

Software Design Document

Software Design Document Software Design Document Mathieu Reymond, Arno Moonens December 2014 Inhoudsopgave 1 Versiegeschiedenis 2 2 Definities 3 3 Introductie 4 3.1 Doel en Scope............................. 4 4 Logica 5 4.1

Nadere informatie

ANOUK ROUMANS TO CODE OR NOT TO CODE.

ANOUK ROUMANS TO CODE OR NOT TO CODE. ANOUK ROUMANS ANOUK ROUMANS TO CODE OR NOT TO CODE. 00 HOOFDVRAAG 00 HOOFDVRAAG Is het relevant voor een UX-designer om development kennis te hebben op gebied van apps? 00 INHOUDSOPGAVE 00 INHOUDSOPGAVE

Nadere informatie

TaskCentre Web Service Connector: Creëren van requests in Synergy Enterprise

TaskCentre Web Service Connector: Creëren van requests in Synergy Enterprise TaskCentre Web Service Connector: Creëren van requests in Synergy Enterprise Inhoudsopgave 1. Voorbereiding... 4 2. Web Service Connector tool configuratie... 5 3. TaskCentre taak voor het aanmaken van

Nadere informatie

Er zijn diverse andere software platformen en providers die werken met SIP, maar in dit voorbeeld gaan we uit van de volgende software:

Er zijn diverse andere software platformen en providers die werken met SIP, maar in dit voorbeeld gaan we uit van de volgende software: Er zijn diverse andere software platformen en providers die werken met SIP, maar in dit voorbeeld gaan we uit van de volgende software: Counterpath Bria SIP client. Net2 Entry Configuration Utility (SIP

Nadere informatie

Gebruik van cryptografie voor veilige jquery/rest webapplicaties. Frans van Buul Inter Access

Gebruik van cryptografie voor veilige jquery/rest webapplicaties. Frans van Buul Inter Access Gebruik van cryptografie voor veilige jquery/rest webapplicaties Frans van Buul Inter Access 1 Frans van Buul frans.van.buul@interaccess.nl 2 De Uitdaging Rijke en veilige webapplicaties Een onveilig en

Nadere informatie

Maximo Tips and Tricks

Maximo Tips and Tricks Maximo Tips and Tricks Agenda Tips & Tricks 1. Scherm lay-out on demand 2. Koppelen Excel en Maximo 3. Foto s toevoegen aan records 4. Type ahead functie 5. Scripting voor calculaties en validaties 6.

Nadere informatie

ideal QR betalen via een QR-code

ideal QR betalen via een QR-code ideal betalen via een -code Introductie ideal- voor softwareleveranciers Roland Thijssen Cards, Cash & Online ideal Kenmerken -code met ideal logo Scannen met de ideal app (en straks bankieren-app) Net

Nadere informatie

Technische aansluit documentatie Versie 2.23 19-08-2011

Technische aansluit documentatie Versie 2.23 19-08-2011 Versie 2.23 19-08-2011 Inhoudsopgave Wijzigingen...2 Introductie... 3 Overzicht koppeling...3 Uw site instellen... 4 Overzicht instellingen...4 Gateway koppeling... 6 Overzicht POST variabelen...6 De hash

Nadere informatie

Werkomgeving. Android Studio. Android - werkomgeving 1/6

Werkomgeving. Android Studio. Android - werkomgeving 1/6 Android - werkomgeving 1/6 Werkomgeving Android Studio Installatie Ga naar de volgende URL: http://developer.android.com/sdk/index.html Klik op de knop "Download Android Studio for Windows" om het programma

Nadere informatie

Naam project Lost And Found Animals Lokaal gehost Percentage van het totaal geleverde werk 1 Cindy Jansen 50% 2 Eline Steyvers 50%

Naam project Lost And Found Animals Lokaal gehost Percentage van het totaal geleverde werk 1 Cindy Jansen 50% 2 Eline Steyvers 50% Naam project Lost And Found Animals Url Lokaal gehost Groepsleden Percentage van het totaal geleverde werk 1 Cindy Jansen 50% 2 Eline Steyvers 50% 1. Beveiliging in de toepassing Naam gebruiker Wachtwoord

Nadere informatie

Intramed OnLine instellen en gebruiken. Voor Android tablet of telefoon

Intramed OnLine instellen en gebruiken. Voor Android tablet of telefoon Intramed OnLine instellen en gebruiken Voor Android tablet of telefoon Inhoudsopgave Hoofdstuk 1 Algemeen...1 1.1 Toegang tot inlogportalen...1 Hoofdstuk 2 Basic account...3 2.1 Microsoft Remote Desktop

Nadere informatie

Handleiding. Opslag Online voor Windows Phone 8. Versie augustus 2014

Handleiding. Opslag Online voor Windows Phone 8. Versie augustus 2014 Handleiding Opslag Online voor Windows Phone 8 Versie augustus 2014 Inhoudsopgave Hoofdstuk 1. Inleiding 3 Hoofdstuk 2. Installatie 4 2.1 Downloaden van KPN Opslag Online QR Code 4 2.2 Downloaden van KPN

Nadere informatie

Dynamiek met VO-Script

Dynamiek met VO-Script Dynamiek met VO-Script Door Bert Dingemans DLA Ontwerp & Software bert@dla-architect.nl Inleiding Op de SDGN nieuwsgroep voor Visual Objects ontstond laatst een draad van berichten over de nieuwe libraries

Nadere informatie

Temperatuur logger synchronisatie

Temperatuur logger synchronisatie Temperatuur logger synchronisatie Juni 10, 2010 1 / 7 Temperatuur logger synchronisatie Introductie Twee of meerdere ontvangers van het Multilogger systeem kunnen met de temperature logger synchronisatie

Nadere informatie

Handleiding. Opslag Online. voor Android. Versie februari 2014

Handleiding. Opslag Online. voor Android. Versie februari 2014 Handleiding Opslag Online voor Android Versie februari 2014 Inhoudsopgave Hoofdstuk 1. Inleiding 3 Hoofdstuk 2. Installatie 4 2.1 Opslag Online downloaden via QR-code 4 2.2 Opslag Online downloaden via

Nadere informatie

MultiSafepay. Handleiding Versie 2.0. 088 990 7700 support@ccvshop.nl. www.ccvshop.nl

MultiSafepay. Handleiding Versie 2.0. 088 990 7700 support@ccvshop.nl. www.ccvshop.nl MultiSafepay Handleiding Versie 2.0 088 990 7700 support@ccvshop.nl www.ccvshop.nl Inhoudsopgave Inhoudsopgave 2 Changelog 3 1. Inleiding 4 2. Aanmelden MultiSafepay 5 2.1 Procedure MultiSafepay 5 2.2

Nadere informatie

MultiSafepay Payment plugin voor VirtueMart Copyright (C) 2011 multisafepay.com INLEIDING

MultiSafepay Payment plugin voor VirtueMart  Copyright (C) 2011 multisafepay.com INLEIDING MultiSafepay Payment plugin voor VirtueMart http://www.multisafepay.com Copyright (C) 2011 multisafepay.com INLEIDING Bedankt voor het downloaden van de MultiSafepay VirtueMart 2.0 plugin. In deze handleiding

Nadere informatie

Cash Software B.V. 2518 AD Den Haag (T) 070-3560570 (E) info@cash.nl 1

Cash Software B.V. 2518 AD Den Haag (T) 070-3560570 (E) info@cash.nl 1 Dit volledige document is eigendom van Cash Software B.V. Niets uit dit document mag worden vermenigvuldigd, openbaar gemaakt, vertaald in enige taal, in enige vorm of met enig middel zonder voorafgaande

Nadere informatie

Bottleball Onderzoeksverslag MovingMonsters. Uitgevoerd door Arno Classens a.classens@student.fontys.nl

Bottleball Onderzoeksverslag MovingMonsters. Uitgevoerd door Arno Classens a.classens@student.fontys.nl Bottleball Onderzoeksverslag MovingMonsters Uitgevoerd door Arno Classens a.classens@student.fontys.nl 1 1. Inhoudsopgave Wat? Bladzijde 1. Introductie 3 2. Methodologie 4 3. Resultaten 3.1 Oriëntatie

Nadere informatie

Portal Handleiding voor de gebruiker 4.8

Portal Handleiding voor de gebruiker 4.8 Portal Handleiding voor de gebruiker 4.8 Deze handleiding beschrijft op gebruikersniveau de basisfuncties van de portal. Version: x.x MOBIDM Gebruikershandleiding Pagina 1 Index Introductie 2 Help-bestanden

Nadere informatie

Object Oriented Programming

Object Oriented Programming Object Oriented Programming voor webapplicaties Door Edwin Vlieg Waarom OOP? Basis uitleg over OOP Design Patterns ActiveRecord Model View Controller Extra informatie Vragen OOP Object Oriented Programming

Nadere informatie

De plug-in is heel eenvoudig te installeren met een setup-programma. Waarna je een aantal menu opties in het tools menu er bij krijgt.

De plug-in is heel eenvoudig te installeren met een setup-programma. Waarna je een aantal menu opties in het tools menu er bij krijgt. Plsqldoc Genereer je documentatie Beeklaan 444 2562 BK Den Haag www.darwin-it.nl info@darwin-it.nl KvK 27283780 ING 65.35.40.663 Technical Architect Net als (vrijwel) elke ontwikkelaar vind ik het documenteren

Nadere informatie

INSTALLATIE EXCHANGE CONNECTOR

INSTALLATIE EXCHANGE CONNECTOR HANDLEIDING INSTALLATIE EXCHANGE CONNECTOR INSTALLATIE EXCHANGE CONNECTOR 0 0 HANDLEIDING INSTALLATIE EXCHANGE CONNECTOR INSTALLATIE EXCHANGE CONNECTOR HANDLEIDING datum: 10-08-2018 1 Inleiding... 1 2

Nadere informatie

Gebruikershandleiding. StUF Testplatform Versie 1.3.0

Gebruikershandleiding. StUF Testplatform Versie 1.3.0 Gebruikershandleiding StUF Testplatform Versie 1.3.0 Documentversie: 0.7 Datum 25 november 2014 Status In gebruik Inhoudsopgave 1 INLEIDING...3 2 GEBRUIK MAKEN VAN HET STUF TESTPLATFORM...4 2.1 INLOGGEN

Nadere informatie

NOTITIE. Vragen gebruikersgroep

NOTITIE. Vragen gebruikersgroep NOTITIE [van] Edward Diemel [voor] Swing gebruikersgroep [kenmerk] n2013-0081ed [plaats] Delft [project] 13057-SWG [datum] 19 maart 2013 [onderwerp] Swing gebruikersdag 19-03-2013 Op 19 maart 2013 heeft

Nadere informatie

Koppeling met een database

Koppeling met een database PHP en MySQL Koppeling met een database 11.1 Inleiding In PHP is het eenvoudig om een koppeling te maken met een database. Een database kan diverse gegevens bewaren die met PHP aangeroepen en/of bewerkt

Nadere informatie

1. Over LEVIY 5. Openen van de activiteit 2. Algemene definities 6. Inloggen op het LEVIY dashboard 3. Inloggen 6.1 Overzichtspagina 3.

1. Over LEVIY 5. Openen van de activiteit 2. Algemene definities 6. Inloggen op het LEVIY dashboard 3. Inloggen 6.1 Overzichtspagina 3. Versie 1.0 05.03.2015 02 1. Over LEVIY Wat doet LEVIY? 08 5. Openen van de activiteit Hoe wordt de activiteit geopend? 2. Algemene definities Behandelen van terugkerende definities. 09 6. Inloggen op het

Nadere informatie

ideal Betaal Formulier (Ondersteund o.a. ideal, MisterCash, Direct E-Banking en Credit Card)

ideal Betaal Formulier (Ondersteund o.a. ideal, MisterCash, Direct E-Banking en Credit Card) Script: Versie: 0.5 Licentie: ideal Betaal Formulier (Ondersteund o.a. ideal, MisterCash, Direct E-Banking en Credit Card) Gratis te gebruiken door (erkende) goede doelen. 200,00 excl. BTW voor aanschaf

Nadere informatie

Taxis Pitane voor iphone / ipad

Taxis Pitane voor iphone / ipad Taxis Pitane voor iphone / ipad gebruikershandleiding Censys BV - Eindhoven Voorwoord Censys BV is erkend Apple iphone software ontwikkelaar en heeft eveneens zijn Taxis Pitane voor iphone 3G/3GS/4 versie

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1

Nadere informatie

Software Design Document

Software Design Document Software Design Document PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie

Nadere informatie

5. Documenten Wat kan ik met Documenten? 1. Over LEVIY. 5.1 Documenten terugvinden Uitleg over vinden van documenten.

5. Documenten Wat kan ik met Documenten? 1. Over LEVIY. 5.1 Documenten terugvinden Uitleg over vinden van documenten. Versie 1.0 23.03.2015 02 1. Over LEVIY Wat doet LEVIY? 08 5. Documenten Wat kan ik met Documenten? 2. Algemene definities Behandelen van terugkerende definities. 09 5.1 Documenten terugvinden Uitleg over

Nadere informatie

Siemens workpoints en DHCP options

Siemens workpoints en DHCP options Siemens workpoints en DHCP options Dit document beschrijft de configuratie en werking van een Windows 2003 DHCP server in combinatie met Siemens optipoint en Siemens OpenStage toestellen (aangemeld op

Nadere informatie

Grafisch ontwerp. Referenties. https://developers.google.com/webmasters/mobile-sites/ http://www.bluetrainmobile.com/mobile-showcase

Grafisch ontwerp. Referenties. https://developers.google.com/webmasters/mobile-sites/ http://www.bluetrainmobile.com/mobile-showcase Mobiel Datanose Op dit moment is mobiel datanose niet goed gedaan; je krijgt gewoon de site te zien zoals je het te zien krijgt op pc's of laptops. Maar vaak heb je het probleem dat je op je mobiel moet

Nadere informatie

1.9.6 Release Notes Verbeteringen en uitbreidingen

1.9.6 Release Notes Verbeteringen en uitbreidingen 1.9.6 Release Notes Verbeteringen en uitbreidingen Februari 2014 Release Versie Item Versie Datum SiteOpMobi Platform (Inclusief SiteOpMobi Service, Control Panel, APIs) 1.9.6 19 februari 2014 2 Inhoudsoverzicht

Nadere informatie

4 ASP.NET MVC. 4.1 Controllers

4 ASP.NET MVC. 4.1 Controllers 4 ASP.NET MVC ASP.NET is het.net raamwerk voor het bouwen van webapplicaties. De MVC variant hiervan is speciaal ontworpen voor het bouwen van dergelijke applicaties volgens het Model-View-Controller paradigma.

Nadere informatie

Inhoudsopgave. Hoofdstuk 1.RMI...2

Inhoudsopgave. Hoofdstuk 1.RMI...2 - CORBA Inhoudsopgave Hoofdstuk 1.RMI...2 1.1.Inleiding...2 1.2.De remote...4 1.3.Het remote...5 1.4.De server...6 1.5.De server opstarten...8 1.6.De client applicatie...8 1.7.De stub en skeleton en...10

Nadere informatie

ArcGIS Mobile ADF. Smart Client Applicaties voor ArcGIS Server Eva Dienske, Wim Ligtendag

ArcGIS Mobile ADF. Smart Client Applicaties voor ArcGIS Server Eva Dienske, Wim Ligtendag ArcGIS Mobile ADF Smart Client Applicaties voor ArcGIS Server Eva Dienske, Wim Ligtendag Agenda Wat is de Mobile ADF? Architectuur Demo Wat is de mobile ADF? Ontwikkeltoolkit voor mobiele (Smart Client)

Nadere informatie

Korte uitleg gebruik Jira als bevindingregistratie systeem

Korte uitleg gebruik Jira als bevindingregistratie systeem MEMO Korte uitleg gebruik Jira als bevindingregistratie systeem Aan : Jira gebruikers Datum : 26 juli 2010 Van : Sogeti Jira beheer Versie : 1.1 INLEIDING Deze verkorte uitleg van het gebruik van Jira

Nadere informatie

Is APEX a worthy substitute for Oracle Forms?

Is APEX a worthy substitute for Oracle Forms? your oracle solu+ons partner Is APEX a worthy substitute for Oracle Forms? APEX for mission critical applications: the Groupm business-case By Ronny Boeykens & Stijn Van Raes iadvise o Opgericht in 2004

Nadere informatie

Inhoudsopgave. Hoofdstuk 1.JMS...2

Inhoudsopgave. Hoofdstuk 1.JMS...2 Inhoudsopgave Hoofdstuk 1.JMS...2 1.1.Inleiding...2 1.2.Messaging architectuur...3 1.2.1.Point to point domein...3 1.2.2.Publish/Subscribe domein...4 1.2.3.Synchrone - asynchrone verwerking...4 1.2.4.De

Nadere informatie

Handleiding Maestro. door Patricia Sturm 29 september Versie 1.1 Openbaar

Handleiding Maestro. door Patricia Sturm 29 september Versie 1.1 Openbaar Handleiding Maestro door Patricia Sturm 29 september 2016 Versie 1.1 Openbaar Inhoud 1. Introductie... 3 2. Maestro... 4 2.1. Verloop van een Maestro betaling... 4 2.1.1. Autorisatie middels 3D Secure...

Nadere informatie

Handboek huisstijl ideal QR

Handboek huisstijl ideal QR Handboek huisstijl ideal QR Datum : december 2016 Versie : 2.0 Auteur : Currence ideal B.V. Inleiding In dit document vindt u voorschriften en voorbeelden van het gebruik van ideal QR in de volgende use

Nadere informatie

Kennis na het volgen van de training. Na het volgen van deze training bent u in staat:

Kennis na het volgen van de training. Na het volgen van deze training bent u in staat: Training Trainingscode Duur Gepubliceerd Taal Type Leermethode Kosten SF2015V8 4 dagen 02/02/2015 Nederlands & Engels Developer, basis Invidueel & klassikaal Op aanvraag Deze training richt zich op het

Nadere informatie

Handleiding OpenCart - Reeleezee

Handleiding OpenCart - Reeleezee Handleiding OpenCart - Reeleezee www.webwinkelfacturen.nl Samenvatting Dit is de handleiding voor de koppeling van OpenCart naar Reeleezee. De koppeling zorgt dat voor bestellingen in OpenCart automatisch

Nadere informatie

Mijnkmosite Support Guide

Mijnkmosite Support Guide Mijnkmosite Support Guide Mijnkmosite Support Guide 1 Inleiding tot de "Support Guide" 1.1 Doel van de Gids 4 2 Gebruik van de Helpdesk 2.1 2.2 2.3 2.4 Inleiding 6 Hoe tickets te vinden 7 Tickets bewerken

Nadere informatie

Clang 1.4.0. Release Notes. created by

Clang 1.4.0. Release Notes. created by Clang 1.4.0 Release Notes created by Release 1.4.0 Vanaf 2 november wordt Clang uitgebreid met unieke mogelijkheden op het gebied van e-mail en social media. Het is dan o.a. mogelijk om geautomatiseerd

Nadere informatie

HTTP SMS API Technische Specificatie messagebird.com versie 1.1.6-05 mei 2014

HTTP SMS API Technische Specificatie messagebird.com versie 1.1.6-05 mei 2014 HTTP SMS API Technische Specificatie messagebird.com versie 1.1.6-05 mei 2014 1 Inhoudsopgave INHOUDSOPGAVE 2 1 VERBINDING MET DE API 4 1.1 QUICK START 4 2 SMS PARAMETERS 5 2.1 VERPLICHTE PARAMETERS 6

Nadere informatie

Handleiding DB Alerts app

Handleiding DB Alerts app Handleiding DB Alerts app 3 mei 2019 DB Alerts De DB Alerts app is vernieuwd en aan de nieuwe eisen en veranderingen aangepast. Je kunt de App installeren via de Google Play Store / Apple App Store op

Nadere informatie

SHAREPOINT ONLINE (SAMEN-)WERKEN IN DE WOLKEN. http://www.ie-net.be - Workshop SharePoint 1

SHAREPOINT ONLINE (SAMEN-)WERKEN IN DE WOLKEN. http://www.ie-net.be - Workshop SharePoint 1 SHAREPOINT ONLINE (SAMEN-)WERKEN IN DE WOLKEN 1 WIE ZIJN WIJ? 2 WIE BENT U? Professional Op zoek naar productiviteit Samenwerken met Collega s Externe partijen Onderaannemers 3 WAT IS ONS PLAN? 1. Wat

Nadere informatie

Heeft u nog vragen of verzoeken?

Heeft u nog vragen of verzoeken? Ga naar Gebruikerszone op www.accorservices.be Klik op Neem deel aan het pilootproject van het e- Ticket Restaurant en kies Mij aansluiten op mijn e- Ticket Restaurant -account Voer uw login (e-mailadres)

Nadere informatie

Gebruikershandleiding. StUF Testplatform Versie 1.3.1

Gebruikershandleiding. StUF Testplatform Versie 1.3.1 Gebruikershandleiding StUF Testplatform Versie 1.3.1 Inhoudsopgave 1 INLEIDING... 3 2 GEBRUIK MAKEN VAN HET STUF TESTPLATFORM... 4 2.1 INLOGGEN OP HET STUF TESTPLATFORM... 4 2.2 OPVOEREN EN CONFIGUREREN

Nadere informatie

Technische Handleiding. ideal

Technische Handleiding. ideal Technische Handleiding ideal Technische Handleiding 2 van 13 Inhoudsopgave 1. Betaal.aspx... 3 1.1 Met bank keuze... 4 1.2 Zonder bank keuze... 8 1.3 Werkwijze... 8 2. GetURL(2)... 9 2.1 Werkwijze... 10

Nadere informatie

Gebruikershandleiding voor toegang tot Gasport

Gebruikershandleiding voor toegang tot Gasport Gebruikershandleiding voor toegang tot Gasport 1. Inleiding In deze handleiding staat beschreven hoe u kunt inloggen op de GTS webapplicatie Gasport via Multi-Factor Authentication (MFA). Voordat u kunt

Nadere informatie

Dynamische webapplicaties in Java

Dynamische webapplicaties in Java Dynamische webapplicaties in Java October 7, 2006 In java is het mogelijk dynamische webpagina s te implementeren. De code om de dynamische gegevens te genereren staat in servlets of Java Server Pages

Nadere informatie

Web Application Security Hacking Your Way In! Peter Schuler & Julien Rentrop

Web Application Security Hacking Your Way In! Peter Schuler & Julien Rentrop Web Application Security Hacking Your Way In! Peter Schuler & Julien Rentrop 1 Agenda Injection Cross Site Scripting Session Hijacking Cross Site Request Forgery #1 OWASP #2 top 10 #3 #5 Bezoek www.owasp.org

Nadere informatie

Een website maken met databasetoegang.

Een website maken met databasetoegang. Hoofdstuk 5 Een website maken met databasetoegang. In dit hoofdstuk gaan we het weblog dat je in hoofdstuk 4 hebt gemaakt verder uitbreiden. Een belangrijk onderdeel wordt toegevoegd aan de applicatie,

Nadere informatie

Rabo SmartPin API koppeling

Rabo SmartPin API koppeling Rabo SmartPin API koppeling Integratiehandleiding Met de Rabo SmartPin App in App (API) koppeling kunt u pinpasbetalingen vanuit uw eigen app initiëren en uw klanten vervolgens laten betalen met hun bankpas

Nadere informatie

APEX vs OutSystems, een vergelijking door een gebruiker

APEX vs OutSystems, een vergelijking door een gebruiker WHITEBOOK APEX vs OutSystems, een vergelijking door een gebruiker Februari 2019 Auteur: Michel Vogelpoel INTEGRATIESPECIALIST Inleiding Als fervent gebruiker van APEX moet men ook af en toe over de Oracle

Nadere informatie

HOWTO: Microsoft Domain Controller en Linux DNS-server. geschreven door Johan Huysmans

HOWTO: Microsoft Domain Controller en Linux DNS-server. geschreven door Johan Huysmans HOWTO: Microsoft Domain Controller en Linux DNS-server geschreven door Johan Huysmans 1. Over deze howto. Deze howto behandelt verschillende aspecten van een MS Windows Domain Controller gebruik makend

Nadere informatie

Handleiding: Whitelabel Customersite

Handleiding: Whitelabel Customersite ARGEWEB B.V. Handleiding: Whitelabel Customersite Controlportal.nl Argeweb Support 8-1-2009 Handleiding voor het gebruik maken van de Whitelabel Customersite op controlportal.nl, door Resellers van Argeweb.

Nadere informatie

Handleiding helpdesk. Datum: 08-10-2014 Versie: 1.0 Auteur: Inge van Sark

Handleiding helpdesk. Datum: 08-10-2014 Versie: 1.0 Auteur: Inge van Sark Datum: 08-10-2014 Versie: 1.0 Auteur: Inge van Sark Inhoudsopgave Inhoudsopgave... 2 1. Beheer helpdesk... 3 1.1. Settings... 3 1.2. Applicaties... 4 1.3. Prioriteiten... 5 1.4. Gebruik mailtemplates...

Nadere informatie

ASRemote WebService. Via deze webservice kunt u:

ASRemote WebService. Via deze webservice kunt u: ASRemote WebService De ASRemote WebService is een SOAP Webservice die softwarematige communicatie met Exact Globe mogelijk maakt vanaf een willekeurige locatie op het internet. Via deze webservice kunt

Nadere informatie

Handleiding. han4me.han.nl m.han.nl/rooster. Datum: 23 september 2011 Versie 1.1

Handleiding. han4me.han.nl m.han.nl/rooster. Datum: 23 september 2011 Versie 1.1 Handleiding han4me.han.nl m.han.nl/rooster Datum: 23 september 2011 Versie 1.1 1 Hogeschool van Arnhem en Nijmegen HAN/ SU-ICT 1. Inleiding... 3 2. Installatie... 3 1. Icoontje toevoegen in je beginscherm

Nadere informatie

Handleiding ZorgMail Secure e-mail - Webmail

Handleiding ZorgMail Secure e-mail - Webmail Handleiding ZorgMail Secure e-mail - Webmail 2014 ENOVATION B.V. Alle rechten voorbehouden. Niets uit deze uitgave mag worden openbaar gemaakt of verveelvoudigd, opgeslagen in een data verwerkend systeem

Nadere informatie

HANDLEIDING HUAWEI MIFI ROUTER

HANDLEIDING HUAWEI MIFI ROUTER HANDLEIDING HUAWEI MIFI ROUTER Copyright 2016. Alle rechten voorbehouden. Niets uit deze uitgave mag worden verveelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand en/of openbaar gemaakt in enige

Nadere informatie

Xelion ESPA koppeling Handleiding Beheer V1.6

Xelion ESPA koppeling Handleiding Beheer V1.6 Xelion ESPA koppeling Handleiding Beheer V1.6 van de Xelion ESPA koppeling. Dit document is bedoeld voor beheerders en operators Inhoud 1 Overzicht... 1 2... 2 2.1 Espa apparaat toevoegen... 4 2.1.1 ESPA

Nadere informatie

Responsive web applicaties op Oracle

Responsive web applicaties op Oracle APEX Responsive web applicaties op Oracle Spreker(s) : Datum : E-mail : Arian Macleane & Jacob Beeuwkes 06-06-2013 info@transfer-solutions.com WWW.TRANSFER-SOLUTIONS.COM Outline Trends APEX intro APEX

Nadere informatie

Handleiding Reseller Controle Paneel

Handleiding Reseller Controle Paneel Handleiding Reseller Controle Paneel Inloggen Om in te loggen in het Controle Paneel kunt u de gebruikersnaam en wachtwoord gebruiken welke u van ons heeft ontvangen. Nieuw is dat u ook met uw social media

Nadere informatie

Les 15 : updaten van gegevens in de database (deel2).

Les 15 : updaten van gegevens in de database (deel2). Les 15 : updaten van gegevens in de database (deel2). In de volgende reeks lessen zal alle vorige leerstof uitgebreid aan het bod komen. Zie ook de vorige lessen en documenten om informatie op te zoeken

Nadere informatie

Technical Specification SOFORT Banking

Technical Specification SOFORT Banking Technical Specification SOFORT Banking (DEB.001) Author(s): Michel Westerink (MW) Version history: V1.0 MW (kopie van targetpay.com) 08/08/13 Table of contents 1. Algemeen... 3 1.1 Opmerking vooraf...

Nadere informatie

Handleiding OpenCart - factuursturen.nl

Handleiding OpenCart - factuursturen.nl Handleiding OpenCart - factuursturen.nl www.webwinkelfacturen.nl Samenvatting Dit is de handleiding voor de koppeling van OpenCart naar Factuursturen.nl. De koppeling zorgt dat voor bestellingen in OpenCart

Nadere informatie

emaxx Systeem eisen ManagementPortaal voor de ZakenMagazijn database

emaxx Systeem eisen ManagementPortaal voor de ZakenMagazijn database emaxx Systeem eisen ManagementPortaal voor de ZakenMagazijn database Datum: 25-09-2007 Auteur: ing. E.L. Floothuis Versie: 0.1 Status: Concept Kopersteden 22-4 Postbus 157 7500 AD Enschede Tel: 053 48

Nadere informatie

Technisch ontwerp. Projectteam 6. Project "Web Essentials" 02 april 2009. Versie 2.1.0

Technisch ontwerp. Projectteam 6. Project Web Essentials 02 april 2009. Versie 2.1.0 Projectteam 6 Faculteit Natuur en Techniek Hogeschool Utrecht Projectleider: Hans Allis, hans.allis@student.hu.nl Technisch ontwerp Project "Web Essentials" 02 april 2009 Versie 2.1.0 Teamleden: Armin

Nadere informatie

HDN DARTS WEB AUTHENTICATIE

HDN DARTS WEB AUTHENTICATIE HDN DARTS WEB AUTHENTICATIE HDN Helpdesk T: 0182 750 585 F: 0182 750 589 M: helpdesk@hdn.nl Copyright Communications Security Net B.V. Inhoudsopgave 1. INLEIDING OP HET ONTWERP... 3 1.1 HET DOEL VAN DIT

Nadere informatie

4Problemen met zakendoen op Internet

4Problemen met zakendoen op Internet Intranet Telematica Toepassingen Hoofdstuk 18 4gebruik Internet toepassingen voor netwerk binnen een organisatie 4In plaats van gespecialiseerde netwerkprogramma's 4Vooral WWW en e-mail 4WWW browser toegang

Nadere informatie

Tales en Markomo heten u van harte. Welkom. Wegwijs op het mobiel internet

Tales en Markomo heten u van harte. Welkom. Wegwijs op het mobiel internet Tales en Markomo heten u van harte Welkom Wegwijs op het mobiel internet Besluit Een hype? Infrastructuur en toestellen: mainframes internet personal computers connectiviteit netwerken laptop, pda, smartphone,

Nadere informatie

Technische data. Versie dec

Technische data. Versie dec Technische data Versie dec.2016 www.mobilea.nl Mobiléa Infrastructuur: Pagina 1 Pagina 2 Specificaties: Het platform van Mobiléa valt op te splitsen in een aantal technische componenten, te weten: De webapplicatie

Nadere informatie

Elektronisch factureren

Elektronisch factureren Elektronisch factureren Inleiding Elektronisch Factureren in RADAR is mogelijk vanaf versie 4.0. Deze module wordt niet standaard meegeleverd met de RADAR Update maar is te bestellen via de afdeling verkoop

Nadere informatie

HANDLEIDING DMS Plugin Installatie, configuratie & werking

HANDLEIDING DMS Plugin Installatie, configuratie & werking HANDLEIDING DMS Plugin Installatie, configuratie & werking Dit document is de handleiding voor de installatie, configuratie en werking van de DMS Plugin. Versie 1-12/09/2005 Inhoudstafel 1 Installatie...

Nadere informatie

Vakgroep CW KAHO Sint-Lieven

Vakgroep CW KAHO Sint-Lieven Vakgroep CW KAHO Sint-Lieven Objecten Programmeren voor de Sport: Een inleiding tot JAVA objecten Wetenschapsweek 20 November 2012 Tony Wauters en Tim Vermeulen tony.wauters@kahosl.be en tim.vermeulen@kahosl.be

Nadere informatie

Apparaten en Azure AD: wie, wat en waar? Sander Berkouwer SCCT

Apparaten en Azure AD: wie, wat en waar? Sander Berkouwer SCCT Apparaten en Azure AD: wie, wat en waar? Sander Berkouwer SCCT Introductie Sander Berkouwer Senior consultant bij SCCT BV MCSA, MCSE, MCT Microsoft MVP, Veeam Vanguard DirTeam.com @SanderBerkouwer Agenda

Nadere informatie

Using Google Maps Engine Connector for QGIS

Using Google Maps Engine Connector for QGIS Using Google Maps Engine Connector for QGIS QGIS Tutorials and Tips Author Ujaval Gandhi http://google.com/+ujavalgandhi Translations by Dick Groskamp This work is licensed under a Creative Commons Attribution

Nadere informatie

ZorgMail Secure e-mail

ZorgMail Secure e-mail ZorgMail Secure e-mail 2014 ENOVATION B.V. Alle rechten voorbehouden. Niets uit deze uitgave mag worden openbaar gemaakt of verveelvoudigd, opgeslagen in een data verwerkend systeem of uitgezonden in enige

Nadere informatie