JavaOne 2013 is over, But have I learnt from it?

On a sunny day, JavaOne took place downtown San Francisco. JavaOne is already over, let me share with you my experience. My personal interests being on mobile technologies and polyglot languages, this was the guiding theme of the sessions I attended.

Monday

I started on Monday as early as 8:30 and already with a cornelian dilemma: which session to choose: the one with my team mates “Notify Your Mobile Clients by Integrating Push Networks and Java EE 7” or the one with my soulmate (and dear husband) “Polyglot Alchemy: JSR223 in action” ? I won't tell which one I attended :)

My next session was with Hans Dockter presenting “Gradle and the New Android Build System”. Starting with a scary image of feet corpse, to make you measure how important is an efficient fully automated build system. Why did Google choose Gradle for their build system? Even a simple android project is more complex that a plain java project. Live cycle phases are more complex and can me declined in different flavors. The key success of Gradle build is about mixing declarative build system with flexible and rich object model. I was even surprised to learn Gradleware is also working on C++ build system.

I also did a couple of Nashorn sessions. "Nashorn: JavaScript on the JVM" with Jim Laskey. With JavaScript on the JVM, programming is fun again ;) Full of concrete examples on how to use JavaScript for scripting, how to mix JavaScript and Java with binding. The one that hurts a bit the eyes (personal feeling here) is nashorn + JavaFX. Interesting debugging IDE askari POC but to be honest, what we really wish for is to have IntelliJ/Eclipse support.

It was time to give my 2 hours tutorial session on "Embedded DSL: Groovy and Scala Fair Duel" with my co-speaker Pascal Cohen. Our presentation was full of code samples assuming knowledge in both Groovy and Scala syntax. If you want to try them by yourself, here is the link of the presentation. Eventually, you can also play the game. That was great fun!

Tuesday

"Developing with Java on iOS and Android: Introduction to Oracle ADF Mobile" with Shay Shmeltzer. Oracle ADF mobile is for Java developers that don't want to see their skills become obsolete. Don't need to learn HTML5/JavaScript. Quoting Shay: "JavaScript is meant to do DOM manipulation but for serious logic, JS is slowing you down", ADF mobile allows you to write all your code in Java and under the hood HTML5 is used. You can write your own ADF module in XML.
Break. Too much for me. JS is a poor language, XML is a great tool for developer. Isn't it late by a few years?

Let's have a session on JavaScript, how funny to see JS used server side too. To do serious logic. "Server side JS on the JVM with Nashorn and avatar.js" by Akhil Arora. Avatar is an implementation of nodejs for the JVM, it was open sourced last Sunday on java.net. Some of the features:

• support multiple event loops: one single event loop in node js.
• multiple java threads support
• compatible with node v0.10.18, of 584 node unit tests 470 passed without patches (80%)

Avatar implementation is based on libuv (cross platform asyn io lib), node’s http-parser(synchronous http parser very fast) and _wrap module.

"RIA Technologies and Frameworks Panel" featuring Stephen Chin, Max Katz, Sven Reimers, Andres Almiray, Gerrit Grunwald and Kevin Nilson was an interesting and informal session with a good focus on mobile technologies. Attendees ask questions to the panel.

"Play vs Grails smackdown" with James Ward and Matt Raible, very entertaining session where Play (Scala web framework) get compared with Grails (Groovy web framework). Fair battle too :)

"Embedding JVM Scripting Languages" of Anton Arhipov. Everything you need to know on JSR223.

"Teaching Java with Minecraft, Greenfoot, and Scratch" by Arun Gupta (proud dad of Aditya who did the Community keynotes on Thursday) and Daniel Green, gives you a good overview of the different software to use. From Scratch to Minecraft. Targeting your audience is key.

"Experimenting with the Boundaries of Static Typing" with Paul King. With code samples, you can compare full blown static type code vs. dynamic code.

Wednesday

"Testing the Enterprise Layers: The ABCs of Integration Testing" with Andrew Rubinger and Aslak Kntusen Welcome earthlings! said alien Arquillian. The session gives a good overview of different test phases and if you need more in-depth you could read the purely open source book.

"Functional Groovy" - Paul King. Always a pleasure to attend Paul's presentation. The good thing is you can review slides and code back home, the content is rich.

"Polyglot JVM: Who, Why, When, and How" starring Ixchel Ruiz and Andres Almiray

