Jag tänkte använda denna post till att beskriva hur man kan använda .NET framework för att skapa applikationer till iPhone. Samtidigt som jag gör det tänkte jag även passa på att visa hur MVC används vid utveckling mot iPhone OS. Som arkitekt tycker jag att det är enormt lärorikt att lära mig hur mönster används på andra plattformar. Helt ärligt tror jag inte jag förstod lambdas i C# innan jag började använda blocks i Ruby (IronRuby ftw!).

I denna post vill jag hänga upp det hela på två mönster nämligen Delegation och MVC.

Vi kör igång... Målet är inte att gå igenom alla moment för att skapa applikationen, om ni vill se allt i detalj är ni mycket välkomna att ladda ner källkoden. Jag vill vandra igenom koden och flagga några aspekter som jag tycker är intressanta. Bakgrunden till att det går att använda C# och .NET för att nå iPhones API:er är Monotouch. Monotouch gör att vi kan nå iPhone OS API:er samt ha lyxen att lägga till alla de saker som vi tar för givna som .NET utvecklare. Lysande! (Det är så sjukt bra att jag inte riktigt fattar det, våra favorit .NET features när vi utvecklar mot en annan leverantörs OS... Wicked!)

(Disclaimer: Självklart vill jag som stolt Microsoftanställd att alla i hela världen skall utveckla mot Windows Mobile, men om ni nu ska utveckla för iPhone så är det klart att ni skall göra det med .NET framework i botten och att lära sig bli en bättre utvecklare genom att titta på vackra mönster på andra plattformar är bra för själen/hjärnan)

Vi startar projektet med MonoDevelop som blir vårt IDE för dagen.mono2

Det första vi ser är att vi har en Main.cs. Grunden i alla iPhone applikationer är en instans av en applikation, men för att vi skall slippa subklassa denna hela tiden, bygger detta på delegation. Applikationsobjektet delegerar arbete till vår AppDelegate som ärver från UIApplicationDelegate. NSApplication hanterar hela livscykeln för applikationen som när vi startar och när vi avslutas. När appen har kickat igång delegerar NSApplication arbetet till vår delegat via ett meddelande till FinishedLaunching. Om du undrar varför allting börjar med NS så finns det många anledningar, den roligaste är Objective-C saknar namespaces så man är så illa tvungen... (*host* Stenålder :-)) Hursomhelst, det finns många andra saker som uppväger detta men det är lite kul... Det är här i vår applikationsdelegat vi sätter upp vår bas-kontroller med tillhörande vy. Det exempel som visas på MonoTouch är lite spretigt. Alla events från knappar och liknande skickas till AppDelegate (Som vi ser ovan). Det blir lite som ett globalt event-knattedisco istället för en ren implementation där givetvis lyssnaren finns i aktuell controller. Vi gör om och gör rätt...

 MonoTest - Main.cs* - MonoDevelop

Vi skapar en UINavigationController och lägger till den som en subview till vårt huvudfönster. Det intressanta med detta är att denna kommer att sköta alla våra kontroller med tillhörande vyer via en intern stack implementation. Navigerar vi oss neråt bland vyer så pushar vi bara nya kontrollers på stacken, navigerar vi tillbaks så poppar vi stacken. Allt annat som övergångseffekter och aktivering sköts av NSNavigationController. Snyggt...Vi skapar en ny ViewController och kallar den för ButtonController. Denna kommer att hantera den första vyn vi kommer att visa. Cocoa applikationer använder sig ofta av Interface Builder för att skapa UI och vi gör detsamma.

   ib


Vi skickar in tre knappar i aktuell vy och hookar upp denna till lyssnare i vår kontroller. Objective-C hanterar events/actions på ett lite annorlunda sätt än vad vi är vana vid. UIn som byggs via Interface builder hookas upp med hjälp av actions/outlets och kan mappas mot metoder i applikationen som taggats upp med IBAction(event)/IBOutlet(referens till kontroll). Internt parsas bara aktuell header fil från Interface builder så att den skall kunna se hur man kan trycka ihop kod/resurs(UI). Ändrar vi i Interface builder så slår detta igenom i koden, men det är lite magi under ytan. Ni kan se hur detta görs i implementationen av den översta och mellersta knappen. Men i och med att vi har tillgång till .net framework kan vi självklat använda en vanlig delegat. Det sista knappen hookas upp med en enkel

eventlambda

Självklart funkar det att använda lambdas. 

Sweet!Nu när ButtonControllern är klar kan vi vid uppstart pusha denna på NSNavigationControllerstacken med en navController.PushViewController(buttonController,true); enligt tidigare bild...När vi smetar vårt finger mot den översta knappen pushar vi en ny kontroll på navigationsstacken. Denna gång blir det en kontroll med en label vy.

 MonoTest - ButtonController.xib.cs* - MonoDevelop 

Vill vi navigera tillbaks till föregående vy är det bara att poppa en kontroller i NSNavigationController (Detta görs automatiskt om man använder knappen i kontrollen). 

 iPhone

Vad jag ville visa med detta exempel är att det är fullt möjligt att skriva lysande applikationer till iPhone med .NET framework. Vissa saker blir snyggare (som eventhantering, minneshantering mm.) samtidigt har vi tillgång till alla native API:er som iPhone erbjuder... Inte alls så dumt... 

Här kommer en liten video som visar hur det hela ser ut i verkligheten:

Vill ni ha källkoden eller är nyfikna på mer så är det bara att pinga mig via bloggen eller på @deurell på twitter!

"Punk. Quarterback Punk..."