Getting to Know #Azure Mobile App

Microsoft Azure Mobile App has recently gone GA (General Availability) and has definitely captured my attention. Mobile App is a tremendous accelerator that enables us to go from an idea to a functional prototype quickly. Then, we can continue to build on that initial investment to create a robust production ready app. Finally, using Visual Studio Team Services and Release Management, we can publish our apps to our favorite app Stores.

Why Mobile App

These are reasons why you should consider Mobile App on your next project. They certainly contributed to my agility throughout my adventure.

• Build native and cross platform apps
• Connect to your enterprise systems
• Connect to SaaS APIs easily
• Build offline-ready apps with sync
• Push Notifications to millions in seconds
• Automatically scale-out to handle any incoming customer load.
• Build low friction server-side REST services.
• Benefit from a simplified data access layer.
• Deliver functional prototypes with minimal effort.

The Journey

For this Azure Mobile App exploration, I will be using ASP.NET to build the server-side services and I will use the Universal Windows Platform (UWP) to build the app.

Getting to Know UWP

A Universal Windows Platform (UWP) app allows you to take advantage of the unique capabilities of the device on which it is running. Your app can make use of all of the power of a desktop device, the natural interaction of direct manipulation on a tablet (including touch and pen input), the portability and convenience of mobile devices, and the collaborative power of Surface Hub.

Sébastien Lachance is passionate about building quality apps. So I turned to him for some advice. Being unfamiliar with app development, I needed a starting point. This is when he suggested that I look at the Template 10 Template Pack. It’s a library of helpers, services, and base classes for Universal Windows Platform (UWP) apps.

A Guide to Universal Windows Platform (UWP) Apps

• Introduction
• Device families
• UI and universal input
  • Universal controls and layout panels
  • Tooling
  • Adaptive scaling
  • Common input handling
• Writing code
• User experience
• Submit a Universal Windows app through your Dashboard

Building a Mobile App

The app I’m building is about helping me curate and share resources about Microsoft Azure. From the Template 10 projects listed below, I decided to use the Hamburger template as my starting point.

The app is called Ask Alex. Its sole purpose is to give you access to the content that I curate. The first step in my adventure is to give the app a personality. So Sébastien Lachance took my profile picture from Twitter and generated a whole bunch of assets for me.

To my surprise, app package requires specific Visual Assets. I had most of them, but I was still missing a few. Luckily, the Package Manifest editor is able to graphically identify missing assets.

I felt lucky, so I tried to build the app, and the compiler happily told me that I needed to provide the missing Visual Assets.

Error	Payload file 'C:\Source\Repos\askalexapp\AskAlex.App\Assets\LockScreenLogo.scale-200.png' does not exist.			
Error	Payload file 'C:\Source\Repos\askalexapp\AskAlex.App\Assets\Square44x44Logo.targetsize-24_altform-unplated.png' does not exist.			
Error	Payload file 'C:\Source\Repos\askalexapp\AskAlex.App\Assets\StoreLogo.png' does not exist.	

Now, I’m not that great at UX… Taking into consideration, that not being able to build the app stops me from doing what I enjoy, I needed a quick fix that didn’t involve editing PNGs… So I did what developers do, I asked a friend!

The first tip I got was to manually edit my project file and to add the following line to the first PropertyGroup.

<UapDefaultAssetScale>100</UapDefaultAssetScale>

Obviously this is kind of a hack… So I kept asking and was gracefully pointed to a Tweet by @WindowsDev

Make sure your #UWP live tiles look right at home with this @VisualStudio extension: UWP Tile Generator Extension for Visual Studio

To install this extension, search for ‘UWP Tile Generator’ in Visual Studio’s Extensions and Updates or download it from the Visual Studio Gallery.

Making an Azure Mobile App

First let’s start by reviewing the Mobile Apps documentation.

• App Service Mobile Apps documentation
• App Service API Apps – What’s changed
• Authentication and Authorization in Azure Mobile Apps
• Work with the .NET backend server SDK for Azure Mobile Apps
• Add authentication to your Windows app
• How to configure your App Service application to use Microsoft Account login
• Check for expired Azure Mobile Services authentication tokens
• Deploy your app to Azure App Service
• Continuous deployment using GIT in Azure App Service
• Scale a web app in Azure App Service
• Monitor Web Apps in Azure App Service

Second, lets install the Microsoft.Azure.Mobile.Client NuGet package to our Mobile App project.

Third, we need to add a new Mobile App project to our solution. This will serve as our backend service for the client Mobile App.

Finally, we have both the client UWP Mobile App and the server Mobile App, and we need a way to identify users. So I used the Azure portal to create an App Service Plan and a Mobile App. These will be used to host the backend services for the Mobile App.

To implement authentication I used App Service Authentication / Authorization. This is a feature that allows the app to login users without having to change code in the backend services. This definitely provides us with an easy way to protect our app and work with per-user data.

How authorization works

App Service Authentication / Authorization exposes several choices for Action to take when request is not authenticated. Before your code receives a given request, you can have App Service check to see if the request is authenticated and if not, reject it and attempt to have the user log in before trying again.