"NoSQL Overview" with Tobias Lindaaker. As the title says it all, you get out of the session with a good overview. Categorisation borrowed from excellent book from Martin Fowler.

"Android and iOS Development with Java EE 7" Have you heard of AeroGear? This was the introduction session to get a broad knowledge of how jBoss tools plays nicely with AG and where they fit in the JavaEE landscape.

Thursday

I am not a big fan of keynotes, but unlike Larry I haven't skip that one. If there is only one thing I should recall from that keynote, it is Aditya Gupta opening Eclipse and explaining the audience: this is Eclipse...
So much like my son.
I did a couple of sessions to finish:

"Groovy and Concurrency with GPars" with Paul King

"Polyglot Enterprise Development on the JVM" with Thomas Enebo

"Truly Native Java Apps on iOS with RoboVM" with Niklas Therning. Interesting subject: How to bring Java and other JVM languages to iOS devices. Funny enough to see code in Java implementing CocoaTouch. The project does not generate Objective-C code but rather compiles bytecode into machine code. However you still need all Xcode installed and you need to run on a mac.

This is the end

Sessions all finished. I had a great time at JavaOne. Nice to meet you guys :)

Tweet

Going to JavaOne? Join us for a tutorial session on DSL

Next Monday at JavaOne, I will be giving a tutorial session "Embedded DSL: Groovy and Scala Fair Duel" with my co-speaker Pascal Cohen.

I invite you to join us and here is a couple of reasons why (in a very objective view of course):

• You want to learn more on Domain Specific Languages. 

• You've heard so much about polyglotism: here a session where you've got a chance to see in action 2 very popular languages on the JVM in the same session! Scala and Groovy are seen theoretically strongly opposed but we will show you how, using different techniques, we achieve the same DSL.

• You want to see code and really learn something concrete. We'll show you step by step how to build KissingTurtles language. If you bring along your computer you can even do it yourself.

• You're not into Groovy or Scala. Fancy a tour in Scala and Groovy land? Even code your first script. 

• You're interested by XaaS buzz words. What are the challenges of platform as a service. Running client code (not to mention when client is 6 years old) can be risky and tricky. 

• You have kids too. You want to see what is KissingTurtles. 

• You love french accent. Two Frenchies on stage with a pure lovely accent. 

• You want to have fun.

But I've already said too much. I love chatting, but this is supposed to be a teasing...

See you Monday at 4:30pm Hilton - continental Ballroom 1/2/3. I'll be there. Will you?








Tweet

AeroDoc push notification application, step by step

Last AeroGear release (1.1.0) main focus is on push notifications. Push notifications are heavily used in today mobile apps. They become key features, changing the UX in a push-notification-enabled application. Notifications' role is to wake up applications to provide updates, and that simple feature fulfils thousands of business use cases.

However, with the broad variety of proprietary Push notification solutions: APNS (Apple Push Notification Service), GCM (Google Cloud Messaging), AMD (Amazon Device Messaging),  WNS (Window Push Notification Service), even the web push is on its way with SimplePush notification for Firefox OS, it mays quickly sound like cacophony to a developer willing to target multiple market places. Here comes UnifiedPush Server, a solution to treat push notifications in cross platform approach. Push in the Open.

But AeroGear UnifiedPush Server, in short how does it work?

A picture is worth a thousand words:

1. Push application registration: UnifiedPush server is based on PUB/SUB model, you need to register you application. After registering your app, you will get a pushApplicationId. A push application can target different platforms. You can add variants to it. A variant contains platform specific properties, such as Google API key for Android, certificate credentials for Apple, or a PushNetwork URL for SimplePush. Out of the variant registration, you get a variantId and its associated secret.

2. Installation registration: This is the actual device registration. Given the pushApplicationId and VariantId and associated secrets, the device will register itself on first connection.

3. Send notifications: All set with registration, now your backend app wants to broadcast push notifications to all devices. Using sender API with its fluent message API, it's easy. You can do broadcast and selective send.

4. Underneath, UP server allows you to work with APNS, GCM or simply over the web with SimplePush

5. Receive push notifications whether you're online or offline.

And maybe we can do more than just talking about it let's see it in action. First of all we need a use case.

Our use case: AeroDoc

AeroDoc is a company in the health care industry, selling a revolutionary medial products. The company's sales department has a call center agents, doing phone calls all day and mobile sales agents, most of their time on the road, attending conferences and meeting potential clients.

