Azure

Azure Resource Manager Batch API

The latest Azure Mobile App update has statuses on the resources list:

Azure App - Statuses on resources list

You probably want to ask why we didn’t have them before. Great question! Currently Azure Resource Manager (public API we are using to get your Azure resources) requires to make separate calls to get single resource status. It means: if you have 100-200 resources, you would have to make 100-200 extra calls. There are some people who has almost 2000 in one subscription! Taking performance and data usage into consideration, this is not ideal.

Both iOS and Android platforms allows to address this problem to some extent by querying for status only resources that are currently visible. However this is still extra 5-10 calls. It is even worse when you start scrolling, and very bad if you scroll on your list containing 2000 resources.

Batch API

Sometime ago ARM added Batch API – you can send POST request with up to 20 URIs in the body. Response will contain up to 20 packaged responses that you have to extract. Using batch API, you can decrease number of requests by up to 20x. This matters especially when user has a lot of resources and keep scrolling on the list.

When implementing batch requests, you need to figure out the optimal interval for sending requests. We started with 200ms, but then we changed it to 50ms. Additionally, every time new request is coming we delay sending batch request by additional 50ms. This may cause indefinite delay. In order to solve this: we always submit request if queue has 20 or more pending requests. 20*50ms = 1000ms = 1s = long time! We tweaked it again, and changed interval to 20ms. With current implementation, we wait anytime between 20ms and 400ms to send batch request.

Implementing Batch API

You probably gonna say: “it all sounds great, but how do I implement it”? For you convenience I created small console application that demonstrate ARM Batch API in action, and I put it on github.

Xamarin.iOS and Xamarin.Android does not have System.Threading.Timer. We created our own implementation OneShotTimer (thanks William Moy!).

Entire magic happens in ArmService. It has one public method GetResource that instead of directly sending GET request is adding request to ConcurrentQueue. OneShotTimer and BatchRequestDipatcher methods are responsible for sending the actual HTTP request.

In order to run console app, you need to provide ARM token, and (optionally) resource ids you want to request. In demo app I provided fake resource ids, which will be fine to issue requests, but you will not get resource back.

To get ARM token, go to Azure Portal, open F12 tools and inspect some ARM request. From request headers, copy Authorization header (string starting with Bearer rAnDoMcHaRacTErS...):

Azure Portal - ARM token

You can also get resources ids from F12 tab. The best way is to go to All Resources blade, and find some batch request:

Azure Portal - resources ids

Once you paste resource ids and ArmToken in Program.cs you can run the app, and you should see the following output:

Batch requests with 5s randomness

Requests are send in random time, anytime from 0 to 5s after program runs. This is done using Task.Delay:

var tasks = _resourceIds.Select(async resourceId =>
            {
                await Task.Delay(new Random().Next() % 5000);   // simulate calling GetResource from different parts of UI
                var response = await _armService.GetResource(resourceId);
                resources.Add(response);
            });

When you change randomness from 5s to 0.5s you can observe that there will be less batch requests (AKA more requests sent in single batch):

Batch requests with 0.5s randomness

Summary

Using Batch API for getting resource statuses visibly improves performance in the mobile app. It is noticeable especially when using network data.

Azure Resource Manager has plans to add ARM API that will allow to do 1 request to get multiple resources with statuses. This should improve performance even more in the future.

If you are facing similar problem with your app, consider implementing Batch API on your server!


Azure Mobile App on Azure Friday

Last month I had a pleasure to talk about Azure App with Scott Hanselman on his show Azure Friday.

In this talk I presented Azure App architecture, our CI/CD infrastructure and how we took advantage of various benefits we get thanks to building app with Xamarin. Check it out!

If you want to learn more details about how we built the Azure App, check out my blog post Under the hood of the Azure Mobile App.

My talk was pretty technical. Deep into the meat. However, the same week, Michael Flanakin gave high-level overview of Azure App and our future plans:

Have you tried Azure App yet?

It is available on iOS and Android.

We would love to hear your feedback through our User Voice!


Under the hood of the Azure Mobile App

