iPhone en Android

Collega Roene en ik hebben het plan opgevat om miljonair te worden. Dat gaan we doen door een iPhone-spelletje te maken en op de iPhone-markt te verkopen. Roene heeft een iPod Touch, daar kan hij 't op testen. Maar ik heb noch een iPhone, noch een iPod Touch. Ik zal dus de iPhone van Lien af en toe moeten lenen. Maar dat is maar tijdelijk, hoor; zodra het geld begint binnen te stromen koop ik gewoon zelf een iPhone.

Maar om een iPhone-app te maken heb je een Mac nodig. En niet zomaar de eerste de beste tweedehands Mac. Nee, 't moet een Intel-Mac zijn. Als diepte-investering heb ik maar een Mac mini gekocht. 't Is een leuk klein doosje, het staat niet in de weg op mijn buro, en is toch redelijk krachtig.

Mac mini (foto © Apple)

Ik heb ook al de iPhone SDK gedownload, en een eerste poging gedaan om My First iPhone App te maken. Dat kostte meer moeite dan ik hoopte; de app is wegens tijdgebrek nog niet klaar.

Uiteraard vergeet ik Android niet. Ik ga 't spelletje tegelijk voor dat platform maken. Zo is 't meteen een mooie manier om de development kits, de programmeeromgevingen en dergelijke van deze twee platformen met elkaar te vergelijken. Daartoe heb ik gisteren de Android SDK maar weer eens gedownload en geïnstalleerd. Opmerkelijk verschil met de iPhone is dat My First Android App in slechts luttele minuten klaar was.

T-Mobile / Google G1 Android Phone

Helaas lukte het niet meteen om de Android app te testen. 't Kostte me eerst een boel moeite om de emulator werkend te krijgen. Ik denk dat ik een oude emulator-configuratie had, van een vorige keer dat ik de Android SDK had geïnstalleerd. Toen ik een nieuwe configuratie aangemaakt had werkte het namelijk wel. Maar voordat ik erachter was dat dat het probleem was was ik al heel wat tijd kwijt.

Vervolgens wilde ik de app op mijn G1 testen, via de USB-koppeling. Dat lukte helaas ook niet meteen. Windows hield vol dat mijn G1 alleen maar een USB disk was. Na een boel gehannes met USB devices en USB drivers gaf Windows eindelijk z'n verzet op, en daarna kon ik moeiteloos mijn “Hello, Android”-applicatie op mijn G1 zien werken.

De volgende stap is dat ik de app sign met een eigen private key. Dat is nodig om een release versie te maken. Dan moet ik eerst een certificaat maken enzo. Nah, dat komt de volgende keer wel, ik vind het wel mooi voor vandaag.

C# is toch niet geweldig

Zo'n twee maanden geleden schreef ik dat ik tegenwoordig in C# programmeer. En dat ik dat toch wel een aardig taaltje vond. Modern, enzo.

Nou, ik ben er toch wel wat op teruggekomen. Ik ben tegen een paar dingen aangelopen die me niet zo bevallen. Properties, bijvoorbeeld. Daarover zal ik vandaag klagen. Later zal ik over delegates en events klagen.

Wat is een property? Het is iets dat het midden houdt tussen een method (een aktie) en een field (een waarde). Stel dat je een class hebt die een AGV representeert. Die zou bijvoorbeeld een method ‘GaRijden’ kunnen hebben, en ‘GaLinksaf’ en ‘Stop’ et cetera. En de class zou als fields onder meer ‘Snelheid’ en ‘ContainerGewicht’ kunnen hebben.

agv.GaRijden();
agv.GaLinksaf();
System.Console.WriteLine("snelheid is " + agv.Snelheid + " m/s");

Een property is, zoals gezegd, iets dat het midden houdt tussen een method en een field. Je gebruikt 'm alsof 't een field is, maar in werkelijkheid roep je met het opvragen en instellen een stukje code aan. Je zou bijvoorbeeld een property voor het opvragen van de positie kunnen maken:

Systeem.Console.WriteLine("positie is " + agv.Positie);

In de AGV-class zou dat er zo uit kunnen zien:

public Coordinates Positie {
get {
// zet de GPS-ontvanger aan
// wacht op een locatie-fix
// return de positie
}
}

Er gebeurt nogal wat bij het ophalen van de positie, maar dat zie je niet. Dus je weet niet wat je allemaal teweeg brengt. Dit soort constructies is dan ook niet zo slim. Microsoft zelf zegt daarover:

“Properties are used like fields, meaning that properties should not be computationally complex or produce side effects.”

Zoals eerder vermeld zijn niet alle IT-professionals in staat om goed werk te leveren. Dus ik reken er maar niet op dat deze eigenschap van C# altijd goed gebruikt wordt.

En wat voegen properties eigenlijk toe? Je kan ze altijd vervangen door (zonodig) een private field (die de waarde bevat), gecombineerd met gewone get- en/of set-methods.