As soon as a call agent get a lead, he uses AeroDoc Admin app to filter out available sales agents in the neighbourhood of the company interested by the products. Call center agents can send mobile sales agents push notifications.

Sales agents receive the notifications on their smart phones. Once a mobile sales agent accepts the lead on his mobile device (using either iOS AeroDoc client app or Android AeroDoc app), the other agents get a push notification that the lead is taken care of. In a highly competitive market, being able to process a lead directly is for sure a competitive advantage :)

Let's start our step by step approach

Step1: Deploy UnifiedPush Server

UnifiedPush server should be up and running. To install it on Wildfly, follow instructions from aerogear unified push server github repo. Alternatively, you can used the cloud deployed version in OpenShift.

Step2: Deploy AeroDoc Admin app

Let's start cloning aerogear-aerodoc-backend github repository. AeroDoc backend should be deployed. Follow instructions from AeroDoc backend.

Step3: Register process

You have 2 options: either use the Admin UnifiedPush Server or do it simply with curl command. It depends whether you're more a UI person or command line addicted.

• Login (reset password if needed) 
• Register your application to get your pushApplicationID and a masterSecret
• Register your iOS variant. Start using development variant, you will need your apple provisioning as explained in prerequisites. You should get a variantID and a secret

Step4: AeroDoc backend configuration

AeroDoc backend needs to know:

• which url is your UnifiedPush Server, it could be local or running on OpenShift. 
• what is your pushApplicationID and masterSecret

You can configure it using its UI as shown below:

Extracted from LeadSender, the service responsible to do selective send, get a feeling of the sender API:

public void sendLeads(List users, Lead lead) {
        if (getActivePushConfig() != null) {
            Map categories = new HashMap();
            categories.put("lead", "version=" + leadVersion++); 
            UnifiedMessage unifiedMessage = new UnifiedMessage.Builder()
                    .pushApplicationId(getActivePushConfig()
                   .getPushApplicationId())
                    .masterSecret(getActivePushConfig().getMasterSecret())
                    .aliases(users)
                    .simplePush(categories)
                    .attribute("id", lead.getId().toString())
                    .attribute("messageType", "pushed_lead")
                    .attribute("name", lead.getName())
                    .attribute("location", lead.getLocation())
                    .attribute("phone", lead.getPhoneNumber()).sound("default")
                    .alert("A new lead has been created").build();

            javaSender.sendTo(unifiedMessage);
        } else {
           ....
        }
    }

Here we're sending to a list of users (see aliases method) of any variants of AeroDoc application, a message with a version and business attributes like name, location... Notice some native specific attributes like alert/sound.

Step5: iOS AeroDoc app configuration

Let's start with cloning aerogear-aerodoc-ios github repo. In config file, let's configure your varianId and secret :

#define URL_AERODOC @"http://localhost:8080/aerodoc/" 
#define URL_UNIFIED_PUSH @"http://localhost:8080/ag-push/" 
#define VARIANT_ID @"YOUR_VARIANT" 
#define VARIANT_SECRET @"YOUR_SECRET" 
#define ENDPOINT @"rest" 

You're all ready to launch the application on your iPhone. Notice that for Push notification test you can not use your iOS simulator, you need to test it on actual device.

How does your iOS app enable push notification?

First register your iOS app for Apple:


Once the application is started the first time, it prompts you with a dialog box, where you have to agree that the application may receive "Push Notification Messages"

< How does your iOS app register to AeroGear push notification? Once you get registered with APNS, you get a deviceToken:

- (void)application:(UIApplication> *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken {
  [self.viewController setDeviceToken:deviceToken];
}

It's now time to register to UnifiedPush server. It's done in application: didRegisterForRemoteNotificationsWithDeviceToken: where you register using the deviceToken provided by Apple with the variantId and secret you got when registering your iOS variant:

- (void) deviceRegistration {
#if !TARGET_IPHONE_SIMULATOR
    AGDeviceRegistration *registration = 
     [[AGDeviceRegistration alloc] initWithServerURL:
        [NSURL URLWithString:URL_UNIFIED_PUSH]];
    
    [registration registerWithClientInfo:^(id clientInfo) {
        [clientInfo setVariantID:VARIANT_ID];
        [clientInfo setVariantSecret:VARIANT_SECRET];
        
        // if the deviceToken value is nil, no registration will be performed
        // and the failure callback is being invoked!
        [clientInfo setDeviceToken:self.deviceToken];
        
        UIDevice *currentDevice = [UIDevice currentDevice];
        [clientInfo setAlias: [[AeroDocAPIClient sharedInstance] loginName]];
        [clientInfo setOperatingSystem:[currentDevice systemName]];
        [clientInfo setOsVersion:[currentDevice systemVersion]];
        [clientInfo setDeviceType: [currentDevice model]];
        
    } success:^() {
       ...
    } failure:^(NSError *error) {
       ...
    }];
#endif
}

How to push lead to my iOS app?

• go to AeroDoc admin UI
• login as john with password 123
• go to your iOS app login as maria/123
• john create a new lead, select it, search for an available sale agent, select Maria and push a  lead to Maria.

and Maria received a new lead!
Maria is Minnesota, AeroDoc admin sends the lead to her.

1. lead Alpha is pushed to Maria

2. Maria accept the lead

3. lead Alpha is broadcasted as accepted and remove form available leads.

Step6: Android AeroDoc app

You're not an iOS person and want to see it in java, follow the readme on aerogear-aerodoc-android.

Step7: Web based AeroDoc app

You're neither an Objective-C nor Java guy, you want to see pure JavaScript. Look at readme on aerogear-aerodoc-web.

Stay tuned!

UnifiedPush server is one feature of AeroGear project, there is more in it and more to come.






Tweet

Gr8Conf: what a great conference!

It's not just a pleonasm, it really is a great conf!

And do you know what makes it so good? People. It's an event where you meet smart people, and even better where you can talk to them. 

The conference started on Sunday 21st July in gorgeous Minneapolis. Sunday was dedicated to workshops. I was running the Grails Mobile workshop with Fabrice Matrat, my geek husband presenting in action the 3musket33rs Grails plugin. 18 attendees for our 3 hours workshops and it always ends up being too short! Fun to run a foursquare clone on your mobile.

Monday morning, conference started with Peter Ledbrook giving an inspiring talk on open source contributions. "Open source and you" makes you feel engaged.

As always, the most difficult part is always to choose your track, specially when you have four choices. I decided to stick to the Groovy track for the first day. I started my day attending Jim Driscoll presentation on "Turtle Graphics in Groovy", a talk on Groovy DSL so close in content to the one I gave in the afternoon with co-speaker Fabrice Matrat. Attending the second talk, Oracle ADF (Application Development Framework) with Jim and co-speaker JR Smiljanic, it turned out that our inspirations have some common roots. We've been dealing with very similar subjects. Oracle has been working on enforcing Security and Web debugging while integrating Groovy inside ADF to provide a customization platform. 

Whereas, when I was working in Amadeus, I was part of the business team (web based SellConnect) designing a Groovy DSL for travel agents to customize cryptic commands. I used to work closely to the architecture team (Fabrice Matrat &Vincent Bersin) in charge of implementing PaaS using Groovy for server side scripting and Aria Templates for UI customization. I certainly think there is some good ground for open source contributions here! Working on the open side is my motto. I am proud to be Red Hatter :)

Carry on Groovy, with “Type checking your DSLs” by Cedric Champeau. Using Groovy as a scripting platform you may want to get errors as early as possible, at compile time. Do you offer DSL to your end users? With Groovy 2, you can go a step further and type checked your DSLs. With powerful AST transform and the usage of a DSL (Groovy developers love DSL), you can hook into the compiler and makes it Grumpy :) Cedric also shows us a very interesting example on how to type check your builder. Suppose you have your XML schema, you can type check your custom XML Groovy builder.

I finish the day giving “Groovy DSL for kids” presentation with Fabrice, moving the Turtle around is always fun.

I started day 2 with “Lift-off with Groovy 2.1”,  to kick off the day. Next session I attended was BDD using Cucumber with Groovy by Marco Vermeulen. Quoting Dan Worth (from a tweet) to give a definition of BDD is just great! Live coding examples on how to practice it is fun too! I really enjoyed this session: packed with information, I even learnt about accelerated agile. You can have any doubt about it, Marco is for sure a BDD addict, his second talk on GVM was named “GVM: an example of BDD in action”.