For last 6 months I’ve been working on the Azure Mobile App for iOS and Android. We officially announced it at Microsoft’s //build conference keynote last month.

Now, you can monitor your Azure Resources from your phone! You can also take quick management actions, like start/stop/restart. Actually, you can do whatever you want using Cloud Shell that enables you to execute any command available through Azure CLI and PowerShell.

To learn more about the app functionalities, check out Michael Flanakin‘s blog post: Introducing the Azure app public preview.

Xamarin

The app is built with Xamarin Native in C#. To learn more about Xamarin, checkout my blog post Getting started with Xamarin in 2016.

The great thing about Xamarin Native apps is the fact that you can do everything what is possible when building native iOS apps with swift and native Android apps with Java. You can take any code sample in swift or Java, translate it to C# and use in your Xamarin app. Additionally, you can share code across platforms. We have around 60-70% code share. Most of our code is shared using PCL (Portable Class Library). Some components are in Shared Project.

Azure Mobile Solution

Continuous Integration and Continuous Delivery with VSTS and Hockey App

VSTS provide awesome tools for customizing build params, running tests, and deploying with HockeyApp. What’s more, when you are publishing your alpha/beta builds with HockeyApp you get auto-update notifications for free.

We have 3 environments:

  • alpha – deployed on every commit if tests are passing (used by team members)
  • beta – deployed after merge from alpha branch if all tests are passing (available for all Microsoft employees – it allows us to test the next release candidate)
  • App Store / Google Play – deployed manually (Apple does not provide mechanism to auto-deploy and we are working on automating Google Play deploy from VSTS)

Build definitions

I blogged about setting up VSTS for Xamarin.iOS earlier this year. Configuring Android build is much easier. Our VSTS build pipelines for iOS and Android look like below.

VSTS Xamarin.iOS build definition

VSTS - Xamarin.Droid build definition

The general scenario is:

  • build in Debug mode (in order to initialize TestCloud, which I described in this blog post)
  • run tests
  • build in Release mode (without TestCloud init code)
  • deploy to HockeyApp

We are thinking about running tests in Release mode (it requires passing TEST_CLOUD build param to build command explicitly). This will give us the same app that later on will be deployed to HockeyApp. A few times we had situations when app was working fine in Debug mode and all UI tests were passing, but it was crashing on startup in Release mode. In this case, if somebody updated app on their device, they had to uninstall it, and install manually again after we fixed bug causing crash. Very inconvenient.

Storing secrets

VSTS provides mechanism to keep your secrets (passwords and tokens) outside of your source code. You can store them in Variables tab in your build definition. Notice small lock next to secret value. Once you click it, it will hide the secret forever. There is no way to read it back from VSTS. I’ve done this a few times, and had to regenerate keys and tokens. You can store your secrets in Azure KeyVault, where they are always readable.

VSTS - variables

When you are running UI tests, usually you need to authenticate (AKA you need password to login with your test account). There is no way to pass password as parameter to Test Cloud, but there is a workaround: we have file Password.txt in UI test project (without password of course), and before running UI tests, we run shell script that takes password (from VSTS Variables) as parameter and writes it to the Password.txt file. You can pass variables stored in VSTS as arguments to VSTS tasks.

This is shell script:

#!/bin/bash
echo $1 > $2/Tests/AzureMobile.UITests/password.txt

And this is VSTS task:

GetPasswordForTestCloud

VSTS is awesome! It allows you to do almost anything with VSTS tasks or custom scripts. You can modify version number in Info.plist file before building solution, add release notes from git commit messages and much, much more.

UI tests with Xamarin Test Cloud

TestCloud is awesome. It allows you not only automate UI testing. It also enables you to test your app on hundreds of devices without need of buying any of them.

UI tests are usually the longest running task in our build pipeline. In order to minimize wait times between builds, we run UI tests only on one, most reliable device. We have separate build definitions to run UI tests nightly on 20 iOS and 40 Android devices. It takes longer, but it helps us to identify issues related to particular device model. Most of the time we don’t have changes that are breaking single device.

