I will assume you have some familiarity with AIR for mobile and Granite. It’s mostly the same as for Flex but there are some things you have to take into account.

1. Get the right version of Granite

The latest version of Granite is 2.2.1 GA. However, in the most recent version of AIR and Flex Adobe made some changes in the API which breaks backwards compatibility for some features of Granite. Therefore this release of Granite won’t work using the newest SDK. Refer to this post on the Granite form for more info on how to make these changes yourself. If you don’t want be bothered with building Granite yourself just download this version of GraniteDS to get started immediately.

2. Connecting to the right server

A problem for AIR applications in general (both desktop and mobile) is setting the right server settings. It is quite simple when running within the browser: The server address is changed with a single reconfiguration of the swf-file and all clients are using the new address on a browser refresh. With AIR it is a bit different and you’re not always at liberty to ‘hardcode’ the service settings in the AIR distribution package.
Granite offers a method for dynamic server configuration using the server initializer component:

Tide.getInstance().addComponentWithFactory(
  "serviceInitializer",
  DefaultServiceInitializer, {
    contextRoot: '/my-app',
    serverName: “10.0.0.1”,
    serverPort: “8080”
});

Note that once a connection is made, it is not possible to reconnect with another configuration, because the service initializer is only used once. You have to restart the application to enable the new connection settings or reset Tide’s RemoteObject. Unfortunately Tide’s API doesn’t support this reset. I came up with a small workaround which requires you to extend the EJB class with an extra reset method with the following body:

public class Ejb extends org.granite.tide.ejb.Ejb {
  /**
   * Reset the Tide Connection to allow new server settings
   */
  public function resetConnection():void {
    if (_ro) {
      _ro.disconnect();
    }
    _ro = null;
  }
 
}

This method resets Tide’s RemoteObject so the next remote call will force a reinitialization using the current settings of serviceInitializer. Refer to Granite’s issue tracker or forum thread for more details.

3. Automatic logout

Applications running on mobile platforms are always susceptible to unpredictable interruptions. For example when a phone call or text is received. Mobile AIR applications provide a deactivate event which is dispatched when the application is halted somehow. The application I wrote was using Tide’s Identity class for user login. Therefore I added an event handler to automatically logout the user and push the LoginView on top of the navigator stack:

private function deactivateHandler(event:Event):void {
  if (identity.loggedIn) {
    identity.logout();
  }
  navigator.popAll(); // Purge the navigator history to disable back button usage
  navigator.pushView(LoginView);
}

4. Build, build, build!

This isn’t directly related to Granite or AIR for mobile. But since they can both be used for enterprise scale applications I thought I’d mention it shortly: Make sure you have a proper build script. Now, I’ve got an example from Chris Black which provides a good starting point. I’ve only added the metadata compiler options required for Tide and of course a reference to the Granite libraries and generated Actionscript classes.

 
 <mxmlc ... >
 
  <!-- .... -->
 
  <!-- location of generated as classes with gas3 -->
  <source-path path-element="${gen.src.dir}" />
 
  <compiler.library-path dir="${basedir}/libs" append="true">
    <include name="granite-essentials.swc" />   
    <include name="granite.swc" />
  </compiler.library-path>
 
  <keep-as3-metadata name="Bindable" />
  <keep-as3-metadata name="ChangeEvent" />
  <keep-as3-metadata name="Destroy" />
  <keep-as3-metadata name="Id" />
  <keep-as3-metadata name="In" />
  <keep-as3-metadata name="Inject" />
  <keep-as3-metadata name="Managed" />
  <keep-as3-metadata name="ManagedEvent" />
  <keep-as3-metadata name="Name" />
  <keep-as3-metadata name="NonCommittingChangeEvent" />
  <keep-as3-metadata name="Observer" />
  <keep-as3-metadata name="Out" />
  <keep-as3-metadata name="PostConstruct" />
  <keep-as3-metadata name="Transient" />
  <keep-as3-metadata name="Version" />
 
</mxmlc>

One plus one

