From iOS to Xamarin for Android/Win Phone in Visual Studio

I've operated as primarily an iPhone/iPad developer / UX guy for the past 3 years. This week I was tasked with the challenge to trial Xamarin and port a small checklist app we built for a client to both Android and Windows Phone.

I installed the latest version of VMWare fusion with a freshly installed Windows 7 64Bit image with Visual Studio 2012 Professional to my MBP 2011, 16 GB Ram, 2.2 GHz dual core i7.

My first thoughts: It works, I like it, it can potentially save a significant amount of time( some back of napkin calculations at the end of this post) :)

They have sample apps that you can build and run and learn from  (After solving some errors and addressing some issues easily solved via stack overflow) to kick start your own development of an Android app in C-sharp.

They have a cool 3rd party component store, which is a great idea and may prove to be very handy in the future.

It states on their site "Easily create apps in C# for iOS, Android and Mac".
If you've ever used XCode, you'll know that as of version 4.6, it's naturally extremely good for building iOS apps, and any other alternative just isn't able to compete.

So in my personal humble opinion...ahem.. don't bother. Which leaves Android and Windows phone. Obviously Windows phone should be developed in Visual studio & C# anyway, hence you find the Xamarin website doesn't focus so much on Windows phone, however that's where Xamarin projects designed in a three tier architecture fits in so well, using the SQL data mapping, all of a sudden business logic and the data model (accessors, aggregation, algorithms and all of the other under the hood stuff) can be written once and used for all 3  operating systems.
Also it means Webservice code can be written once, which for reasonably large apps could make it much more economical to develop for multiple devices.


