Android Toepassing Groep 1 Tem Bertels
Andres Gutierrez
1ste master CW
3de bach Informatica
[email protected]
[email protected]
Tom Mercelis
Annelies Van der Borght
1ste master CW
2de bach Informatica
[email protected]
[email protected]
ABSTRACT Met deze android toepassing zijn we helemaal afgestapt van ons idee van backmasking. Nu wilden we een applicatie maken waarmee je een foto van iemand kan animeren zodat de persoon danst op muziek. We hebben een werkende demo gemaakt, maar helaas niet alle features kunnen implementeren.
INDEX TERMS multimedia, android
1 IDEE In het ontwerp van deze applicatie zijn we helemaal afgestapt van het concept van onze vorige applicaties. Dit na toestemming van professor Duval en omdat we niet meteen zagen hoe we typische voordelen van mobiele toepassingen (zoals GPS, fototoestel, spraakopname,...) konden toevoegen aan onze backmasking-applicatie, en hierdoor ervoor zorgen dat deze ook extra functionaliteit biedt. Omdat we nu opnieuw van nul moesten beginnen, hebben we eerst een kleine brainstorm gehouden. Hierin kwamen volgende ideeën naar boven: •
•
•
het menu van de dichtstbijzijnde Alma (of andere restaurantketen) tonen en als je een maaltijd aanklikt een liedje spelen dat weergeeft hoe goed andere mensen deze maaltijd vonden (bijvoorbeeld “Dead Body’s Everywhere” afspelen als mensen deze maaltijd helemaal niet lekker vonden); mensen zelf geluiden, gesprekken/voicemail, liedjes,... laten opnemen en deze dan omgekeerd terug laten afspelen zodat ze kunnen ontdekken wat de “echte” boodschap is; een GPS-spelletje waarin de gebackmasked worden gegeven;
aanwijzingen
•
de gebruiker de mogelijkheid geven de barcode van een cd in te scannen met zijn/haar android en dat het programma zou teruggeven of deze cd liedjes bevat die voorkomen in de lijst van gebackmaskte liedjes (dezelfde lijst die gebruikt werd in de vorige applicatie);
•
een danssimulatie uitvoeren op een persoon waarvan je een foto trekt.
Een van deze ideeën kiezen, was niet zo eenvoudig omdat we allemaal redelijk uiteenlopende meningen hadden. Maar uiteindelijk hebben we er toch eentje gevonden dat iedereen goed vond. Hierna volgt een korte beschrijving van waarom we elk idee al dan niet gekozen hebben: •
Het “Alma” idee vonden we allemaal wel leuk, maar hebben we toch niet gekozen omdat de beoordeling van maaltijden heel subjectief is. Daarbij is het ook niet zo makkelijk om met liedjes genuanceerd weer te geven wat mensen nu juist van een maaltijd vonden.
•
Het backmasken van geluidsfragmenten hebben we ook laten vallen aangezien de meeste features in deze applicatie reeds bestaan (geluid opnemen, afspelen...) en dit dus weinig eigen input zou toelaten. Het backmasken zelf zouden we ofwel
1
zelf moeten implementeren, maar dit leek niet makkelijk haalbaar op het toestel zelf, en het leek ons ook niet de bedoeling dat we dit op een externe server zouden doen. Dit zou daarenboven niet erg snel gaan via mobiele internetverbindingen. •
Het GPS-spelletje hebben we laten vallen aangezien het veel gehardcode “acties” zou bevatten en dat het uiteindelijk weinig qua meerwaarde met zich meebracht.
•
Ook het inscannen van barcodes had in onze ogen niet echt veel meerwaarde en zou waarschijnlijk maar een beperkt publiek aanspreken.
•
We kozen dus voor het laten dansen van gefotografeerde personen aangezien dit zeker een grappige applicatie kan zijn, dat dit vrij origineel lijkt. Het spreekt ook een groter publiek aan dan de backmasking. Het maakt gebruik van de camera in de smartphone. Ook de GPS zou gebruikt worden om de locatie waarop de foto gemaakt is op te slaan en mobiel internet om deze foto’s te kunnen delen met andere gebruikers.
2 STORYBOARD Een afbeelding van het storyboard is te vinden in de appendix (afbeelding 1). Dit storyboard is hoe we, in het meest optimistische geval en voor we wisten hoe android werkt, wilden dat onze applicatie eruit zag. Het programma zou als volgt verlopen; de gebruiker verveelt zich en neemt een foto van iemand in zijn/haar omgeving en een foto van de achtergrond. Hij/zij kiest dan een liedje waarop hij/zij de animatie wil laten gebeuren. Het programma zal dan op een simpele manier de getrokken foto animeren. Wanneer de gebruiker genoeg heeft van die animatie, kan hij/zij kiezen om het programma gewoon af te sluiten of de foto's die hij genomen heeft, op te slaan. Dit storyboard bevat wel een aantal features die we uiteindelijk niet geïmplementeerd hebben. Dit wordt verder besproken in puntje vier (“Implementatie”).
3 SOFTWARE-ONTWERP Om het softwareontwerp te begrijpen is het noodzakelijk om iets van android te begrijpen. De basis van een use case scenario is een “Activity”. Een activity komt in feite overeen met een use case. Normaalgezien heb je maar één gui-layout voor één activity. De menu's en de “View” zijn verbonden aan een activity. Je maakt een activity door een klasse te maken die de Activity klasse uitbreidt. De activity wordt door het android systeem op de hoogte gebracht van statusovergangen in het systeem. De lifecycle van een activity kan je zien op afbeelding 3 in de appendix. Er is steeds maar 1 activity zichtbaar/running. Om een bepaalde
activity te starten moet je een Intent sturen. In onze applicatie maken we gebruik van vier activities: eentje om het mannetje uit de foto te knippen, eentje om een foto te maken uit de webcamstream, eentje om een bestaande foto uit het apparaat te laden en een laatste waarin het mannetje geanimeerd wordt en de muziek kan gestart en gestopt worden. De activity om een bestaande foto te laden hebben we niet zelf geïmplementeerd, deze is reeds voorzien in het android platform. Dit is ook een van de krachtige zaken in het Activity/Intent systeem: je kan ofwel een specifieke Activity klasse starten, ofwel vragen dat het platform een Activity start die een bepaald resultaat kan geven, zoals een afbeelding. Wanneer er meerdere Activities het juiste resultaat kunnen geven, dan krijgt de gebruiker de keuze. De keuze die de gebruiker dus krijgt tussen een opgeslagen foto en een beeld van de webcam halen, komt omdat het platform twee mogelijkheden heeft om een afbeelding te vinden. Om iets weer te geven in een Activity moet je een View object gebruiken. Aangezien we een gui nodig hebben om een figuur uit te knippen en om een figuurtje te animeren, hebben we geen standaard views gebruikt, maar zelf views geïmplementeerd. De views krijgen ook de muis- en toetsevents van het systeem. De singleton klasse die we maakten dient om de gegevens tussen twee Activities door te geven. Wat ook opvalt is dat een aantal zaken in Android steeds met integers werken, bvb om aan te duiden welk menu item aangeklikt is. Ook de resultaten van een Intent worden doorgegeven aan een bepaalde methode van de Activity en geïdentificeerd op basis van een integer. Hierdoor kunnen we enkele object georiënteerde patronen ook niet gebruiken. Op afbeelding 4 in de appendix is ook het klassendiagram van onze applicatie te vinden.
4 IMPLEMENTATIE We hebben het werk van bij het begin opgesplitst en ieder van ons heeft een deel van het werk voor zijn/haar rekening genomen. Hier zullen we kort bespreken wat we exact gedaan hebben en welke moeilijkheden we hierbij ondervonden hebben. Eerst en vooral wilden we weten of het mogelijk was om de camera te gebruiken in de android emulator, dit via een webcam aan een computer gekoppeld. De emulator voorziet geen manier om de camera te emuleren met echt opgenomen beeld. Daarom hebben een http webcam streamer opgezet op een laptop met webcam. De android Activity om camera beelden op te halen haalt periodisch een beeldje op uit van de server, en toont het. Dit betekent
2
dat deze Activity moet herschreven worden indien gebruikt op een echt G1 toestel met camera. Daarna hebben we ons bezig gehouden met het spelen van muziek. Het eerste probleem was dat we een muziekbestand meegegeven hadden met het programma, maar dat dit bestand te groot was. Nu bleek dat elk programma dat geïnstalleerd wordt op de android beperkt wordt in grootte. We hebben dan simpelweg de bitrate van de muziekbestanden verlaagd. Muziek embedden in de applicatie is slechts een gemakkelijke manier om het programma te demonstreren. In een echte versie is zouden we het mogelijk kunnen maken de muziek te halen van bijvoorbeeld het SD kaartje. Het spelen van muziek gebeurt via een MediaPlayer object in android, waaraan we een muziekbestand geven. In ons uiteindelijk programma is het mogelijk om te switchen tussen verschillende liedjes. De volgende stap was het opslaan van de foto’s die de gebruiker genomen heeft. Dit heeft voor vrij veel irritatie gezorgd. Omdat er geen bestanden op de emulator staan, wilden we images van op een externe server downloaden en opslaan op de emulator. Na veel fouten bleek dat het gewoon niet mogelijk is om bestanden op te slaan op het interne geheugen van android. We besloten daarom om een virtuele SD kaart aan te maken, aangezien het ook makkelijker was om hierop een aantal voorbeeldafbeeldingen te zetten, vóór de SD kaart geladen werd in de emulator. Dit gaf initieel echter fouten aangezien onze SD kaart kleiner was dan 8Mb en dit aanvaardt de emulator niet. Eenmaal de virtuele kaart groter dan (en dus niet gelijk aan, want dit gaf ook fouten) 8Mb was, werkte het laden van deze SD kaart wel. Na het opslaan kwam het ophalen van bestanden. Initieel deden we dit door een query uit te sturen naar het externe geheugen. Dit deden we via een android.Uri (MediaStore.Images.Media.EXTERNAL_CONTEN T_URI) omdat we dachten dat dit het pad naar het externe geheugen gaf. Dit werkte niet op wat we wilden doen. We weten nog steeds niet of dit is omdat de Uri niet om te vormen is naar het pad, of omdat de Uri hier gewoon niet voor dient. Dit hebben we dan tijdelijk opgelost door het pad naar de SD kaart hardcoded in te geven. Uiteindelijk besloten we dan toch om een andere weg in te slaan, omdat het eerder uitgelegd systeem enkel werkt als we de exacte naam kennen van het bestand dat we willen ophalen. In plaats daarvan werken we nu met een in android ingebouwde Intent. Deze laat de gebruiker twee afbeeldingen (eentje voor de persoon en eentje voor de achtergrond) kiezen tussen alle afbeeldingen die op de android staan. De Intent geeft als antwoord een URI, die met de ContentResolver kan gebruikt worden om het bestand te openen. We wilden het uitknippen simpel houden door steeds
dezelfde stukken uit een afbeelding te knippen. Het bleek echter moeilijker om een algemeen bruikbare locaties van armen, benen, romp en hoofd te vinden dan om een implementatie te maken waarin de gebruiker zelf de lichaamsdelen en gewrichten aanduidt. Daarom hebben we uiteindelijk ook voor dit laatste gekozen. Dit hield in dat we de gebruiker zelf de vakjes zouden laten trekken rond de lichaamsdelen (hoofd, armen, benen, romp) die we gaan animeren. We doen dit door twee punten in het beeld te laten selecteren door de gebruiker, en die te nemen als linkerbovenhoek en rechteronderhoek van een rechthoek waarin dit lichaamsdeel ligt. Ook de scharnierpunten van de gefotografeerde persoon worden nu door de gebruiker zelf gekozen. Dit zorgt ervoor dat we onszelf veel beeldverwerking en uitrekeningswerk (als de foto niet mooi gecentreerd is, of de persoon op de foto zijn benen niet mooi strekt bvb) besparen. We hebben ook een eigen Intent gemaakt, die de camera in de telefoon simuleert (we gebruiken in werkelijkheid een webcam van de laptop). De beelden van de laptop-webcam worden via een http-server beschikbaar gemaakt aan android. Wanneer de gebruiker een "kies foto" intent lanceert, kan de gebruiker kiezen tussen een reeds bewaarde afbeelding, of een nieuwe van de webcam. Indien de gebruiker via de webcam een foto maakt, kan hij deze draaien in de gewenste positie, en wordt deze opgeslagen voor later hergebruik. Om de animatie te maken hebben we lang gezocht naar de verschillende manieren waarop we dit in android konden doen. Android heeft zelf een paar ingebouwde methodes om afbeeldingen te animeren, maar omdat we initieel de snelheid waarmee de animatie gebeurt, wilden afstemmen op de muziek, hebben we er voor gekozen om deze niet te gebruiken. De uiteindelijke animatie bestaat uit een achtergrondfoto waarop de verschillende lichaamsdelen van de danser getekend worden met verschillende rotaties (rond de door de gebruiker aangegeven gewrichten). De rotaties gebeuren door het canvas te roteren, het lichaamsdeel te tekenen en het canvas dan weer te “herstellen”. De manier waarop de danser beweegt is vrij willekeurig en wordt via een aparte thread periodisch berekent. Het hertekenen gaf nog wat praktische problemen, omdat dit vanuit een aparte thread moet gebeuren: android laat namelijk niet zomaar toe dat de UI wordt aangepast vanuit een andere thread dan deze die de UI maakt. Hoewel we heel optimistisch aan het project begonnen zijn, bleek uiteindelijk dat het niet mogelijk was van alles af te werken in de gegeven tijd. Onze applicatie was vrij ambitieus en we hebben gedaan wat we in de vooropgestelde tijd konden afkrijgen. De features die we hebben laten vallen zijn uiteindelijk
3
leuke uitbreidingen maar niet kritiek voor de werking van de applicatie. Concreet de delen die we hebben laten vallen: •
Het animeren van de foto op het ritme van de muziek. In de plaats hebben we ervoor gekozen om de onderdelen van de persoon in de foto random te laten bewegen.
•
De GPS uitbreiding waarbij de gebruiker ook foto's kon kiezen die andere gebruikers gemaakt hadden in dezelfde buurt. Dit deel hebben we helemaal weggelaten, hoewel het wel expliciet in het storyboard staat. Er zou daarvoor ook een centrale server nodig zijn om de foto’s van alle gebruikers te verzamelen.
5 RESULTAAT We vinden het uiteindelijke resultaat nog behoorlijk goed geslaagd. Het is enkel jammer dat we niet genoeg tijd hadden om de meer “fancy” dingen, zoals het animeren op de muziek, ook nog te implementeren. Dit zou zeker een meerwaarde zijn aan de applicatie. Het systeem om het lichaam op te delen in de verschillende ledematen en om de scharnierpunten aan te geven is misschien ook nog een beetje omslachtig. Je moet steeds een menu en submenu doorlopen om het lichaamsdeel of scharnierpunt aan te kunnen duiden. Over de rest van onze applicatie kunnen we weinig opmerken. Deze lijkt ons goed in elkaar te zitten.
6 ANDROID Eerst en vooral zullen we bespreken welke, volgens ons, de voordelen van android zijn. Google heeft een uitgebreide, platformonafhankelijke SDK gemaakt voor android. Aangezien de Java programmeertaal gebruikt wordt, en er een Eclipse-plugin is voor android, was het voor ons niet zo moeilijk om met android van start te gaan.
te vinden is online (gebruikerssites, fora...) even correct is. We denken dat dit vaak te wijten is aan veranderingen aan de API, aangezien android nog steeds in volle ontwikkeling is. Dit maakt het opzoekwerk er niet makkelijker op. De hoeveelheid informatie die te vinden is online is ook een stuk minder dan bijvoorbeeld voor Flex. Ook dit ligt waarschijnlijk weer aan het feit dat android nog relatief “nieuw” is. Een laatste ietwat negatieve opmerking is dat de emulator niet altijd even consistent is qua fouten. We hebben tweemaal de situatie gehad waar we foute code geschreven hadden, die de emulator deed crashen. Als we deze code dan in commentaar zetten, bleef hij toch dezelfde fout geven en bleef de emulator crashen. In een geval hebben we dit kunnen oplossen door de emulator simpelweg te herstarten maar in het andere (waarbij we telkens een “INSTALL_FAILED_INSUFFICIENT_STORAGE” kregen) konden we niet anders dan een ander project aanmaken en de code die geen fouten gaf, hierin kopiëren. Na onze ervaring met android kunnen we zeggen dat dit besturingssysteem duidelijk gemaakt is voor mobiele toepassingen en dit zou dan ook het soort applicaties zijn dat we met android zouden maken. Het kan bijvoorbeeld handig/nuttig zijn om omgevingsinformatie te gebruiken in programma's. Denk hierbij vooral aan het gebruik van de GPS, foto's maken, omgevingsgeluid opnemen. We zouden het systeem echter niet gebruiken voor grote programma's die veel CPU gebruiken omdat android nog niet volledig geoptimaliseerd is qua performantie. Ook programma's die in se een groot scherm vereisen (bvb “grote” games, programma's voor films te bekijken...) zouden we hier waarschijnlijk niet op ontwerpen. Dit laatste ligt voornamelijk aan het feit dat android bedoelt is om op mobiele toestellen te werken en niet noodzakelijk omdat het besturingssysteem hier niet voor geschikt is.
7 ERVARING
We zijn ook heel tevreden over de heel uitgebreide API en tutorials die Google zelf ter beschikking stelt van android developpers.
Tijdens het implementeren hebben we geleerd dat het wel nodig is om te “leren” werken met android. De Intents en Activities bijvoorbeeld, waren nieuw voor ons en dit zorgde er voor dat we toch een zekere tijd nodig hadden om echt vertrokken te raken. Eenmaal we hier meer vertrouwd mee waren, bleek android wel een aangenaam en krachtig mobiel platform om mee te werken.
Een voordeel van de emulator waarop we werkten, was dat die in grote mate overeenkomt met hoe een echt android systeem (op een G1) werkt. Dit liet ons toe om te ontwikkelen zoals we op een “echt” systeem zouden doen.
Iets wat we zeker handig vonden was dat twee van de leden van ons team op Devoxx twee lectures van Romain Guy hebben kunnen volgen en hem nadien ook vragen hebben kunnen stellen in verband met onze applicatie.
Maar android heeft ook nadelen, die ons duidelijk werden tijdens het programmeren.
Iets dat we een volgende keer zeker anders zouden doen, is dat we waarschijnlijk een minder ambitieus storyboard zouden maken. Dit omdat de tijd die we eraan
We hebben ook het gevoel dat het android platform heel goed gericht is op uitbreidbaarheid. Dit vooral door de mogelijkheid om Intents te schrijven en te herbruiken.
Allereerst kunnen we opmerken dat niet alle informatie die
4
konden/moesten spenderen deze keer niet evenwichtig is met de features die we in ons storyboard hebben gestoken.
demonstratie geeft volgens ons meer zin om aan het project te beginnen.
Het was ook minder aangenaam dat we de eerste weken van het project geen tijd hadden om veel buiten de multimedia zittingen te werken. We zijn hier pas mee begonnen de laatste week voor de deadline. Dit voornamelijk omdat we allemaal nog andere lopende projecten hadden die eerder af moesten. Uiteindelijk hebben we toch nog het nodige aantal uren in dit project kunnen steken, waardoor we een werkende applicatie hebben die we kunnen demonstreren.
Er zijn ook een aantal dingen die we zeker niet zouden veranderen aan hoe het vak dit jaar gegeven werd: •
Het feit dat er tijdens de eerste zittingen van een nieuw project, er altijd iemand aanwezig is die vertrouwd is met het systeem, zodat we vragen kunnen stellen indien nodig.
•
Ook vinden we de manier waarop het vak gegeven wordt zeer aangenaam.. Dat elk jaar verschillende nieuwe systemen verkend worden, is ook zeker een pluspunt, aangezien dit ervoor zorgt dat de interesse in het vak niet vervaagd midden het semester.
•
Uiteindelijk vinden we ook zeker interessant dat externe personen uitleg komen geven over hun vakgebied (zoals dit jaar bij METS het geval was).
Verder zijn we ervan overtuigd dat we het werk weer goed verdeeld hebben en denken we niet dat we bepaalde dingen anders zouden aanpakken.
8 GLOBALE FEEDBACK Drie dingen die we graag zouden veranderd zien in dit vak zijn: •
•
•
Graag zouden we android vroeger op het semester gekregen hebben (aangezien hiervoor toch wel wat werk buiten de sessies verreist was). Op het einde van het semester zouden we liever een project hebben gehad waaraan minder werk buiten de sessie besteed moet worden. Dit omdat het einde van het semester voor ons meestal “een hele hoop deadlines” betekend. Ook zouden we het leuker gevonden hebben als sommige opdrachten iets beter voorbereid waren door het onderwijsteam. Hier denken we concreet aan SCORM, waar we de indruk kregen dat de assistente niet helemaal wist wat onze opgave voor het semester concreet inhield en dat de professor niet heel goed wist wat juist mogelijk was en wat niet in het SCORM systeem. Daardoor kregen we tijdens één zitting telkens nieuwe opgaven, die soms “tegenstrijdig” waren. Gelukkig werd dit rechtgezet in de volgende zitting, waar we dan wel weer op het juiste pad gezet werden. Uiteindelijk zouden we het aangenaam gevonden hebben dat we bij de presentatie voor elke opgave meer toepasselijke en “aantrekkelijkere” demonstraties kregen van wat het systeem ons toelaat van te doen. Bij de presentatie over MashUp was dit zeker het geval, bij android daarentegen minder. Een aantrekkelijkere
Wat we een twijfelende medestudent zouden vertellen over dit vak is voornamelijk dat het vak “tof” wordt gegeven en het zeker een originele manier is om met een vak om te gaan. Op zich vinden wij het groepswerk aangenaam en dit zorgt er natuurlijk voor dat de workload niet te groot wordt. Dit laatste wordt ook onderhouden door het feit dat de professor de taak bijwerkt wanneer blijkt dat de hoeveelheid werk te groot is. Ten laatste was het zeer interessant om te leren werken met systemen/platformen waar we anders niet noodzakelijk in aanraking mee zouden komen (in onze opleiding of in onze vrije tijd).
APPENDIX A Tijdsbesteding Tabel 1: Overzicht van de tijd besteed aan het project Naam In de les Buiten de les Totaal Andres
11.30 uur
11 uur
22.30 uur
Annelies
13.30 uur
23.30 uur
37 uur
Tem
13.30 uur
21 uur
34.30 uur
Tom
9.30 uur
24.30 uur
34 uur
Voor een meer gedetailleerde tijdsbesteding, zie tabel 2 in appendix B.
B Afbeeldingen en tabellen
5
Afbeelding 1: Het storyboard (deel 1)
6
Afbeelding 2: Het storyboard (deel 2)
7
Afbeelding 3: De lifecycle van een Activity
8
Afbeelding 4: Het klassendiagram
Wanneer 28/11/2008
In de les 4.30 uur
28/11/2008 28/11/2008
2.30 uur 4.30 uur
28/11/2008
4.30 uur
28/11/2008 30/11/2008 02/12/2008
-
Tabel 2: Gedetailleerde lijst van de tijd besteed aan het project Buiten de les Naam Gewerkt aan Annelies Android SDK downloaden en installeren, tutorials over android proberen + nieuw storyboard tekenen Andres Android SDK downloaden en installeren, tutorials over android proberen Tem Android SDK downloaden en installeren, tutorials over android proberen + nieuw storyboard tekenen Tom Android SDK downloaden en installeren, tutorials over android proberen + nieuw storyboard tekenen 30 minuten Tem Wiki aanpassen 1.30 uur Annelies Storyboard tekenen 30 minuten Annelies Storyboard afwerken
9
03/12/2008 04/12/2008 04/12/2008 04/12/2008 05/12/2008 05/12/2008 09/12/2008 10/12/2008 10/12/2008 11/12/2008 12/12/2008 12/12/2008 12/12/2008 12/12/2008 17/12/2008 18/12/2008 18/12/2008 18/12/2008 18/12/2008 18/12/2008
4.30 uur 4.30 uur 4.30 uur 4.30 uur 30 minuten -
1.30 uur 2 uur 1 uur 2 uur 3 uur 2 uur 3 uur 1 uur 2 uur 30 minuten 5 uur 15.30 uur 15.30 uur 15.30 uur 4 uur
Annelies Tom Andres Tem Groep Tem Andres Andres Annelies Annelies Annelies Tem Andres Tom Annelies Andres Annelies Tom Tem Tom
22/12/2008 26/12/2008 27/12/2008
-
1.30 uur 3 uur 30 minuten
Annelies Tom Annelies
Zoeken naar fast fourier transform Camerabeelden in android emulator krijgen Zoeken naar mogelijkheden voor animatie Zoeken naar animatiemogelijkheden + fast fourier transform Camera + animatie + muziek Zoeken hoe bestaan op te slaan/uit te lezen uit interne opslagruimte android Werken aan animatie Werken aan animatie Zoeken hoe bestanden op een server te zoeken Zoeken hoe bestanden op een server te zoeken Bestanden opslaan en uitlezen op sdcard android Bestanden opslaan en uitlezen op sdcard android Werken aan animatie Werken aan animatie Werken aan verslag Programma afwerken: animatie, alles samenvoegen, verslag Programma afwerken: animatie, alles samenvoegen, verslag Programma afwerken: animatie, alles samenvoegen, verslag Programma afwerken: animatie, alles samenvoegen, verslag Programma afwerken: webcamstream implementeren in een get_content intent, bugjes verwijderen Verslag Verslag bijwerken, klassendiagram Verslag samenvoegen
10