I can imagine one must be thinking: ‘Everyone could have figured that out!’ And I totally agree, because that’s exactly what this article is about. With some experience with Flex, a developer can write a mobile application on top of a Java EE backend. It doesn’t take much to utilize an existing backend from a mobile platform. Since the latest release of AIR the performance for iOS and Android is pretty good and together with the Granite Enterprise Platform the barrier to emerge an enterprise application to a mobile platform has become much lower.

Goal

We will create a simple RSS reader. Not a very exciting example, but already shows some nice features of AIR for mobile. I’ll assume you have experience with Flex or AIR, but I think you will manage with some level of programming experience. If not, feel free to leave a reply if you have any questions or take a look at the full source.

Setup

Download and install the preview release of Flash Builder called Burrito It provides a wizard to start an empty mobile application. By default the wizard creates two mxml files containing a MobileApplication and a View component.

The MobileApplication class is inherited from the Application class used for desktop AIR. The mobile version provides, among other things, an action bar and a navigator. Furthermore its firstView property points to the empty view component. The view component is a normal group, but optimized for mobile use as well.

Article list

Open the main view component (called <projectName>Home.mxml). Create a List component in the main view. Provide positioning constraints to let it occupy the whole screen.

<s:List left="0" top="0" bottom="0" right="0" />

To retrieve the feed, create an HTTPService pointing to the RSS feed in the declaration section of the view. Add a resultHandler function to parse the feed-data. Parsing xml data is quite simple. You can just navigate to the DOM-tree as it were a normal ActionScript object. Use the data property of the view to store the articles locally. Using this property will provide some benefits with navigation, which will become clear in a bit.

<fx:Script>
  <![CDATA[
    import mx.rpc.events.ResultEvent;
 
    protected function service_resultHandler(event:ResultEvent):void {
      data = event.result.rss.channel.item;
    }
  ]]>
</fx:Script>

<fx:Declarations>
  <s:HTTPService
    id="service"
    url="http://lsd.luminis.nl/feed/"
    result="service_resultHandler(event)" />
</fx:Declarations>

Now there are only a couple of things left to do. Invoke the server and provide the list with the articles and instructions to show them.

Both are quite simple. The feeds are retrieved by invoking the send() method of the service. To automatically retrieve them, this method should be invoked when the view is created so we will use the creationComplete handler.

<s:View
  xmlns:fx="http://ns.adobe.com/mxml/2009" 
  xmlns:s="library://ns.adobe.com/flex/spark"
  title="Home"
  creationComplete="service.send()">

Finally, bind the data property to the dataProvider of the list and set its labelField attribute to ‘title’.

<s:List
  dataProvider="{data}"
  labelField="title"
  left="0" top="0" bottom="0" right="0" />

Your view will probably look something like this.

<?xml version="1.0" encoding="utf-8"?>
<s:View
  xmlns:fx="http://ns.adobe.com/mxml/2009" 
  xmlns:s="library://ns.adobe.com/flex/spark"
  title="Home"
  creationComplete="service.send()">
 
  <fx:Script>
    <![CDATA[
      import mx.rpc.events.ResultEvent;
 
      protected function service_resultHandler(event:ResultEvent):void {
        data = event.result.rss.channel.item;
      }
 
    ]]>
  </fx:Script>
 
  <fx:Declarations>
    <s:HTTPService
      id="service"
      url="http://lsd.luminis.nl/feed/"
      result="service_resultHandler(event)" />
  </fx:Declarations>
 
  <s:List
    dataProvider="{data}"
    labelField="title"
    left="0" top="0" bottom="0" right="0" />
 
</s:View>

Emulator

Emulate hardware buttons

When the emulator is launched it shows a list of articles after a couple of seconds. Now you can select Rotate Right from the Device menu to display the landscape view. You will also notice the list is able to scroll up and down when dragging your mouse pointer (Which of course is the emulated equivalent of a one-finger swipe)

Article details

Next is to create a detailed view showing the full content of an article. Close the emulator and return to Flash Builder. In the views package, create a new component and call it DetailView. Bind the title attribute to data.title. Add a label as well and bind the text property to data.description. Don’t forget to specify the positioning constraints.

