In-memory caching in Xamarin apps


Recently we added in-memory caching to Azure App. You can try it out now on iOS and Android!

It turns out Mono doesn’t have System.Runtime.Caching namespace, which makes it easy to implement caching for .NET apps. We had to find another way.

Caching libraries for Xamarin

We looked at a few libraries for caching (e.g., MemoryCache and Akavache), but surprisingly none of them manage cache size and memory. They simply add items to Dictionary, and if you add too many you get OutOfMemoryException.

It may not be an issue for many applications, but in Azure App we need to take into account users who has multiple subscriptions with thousands of resources.

BTW: Akavache is a great library. Besides in-memory cache it also supports persistent cache, have clean APIs and a lot of great documentation.

Implementing in-memory cache

After browsing internets and asking people at Xamarin chat we didn’t find anything that would work for us, and we decided to implement in-memory cache by ourselves.

public class InMemoryCache<T> : IInMemoryCache<T>
    private const int LimitedCacheThreshold = 1000;

    private class Reference
        private int _hitCount = 0;

        public DateTimeOffset Timestamp
            private set;

        public T Data
            private set;

        public void AddRef()
            Interlocked.Increment(ref _hitCount);

        public int ResetRef()
            var count = _hitCount;
            _hitCount = 0;
            return count;

        public static Reference Create(T obj)
            return new Reference()
                Timestamp = DateTimeOffset.Now,
                Data = obj,

        private Reference()

    private readonly ConcurrentDictionary<string, WeakReference<Reference>> _weakCache;
    private readonly ConcurrentDictionary<string, Reference> _limitedCache;
    private readonly ConcurrentDictionary<string, Task<T>> _pendingTasks;

    private InMemoryCache()
        _weakCache = new ConcurrentDictionary<string, WeakReference<Reference>>(StringComparer.Ordinal);
        _limitedCache = new ConcurrentDictionary<string, Reference>(StringComparer.Ordinal);
        _pendingTasks = new ConcurrentDictionary<string, Task<T>>(StringComparer.Ordinal);

    public static IInMemoryCache<T> Create()
        return new InMemoryCache<T>();

    public async Task<T> GetOrAdd(string key, DateTimeOffset expiration, Func<string, Task<T>> addFactory)
        WeakReference<Reference> cachedReference;

        if (_weakCache.TryGetValue(key, out cachedReference))
            Reference cachedValue;
            if (cachedReference.TryGetTarget(out cachedValue) || cachedValue != null)
                if (cachedValue.Timestamp > expiration)
                    return cachedValue.Data;

            var actualValue = await _pendingTasks.GetOrAdd(key, addFactory);

            if (_limitedCache.Count > LimitedCacheThreshold)
                var keysToRemove = _limitedCache
                    .Select(item => Tuple.Create(
                    .OrderBy(item => item.Item1)
                    .ThenBy(item => item.Item2)
                    .Select(item => item.Item3)
                    .Take(LimitedCacheThreshold / 2)

                foreach (var k in keysToRemove)
                    Reference unused;
                    _limitedCache.TryRemove(k, out unused);

            var reference = Reference.Create(actualValue);
            _weakCache[key] = new WeakReference<Reference>(reference);
            _limitedCache[key] = reference;

            return actualValue;
            Task<T> unused;
            _pendingTasks.TryRemove(key, out unused);

We use two layers of caching. First is using WeakReference that leaves memory management to Garbage Collector. As GC is not very predictable and sometimes may unnecessary release some reference, we have second layer of caching. We call it _limitedCache, and it keeps objects in memory until capacity reach 1000 objects. Then we remove half (500), least used objects from dictionary. Because the same objects are being kept in two dictionaries, the WeakReference will never be released as long as object is in _limitedCache. Thus, we always check only if object is present in _weakCache.

There is also third dictionary that keeps track of pending tasks that are responsible for getting data. This prevents us from sending the same requests more than once if object is not in cache yet.


What is great about building apps with Xamarin is the ability to share code across platforms. When we were implementing cache, we didn’t touch any platform specific code. All work was done in Portable Class Library.

Adding cache to Azure App helped not only to decrease user’s network data usage, but also to improve performance significantly!

If you need in-memory cache for your app, go ahead and use the above code snippet! If you are looking for persistent cache then consider using Akavache.

Are you caching? How? Why? Why not?

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.


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:

echo $1 > $2/Tests/AzureMobile.UITests/password.txt

And this is VSTS task:


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:

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

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

  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:

public void Favorites_AddToFavorites_ResourceVisibleOnFavoritesPage()
    // Arrange
    var resourceToFavorite = TestResources.Azurembwinvm;

    // Act
    _resourceDetailsPage.ExecuteCommand(Strings.Favorite, Strings.Unfavorite);

    // Assert

Here, are some methods implemented in Page class:

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


    return this;

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


    return this;

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


    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 🙂


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 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 🙂

dotNetConfPL – online conference for .NET developers

Together with Michal Franc and Pawel Sawicz we are organizing online conference for .NET Developers: dotNetConfPL. It will take place on October 12 (3pm-10pm UTC+2), on the Internet! We have many great speakers and hot sessions.

Attendees will be able to ask questions through dotNetConfPL2013 room on JabbR.

Today, we have over 500 registered users! Additionally, during the conference we will give away 6 ReSharper licenses (thank you JetBrains).

Registration is not obligatory, but only registered users will have chance to win ReSharper licenses.

See you there!

The future of Mobile Apps

I think that in next 5 years Web Mobile apps will be more popular than classic Mobile apps we are using today.

Me, June 28, 2013

That is what happend in case of PCs. 10 years ago we were installing apps instead of just use them in the browser. Now we can edit Word documents, play games and even use IDE in Web Browser. I am not saying that it will be no classic Mobile apps at all, but e.g. apps like Calendar, gmail, Evernote, OneNote or games should be easilly accessible through Mobile Web Browser. The advantage of that would be lack of necessity to install bunch of apps.

What that means for developers? People who are currently working as Mobile Developers will need to learn Web Development. People who are currently working as Web Developers will need to learn Mobile Development. Additionally, future developers will not necessary need to know all different platforms (iOS, Android, WP), because they will be able to create apps in HTML5 and JavaScript (which should be well supported and compatible with Mobile Web Browsers in next 5 years).

This is my prediction. We’ll see what happens after 5 years.