We are also thinking about creating 1-2 smoke tests that will be run on every commit, and run entire suite nightly or on separate build (to don’t block other runs).

Don’t assert! Use WaitFor!

UI testing 101: when you are writing UI tests, remember to wait for UI to update before asserting some condition. E.g., let’s say you have button and label. After button click, you expect label to update its text to ‘Button clicked’. Below test will be very flakey:

  app.Tap("myButton");
  Assert.AreEqual("Button clicked", app.Query("myLabel").Label);

Label may not get updated before assertion gets executed. Instead you should use WaitFor:

  app.Tap("myButton");
  app.WaitFor(app.Query("myLabel").Label.Equals("Button clicked", StringComparison.InvariantCulture));

Page Object Pattern

Another very good practice for writing UI tests is to use Page Object Pattern. This allows you to isolate implementation details from tests scenarios.

Here is one of our tests:

[Test]
public void Favorites_AddToFavorites_ResourceVisibleOnFavoritesPage()
{
    // Arrange
    var resourceToFavorite = TestResources.Azurembwinvm;
    TapTabBarItem(Strings.Resources);

    // Act
    _resourcesPage.TapResourceByName(resourceToFavorite);
    _resourceDetailsPage.VerifyPresent();
    _resourceDetailsPage.ExecuteCommand(Strings.Favorite, Strings.Unfavorite);
    _resourceDetailsPage.GoBack();

    // Assert
    TapTabBarItem(Strings.Favorites);
    _favoritesPage.VerifyPresent();
    _favoritesPage.VerifyNavBarTitle(1);
    _favoritesPage.WaitForResourceByName(resourceToFavorite);
}

Here, are some methods implemented in Page class:

public FavoritesPage WaitForResourceByName(string resourceName)
{
    _app.Screenshot($"Waiting for resource {resourceName}...");

    _app.WaitForElement(resourceName);

    return this;
}

public FavoritesPage TapResourceByName(string resourceName)
{
    _app.Screenshot($"Tapping resource '{resourceName}'...");

    _app.WaitForAndTapOnElement(resourceName);

    return this;
}

public FavoritesPage WaitForNoResourceByName(string resourceName)
{
    _app.Screenshot($"Checking if resource '{resourceName}' is not present...");

    _app.WaitForNoElement(resourceName);

    return this;
}

Screenshots during UI tests

As you probably noticed in above code snippet, we are taking screenshots at almost every step. Thanks to Page Object Pattern we don’t have to think about it in our test steps, but only in our Page implementations. Screenshots helps a lot in diagnosing failures in TestCloud:

Xamarin TestCloud - screenshots

Above test is failing when Waiting for DetailsCommandLayout… Thanks to screenshot, you can easily identify the line of code responsible for failure.

Monitoring and Crash Reporting with HockeyApp and AppInsights

A lot of people are using HockeyApp for crash reporting. Not many people are using it for application logging though. That’s because HockeyApp does not provide a good way for searching logs. However, you can create an AppInsights bridge app and stream all HockeyApp events to AppInsights.

AppInsights provides very powerful query explorer to search through your logs.

By default logs are preserved for 3 months, but you can export them to storage account and keep forever if you want.

What’s more, you can create awesome PowerBI dashboards using data from AppInsights.

Xamarin Open Source plugins and libraries

We saved a lot of time by using cross-platform Xamarin plugins:

  • XamSettings Plugin (from James Montemagno) – it is an abstraction over native data storage (SharedPreferences for Android, NSUserDefaults for iOS) that allows you to store/access local data in shared code
  • FFImageLoading (from Daniel Luberda) – very powerful image library, it allows us to convert SVGs to native formats in runtime, in shared code
  • OxyPlot (recommended by Frank Kruger) – awesome, powerful, cross-platform chart library used for metrics visualization

Xamarin community is awesome. If you are building Xamarin apps, I strongly recommend you to join slack channel XamarinChat. You can find there a lot of great developers who are willing to help. We learned about FFImageLoading there. What’s more, Daniel Luberda (FFImageLoading top contributor) is very active there. One time, he fixed a bug in less than 6h after reporting it by us 🙂