<s:View
  xmlns:fx="http://ns.adobe.com/mxml/2009" 
  xmlns:s="library://ns.adobe.com/flex/spark"
  title="{data.title}">
 
  <s:Label
    text="{data.description}"
    left="20" right="20" bottom="20" top="20" />
</s:View>

All view components provide a navigator object. We will use this in the change event handler of the article list. This event is fired when the user selects an article from the list. It looks as follows:

import spark.events.IndexChangeEvent;
 
protected function articleList_changeHandler(event:IndexChangeEvent):void {
  navigator.pushView(DetailView, data[event.newIndex]);
}

It simply instructs the navigator to create a new DetailView and push it on top of of the navigation stack. Furthermore the selected item from the article list is passed on to the data property of the DetailView.

Add the change handler and assign it to the change event of the article list:

<s:List
  dataProvider="{data}"
  labelField="title"
  change="articleList_changeHandler(event)"
  left="0" top="0" bottom="0" right="0" />

Article list inside the emulator

For performance optimization, AIR destroys the view when a user navigates away and recreates it when he returns. Only the contents of the data property is saved and passed into a recreated view of the same type. This is why we used it to store the articles. Otherwise the user has to wait for a reload when he returns to the main view.

When you launch the new version in the emulator, you will notice the application slides to the detail view when an article is selected. Click Back from the Device menu to simulate a click on the hardware back button.

Last but not least: action buttons

One thing our application is missing, is a button to go to the original webpage showing the full article. This button is placed inside the header of our detail view, next to the title.
To achieve this, add the button inside the actionContent of the detail view. Give the button an icon (I used one from the Tango project) and set the click handler to open the url of the article.

<s:actionContent>
  <s:Button
    click="{navigateToURL(new URLRequest(data.link))}"
    icon="@Embed('/assets/internet-web-browser.png')"/>
</s:actionContent>

Of course you might want an additional button to return to the article list instead of using the ‘hardware button’. Place this button inside the navigationContent. This will place the back button at the upper left corner. The click event of this button will invoke the navigation.popView() method to remove the current view from the stack and return to the previous one.

<s:navigationContent>
  <s:Button
    click="navigator.popView()"
    icon="@Embed('/assets/go-previous.png')"/>		
</s:navigationContent>

Action and navigator buttons

If you launch the application you will notice the buttons are nicely aligned at the top of the screen.

What’s next?

The next step will be to package the application to an apk file so you could install it on an Android device. This is done by the Export Release build wizard inside the Project menu of Flash Builder. It includes the ability to sign your application to allow distribution through the Android Market.

Another nice feature which I will not discuss in detail is to add gesture based navigation. Take a look at this article from Adobe to find out more. The approach discussed should be working for mobile AIR applications as well.

Unfortunately the most interesting benefit of using AIR for mobile didn’t become clear with this tutorial. It would be nice to deploy our application on other mobile plastforms as well. However the cross compiler for iOS isn’t available yet and the same goes for AIR on Windows Phone, BlackBerry or Symbian. We will just have to wait when Adobe is ready so we can fully benefit from the “Write once, run anywhere” promise.

PhoneGap is een interessante open source alternatief voor het schrijven van native applicaties voor elk (mobiel) platform dat er is. In het kort komt het erop neer dat PhoneGap zorgt dat je een HTML applicatie met javascript.  De specifiek API, zoals location, contact, e.d. worden afgeschermd door een standaard API van PhoneGap.

iPhone

Voor de iPhone kan de HTML applicatie gewoon worden aangeboden via de appstore. Dit is dan ook direct de truc waardoor er voldoende rechten zijn om de hardware aan te spreken. Er zijn al vele applicatie geplaatst in de appstore (zie een selectie in www.phonegap.com/apps).  Er is tevens een getting started en er zijn  extra plugins beschikbaar

Ondersteunde platformen

Naast iPhone wordt zowel Android, Blackberry, Symbian, Palm, N900 en Windows Mobile. Ook Windows Mobile 7 is zodra dit uitkomt eenvoudig te ondersteunen en ze zullen ook geen blokkade opwerpen in het voordeel van silverlight. Interesante gedachte is natuurlijk ook de iets minder mobiele system met Linux, Windows MacOS hebben ook allemaal een browser.