One option is to have unauthenticated requests redirect to one of the identity providers. In a web browser, this would actually take the user to a new page. However, your mobile client cannot be redirected in this way, and unauthenticated responses will receive an HTTP 401 Unauthorized response. Given this, the first request your client makes should always be to the login endpoint, and then you can make calls to any other APIs. If you attempt to call another API before logging in, your client will receive an error.

If you wish to have more granular control over which endpoints require authentication, you can also pick “No action (allow request)” for unauthenticated requests. In this case, all authentication decisions are deferred to your application code. This also allows you to allow access to specific users based on custom authorization rules.

To set this up, we can follow the steps described in the following documentation about how to configure your App Service application to use Microsoft Account login.

Running through the documentation, we are presented with the following way of triggering the authentication process.

var user = mobileService.LoginAsync(MobileServiceAuthenticationProvider.MicrosoftAccount)

So I ended up adding the following code to the App.xaml.cs source file.

private readonly MobileServiceClient mobileService = new MobileServiceClient("https://askalex.azurewebsites.net/");

private async Task Authenticate()
{
    var vault = new PasswordVault();

    while (mobileService.CurrentUser == null)
    {
        try
        {
            SetIdentityFromPasswordVault(vault);
        }
        catch (Exception ex)
        {
            Debug.Write(ex.ToString());

            var user = await mobileService.LoginAsync(MobileServiceAuthenticationProvider.MicrosoftAccount);

            vault.Add(new PasswordCredential("AskAlex", 
                                             user.UserId, 
                                             user.MobileServiceAuthenticationToken));
        }
    }
}

private void SetIdentityFromPasswordVault(PasswordVault vault)
{
    var creds = vault.FindAllByResource("AskAlex")
                     .FirstOrDefault();

    creds.RetrievePassword();
           
    var user = new MobileServiceUser(creds.UserName)
    {
        MobileServiceAuthenticationToken = creds.Password
    };

    MobileService.CurrentUser = user;
}

Once I obtained a MobileServiceUser, I used the PasswordVault to store the MobileServiceAuthenticationToken. The PasswordVault is a Credential Locker that securely stores and retrieves user credentials. It roams them between devices with the user’s Microsoft Account and its contents are specific to the app.

Credential Locker

Apps that connects to a service to access protected resources such as media files, or social networking. Your service requires login information for each user. You’ve built UI into your app that gets the username and password for the user, that is then used to log the user into the service. Using the Credential Locker API, you can store the username and password for your user and easily retrieve them and log the user in automatically the next time they open your app, regardless of what device they’re on.

Credential locker works a little differently for domain accounts. If there are credentials stored with your Microsoft account, and you associate that account with a domain account (such as the account that you use at work), your credentials will roam to that domain account. However, any new credentials added when signed on with the domain account won’t roam. This ensures that private credentials for the domain aren’t exposed outside of the domain.

Then I added a call to force authentication whenever the app is opened.

public override async Task OnStartAsync(StartKind startKind, IActivatedEventArgs args)
{
    await Authenticate();

    NavigationService.Navigate(typeof(Views.MainPage));
}

At this point, I was missing a way to test my login feature. So I did the only logical thing that came to my mind, at that time, and added a Logout feature.

Reusing the same patterns that were present in the Settings Page View Model, I added the following command.

private DelegateCommand _LogoutCommand;

public DelegateCommand LogoutCommand
=> _LogoutCommand ?? (_LogoutCommand = new DelegateCommand(async () =>
{
    Views.Shell.SetBusy(true, _BusyText);

    await App.MobileService.LogoutAsync();

    var vault = new PasswordVault();
    var creds = vault.FindAllByResource("AskAlex").FirstOrDefault();
    if (creds != null)
        vault.Remove(creds);

    Views.Shell.SetBusy(false);

    await App.Current.OnStartAsync(BootStrapper.StartKind.Activate, null);

}, () => App.MobileService.CurrentUser!= null));

To trigger the command, I added a Button to the Settings Page View.

<Button Margin="0,12,0,0"
        Command="{x:Bind ViewModel.SettingsPartViewModel.LogoutCommand}"
        Content="Logout" RelativePanel.Below="BusyTextTextBox" />

The screenshots below show the early beginnings of the Ask Alex app running on my Lumia 640 XL. It’s not much to look at for now, hopefully I’ll find a kind soul that will help me with the UX. The important thing to note is that Template 10 gave me a good app skeleton to work with, and Azure Mobile App gave me SDKs that reduced boiler plate code. Essentially, I put together an app and protected using Microsoft Accounts, without wasting time with boiler plate code. Template 10 and Azure Mobile App were accelerators and allowed me to get this first feature out of the way. Now I can focus on the fun stuff.

Mobile App Resources

• APIs, SDKs and open source projects from Microsoft Azure
• Microsoft Azure Mobile Services E2E tests
• Mobile Services Samples
• Microsoft Azure Mobile Apps: .NET Client SDK

Share your thoughts in the comments below

In future posts, I will continue to implements various aspects of the Ask Alex Universal Windows Platform (UWP) Mobile App.