Language Abstraction – Many MEAPs have their own language that claim to be similar to Java or a flavor of JavaScript. Even if it is the same language, there is always something new to learn. Also, developers tend to shy away from learning any language that’s vendor specific (APEX on Force.com anyone? ;–)

Language Limitations – When you create a language that abstracts other languages you always end up serving only the lowest common denominator. Often there are ways of coding styles and nuances supported in the native language that the MEAP won’t expose because it’s not on other platforms.

Platform Limitations – Time has shown that platform abstraction doesn’t work (do a search on Wikipedia for cross platform RAD tools if you don’t believe me). Also, platforms change quickly. What happens if/when the next version of iOS is released? You have to wait for your MEAP vendor to catchup before you can use any of the features.

UI Limitations – Following on from the previous point, many of the controls that MEAPs offer also follow the lowest common denominator rule. For example, Cocoa Touch has a neat feature called a “Half Page Curl Transition”. If you abstract your UI to a MEAP vendor, how is this supported on other platforms? Either a) it’s not (so by default you can’t use it on iOS), b) you can only use it on iOS (which breaks the promise of a MEAP) or c) it’s implemented as a hack job on all platforms.

Tooling – MEAP tooling is often Web based, or bundled as an Eclipse add-on – but in both cases it often doesn’t fit in with the other tools that developers use today (e.g. ALM, refactoring, unit testing, etc.). Also, many of the MEAP vendors seem to be aiming their toolsets towards business analysts. When are we going to let this one go? Business analysts have an important role to play in teams, but they shouldn’t be developing UI, and they shouldn’t be writing code.

Debugging – Let’s say you create your application with a MEAP, and then it crashes 1 time in every 10 (i.e. one of those really nasty bugs to find). What are you going to do? a) Reach out to Apple? I suspect they won’t help you. b) Search the web for other people with the same issue? Could be difficult to find. c) Pay the MEAP vendor even more money to investigate your issue? Ah, that’s the one…

Data Abstraction – Many MEAPs offer connectors to databases, XML files, SAP, etc. Not only are these costly, but many are just pass-through connectors, so as a developer you don’t get any control over the connection. Want to implement synchronization? Want to change the formatting or query for better optimization? Probably not going to be possible.

Difficult to Extend – Many MEAPs don’t extend very easily. Found a new JavaScript library that you want to use in your application? How about a native control that you’d like to display? Could be tough. Some MEAPs do offer bridging to native code – but in which case, why not just write the whole thing in native code to start with?

Vendor Lock In – The sum of all the above leads to quite the definition of vendor lock in. Chances are by the time you deploy your first application you’ll be signed up with an expensive support and service agreement, with your developers working on code in a language that they’ll never be able to re-use, on a platform that won’t go anywhere.

I’ve extended this into a presentation that you can find below – which cover the above points in more detail, plus outline some general alternative approaches to creating applications without the dependency on a MEAP framework.

Based on other people’s experience with MEAPs, am I missing anything?

From these projects, I’ve come up with a list of tips, tricks, and recommendations that I wanted to share if you are looking to develop your own Mobile Web applications. Hope you find them useful…

Understand the differences between Mobile Web and hybrid applications

It’s important to make an early decision on whether your application is going to be pure Mobile Web (the user accesses it through the browser on the device) or hybrid (the user launches an application with an embedded control to display web based content). The decision to use the mobile browser or to have a dedicated hybrid application will likely be determined by the functionality the application requires. For example, obtaining the GPS location from the device can be performed perfectly well inside the browser, but accessing the camera from a Web page needs a hybrid application to provide the functionality.

In my experience there are three common features that drive developers towards a hybrid application: 1. Access to the camera. 2. Access to local contacts on the device. 3. Deployment to the AppStore/Marketplace. The first two are to overcome limitations of what can and can’t be accessed through the mobile browser (and is something that Mozilla is trying to tackle through WebAPI). The latter one is probably the most important to understand however – as while a hybrid solution will enable the application to be published to the app stores, extreme care needs to be taken to ensure that the application will not be rejected. This is most common with applications destined for Apple’s AppStore (if Apple view your application as a single container for web content with no apparent native functionality, they will more than likely reject it).

If you do take the hybrid approach, you really have two options to build the application – you can either set out and build a native application, embed a WebView control and then hook different events to create your own bridge between the two. This can be very useful if you only have a small piece of Web functionality that you need to embed in your application. Alternatively, you can consider using a framework such as PhoneGap (now known as Apache Cordova). Using Cordova is not without it’s challenges (for example, with cross domain scripting and client side certificate authentication), but it can definitely give you a head start especially if the majority of your application is going to be based on mobile web content.

Setup a robust development and testing environment