Voor meer informatie zie www.phonegap.com

Gebruiker

Ik heb de telefoon niet zelf bedient maar heb toch een redelijke indruk gekregen. Zelf ben ik een iPhone gebruiker en zie wel wat verbeteringen en interessante ontwikkelingen

• Het gebruik is opgezet rond hubs. Er is bijvoorbeeld een social hub, op deze hub komt alle sociale media bij elkaar en bieden ze mogelijkheden tot integratie. Er zijn dus geen aparte ingangen meer voor linked-in, contacts, facebook e.d. maar alle informatie wordt gebundeld weergegeven.
• Drie verplichte toetsen op de telefoon waarbij naast de enige toets op de iPhone om applicaties te starten er ook een zoek toets is die de standaard zoek functionaliteit heeft maar ook kan worden gebruikt voor zoeken binnen de applicatie. Daarnaast is er de back toets hiermee kan je terug naar de applicatie die een andere heeft aangeroepen. Een typisch voorbeeld waar ik mij vaak aan heb geërgerd is: Je leest je mail daar staat een link in die je opent en vervolgens zit je in safari. De enige manier om die te verlaten is stoppen en je mail opnieuw opstarten.
• Het metro concept van de user interface (Kort samengevat: beperkt grafisch en meer tekst) aangevuld met een panorama view en pivot view is wel een verfrissende aanpak waarbij je direct informatie ziet die je nodig hebt en niet alleen een menu.

Ontwikkelaar

Voor een .Net ontwikkelaar is er eigenlijk niets nieuws. Je kunt namelijk gewoon ontwikkelen met je opgedane kennis in XAML (WPF en Silverlight) in je vertrouwde ontwikkelomgeving. Ik wil echter wel een aantal punten benadrukken

• Een virtuele machine met de phone OS op de ontwikkel PC dus geen emulator of simulator dus betere test omgeving
• Naast API’s die telefoonfunctionaliteit geven zijn er ook API’s voor bijbehorende services in de cloud
• Er is een gratis omgeving bestaande uit visual studio express voor ontwikkelaars en Blend express voor designers

Het lijkt mij een eitje om de look en feel van de quote eetgids (een iphone app gemaakt door luminis) te bouwen voor W7

Business

• Beperkt aantal modellen en veel verplichte onderdelen zoals een grafische processor en sensoren als GPS e.d. Dit maakt de herkenbaarheid groter
• Geen exclusieve contracten met KPN’s en de TMobile’s
• Vergelijkbare appstore als Apple waarin een applicatie gegarandeerd binnen dagen wordt geplaatst.
• Office applicaties en zelf een sharepoint front-end

Het evenement

Het evenement zelf was wat mij betreft teleurstellend. Op een developer event verwacht ik concrete presentaties met duidelijke concepten en voorbeelden. Helaas bleven de presentaties erg oppervlakkig ook al aangemoedigd door de vele bizarre vragen die gesteld werden. Wat mij wel duidelijk is geworden dat Microsoft serieus hun best doet om weer aansluiting te vinden of zoals ze zelf beweren een voorsprong te nemen maar dat ze nog  heel goed hun best moeten doen om alles in de winkels te krijgen voor de kerst.

English: The whole presentation can be downloaded here (175mb).

http://www.youtube.com/watch?v=tmGZHV-DFYM

Augmented Reality op mobiele devices heeft een enorme vlucht genomen met de introductie van Google Android. Android biedt out-of-the-box de componenten om met augmented reality aan de slag te gaan. In deze sessie staan we stil bij de frameworks die beschikbaar zijn om augemented reality applicaties / content te deployen op Android. Aan de hand van een voorbeeld applicatie gaan we in op de mogelijkheden om zelf een augmented reality applicatie te ontwikkelen met de faciliteiten die door Android worden geboden. Praktische uitdagingen waarmee wij zijn geconfronteerd worden gedeeld en geven inzicht in de mogelijkheden en onmogelijkheden van het Android platform. Opbouw van de presentatie:

• Introductie over augmented reality: location based vs beeldherkenning;
• Wat is te krijgen in de markt? Layar, Wikitude, etc;
• Wat zijn de mogelijkheden om applicaties te ontwikkelen met de beschikbare frameworks;
• Hoe ontwikkel je zelf een augmented reality applicatie op Android?