Well 4 operating systems if you include mac OSX... but it should be pointed out to non developer stakeholders the time it takes to write the User Interface / User Experience code for each operating system can still be a significant amount of the development effort, and Xamarin cannot help in this department, where some apps could require 90% UI/UX code and 10% business logic/Data model code, only 10% is being reused. Also (obvious to the developer but seems to fall through the cracks for other stakeholders like BA's the User interface design should be designed for the operating system following the OS guidelines.

So then the experience of the developer with native tools over C# should be considered. Whereas some apps could have a relatively large amount of business rules to develop for and it would suddenly be a very compelling option.


The general gist of the framework:

They have some case studies here.

Some first experiences I found:
- You must have Xamarin Business Edition or higher to use Xamarin.Android from Visual Studio. They have their own IDE (fork of Eclipse) that you can use as an altnerative to Visual studio, but that's not ideal if you wish to build for Windows Phone as well. And entry level pricing ain't cheap, $999 gets you in the game as of writing this article.

- Installing some of their sample apps don't work out of the box without addressing error messages and bringing in third party libraries such as Google Maps.

- I found the android emulators to be very slow, but that's Googles fault.

- Initially I pressed 'start with debugging' in the Tasky 10 minute guide I got a 'Failed to create pbuf surface' error, I restarted the machine and did a clean build without debugging which seemed to fix it.



- The XAML editor for Android in Visual studio is pretty good. well it does the same job as in eclipse, however Laying out XAML for Android User interfaces is like playing battleships. It's an educated guessing game and you have to wait to preview in emulator for each change to see if you got it right. But if it's right on one Android device it could be completely off on a different device. Design is built into Apple’s DNA...Google has just bolted it onto its search engine. Ain't no avoiding this unfortunately.

Me in the Xaml editor:

- On first run of the 10 Minute guide I encountered this error despite following the instructions (The application could not be started. Ensure that the application has been installed to the target device and has a launchable activity), which fixed itself after a restart after I checked stackoverflow for help:

- I also found 5-10 minute loads causing VS to not respond (Microsoft Visual Studio is busy) on the emulator on first load then 1-2 minute loads from then on, no different to using eclipse of course:

Conclusion:
As an iOS developer, Xamarin has been a fairly quick and easy tool to learn once it's running.
The sample apps help for getting going despite some errors preventing things from working straight out of the box. The UI for android is still XAML based, but the UI logic can be written in C-sharp well enough for any basic design. Given that I'm not a huge Java or eclipse fan, this is really quite useful to me.
Running Android app builds on device instead of emulator is definitely a wise idea to save time given the huge time it takes to emulate.
The Tasky app serves as a great sample app to quickly get up to speed with how lists are handled compared with UITableViews in iOS.
Given that Android has many versions, with many devices with many resolutions, user interface design remains a time consuming task for the developer. So it should be clear to all stakeholders that Xamarin cannot address this. If you brake the dev time down (UI/UX, Business logic, Data Model). You can save time on the business logic and Data model, I would give generally speaking 50% of the time to UI/UX.

So if you were to dev the 3 apps with one code base for business logic and the data model you're saving 1/3 of your development time. This is of course subjective to the app your developing, but in any case you're going to save time. Just not as much as you might think on first impression.

Further Information and links:

- Xamarin's Developer Home page
http://docs.xamarin.com

- Xamarin / Mono touch tagged Stackoverflow questions:
http://stackoverflow.com/questions/tagged/monodroid+or+monotouch+or+xamarin?sort=active

- Xamarin for Android Docs
http://androidapi.xamarin.com

- Xamarin Components Store
http://components.xamarin.com

- Xamarin Forums
http://forums.xamarin.com

- Windows Phone Developer Home
https://dev.windowsphone.com/en-us

~Dave van Dugteren

Peoplebank iPhone App

As Declared on Twitter, we at www.alivemobile.com have designed and developed a Job Search tool for Peoplebank.

A tool for folks in the IT industry allowing them to Save Job searches, receive Job Push Notifications, Email notifications, apply for jobs from the app, autofill their application via Linkedin, and a bunch of other cool features that other apps like Seek don't yet do.

Download it here

The White Party iPhone App

For anyone interested... Alive Mobile has released an impressive iPhone app for the Sydneys Digital industry annual White Party available on the App store here:

 https://itunes.apple.com/au/app/the-white-party/id576995647?mt=8

 Party's in 9 days @ the Beresford hotel, Surry hills.

 Some of our team including myself are gonna rock along. Should be a good night.

Some Screenshots:

One of their promo vids:

The Linkedin API with OAuthStarterKit

An iOS app I've been working on at work, requires me to use OAuth with linkedin, to use the app users data for autofilling in a job application

I started with git: https://github.com/synedra/LinkedIn-OAuth-Sample-Client

And immediately got the error "signature_invalid" returned, when calling for any specific field selections.

 I eventually sussed it and answered my own question in how to get it to give me the users authorized data including their email, telephone, address, job history etc etc.

The raised question was here:
linkedin-api-error-invalid-signature-in-iphone-starter-kit

The profile usage link here:

https://developer.linkedin.com/documents/profile-api

I'm able to get the users email address which conflicts with official information from Linkedin's site (Depending on where you look) e.g. here a Linked in staff member explains that email is not given out to protect their users:
https://developer.linkedin.com/forum/getting-started-linkedin-api-read-first

Come Get Me App - Submitted to the appstore

So with Nick Flower on UI, Brad Hircock on marketing and myself coding we built an iPhone utility app called 'Come Get Me'. A one click SMS builder for requesting pick up from your current location using CoreLocation (GPS/network triangulation).

We got the domain name comegetmeapp.com and thanks to Brad and Nick a nice splash page and twitter account set up.

Potentially a useful SOS utility when needing a pick up in situations where it's difficult to make a phone call. E.G. a nightclub. Using Google reverse Geolocation it can fairly accurately autofill your location and provide a maps link in the SMS using the Google URL shortener API.

We chucked some analytics into the app, as well as a feed back form, so we may change / add functionality and/or design depending on the popularity and demographics usage.



Screenshots:

The copy to go on the app store description:

The app will help you to forget those awkward conversations where you have to explain where you are and how you got there, instead the app will do that for you. Come Get Me detects your location and remembers your favourites so all you have to do is tap a single button when you need to be picked up. 
If you find us a bug or have a suggestion for improvement let us know using the feedback button below. 
Click Come Get Me, sends a link to your location on Maps Instantly via SMS to your car owner (mate, Mum, Dad, girlfriend, office assistant) of choice. 
This is the first release, please give feedback on how we can improve this app! 

This app brought to you by Brad, Dave and Nick

Upgrading my Macbook Pro (Early 2011)

Currently I run a Macbook Pro with 2 HD's (120 GB Intel 3GB/s SSD and a 700GB 7200 RPM with 4GB stock Apple RAM dual booted between OSX Mountain Lion and Windows 7.

Today I ordered a few parts for my yearly upgrade.

The Upgrade:
1. Chuck in 16 GB Ram - GSkill (1.5V) 2 x 8GB. $100 AUD - G.SKILL 16GB (2 x 8G) 204-Pin SO-DIMM DDR3 1333 (PC3 10600) Laptop Memory F3-10600CL9D-16GBSQ
2. 512 GB Crucial M4 SSD in the main disk bay. $435 inc shipping Crucial 512 GB m4 2.5-Inch Solid State Drive SATA 6Gb/s CT512M4SSD2
3. External case for 700GB $25

The plan:
Move the 120GB to the opti-bay slot. As the CD Drive bay as a max through put of 3GBs on the 2011 mbp's.
Use Clonezilla to take a full image of the Bootcamp partition OSX and Win7 partitions on the 120GB
Chuck in the 512GB.
Restore the bootcamp osx/ntfs image to the 512GB. Create a partition for OSX and win7( Exfat), move all of the tools/apps/games that were installed on the 700GB to the respective drive.
Partition the 120 to 80GB HFS+ and 40 EXFat.

As long as I can get the state logically the same as before I'll be in a good position, the 120GB is over a year old so I'm happy to move my most critical work related tools to the new faster bigger SSD, demote the intel 120GB to a file storage device and use the 700 GB as my backup HD.

OSX Will look like:
OS Drive - 128 GB - {XCode, Photoshop, Documents, Tools}
HFS Data - 128 GB - {iTunes, Downloads}
EXFat 80GB - {Media (TV Shows etc)}

Windows 7 Will look like:
C:\ 128 GB NTFS {Visual Studio/Photoshop/ Anything that doesn't need registry key changes}
D:\ 128 GB EXFat {Steam games}
E:\ 40 GB ExFat {Downloads}

Decorator, Builder and Factory Design Patterns in Objective C

Some people get confused with these 3 patterns (Like me), for you objective c programmers I've rewritten the 3 patterns in example implementations and uploaded them to github, if you can do better, by all means tell me and I'll use your link instead.

Decorator
Builder
Factory Method

All 3 patterns are similar in their achievement of decoupling code, but they have unique purposes and it's necessary to understand these differences, and for those with a visual brain, it's best to see the code alongside reading about them.

If you're a learning cocoa/objective c programmer and you know the time savings incurred from good use of design patterns then you'll gain a lot of key notes from this book: Cocoa Design Patterns



http://en.wikipedia.org/wiki/Decorator_pattern
http://en.wikipedia.org/wiki/Builder_pattern
http://en.wikipedia.org/wiki/Factory_method_pattern

But to see the value in these patterns, it's necessary to consider the alternatives and Anti-Patterns, and even make some real world mistakes...

Decorator Pattern
https://github.com/mrdavenz/DVDecorator
For those without git, the Decorator Pattern code is copy and paste-able at the bottom of this post.

Builder Pattern
https://github.com/mrdavenz/DVBuilder

Here is a decent enough UML diagram of the Builder Pattern (Found here http://www.dofactory.com/Patterns/PatternBuilder.aspx)

Also a pretty good description is found here: http://www.codeproject.com/KB/architecture/Builder_Design_Pattern.aspx

In the source example, you have a Shop (Director), which has a suite of Custom Builders available, they can be interchanged at run time. If the user asks for a Motorcycle, the Shop owner can simply tell the code to build one using the Builder, and the custom attributes for a motorbike are built.

Without the builder pattern, a developer would simply have more code, and a higher dependence, which over time can reduce readability and discourage the reuse of the code.

So depending on the context, the benefits of the Builder pattern are subtle, but worth using when applicable.

Also don't confuse Builder with Factory:
http://en.wikipedia.org/wiki/Factory_method_pattern

Factory Method
https://github.com/mrdavenz/DVFactoryMethod

The Factory pattern can almost be seen as a simplified version of the Builder pattern.

In the Factory pattern, the factory is in charge of creating various subtypes of an object depending on the needs.

The user of a factory method doesn't need to know the exact subtype of that object. An example of a factory method createCar might return a Ford or a Honda typed object.

In the Builder pattern, different subtypes are also created by a builder method, but the composition of the objects might differ within the same subclass.

To continue the car example you might have a createCar builder method which creates a Honda-typed object with a 4 cylinder engine, or a Honda-typed object with 6 cylinders. The builder pattern allows for this finer granularity.
Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Prototype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed.
Sometimes creational patterns are complementary: Builder can use one of the other patterns to implement which components get built. Abstract Factory, Builder, and Prototype can use Singleton in their implementations.

A great comparison on stackoverflow found here:

what-is-the-difference-between-builder-design-pattern-and-factory-design-pattern

The Builder class is often used to build complex objects step by step, perhaps ordering matters. And is frequently used in conjunction with the Composite pattern, http://en.wikipedia.org/wiki/Composite_pattern, the common composite example in Cocoa UIKit is the use of UIView, where UIView has can have many subViews, that all have a common set of attributes, such as the Frame Size.

In iOS this pattern is analogous to the

Further reading:

builder-vs-decorator-pattern

#import 

@interface Car : NSObject

- (NSString *) getDescription;
- (double) getPrice;

@end

#import "Car.h"

@implementation Car

- (id)init
{
    self = [super init];
    if (self) {
        // Initialization code here.
    }
    
    return self;
}

- (NSString *) getDescription{
    return @"Car";
}

- (double) getPrice{
    return 99999.0;
}

@end

#import "Car.h"

@interface FamilyCar : Car{
    
@private
    Car *car;
}

- (id)initWithCar : (Car *) theCar;

@property (assign) Car *car;

@end

#import "FamilyCar.h"

@implementation FamilyCar

@synthesize car;

- (id)initWithCar : (Car *) theCar{
    self = [super init];
    if (self) {
        // Initialization code here.
        self.car = theCar;
    }
    
    return self;
}

- (NSString *) getDescription{

    return [NSString stringWithFormat: @"%@::FamilyCar", self.car.getDescription];
}

- (double) getPrice{

    return  (self.car.getPrice + (self.car.getPrice * 0.1));
}

@end

#import "Car.h"

@interface Sunroof : Car{

@private
    Car *car;
}

- (id)initWithCar : (Car *) theCar;
- (NSString *) getDescription;
- (double) getPrice;

@property (assign) Car *car;

@end

#import "Sunroof.h"

#pragma mark -
#pragma mark Private Methods go here.

@interface Sunroof()

@end

#pragma mark -
#pragma mark Implementation

@implementation Sunroof

@synthesize car;

- (id)initWithCar : (Car *) theCar{
    self = [super init];
    if (self) {
        self.car = theCar;
    }
    
    return self;
}

- (NSString *) getDescription{
    
    return [NSString stringWithFormat: @"%@::Sunroof", self.car.getDescription];
}

- (double) getPrice{
    
    return  (self.car.getPrice + (self.car.getPrice * 0.2));
}

@end

#import "Car.h"

@interface Airbag : Car{
    
@private
    Car *car;
}

@property (assign) Car *car;

- (id)initWithCar : (Car *) theCar;
- (NSString *) getDescription;
- (double) getPrice;

@end

#import "Airbag.h"

@implementation Airbag

@synthesize car;

- (id)initWithCar : (Car *) theCar{
    self = [super init];
    if (self) {

        self.car = theCar;
    }
    return self;
}

- (NSString *) getDescription{
    
    return [NSString stringWithFormat: @"%@::Airbags", self.car.getDescription];
}

- (double) getPrice{

    return  (self.car.getPrice + 220.0);
}

@end

I chose to test the code in my App Delegate didFinishLaunchingWithOptions method:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    // Override point for customization after application launch.
    
    Car *standardCar = [[Car alloc] init];
    
    NSLog(@"standardCar: %@ for $%.2f", standardCar.description, standardCar.getPrice);
    
    Car *carWithAirbags = [[Airbag alloc] initWithCar : standardCar];
    
    NSLog(@"carWithAirbags: %@ for $%.2f", carWithAirbags.description, carWithAirbags.getPrice);
    
    Car *carWithEverythingElse = [[Sunroof alloc] initWithCar : [[FamilyCar alloc] initWithCar: carWithAirbags]];
    
    NSLog(@"carWithEverythingElse: %@ for $%.2f", carWithEverythingElse.description, carWithEverythingElse.getPrice);
     
    self.window.rootViewController = self.viewController;
    [self.window makeKeyAndVisible];
    
    return YES;
}

This example was inspired from the Java implementation here : http://java.dzone.com/articles/design-patterns-revisited-2-de

For some further language agnostic discussion on the matter read here:
http://stackoverflow.com/questions/4768349/builder-vs-decorator-pattern