Last, Vankat Subramanian’s key note was brilliant. Showing closure to talk about functional programming in  a Groovy conference because “off course I know you know Groovy” is just so gooood.

See you next year !

Tweet

Hackergarten on Mars

Yesterday Marseille JUG hosted a hackengarten. Broad variety of topics:

• Julien Viet presenting CRaSH 
• Stephane Epardaud with Ceylon language
• Thomas Segismont with RHQ
• Andre Dietisheim for Openshift 
• Sebastien Blanc and me for Aerogear

It was actually the first hackengarten I was attending. I've done workshop before, where you prepared a demo with steps. Hackengarten are cool stuff. They required less preparation work, it's more on the fly event. It's also a good opportunity to meet and talk to open source developers. Small group, pair programming and interacting is for sure fun.

For AeroGear, we prepared some markdown doc where you put together quick start instructions.  we had two proposals: work on scaffolding geolocation or do some cool Spock test.

Two brave hackers: Victor and Axel volunteer to do Spock testing on the new AeroGear feature Unified Push.

We endup doing our first PR on AeroGear integration test branch!

Another PR was pushed to CRaSH git repo. The lucky contributors went back home with AngularJS t-shirt - ask Julien why Angular :)

Keep up the nice work, more contrib welcome ;-)
See you on next JUG guys!



Tweet

Blocks vs Delegate

How can you simplify your code using blocks. 

All iOS developers are familiar with the Delegate pattern. It is an object oriented pattern widely used in Cocoa Touch frameworks. Most of time  the delegate pattern is used to express callback code. Code that will be handled once a button is clicked or once datasource is initialized.

Since iOS4 and with the introduction of Blocks, it opens a new style of callback programming. If you're coming from functional language like Lisp, Clojure or like me, from Groovy, you know what a closure is. Simply put, Blocks (iOS term for Closures) encapsulate a piece of code, enclosing with it, variable that are in scope at the time the block is declared. Blocks can greatly simplify code. They can help you reduce code and more importantly they allow you to declare what going to happen at the same time than defining your code. Let's take a common use case and compare with Delegate approach versus with Block approach. For the Block code sample our example is base on ARGenericTableViewController reusable component.
Our use case is taken from AeroGear TODO app for server side and for the client, let's look at iOS client source code. I extracted from this sample app, the display of two tables: I'd like to focus on the implementation of two kinds of list: one is a dynamic list with standard cell, the next one is detailled view with section and custom cell.

TODO task list + task detail screens 

Using our cloud hosted backend for TODO, you can add tasks with the web interface. Let's write an iOS client app to visualize the tasks list. Source code could be find on github.

Delegate version

When implementing a UITableViewController, you need to define datasource delegate function tableView:cellForRowAtIndexPath: This method is called for each row. It's the developer duty to customize the cell depending for each section depending on the row index.

In the case of a list of tasks (using one type of cell -besides standard one), our method tableView:cellForRowAtIndexPath: is not doing much. But when defining detailed task table which has sections and inside section different types of cell, we end up with:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    NSUInteger section = [indexPath section];
    NSUInteger row = [indexPath row];
    
    UITableViewCell *cell;
    
    switch (section) {
        case AGTableSectionTitle: {
            EditCell *titleCell = [EditCell cellForTableView:tableView withClassName:@"EditCell"];
            titleCell.txtField.text = [self.task objectForKey:@"title"];
            cell = titleCell;
            break;
        }
        default:
        {
           ...
        }
        case AGTableSectionDescr:
        {
            ...
            break;
        }
        case AGTableSectionDueProjTag:
        {
            switch (row) {
                case AGTableSecDueProjTagRowDue:
                {    
                    ...
                    break;
                }
                case AGTableSecDueProjTagRowProj:
                {
                    ...
                    break;
                }
                case AGTableSecDueProjTagRowTag:
                {
                    ...
                    break;
                }

            }
            
            break;
        }
        
    }
    
    return cell;
}