Summary

I am really excited about this app. It is an awesome feeling to take an app from zero to //build keynote. I am even more excited because there is a lot more to come. You can help us with that! If you have an idea about what should be added/changed/removed in Azure App go to aka.ms/azureapp/feedback and add or vote for a feature.

In meantime, get the app from App Store or Google Play, and let us know what you think!

Check out me and James Montemagno chatting about the app on Xamarin Show:

*This post was written in the clouds during my flight from Seattle to Frankfurt 🙂


Ignite Australia 2017

Microsoft Ignite Australia 2017

This month I had a pleasure to speak at Microsoft Ignite conference in Australia.

My talks

I updated my talk about the Azure Portal with more performance tips & tricks, and one of the most important thing I learned while working with the Azure Portal Team: the Data Driven Approach for making decisions and improving product.

I got very positive outcome during and after my session:

Azure Portal talk recommendation

 

Azure Portal - performance tricks

 

Azure Portal - Future Stack

 

I also updated my TypeScript talk with yarn (faster and better npm), and webpack (module bundler that can also compile TypeScript to JavaScript, minify it, optimize it and much more).

 

After my talks I’ve been interviewed by Duncan Hunter on Azure Portal and Building Large Scale Web Apps with TypeScript:

Recommended sessions

I personally attended, and watched later (after the conference), a few good talks. From what I’ve seen I would strongly recommend (in addition to my sessions of course):

The Technical Debt Prevention Clinic (Richard Banks) – great talk on distinguishing technical debt from bad code, and strategies to avoid bad code
Microservices, Docker, .NET, Windows, Linux, Azure. Oh, My! (Richard Banks) – awesome intro to Docker+Azure (if you haven’t check Docker yet)
Applied Azure: Building a Large Scale Real World Application on a Coffee Budget (Troy Hunt) – nice overview of different Azure’s offerings (did you know that New Relic is free with Azure App Service?)
Ten Things Every Expert Xamarin Developer Should Know (Glenn Stephens, Kym Phillpotts) – 10 good to know things if you are building apps with Xamarin
Building Azure Connected Mobile Client Apps (Glenn Stephens) – high level overview of building Xamarin apps with Azure
CQRS Secrets: How to Support Scalability and Performance (Richard Banks) – great intro to CQRS, from why to how
Blockchain 101 & Azure Blockchain as a Service (David Burela) – new hot thing from Azure
Blockchain Development on Azure Blockchain as a Service (David Burela & Chris Zhong) – deeper dive
30 Terrible Habits of Server and Cloud Administrators (Orin Thomas) – BEST VOTED SESSION OF THE CONFERENCE, title says all, and it also relates to developers’ habits

Summary

Microsoft Ignite Australia was very well organized conference. I had a pleasure to meet a lot of passionate and curious people there. If you are a speaker or developer looking for a good conference, I strongly recommend you to go. If you are not from Australia, don’t forget to take melatonin for 14h+ flight 🙂 Oh, and the location is great too!

Gold Coast, Australia


Predicting future with F# and Azure Machine Learning

Earlier this year I blogged about StockEstimator – my side project for predicting future stock prices. Recently in addition to F# module, which estimates future prices, I added Web Service that takes advantage of Azure Machine Learning to do the same much faster.

Last month I talked about my project at .NET Developers Association Meetup in Redmond and in Seattle. I streamed both session with YouTube live, and recordings are already available:

Both videos cover the same topics. Not sure, which one is better. However, there was one gentleman who went to both my talks and he said that the second one was better 🙂

In both presentations I do a quick intro to F#, an overview of Machine Learning, and how I took advantage of both to predict future stock prices.

If you are interested in F# I recommend you to check my Getting started with F#.

Presentation slides are available here (you can find there a lot of references to materials about F#, Machine Learning and Azure Machine Learning).

StockEstimator project is open source and available on github.

I’m not going to stop here. As you can see on my slides, and at the end of my presentations I have future plans to evolve this overnight project 🙂