Setting up a robust development environment might be viewed as obvious for most of us, but tools for developing Mobile Web applications are still relatively immature, so it’s an important area to get right before you start your first app. In the most basic setup, you are going to need three things to be successful:

The first is a great IDE for HTML development. You’ve probably got your favorite already, but a strong IDE with as much JavaScript code completion support as possible will be your friend. Personally, I switch between TextMate, Visual Studio 2010, and WebStorm depending on which platform I’m working with. It’s also interested to see where Adobe are headed with their toolset.

Secondly, you are going to need a browser capable of inspecting the DOM and doing JavaScript debugging. Personally, I use Safari for doing this, but Chrome and/or IE9 will equally provide you the tools that you need. The important thing here is not so much the choice of the browser, but the understanding of how to breakpoint JavaScript code and inspect elements both on and off the page.

Finally, you’ll need some kind of device, or device emulator. Switching the user agent on a desktop browser will only get you so far, and eventually you are going to need to test on something representative of the device that the user will be using. If you are developing an application that will be primarily used on iOS devices, I would certainly recommend a Mac (as the iOS simulator is very robust). If a Mac doesn’t float your boat as your development machine however you could consider a hosted solution such as MacinCloud or simply do all your debugging using an iPod touch. There are a few PC based utilities that claim to emulate mobile safari/iOS, but I’ve had a poor experience with all of them.

For Android, I tend to avoid the emulator whenever possible (it’s a resource hog) and instead have a selection of devices that I can use for debugging on the fly. I’ve found that the key for Android testing is to have a selection of devices with preferably different resolutions and running different versions of the OS (e.g. a separate device running 2.1, 2.2, 2.3, and 4.0 should cover most of the current market, unless you have a need to go back to 1.6 for some reason). If you don’t have access to physical handsets, you may want to consider one of the testing providers such as Perfecto Mobile. They have a variety of devices that you can rent, covering many different platforms.

Use client side JavaScript instead of server side scripting

If you’ve been developing Web applications for some time, especially enterprise facing applications, you’ll be used to having a lot of the presentation and application logic tied up in server side scripts, maybe running server-side ASP, ASP.NET, JSP, PHP, etc. When developing Mobile Web applications however, things need to change. While server-side scripting will of course still work for a mobile application (and might be very tempting as you start to write your first application), it quickly creates a tight coupling between your device and the server. In the old days where you were accessing the server from a desktop browser on the same network, this wasn’t a problem – but once you move the experience to a mobile device with a potentially patchy network connection, the last thing you want to be doing is relying on the server side for generation of pages and views. If your mobile web application needs to do a roundtrip to the server when you hit the “Next Page” button, you’re going to be heading for a world of hurt.

The answer is to move as much (if not all) of the application logic to client-side JavaScript. This might be a painful exercise as you translate the move from an MVC server side framework to handcrafting page navigation using client side JavaScript, but the pay off will be worth it. If you have all of the application logic locally, together with pre-fetching as many of the pages into the DOM when your application first loads, you effectively disconnect yourself from the server side which makes performance much better and also moving to offline much easier. Of course, you still want to communicate with the server side – who doesn’t? – but this should be done via a set of asynchronous REST/JSON calls to bring data into the application rather than relying on the server to generate HTML for your application.

Design for running offline

Related to the previous point, you should also start thinking about how your application could run offline, even if you have no plans to do so. This will put you on a good architectural path, and will also mean that your application will work if and when network connectivity is lost. There are plenty of articles explaining how to enable offline access in HTML5 applications, so I won’t plan to cover here – other than to say you’ll be creating a cache manifest for your application, specifying the files to go into your cache, enabling the scripts for checking the cache when your application starts, and handling control logic accordingly (e.g. when you hit that submit button, you’ll want to know whether there is network connectivity before making the call to the server!).

If there’s one piece of advice that I can offer here however (and we learned this the hard way) it is to design for offline first, but implement last. Do all of the right things to support offline in your application, but don’t enable it until you are close to the end of your development cycle. If you enable it too early, it can cause mayhem with the development team – as your developers could end up debugging against a version of the application that could be slightly older – or the cache doesn’t get refreshed in the way it should. This doesn’t application to local storage – this is fine to access during development – I would just recommend not enabling the cache manifest until you go into UAT.

Select the right UI framework for your needs

Almost every other day there seems to be a new HTML UI framework released, and mobile frameworks are no exception. At Neudesic we’ve had most experience and success using jQuery Mobile, but have equally done work using Sencha, Dojo and others. As all the frameworks offer slightly different combinations of controls, I’ve found one of the tricks for selecting a suitable framework is to first build out a list of the controls that you are likely to need. For example, in one project we developed a set of paper prototypes (side note – I really dig UI Stencils for this) and realized that we would be creating a multi-tabbed application, with many lists on each page. Knowing what controls we were likely to use ahead of time made selecting the framework easier, and also put into perspective what controls we would have to build from scratch.