With the usage of switch your McCabe cyclomatic complexity increases :(
You will see how ARGenericTableView helps the cause.

Notice that for accessing property we chosen to subclass UITableViewCell (EditCell), at least we can keep the initialization of the cell shorter. Always in a worry to keep it short, we define a method cellForTableView:withClassName: for each custom cell. The method is using dequeueReusableCellWithIdentifier: internally allowing reuse of cell.

Blocks version

Let's revisit our TODO app using UITableViewController to use Blocks.

1. Add pod dependency

2. Inherit from ARGenericTableViewController instead of UITableViewController

@interface AGTaskViewController : ARGenericTableViewController
@property (strong, nonatomic) id task;
@end

3. Initialise your callback blocks:

- (void)viewDidLoad
{
    [super viewDidLoad];
    ARTableViewData *tableViewData = [[ARTableViewData alloc] init];

    [tableViewData addSectionData:[self sectionTitle]];
    [tableViewData addSectionData:[self sectionDescription]];
    [tableViewData addSectionData:[self sectionDueDateProjectTag]];
    
    self.tableViewData = tableViewData;  
}

- (ARSectionData *)sectionTitle {
    NSString *name = NSStringFromClass([EditCell class]);
    ARSectionData *sectionData = [[ARSectionData alloc] init];
    [self.tableView registerClass:[EditCell class] forCellReuseIdentifier:name];
    
    ARCellData *cellData = [[ARCellData alloc] initWithIdentifier:name];
    [cellData setCellConfigurationBlock:^(EditCell *cell) {
        cell.txtField.text = self.task[@"title"];
    }];                
    [sectionData addCellData:cellData];    
    return sectionData;
}

All you code definition goes in the init method (viewDidLoad). You don't have to implement the delegate method tableView:cellForRowAtIndexPath:, ARGenericTableViewController is doing it for you behind the scene.

ARGenericTable is a acting like a map of blocks that you register at init time. ARGenericTableViewController implements tableView:cellForRowAtIndexPath:. For each cell, we retrieve cell configuration and call its associated block.

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    ARCellData *cellData = [self.tableViewData cellDataAtIndexPath:indexPath];
    
    NSString *CellIdentifier = cellData.identifier;
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (!cell) {
        Class TableViewClass = self.tableViewCellClassDict[CellIdentifier];
        cell = [[TableViewClass alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier];
    }

    // Configure the cell...
    if (cellData.cellConfigurationBlock) {
        cellData.cellConfigurationBlock(cell);
    }
    
    return cell;
}

As you can see with the block approach, we have achieved much leaner code: no imbricated switch statement anymore. Notice the usage of registerClass:forCellReuseIdentifier: which works with dequeueReusableCellWithIdentifier: (iOS6 new pattern). Slight note on feature improvement for ARGenericTableViewController in order to be more flexible: everything is fine as long as your working with custom cell or standard cell using default style. However if you want to init with style of UITableViewCellStyleValue1, with the current implementation you can't.

Tweet

To Xib or Not to Xib?

Being new to iOS environment, I watched different tutorials: the latest Stanford iOS classes uses storyboard for almost all demos, reading big nerd ranch iOS programming book, Interface Builder (xib files or in their binary form nib file) are much prefer over storyboard, looking at source code in TODO sample none of those methods are used. Everything is crafted by hand, which I will call in the rest of the blog the hand-crafted approach. Which one to choose?

First of all, all of them work, it's just a matter of finding which one works best for you. Which can you app are you making? Are you working alone? Are you an addicted to IDE or you'd rather use plain old text editor? Are you more a mouse person or a a do-it-all-with-the-keyboard guy?

I try the different ways with one simple example: I want to build an App that displays a list of item. We want to create a ViewController named MyViewController which inherits from UITableViewController. All source code could be found here.

Hand-crafted

Step1: Create Xcode project with empty template

Open Xcode and go to File -> New Project, select the  Empty Application template

Step2: Add new file MyViewController

and make it extends UITableViewController

Step2: Link MyViewController to AppDelegate 

By adding property at line 4:

@interface MyAppDelegate : UIResponder 

@property (strong, nonatomic) UIWindow *window;
@property(strong, nonatomic) MyViewController *viewController;

@end

Step3: Take care of initialisation of AppDelegate

Once the application is loaded, it's the developer's duty to instantiate MyViewController. As per commonly used Delegate pattern, once app is loaded the delegate method application:didFinishLaunchingWithOptions: is called. Within this method, you should add line 6-7

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
    // Override point for customisation after application launch.
    self.window.backgroundColor = [UIColor whiteColor];
    self.viewController = [[MyViewController alloc] initWithStyle:UITableViewStylePlain];
    self.window.rootViewController = self.viewController;
    [self.window makeKeyAndVisible];
    return YES;
}

Step4: Implement your model in MyViewController