De slides van de presentatie zijn te vinden op de NLJUG website.

Interface Builder is different. I think the idea is that you use it for nothing else than your GUI. There is no way to put any code anywhere. All handling of UI-events is done in delegates and the trick is to learn how to link your GUI to your code.

I hope you will have a better insight in how to do this, after this post. I learned the most from one of the videos on MonoTouch.Info, by Code Snack. I literally played it frame by frame, carefully watching what he did and what could be learned from the code on the background. Highly recommended.

So, let us build an interface with a tab-bar-controller. You might know this type of application from the default iPhone clock.

Start a new application in MonoDevelop, an “iPhone MonoTouch Project”. Double-click the MainWindow.xib and Interface Builder will start.
The empty window you get is important because it is the window that is referenced from AppDelegate. You will add all your own stuff to it as subwindows. But for now you can ignore it.

Make sure the Library Window is open (Tools / Library) and selected like this:

Now drag a Tab Bar Controller and drop it on the MainWindow (that looks a bit like a solution explorer) just below “Window”. The MainWindow will look like this:
And you get a new window looking like this:

It is not to hard to change some of the settings of the tab bar. Open Tools/Inspector, select the Attributes tab, make sure you have the right part active in the Tab Bar Window and change the Identifier Pull-down to “Search”. You will get a default Search Tab, including the search image.

Make the first tab a Search tab and the second a History tab. Now save the project and check the MainWindow.xib.designer.cs. Nothing interesting, except for a mapping to the window called “Window”. If you run your application now, nothing interesting.

That is because we have to add our new view as sub-views to the main window. In code like this:

1
2
3
4
5
6
7
8

public override bool FinishedLaunching (UIApplication app, NSDictionary options)
{
	// If you have defined a view, add it here:
	window.AddSubview (tabBar.View);
	window.MakeKeyAndVisible ();
 
	return true;
}

But we have no variable named “tabBar”. Well, now we’re coming to the very important part where we hook up our GUI to our code. Interface Builder does that with something they call “outlets”. And defining them is one of the weirdest experiences in your live as a programmer.

Ok, since I want to have a reference in my AppDelegate to the Tab Bar Controller, I go back to Inteface Builder, to the Library Window and select the Classes button. All the way on the top, there is a AppDelegate. Select it. Then look on the bottom of the window. Select the Outlets button. Now you see that the AppDelegate has an outlet called “window” which is mapped in the designer file in MonoDevelop to a property of type UIWindow with the name “window”. That is how the code above can reference a “window” object. We need to add an outlet by clicking the + button. Give it a name like “tabBar”. The change the type to UITabBarController.

Now we have a definition of an outlet. But it is not linked to any UI-element yet. So go to the MainWindow and select the AppDelegate there. Now go to the Inspector Window and select the Connections tab. You will see that the connection from the tabBar outlet is still open:
Now comes the magic. You drag the open circle to the Tab Bar Controller window. While getting there you will notice that only windows that are of the right type (UITabBarController) will be an acceptable drop-target. Now drop it, save it and go to MonoDevelop. In the designer file you will see that a new mapping is made. If you change the code in your main.cs to reflect the code above and run your application, you will have your tab bars!

Ok, so far for this post. Next post I will add a search-bar to the search window on the search tab and try to hook them all up to each other and to the code.

A word about Twitter

I’m going to digress a little before telling you more about iPhone application structure. It is not essential for this series, but it is essential to completely describe the adventure that this first application brought on me.

When I found out about the MonoTouch project, it was in Beta and you had to apply to be admitted. I filled in the form (from my iPhone, just to impress them) and then waited. Nothing for a couple of days. I applied again, just to make sure you know. Nothing. Now I’m a modern guy, so I tweet. I tweeted my frustration (in Dutch), since I really wanted to get started. But hey, what where the 3 followers I have gonna do about that? Then it turned out that this guy Joseph Hill, somehow monitors all tweets in the world for the MonoTouch keyword. Joseph is one of the people in the MonoTouch project that is really a Person. He pulled some strings and presto! I got my Beta-account.