The good news is that most of the frameworks have demo pages/sites available, so that you can check them out beforehand without having to download anything. This can be a great way of testing the controls across a different number of devices, as well as getting a feel for the performance. My rough order of magnitude is that HTML based mobile UI will feel around 85% of a native control – it will look similar, react similar, but you just know that there’s this 10 – 15% gap that doesn’t quite feel native.

Understand the caveats with implementing maps in Mobile Web applications

Related to the last point, many applications have a need to display maps and pinpoints, and this will likely remain true for many mobile web applications that you might be creating. Based on experience, there are a couple of caveats that need to be understood before you head down this path.

Firstly, performance on Mobile Web map controls is not to par with native controls. Using Google Maps in Safari on iOS seems sluggish when comparing it to using MapKit in a native iOS application. I’m not sure what optimizations have been done in MapKit to give it the performance it has, but the difference is quite noticeable. As a result, if your application has a fundamental need to do a lot of mapping (i.e. if this is it’s primary function) you may want to consider a hybrid approach where you navigate to native pages for the mapping as part of your application.

Secondly, the web control for Google Maps (and this probably applies to other mapping controls) likes to “own” the page – which can put it into conflict with UI frameworks such as jQuery Mobile. For example, when you change pages in jQuery Mobile, the DIV element of your current page is set to hidden, and the DIV element of the new page to block. If your map control is embedded on a page that gets set to hidden this can cause Google maps to have a hard time. We’ve experienced random behavior such as the map control not updating or repainting correctly when it is brought back into focus. This can be overcome by an event on the page load to refresh the map canvas (example below), but it’s one of those bugs that takes a lot longer to find than it does to fix.