For the example we feed an array of fake data in it setter method.

@implementation MyViewController
NSArray *_items;

- (NSArray *)items{
    _items = [[NSArray alloc] initWithObjects:@"Item No. 1", @"Item No. 2", @"Item No. 3", @"Item No. 4", @"Item No. 5", @"Item No. 6", nil];
    return _items;
}

Step5: Display your model in MyViewController

To display the content od a cell you need to conform to protocol UITableViewDataSource, tableView:numberOfRowsInSection:  and tableView:cellForRowAtIndexPath: are the two methods responsible for the display of a cell.

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section{
    return [self.items count];
}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{
    static NSString *CellIdentifier = @"Cell";
    UITableViewCell *cell;
    
    cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil) {
        cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier];
    }
    // Configure the cell... setting the text of our cell's label
    cell.textLabel.text = [self.items objectAtIndex:indexPath.row];
    return cell;
}

That's it you're all done, run the app!

Interface Builder

Xib, nib depending if it's the next generation or not. Actually xib file is the xml source file which describes your view. Nib being the compiled version.

Step1: Create Xcode project with Single App template

Open Xcode and go to File -> New Project, select the Single View Application template

In the next step make sure you have the option Use Storyboard unchecked.

No need to add code in AppDelegate's application:didFinishLaunchingWithOptions:, the code has been added for you. See line 5-6.

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
    // Override point for customization after application launch.
    self.viewController = [[AGViewController alloc] initWithNibName:@"MyViewController" bundle:nil];
    self.window.rootViewController = self.viewController;
    [self.window makeKeyAndVisible];
    return YES;
}

Step2: Implement your view with xib view

1. drag and drop Table view from object library in utilities bar.

2. create an outlet, drag and drop (with control key down) up to MyViewController interface.

3. link data source to file owner: right click on TableView all the way to file's owner in document view.

Step3: Implement your model in MyViewController

Same code than Hand-crafted approach step4.

Step4: Display your model in MyViewController

Same code than Hand-crafted approach step5.

Run the app an you will have the same result. As you can see there is less code to write, but the approach involved more mouse actions. One piece of code that was generated for you but which is important to understand is in step1, the call to initWithNibName:bundle:; One interesting stuff with Interface Builder is that you can mix handcrafted and interface builder. The strength of a WYSIWIG widget based tool like Interface Builder is to build complex customized view. If you have to build a Custom Cell for you TableView, you could use Interface Builder and then load the archive and associate it with the relevant object.

Storyboard

Introduced in iOS5, Storyboard carries on the WYSIWYG approach launched by Xib. Sometime seeing as a replacement of nib, it brings UI definition in one simple file rather than several xib files, also deal with transition between screen.

Step1: Create Xcode project with Single App template

Same as for Interface builder, but this time make sure Use Story board option is checked.

Step2: Make connection from storyboard to your code

1. Go to .storyboard file, select the UIViewController graphic
2. On the utilities tab, in the identity inspector, change the class field to match MyViewController
3. create an outlet: holding the ctrl key with a drag from your view in storyboard to MyViewController.h file. Once you drop you will be prompted to enter a name, and click connect. this is the magic part of Apple WYSIWYG editor and how the link to source code. All newbies get surprised here.

Step3: Connect the datasource with outlet

Remember for hand-crafted we had to implement 2 protocols data source and delegate one. Same thin here, right click on TableViewController in the storyboard. From the outlet section, drag and drop to My Table view controller. Do it for data source and delegate.

Step4: Implement your model in MyViewController

Same code than Hand-crafted approach step4.

Step5: Display your model in MyViewController

Same code than Hand-crafted approach step5.

Run the app an you will have the same result. Here again, there is less code to write, but the approach involved more mouse actions. Besides, I thing the strength of storyboard comes when you have an application with several views and transitions using segues.

As a conclusion, we've seen the different approaches, I think to start with it's easier with the hand-crafted approach as you get to understand frequently used patterns in iOS like the Delegate pattern. But then I might be biased as I have a developer background. I like the idea Xcode storyboard/xib approach , I think it's nice to prototype or to experiment (like a preview you see it right away) but at the end of the day I find source code easier to maintain. It's all written in plain code. But you know what, storyboard/xib file are be all written in plain XML too ;) Right click and open then as source code.

Do you prefer to write XML or Objective-C?



Tweet