For me, that’s just amazing. I didn’t think that Twitter would give me much more than just the latest tips from Scott Guthrie, but this is a totally new way to bring people together and build communities.

The AppDelegate

When you create a new iPhone solution in MonoDevelop, you get a couple of things:

New Solution

1. A xib file called MainWindow.xib. This is where your user-interface is defined. It is an XML file that can be used by the Interface Builder. Simply double-click it and the Interface Builder opens up. More about the Interface Builder later. MonoDevelop monitors the file and regenerates the accompanying designer file when the XIB is changed by Interface Builder. The designer file maps the elements from the user-interface to the classes in your project.
2. A main.cs that contains the entry-point to your code. There is  a partial class called AppDelegate that is mapped to the main window of your UI. The most important method there is “FinishedLaunching”. It gets called when the iPhone is done with all the stuff it does when loading an application. The name is a bit misleading. Your application is definitely not done launching, at best it is done loading. All the stuff that you need to do yourself still has to happen. Like loading some files, initializing your controllers, setting-up your model classes.

Loading your application

There’s more to say about the loading process. Since it takes some time before you even get control about what happens, you have the option to show an image while loading. Add a file to your project with the name “Default.png” and set it’s properties to “Build Action – Content” and it will be picked up by the loader. Your supposed (according to the designer guidelines) to use an image of your app in action, but it is often abused to show a company logo or something. Some applications make a screen-shot of themselves when the application closes and save that as Default.png. That way, the next time you start your app it looks like it quickly continues where it left off.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// The name AppDelegate is referenced in the MainWindow.xib file.
public partial class AppDelegate : UIApplicationDelegate
{
	// This method is invoked when the application has loaded its UI and its ready to run
	public override bool FinishedLaunching (UIApplication app, NSDictionary options)
	{
		Console.WriteLine("Launched");
 
		window.AddSubview(yourViewHere);
		window.MakeKeyAndVisible();
		return true;
	}
 
	// This method is required in iPhoneOS 3.0
	public override void OnActivated (UIApplication application)
	{
	}
}

You should not be doing too much work in this method. The loader times the duration of this method and kills your application when it takes more than 10 seconds. Or so they say, I never tried it out.

You can use this method to build up your user-interface in code. I went that way first. I had such a hard time getting my head around the Interface Builder that I decided to drop it and build my interface by hand. That worked reasonably but caused unexpected crashes. I knew it had something to do with the way I hooked up the different views, so I went back to Interface Builder and tried and tried and tried. I got it, more or less, and my interface (using a tab-bar) is now stable. In the next episode I will dive into the Interface Builder.

Developing for the iPhone is exciting. Well, let me re-phrase that: the result of your development for the iPhone is exciting. Mmmmh, let me re-phrase that again: it was a helluva job to build a working iPhone app, and now that I know how to do it I’m excited!

This post is the first of a couple of post I’m planning to do on development of iPhone applications with .NET. There’s simply too much to learn and to tell to do it all in one post. These posts will not only be about programming C#, but also about design principles, open-source programs, Twitter.

Where do you start?

As a .NET developer you have two choices to program for the iPhone:

1. You learn the Objective-C programming language and the XCode development environment
2. You use MonoTouch and MonoDevelop

I started out with the first option, since the second was not available at that time. I found it really hard. Using a c-like syntax is not the hardest thing, but I surely wasn’t used to manage my own memory any more! I got really frustrated since I also had to learn all the other things I’ll talk about in a minute.

The solution came in a podcast from DotNetRocks titled “Rory does iPhone” in which Rory Blyth raved against Objective-C. In that podcast there was a short mention of an open-source initiative called MonoTouch.

Mono

That changed my world radically. I went out looking for the Mono guys and found a very mature platform and active community. if you don’t know: Mono is an open-source initiative that brings the .NET framework to a lot of other platforms, especially the Unix-look-a-likes.
I had heard about Mono before, but always thought it was a project that was way behind the development of the .NET framework. You know, like Microsoft is releasing .NET 4.0 and the Mono guys are proud to announce they now support 2.0! Nothing like that! Mono is on .NET 3.5 and preparing for the changes that 4.0 will bring. They also have a very nice IDE called MonoDevelop that looks a lot like Visual Studio.