$(‘#mappage’).live(‘pageshow’, function() { google.maps.event.trigger(map, ‘resize’); });

Think ahead for non-standard UI elements you are likely to need

While frameworks such as jQuery Mobile will provide standard controls such as buttons, lists, labels, and radio boxes, your application will likely have a need for elements and controls that are non-standard. These can include tables, grids, and image carousels to name a few. Many of these can be created using custom controls, but before going down that path, I always try and ask myself two questions:

Firstly, if the control does not exist, does that mean a better UI nuance is available for the device? For example, there are few mobile web controls for displaying datagrids on mobile devices. Rather than force-fitting a solution that might not work well on a 3.2″ screen, think about what alternative solutions could be used instead. For example, maybe a series of cascading list controls would actually provide for a better user experience over some custom hacked-together table control. When in doubt, try to look at how other mobile applications have used controls to represent a similar data set.

Secondly, if the control does seem to fit, but it’s just not included in the standard UI framework that you’ve chosen, think about searching for a third party solution before re-creating something new. This can apply to image carousels (PhotoSwipe is one of my favorite controls for doing this) as well as charting (there are several really good JS based charting controls out there).

Make your mobile web app look and feel like it belongs with native applications.

Why not go that extra step and have your mobile application look like it belongs with other native applications on the device? A couple of small recommendations for this one:

Firstly, never show the address bar in your mobile application. Simply use a <viewport…/> tag to have your application run in full screen mode. The user will still be able to get to the address bar, but it will be hidden from view by default. (side note – jQuery Mobile now performs this automatically without the need to do “scroll to” events in JavaScript).

Secondly, if you are targeting iOS devices, consider using Cubiq’s AddToHome JS library. This is an excellent add on that will display instructions for the user to add the application to the iOS home screen, enabling the application to have it’s own icon and run completely full screen when launched.

Don’t go creating your own username and password database

Have users sign on to your application can be very useful for security of the application and for storing preferences and other settings. Unless you have a very strong reason however, I recommend that you avoid creating your own username and password database for your application. Doing so can seem really easy at first, but as your application gets more popular you’ll be left with a nightmare situation of having to deal with registration issues, password resets, and all of the other administration that comes with owning your own identity provider.

If you are building a mobile web application for the enterprise, I suspect you’ll already be thinking about this – either hooking in to an existing Active Directory instance or other identity provider (although you’ll likely need to consider how this will work outside the firewall when your mobile users are accessing your application via a public connection).

If you are building a public-facing application however, an efficient solution can be to federate with an existing identity provider. Chances are your users already have a Google, Yahoo, or Facebook account. Why not take advantage of this and use this sign-in information to authenticate the user for your application? This can be done in a couple of different ways – either with a native SDK from one of the providers – or using a federated service such as Microsoft Azure’s Access Control Service. This is a simple service to setup, which will enable you to configure a list of providers and returns a bag of claims to your application which you can use to match up with a list of settings, preferences, etc. There are a few caveats with this approach, especially as some of the providers return the information via a post back (which can really upset your mobile application if you’ve pre-fetched all of the pages in to the DOM beforehand). This is something that I’ve written previously about in this post.

Make your Mobile Web application perform well

It might sound obvious, but if you want your Mobile Web application to come anywhere near to the performance of a native application, you’ll want to keep a keen eye on performance. Generally, I’ve found there are three main causes of bad performance in Mobile Web applications:

First is server-side generation of the UI and round tripping (as discussed in the point on client-side JavaScript earlier). If you are generating any of the UI on the server-side or making any synchronous server-side calls, you are more than likely to run in to trouble.

Second is too many CSS effects/transitions. Many of the UI frameworks, including jQuery Mobile, include several page transitions for when the user navigates between different pages. Unless you are exclusively targeting iOS devices, I would recommend turning all of these off. Many of the older Android devices don’t implement a version of Webkit that supports hardware acceleration – plus they are running on less capable hardware – so to avoid creating an application that stutters on Android devices, it’s best to disable any transitions and effects.

Finally, watch out for too many registered JavaScript events (especially on the class level). The JavaScript performance on mobile browsers can be much lower than desktop equivalents, and if you are not careful you can end up where the performance of the browser is being compromised by too many registered events. Often this will only add 100ms to various events, but combine this with specific events (such as a button tap) that must immediately navigate to another page, any delay over 100ms might be enough that your user thinks that the button wasn’t pressed correctly. They’ll press it again, and before you know it you have two JavaScript navigation events that you’ll need to handle.

Wrapping up

A bit of a lengthy post, but I hope that this is useful if you are heading down the path of developing Mobile Web applications. If you’d like more information on this, or maybe to share with colleagues, I’ve uploaded this presentation to SlideShare that goes through the above list in some detail.

If the answer to the above is yes, we’d love to hear from you. We are looking for developers with mobile experience in all regions of the US. Developers that can work 1:1 with clients to help design, develop, and deliver innovative mobile applications across all platforms, with the following skills and experience:

• At least 7 years of experience in software development, with at least the last 2 involved in mobile application development.
• Core competency in developing applications for one primary mobile platform – either iOS, Android, Windows Phone 7, or Mobile Web (jQuery Mobile) – with a knowledge and understanding of the other mobile platforms.
• Strong customer facing and presentation skills – ability to lead a mobile software development project with minimal direct supervision.
• Knowledge of enterprise application development on the Microsoft platform (WCF, XML Web Services, SQL Server, .NET Framework, IIS).
• Experience of working in an agile environment, working with a team against an active product backlog, following TDD (Test Driven Development) approaches, and committing to daily scrums and weekly sprint reviews with customers.

In return, you’ll get to work on projects with some of the smartest people in the industry, using the latest mobile technologies and tools that push your skills and knowledge to the limit. You’ll do this in a working environment that you control – you dictate how best to structure your work to get the job done. You’ll also have the opportunity to shine as a thought leader in the community – many of us at Neudesic at MVPs, RDs, speakers, and authors.

Want to learn more? Contact me directly at simon/dot/guest/at/neudesic/dot/com

I was recently asked whether it’s possible to extract an OAuth token as part of the ACS sign in process that can then be presented to Facebook’s Graph API in order to access details such as friends lists, photos, etc. In this post, I’ll cover how this can be done.

The first step is of course to display the authentication page. As you’ve seen in previous posts, this can be achieved using the following:

WACloudAccessControlClient *acsClient = [WACloudAccessControlClient accessControlClientForNamespace:@“iostest-walkthrough” realm:@“uri:wazmobiletoolkit”];

[acsClient showInViewController:self allowsClose:NO withCompletionHandler:^(BOOL authenticated) { if (!authenticated) { NSLog(@"Error authenticating"); } else { WACloudAccessToken *token = [WACloudAccessControlClient sharedToken]; NSString *securityToken = [token securityToken]; ... }
}];

In the application, this will display the federated login dialog, and prompt the user to enter their Facebook credentials.

You’ll notice that the ACS client returns a cloud access token, of which a security token can be extracted. This security token is a set of claims returned from ACS. Here’s an example:

http://schemas.microsoft.com/ws/2008/06/identity/claims/expiration=2011-11-11T22:00:00.3593475Z&http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress=me%40simonguest.com&http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name=Simon+Guest&http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier=677830765&http://www.facebook.com/claims/AccessToken=AAADWLwgHWSUBABBXdxbhJB0ZBtA3VOfPSsqzKKwObAtW2rb8EGGTQ8EvnvAdNOcZAGpKfV2gSGbNg7f0gxk4BhI1rhzKEn17VLw343gZDZD&http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider=Facebook-235497486506277&Audience=uri:wazmobiletoolkit&ExpiresOn=1321044986&Issuer=https://iostest-walkthrough.accesscontrol.windows.net/&HMACSHA256=bnvyPmX4/PcWhiImgVVIvSqwHpc4cfi0vI6%2b/BSDK0Q%3d

If we want to make follow on calls to Facebook’s Graph API, we are going to need to present the Facebook User ID and an OAuth Token. Fortunately both of these can be extracted from the token.

To extract this, we first HTTP encode the token:

NSMutableArray *httpEncoding = [NSMutableArray arrayWithObjects:[NSArray arrayWithObjects:@"%3a",@":",nil], [NSArray arrayWithObjects:@"%2f",@"/",nil], nil]; 

while ([httpEncoding count] >= 1) { securityToken = [securityToken stringByReplacingOccurrencesOfString:[[httpEncoding objectAtIndex:0] objectAtIndex:0] withString:[[httpEncoding objectAtIndex:0] objectAtIndex:1]]; [httpEncoding removeObjectAtIndex:0]; }

NSError *error = NULL;

Using a simple RegEx search we can extract the Facebook User ID:

NSRegularExpression regex = [NSRegularExpression regularExpressionWithPattern:@“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier=([0-9])” options:0 error:&error];
NSTextCheckingResult *match = [regex firstMatchInString:securityToken options:0 range:NSMakeRange(0, [securityToken length])]; firstRange = [match rangeAtIndex:1]; fbuserId = [securityToken substringWithRange:firstRange];

And the required OAuthToken:

regex = [NSRegularExpression regularExpressionWithPattern:@“http://www.facebook.com/claims/AccessToken=([A-Za-z0-9]*)” options:0 error:&error];

match = [regex firstMatchInString:securityToken options:0 range:NSMakeRange(0, [securityToken length])];
NSRange firstRange = [match rangeAtIndex:1];
oauthToken = [securityToken substringWithRange:firstRange];

Now it’s just a case of calling the Graph API using these credentials:

NSString *graphURL = [NSString stringWithFormat:@“https://graph.facebook.com/%@/friends?access_token=%@”,fbuserId,oauthToken];

For the purposes of this post, let’s take a quick look at my list of friends.

NSURLRequest *request = [NSURLRequest requestWithURL:[NSURL URLWithString:graphURL]];
NSURLResponse *response = NULL;
NSData *data = [NSURLConnection sendSynchronousRequest:request returningResponse:&response error:&error];
NSString *friendsList = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];
regex = [NSRegularExpression regularExpressionWithPattern:@“id” options:0 error:&error];
NSUInteger friendCount = [regex numberOfMatchesInString:friendsList options:0 range:NSMakeRange(0, [friendsList length])];

Displaying the friend count in a UIAlertView on the screen shows how popular (or not!) I am:

A simple example, but hopefully this shows not only that you can authenticate against Facebook using AppFabric ACS, but also how the returned Facebook User ID and OAuth Token can be used to make further calls to Facebook using the user’s credentials.

1. Create a new Android project called AzureLibrary, set the target to Android 2.3.3, use com.microsoft.cloud.android as the package name, but do not create an activity or test project.

1. Right click on the AzureLibrary project and select Import. Choose General / File System as the import source, and click on Next.
2. Browse to the /library/src/com folder in the toolkit folder that you downloaded from GitHub.
3. Click on the Browse (into folder) button and select the src folder under your project. Expand the src folder, and check the com folder as shown in this screenshot:

1. Click on the Finish button. The import will complete.

1. Right click on the project, select properties, and change the Java compiler version from 1.5 to 1.6. (The default is 1.5, yet the toolkit uses many constructs only supported in 1.6)

1. Click OK, and say yes to rebuilding the project. The project should now build with no errors.
2. Assuming everything builds correctly, right click on the project, and select Properties again. Go to the Android setting, and click on the Is Library check box.

Setting Up the Sample Application in Eclipse

To import and build the sample application in Eclipse, perform the following steps:

1. Create a new Android project called AzureSample. Select Android 2.3.3, set the namespace to com.windowsazure.samples.sample, and choose not to create an activity.

1. As you did with the library, right click on the project, and select Import. Select the /samples/simple/src as the source and import into the AzureSample/src folder.

1. Right click on the project, select Properties, select Android and add a reference to the AzureLibrary project:

1. Right click on the project, select Import. Import from the /samples/simple/res folder into the AzureSample/res folder. This will import the resources required for the sample application.

Answer yes when prompted to overwrite the main.xml file.

1. Right click on project, select Import and select the file system again. Select the AndroidManifest.xml from the root of the source directory and import into the root of the destination project.

The Sample project should now build with no errors.

Configuring your Windows Azure Account Name and Key

In order to setup the sample project, you need to supply your account name and key, as provided by Windows Azure. You can obtain this by logging into the Windows Azure Portal (http://windows.azure.com) and navigating to Storage Accounts to obtain the details.

When you have the name and key, perform the following:

1. In the sample project, open ProxySelector.java from the src/com.windowsazure.samples.sample package.
2. At the top of the file replace the ACCOUNT and ACCESS_KEY values with the account name and access key for your Azure storage account.

Running the Sample

1. To run the sample, right click on the sample project, select Run As / Android Application.

1. Once the emulator is up and running, unlock the device.
2. Refer to the LogCat/Console window in Eclipse if there are any errors.
3. Click on the Start button in the sample application.
4. Select either table, blob, or queue storage and browse the storage associated with your Windows Azure account.

That’s it! Your sample application is now up and running, and you are able to browse Windows Azure storage!

Before you begin, you’ll need a few things:

1.  A Windows Phone 7 device with all of the current updates (a.k.a. NoDo) installed.  Double check the updates in the Zune application to make sure everything is up to date.  You should see that your WP7 build number is 7390.

2.  Zune Software 4.7.1404.  Although 4.8 was released yesterday, you won’t be able to do the update with this version (yet).  Download 4.7.1404 from here if needed.

3.  Windows Phone 7 Support Tools.  You can download this from here (32bit, 64bit).  Run the installer, but you don’t need to run the application.

4.  Enough battery power to get you through several updates (when the phone is updating, your device isn’t being charged).  I would avoid trying this with anything less than 50% charge.

5.  The mango update tools.  If you are a registered Windows Phone 7 developer, you can supposedly download these from the Microsoft Connect site.  If you are not (or like me you are, but couldn’t find the tools on Connect), you can find a version of the tools on this site.  (Note:  Follow Step 1, and yes, you have to wait for 45 seconds for the download link to work).

With all of the above in place, run the Update.bat from the Mango update tool download.  Assuming there are no errors, you should see something similar to the following.

Firstly, the tool will make a backup of your device to the c:\PreMangoState2 directory, and install the updates necessary for your device to receive the pre-release Mango bits.  The time this will take may vary, but on my machine it took 112 seconds to backup, and 70 seconds to update the device.

Once the batch file completes, and the device reboots, the Zune software should automatically launch.  You’ll be shown that an update is available (likely build 7403).

Choose to install this, which will then download the Zune 4.8 software.  After the Zune software has been updated, the phone will be updated to 7403, which should be a fairly quick update.

As the phone reboots once more, the Zune software will do another check – and this time will pick up the 7712 build, which is Mango RC.  Choose to download and install this one.  This is where the battery power is important, as this install can take quite a bit of time to complete (let’s just say that I’ve been able to pen this blog post, and it’s still not 75% of the way there!).

Be patient though – one final reboot, and you’ll be running the latest Mango RC (Build 7712) bits!  Enjoy!

Having implemented this a couple of times now, here is a rough guide of how to integrate AppFabric ACS (Access Control Service) authentication into a jQueryMobile application. (There is already a ton of documentation of both jQueryMobile and ACS, so I’m assuming that you understand the basics of how these both work).   

Step 1:  Create your own provider selection screen

When you first start playing around with using ACS on mobile web browsers, the first thing you’ll notice is that the default login page isn’t that nice. 

While the functionality of logging in will work, users have to pinch zoom to be able to read the buttons, which isn’t a great experience.  It also doesn’t fit in with any jQueryMobile theme that you may have created.  To overcome this, we can create our own provider screen. 

To build something similar to the above, I’ve used a jQueryMobile Dialog (which has an automatic border as well as a background effect).  The basic code for the screen looks like the following:

<!DOCTYPE html>
<html>
<head>
    <title>Select Login Provider</title>
</head>
<body>
    <div data-role="dialog">
        <div data-role="header">
            <h1>Select Login Provider</h1>
        </div>
        <div data-role="content">
            @{
                if (ViewBag.JSONProviders != null)
                    {
                    var providers = Json.Decode(ViewBag.JSONProviders);
                    foreach (var provider in providers)
                    {
                        <button type="button" onclick="javascript:window.location.href='@provider.LoginUrl'">@provider.Name</button>
                    }
                }
            }
        </div>
    </div>
</body>
</html>

As you can see from the above, the form is built by parsing a JSON object containing a list of identity providers and creating buttons for each provider – setting a name for a button and setting an on click action to the URL.  (The above code uses the Razor-based syntax for  ASP.NET MVC, but the same will work just by using JSON calls in regular Javascript). 

Two things to note here:

1.  It’s really important to use window.location.href instead of an <a> anchor when linking to the provider – otherwise you’ll break the AJAX model of your jQueryMobile app and a new browser window will be launched (which looks horrible, especially in full screen web applications).

2.  You are probably asking yourself where the JSON objects actually come from.  This brings us to our next point…

Step 2:  Make a call to the ACS JSON endpoint

The buttons in the form are based on identity providers, which you likely setup when you configured ACS.  These providers can be extracted as JSON objects using a JSON based endpoint that the ACS service providers. 

Here’s the URL of the JSON endpoint for ACS v2.

https://{0}.accesscontrol.windows.net/v2/metadata/IdentityProviders.js?protocol=wsfederation&realm={1}&reply_to={2}&context=&request_id=&version=1.0

{0} is the namespace of your ACS service

{1} is the realm within your ACS service

{2} is an optional URL (which must be HTML encoded) that specifies where to return the browser once authentication has been completed.  Remember, if you are using AJAX navigation, then you’ll want to pass in the correct #-prefixed syntax.  For example a return URL of the following:

http://localhost/MyWebApp#/MyWebApp/Accounts

Will instruct the ACS service to return to the Accounts page in your jQueryMobile app.

Again, you can make the call to the JSON endpoint using Javascript, or if you are using ASP.NET MVC like in Step 1 I would recommend creating a controller action called Providers which passes the return JSON object in a ViewBag. 

Step 3:  Launch the providers screen from your app

Finally, once you have your provider screen created, you’ll need to call it when authentication is required.  There are a couple of different ways of doing this – if you are using Javascript only, then create and maintain a variable called claims – which corresponds to the claims bag returned from the service (when the ACS service returns it does a post back to your application so that you can capture the claims).  Secondly, if you are using ASP.NET MVC then you can create a second action on the Account controller called claims with something similar to the following:

public JsonResult Claims()
  {

    return Json(string.Join("n", ((IClaimsIdentity)this.User.Identity).Claims.Select(c => c.ClaimType + ": " + c.Value).ToArray()));

}

This will return the claims bag directly from the User.Identity property from the controller.

Well, just a short overview, but if you are thinking of implementing Google and Facebook authentication in your jQueryMobile application, hopefully this has been of some help.

First, some background…

Many iPhone and iPad applications have a need to authenticate.  Maybe it’s to access sensitive information or record a particular high score against your name.  Implementing an authentication scheme for iOS can however be time consuming and tricky – you often have to create an authentication service, host it, expose the service through REST, and consume it on the device.  And afterwards you are responsible for backing up the user database and dealing with lost passwords, etc.

To help overcome this many applications are now turning to external providers.  For example, to identify yourself when playing Zynga Poker, instead of creating a new account, you simply sign into Facebook (when launching the application for the first time) and the game uses these credentials as you play. This type of sign in method is called federated identity. This prevents Zynga from having to maintain a complex and large set of user accounts and passwords, and also prevents the player from having to remember yet another username and password. 

Adding federated identity to your iPhone or iPad application can be difficult, requiring knowledge of exchange secure tokens with a set of providers, and creating and sending the right OAuth headers in your application.  Removing this difficultly is exactly what we are trying to address in v1.2 of the Windows Azure Toolkit for iOS. 

Sounds great – how do I use it?

To implement ACS in your application, you’ll first need to access the Windows Azure portal by navigating to http://windows.azure.com and signing in with your credentials.

Click on the Service Bus, Access Control & Caching menu item and select the Access Control menu item under the AppFabric folder.  Select an active Windows Azure subscription and click on the New button in the toolbar.

The new service namespace dialog will open.  Ensure that Access Control is selected, and enter a unique namespace and country/region for the service.

The ACS namespace will now be created.  This might take a few minutes.  Wait until the namespace is showing in an Active state.

Once this is complete, highlight the newly created service and click on the Access Control Service button in the toolbar.  This will launch the Access Control Service portal.

Within the portal, click on Identity Providers and add the identity providers you would like to use for your application.

The default is Windows Live ID, but you can add other preconfigured providers (such as Google and Yahoo!) as well as external identity systems configured to use WS-Federation.

Once you have added the required providers, click on the Relying Parties section of the portal.

Click on the Add button and enter the following information for the relying party application:

Name – a given name for your application

Realm – a unique ID for your application.  For this walkthrough, we’ll be using uri:wazmobiletoolkit

Return URL – you can leave this blank

Error URL – you can leave this blank

Token Format – select SWT

Token Lifetime – Feel free to change the default from 600 seconds.

Select the identity providers that you would like to use, and then under the Token Signing Settings section, click on the Generate button to create a new symmetric key that will be used for this application.

Finally, click on the Save button.  This will create the Relying Party Application.

Next, go into the Rule Groups section of the portal and select the default rule group that was created for the application.

Click on the Generate link in order to generate a set of default rules for this rule group.

Select the providers that you wish to use, and click on the Generate button.  Once this is complete, you should see a set of rules.

After this step is complete, ACS has now been configured correctly to be used with your iOS application.  Make a note of your Service Namespace (found at the top of the portal) and Realm.

Ok, the service is now setup.  How do I use it in my Xcode project?

To start, launch Xcode (4.02 or higher) and create a new project.

From the project template dialog, select a View-based application and click on the Next button.  Enter a Product Name and Company Identifier and click on the Next button to continue.  Select a directory to use for the project file and return to the IDE.

Next, download the latest version of the Windows Azure Toolkit for iOS library from http://github.com/microsoft-dpe/watoolkitios-lib. In the download will be a zip file containing two versions of the library (one for the device, one for the simulator) and some header files for the project.

Right click on your project and select the Add Files to… menu option.

Locate the .a file (for the simulator) and header files and add them to your project.  You may want to create a new group (called lib) to store these in.

Now we need to add a reference to a library required for XML parsing.  To do this, click on the top most project file, click on the target in the 2nd column of the IDE, and select Build Phases from the tab menu.

In the main window, expand the Link Binary with Libraries option.

Ensure that the libwatoolkitios.a file has been automatically added as a reference, click the + button to add a new library, and select the libxml2.dylib library from the drop down list.

Click on the Add button to add a reference to this library for your project.

Before we start adding any code, we need to add a couple of required linker flags to the project.  To do this, click on the Build Settings tab (next to Build Phases).

In the search box, type “other linker” to filter the settings.

You should see a setting called Other Linker Flags.  Double click on the right side of this row to add new flags.

Click on the + button to add two flags.  The first is –ObjC and the second is –all_load.  Once complete, your linker flags should look like the following screenshot:

Click on the Done button to save these settings.  The project is now configured correctly to reference the Windows Azure Toolkit library.

To test that the library works, click on the project’s [ProjectName]AppDelegate.m file.  Add the following #import statement at the top of the class:

#import "WACloudAccessControlClient.h"

Next, search for a method called didFinishLaunchingWithOptions and after the [self.window makeKeyAndVisible] line, enter the following code.

NSLog(@"Intializing the Access Control Client...");

WACloudAccessControlClient *acsClient = [WACloudAccessControlClient accessControlClientForNamespace:@"iostest-walkthrough" realm:@"uri:wazmobiletoolkit"];

[acsClient showInViewController:self.viewController allowsClose:NO withCompletionHandler:^(BOOL authenticated) {

if (!authenticated)

    {

NSLog(@"Error authenticating");

    }

else

    {

NSLog(@"Creating the authentication token...");

WACloudAccessToken *token = [WACloudAccessControlClient sharedToken];

/* Do something with the token here! */

    }

}];

Replace the namespace and realm in the first line with the service namespace and realm for your own service.

As you can see from the above, the code creates a new instance of the access control client, requests that the client shows itself in the current view controller, and then extracts a token.

Build and run the application in the iOS Simulator.

Once the application starts, you should be prompted to select an identity provider from the list that you configured in your ACS service.

Pick one of the providers, and enter a valid set of credentials.

Click on the Remember me checkbox if you want to skip this step when running this application again, and click on the Sign in button.

The first time the application is run, you’ll be prompted to authorize the application to access your provider data.

Click on the Allow button to continue.  The login window will now disappear and you’ll be returned to your application.

In the debug window, you should see the following two logs:

2011-07-22 10:12:26.284 iostest-walkthrough[25838:207] Intializing the Access Control Client…

2011-07-22 10:12:36.359 iostest-walkthrough[25838:207] Creating the authentication token…

If you are seeing this, congratulations!  You’ve successfully setup federated identity for your application.  The final message indicates that the access token was retrieved and can be used for further use.  The WACloudAccessToken (derived from [WACloudAccessControlClient sharedToken]) contains an NSDictionary of claims and other properties that can be stored within your application.  Using these properties on future calls can be used to identify returning users to your application.

You’ll be sad to hear that I don’t have a special version of Visual Studio for Mac OSX – instead I am using VMWare Fusion 3.1 to run a copy of Windows 7 in a virtual machine. Fusion has a mode called “Unity” which allows windows from the virtual machine to interact with windows on the host operating system (even to the point where I can put icons for Windows-based applications in the dock on the Mac). There is a little performance hit running applications in this way vs. a full screen virtual machine, but it’s certainly useful for presentations where you are flipping between both environments.