Top Reasons Developers Should Use Windows Azure Mobile Services

This article is also available on the RedBit Site

With the recent release of Social Cloud, I asked the RedBit team what are the top reasons for using Windows Azure Mobile Services and here is what we have.

Easy Third Party Authentication

Using the Identity feature of Azure Mobile Services allows developers to quick implement OAuth based authentication without having to worry about a lot of the plumbing code that is required when writing everything from scratch.

You can easily incorporate authentication with

  1. Microsoft Account
  2. Facebook
  3. Twitter
  4. Google

As a developer all you would have to do is

  1. Specify the keys in the portal
  2. Use the mobile SDK for iOS, Android, Windows 8, Windows Phone with application
  3. Authenticate via the SDK calling MobileServiceClient.LoginAsync()

Here is what it would look like from the dashboard to setup keysidentity

 

To learn more about this feature see Get Started With Authentication with Mobile Services

Data Storage

Most mobile apps written today need some form of data storage and usually the process is

  1. Figure out where to host it
  2. Figure out what type of database to use
  3. Write some REST APIs to access the data
  4. Make sure the APIs are secured

Using the data feature of Azure Mobile Services developers can quickly create data tables, secure the data tables for read/write operations and also write custom scripts to run when an insert, update, delete or read operation is performed on the data.

From the client side, using the SDK, you call the MobileServiceClient.GetTable<>() method and data will be retrieved.  If the data is secured via the portal settings, you will need to login using the client SDK before attempting to retrieve the data.

For more information see Get Started with Data in Mobile Services.

Client Libraries