With MonoDevelop developing applications on the Mac is so straightforward that I never go back to my VMWare installation with XP and VS2008 to do some quick development. If you think about porting your application (since not all that is available on Windows is there on Linux too), install their Mono Migration Analyzer add-in.

And they have MonoTouch. On the surface it is just a wrapper around the CocaoTouch library that you use to program UI’s on the iPhone.

But is is also a very special compiler that pre-JITs (the call it Ahead Of Time compilation) the entire application. Why? The iPhone OS will not allow you to run a virtual machine. Ever wondered why there is no Java or Flash on the iPhone? They cannot run since they depend on their own VM.
MonoTouch circumvents this problem by generating native code, removing all the unused libraries, classes and methods and then building a Mac App package from that.

What do I have to learn?

When you want to build your own application, you will at least have to learn about:

1. The structure of iPhone apps
2. The Cocao Touch library
3. The Interface Builder
4. Debugging in XCode
5. Signing your application
6. How to distribute your application

I will try to tell you about all of these subjects in different installments.

The structure of an iPhone app

It is essential to know what the iPhone expects from you and how the Cocao Touch library supports that. It is probably  way different from the way you worked in C# and WinForms, and it takes some time to get used to finding out where to put your application logic.

The Cocao Touch library is full of Design Patterns, but the most pervasive, noticable, visible and wonderful is The Model View Controller. Below is an image from the Mac Development Library:

MVC

This post is not about Design Patterns, so I will not explain how the MVC pattern is supposed to work. The image is just their to help me explain which classes you will have to inherit from.

Cocao development is about inheriting from the classes that wire up the application for you. That means that you only have to override the methods that are of interest to you, but it also means that you essentially have no way to stray from this setup. You use the Cocao classes or you end up building your own library.

These are the classes that implement the MVC pattern for the often-used TableView:

1. UITableView
2. UITableViewDataSource
3. UITableViewDelegate
4. UITableViewController

The UITableView is in the NIB: the file that is generated for you by the Interface Builder and that holds all the GUI elements.

The UITableViewDataSource holds the data that is displayed in the table. It’s methods are called by the Controller to fill the cells in the table (e.g. GetCell, RowsInSection).

The UITableViewDelegate implements methods for dealing with user-actions that are performed on the view, like “RowSelected” when (yep) a row in the table is selected.

The UITableViewController is the man-in-the-middle. It sits between the DataSource and the TableView, and does things like passing the DataSource filtered data when some search criterion is entered and then telling the TableView to reload with this new data. The controller can use your own model to get this filtered data.

So far for this installment. Next time I will show some code and tell about the AppDelegate, the object that functions as the heart of your application since it receives a lot of interesting messages like “Hey you’re app is started!”.

We are pleased to announce the launch of EZdroid, the world’s first open-source, collaborative platform for the safe deployment of component-based software applications and content across Android, and other Linux-based mobile devices.
EZdroid was founded by two of Europe’s leading companies in the field of OSS technology; the platform consists of Android, Apache Felix and a number of their own enhancements (e.g. software license-, device- and integrated software-management). EZdroid supports the secure deployment of software applications and content (known as Provisioning) to Android phones and in the future, other Linux-based operating systems. It is available to any organization or individual wishing to make software and content available to Android users world-wide. Further information and a demonstration of the platform is now available and downloadable to Android phones at: http://www.ezdroid.com.

EZdroid’s founders: Luminis BV (www.luminis.nl/en) of The Netherlands and Akquinet GmbH (www.akquinet.com/en) of Germany are now inviting partners and collaborators to become part of the EZdroid community – whether these are developers, wishing to show-case their applications, business partners interested in co-development or an OEM relationship, or organizations which are interested in owning and controlling their own application repository/App Store.

The launch of EZdroid is very significant; it is the world’s first platform, built from open source components, which will allow the mass deployment of applications without proprietary licensing issues. The founders intend to supplement the platform with a validation and quality assurance system – to ensure that applications are safe and do not interfere with Android’s normal operations.