Azure Mobile Services comes with clients libraries for the main mobile platforms available in the market today which are

  1. iOS
  2. Android
  3. Windows Phone 8
  4. Windows 8 (C# & JavaScript)
  5. Xamarin for iOS & Android

Leveraging this library and Azure Mobile Services on the back end, developers can focus on writing their app and not all the extra plumbing required for things such as authentication.

Custom APIs

The API feature is relatively new (as of Jun 24 2013) to Azure Mobile Services but allows developers to quick build APIs to the systems to be accessed by various client applications. You can quickly build out the APIs required by your app and just as quickly secure the APIs making sure only authenticated users have access to the APIs. Definitely something to use more often in the future!

Push Notifications

I’m a big fan of push notifications for mobile apps because it allows users to stay connected and engaged with their users. It’s also a great way to entice users to open your apps and this is especially useful if you are monetizing your apps with in app advertising.

Using Azure mobile Services, developers can quickly get this up and running on the various platforms such as iOS, Android, Windows Phone 8 and Windows 8 and it’s as easy as setting a few keys in your Azure Mobile Services Dashboard

push

Definitely something every developer should look at to keep their users engaged with their app.

For more information on how to get this running, see Get Started with Push Notifications in Mobile Services.

Overall, I think Windows Azure Mobile services really helps accelerate the development cycle and get your product to market faster. It allows you to focus on building out your product on not have to worry about server infrastructure or plumbing code required for things like authentication.  When you need to scale, it’s just a few clicks and you are ready to handle your extra load from your users.

So those are our top reasons for using Windows Azure Mobile Services. If you have used it, what are your top reasons? Ping me or the RedBit team on Twitter or leave a comment here.

Quick Tip: Getting Device ID on Windows & Windows Phone

When building out apps, there are some situations where you are required to get a unique ID of the device whether it be for analytic data or to potentially limit devices from accessing some private services.

This quick tip will show you how to get the device ID on different platforms such as Windows Phone 7, Windows Phone 8 and Windows 8.

Windows Phone 7

To get device ID on Windows Phone 7 you can use the following

private string m_DeviceUniqueId;
public string DeviceId
{
    get
    {
        if (m_DeviceUniqueId == null)
        {
            object val;
            if (Microsoft.Phone.Info.DeviceExtendedProperties.TryGetValue("DeviceUniqueId", out val))
                m_DeviceUniqueId = Convert.ToBase64String((val as byte[]));
        }
        return m_DeviceUniqueId;
    }
}

Windows Phone 8

Getting device ID on Windows Phone 8 is slightly different the the previous version and can be accomplished with the following

private string m_DeviceUniqueId;
public string DeviceId
{
    get
    {
        if (m_DeviceUniqueId == null)
        {
            m_DeviceUniqueId = Windows.Phone.System.Analytics.HostInformation.PublisherHostId;
        }
        return m_DeviceUniqueId;
    }
}

Windows 8

On Windows 8, it’s yet another API to get the device ID and can be accomplished with the following

private string m_DeviceUniqueId;
public string DeviceId
{
    get
    {
        if (m_DeviceUniqueId == null)
        {
            var token = Windows.System.Profile.HardwareIdentification.GetPackageSpecificToken(null);
            var hardwareId = token.Id;
            var dataReader = Windows.Storage.Streams.DataReader.FromBuffer(hardwareId);

            byte[] bytes = new byte[hardwareId.Length];
            dataReader.ReadBytes(bytes);

            m_DeviceUniqueId = BitConverter.ToString(bytes).Replace("-","");
        }
        return m_DeviceUniqueId;
    }
}

Gotchas

If you are using this code to get ID with your apps, be aware that the ID returned will be different in every app.  For example, if you have APP1 and APP2, APP1 may return 12345 as the device ID and APP2 may return 09876 as the device ID even though they are running on the same device.

Enjoy!

Getting Started With Windows Phone Development

Going to a lot of local events I always get asked “what do I have to do to get started to create an app on Windows Phone?”  I noticed I have never put together a getting started article so here it goes.

Basically, the only URL I give everyone is create.msdn.com which is App Hub.

Here developers will find everything they need to get started including tools and registration process to publish your apps.  The biggest shock to most people are that all tools are free so it costs you nothing to get started and the only cost is when you are ready to submit your application for certification into the Windows Phone Marketplace.  The cost is $100/yr for an AppHub membership similar to the Apple AppStore pricing.

There are also some targeted Microsoft programs that devs can take advantage of not just for Windows Phone but for all MSFT based software. Continue reading Getting Started With Windows Phone Development

Windows Phone End User Quick Tips

Many people using Windows Phone or new to it that I meet don’t know some of the ‘hidden features’ of Windows Phone that make the phone easier to use.  Now I’m talking about completely non-technical people who have decided to get a Windows Phone and I’m sure most regulars readers already know these tips.

Switching Apps (Multitasking)

First switching apps, not many know that you can easily switch between apps using how to easily switch between applications on the phone.  I tend to see people hit the back button over and over to get back to the app they were at or hit the start button to get to the start page.

Quick Tip #1: Hold down the back button and you will get a list of all apps that are currently running.  Scroll through the apps you want, click it and it will come back! If you are coming from iPhone world, it’s like double clicking on the main button to get a list of running apps but I find the Windows Phone experience much better. Check out the Windows Phone How-To on Switching apps. Here is a picture of what to expect:

Continue reading Windows Phone End User Quick Tips

Quick Tip: Theme Aware Icons

In a previous post I talked about how sometimes when selecting text when cutting and pasting on Windows Phone, the text might not be visible because the brushes where changed potentially leading to unreadable text.

Another issue I have encountered is when dealing with images.  Sometimes your design calls for adding metro style icons to your page instead of using the Application Bar which is fine, but as developers, we have to be aware that Windows Phone provides both Light and Dark backgrounds when a user customizes their Theme.  This can lead to some undesirable experiences for the user.

The Wrong Way
The first way most will go about and do it is by using an image on a button.  For example, lets say you have a button with an email icon on it as follows.

image

All looks good, but what happens when the user switches to the Light Background?  Using the Device Tab in Expression Blend, we can easily switch the background color and see that the icon is no longer visible.

image

Switching to Light results in the following

image

You’ll notice the button border is still visible, but our icon is not anymore.

How to fix?
The easiest way I find to fix this is by using paths.  With Expression Blend you can either create your own paths or import Adobe Illustrator or Photoshop files into your page.  If you like you can create the paths manually, but that can be a little of tedious process so the importing feature comes in handy!

image

So if we select the ‘email icon’ available, we will get the following path in XAML which essential translates to the email icon

<Path Data="F1M372.2549,480.7969L372.2549,470.1369L380.8289,476.8239C381.0519,476.9959,
381.3179,477.0819,381.5829,477.0819C381.8469,477.0819,382.1109,476.9959,382.3329,
476.8259L391.2659,469.9019L391.2659,480.7969z M390.6919,467.2499L381.5849,474.3089L372.5359,
467.2499z M392.4859,464.8029L371.0289,464.8029C370.3559,464.8029,369.8089,465.3499,
369.8089,466.0259L369.8089,482.0199C369.8089,482.6949,370.3559,483.2439,371.0289,
483.2439L392.4859,483.2439C393.1629,483.2439,393.7119,482.6949,393.7119,
482.0199L393.7119,466.0259C393.7119,465.3499,393.1629,464.8029,392.4859,464.8029"
Fill="Black" Height="18.441" Stretch="Fill" Width="23.903" HorizontalAlignment="Right"
Grid.Row="1" UseLayoutRounding="False" VerticalAlignment="Top"/>

So now to make the path visible in either theme, you will have to set the Fill Property of the path to PhoneForegroundBrush.

image

Add this path as the ‘Content’ of your button instead of the image, and when switching themes, the path will visible in either Light or Dark background color as follows

image

image

Why Bother?

For me there are two reasons to bother.  First one being user experience.  If your images disappear because of user settings, it’s not the best experience and doesn’t make for a professional looking app.  The second reason, your app may fail certification if this happens.  The Windows Phone Marketplace ingestion team does look at theme awareness making sure apps adhere to themes on the device.  We did fail one app once because of images disappearing (this is why I’m sharing this tip Smile) so make sure you test in both Light and Dark backgrounds.

Hopefully this tip helps you, moral of the story is test your application in both the Light and Dark backgrounds to bring that right user experience and hopefully not get stung by this on marketplace cert testing.

Windows Phone Developer Tip: Navigation Events and Tombstoning

computer-geek-gets-fitting-tombstone_1One of the developer features that I think all Windows Phone developers should be supporting is tombstoning.  If you are writing Windows Phone apps and are not supporting Tombstoning then please do just makes UX better which makes happy customers!  If you have not implemented tombstoning in your app, make sure you you read the Windows Phone Execution Model which has details on this.

So what is the tip?  First some background to give some context.  We built a picture viewer for one of our apps, and to conserve memory on the Page.OnNavigateFrom we dispose of a bunch of objects in the view model as we don’t want those lingering around.  Our primary concern was WriteableBitmaps.

The issue was we were cleaning up objects in the Page.OnNavigateFrom method and cleared our objects before we had a chance to save any state in the PhoneApplicationService.State.  This is because Page.OnNavigateFrom was called before the PhoneApplicationService.Deactived event was fired.  So to work around this we did the following

protected override void OnNavigatedFrom(System.Windows.Navigation.NavigationEventArgs e)
{
    if (!e.Uri.ToString().Equals("app://external/"))
    {
        //Clean up only if not tombstoning
    }
    base.OnNavigatedFrom(e);
}

This way our PhoneApplicationService.Deactived event handler can save any state required.

The key take away is the Uri your app navigates to when being tombstoned and that is “app://external/”  This is the Uri you need to look for to see if you are being tombstoned before cleaning up any view models or objects.

Again, this is relevant in the app we where building and the code above may not fit your scenario exactly.  But the “app://external/” Uri may be useful at some point when developing for Windows Phone!  And you get this Uri if you are using Windows Phone Mango or Nodo.