Xamarin F# – Experience Report

For the past few months I have been working on an Android application that collects automotive CAN bus data – ultimately for analysis with BigData technologies such as Hadoop. I have already described some aspects of this project here and here. Thus far close to 2 Terabytes of data has been already collected.

In this post I would like to recount my experience of using F# with Xamarin for a real-world mobile application.

Before anything else, I want to state that this was a substantial effort and the final app has over 6000 lines of new F# code. It is by no means a toy app. It is a complex app with several system and user interface points and non-trivial background processing. It is meant to run for several months without any involvement by the user – after the initial setup.

Here is a partial list of app features / highlights, roughly in decreasing order of complexity:

  • Bluetooth and USB interfaces to the OpenXC dongle
  • About 10 Android screens with two custom built graphical controls
  • ProtoBuf protocol for higher throughput data transfer over Bluetooth
  • Asymmetric and symmetric cryptography
  • Compression of data before upload
  • OAuth authentication via Azure Access Control Service
  • Upload to Azure storage via a WebAPI
  • A settings/preferences module where the UI is auto generated (partially portable to IOS)
  • Android features: Service, Alarms, Notifications, BroadcastReceivers, Toasts, Intents, PendingIntents, Activities, Dialogs, etc.
  • Pervasive use of F# Actors and async computations (events bus, pub-sub, ‘nanoservices’)

Under the stress test framework, the app can happily run all day long processing around 7000 msgs/sec over Bluetooth on a Samsung Galaxy SIII (10,000+ msgs/sec rate is achieved if messages are not stored). The package size is about 8 MB and the runtime size is between 25-50 MB.

Xamarin F# support is now very good and I will gladly recommend that for production use. When I started out, F# support was still in beta and I ran into many issues. However the Xamarin team was super responsive and have rapidly advanced the plug-in to where it is it now stable and very usable.

Just a few points to note if you want delve into F# and Xamarin. You need to install both F# 2.0 and 3.1 runtimes before F# will work.

I ended up writing our own simple Actor (MailboxProcessor) implementation which gives us better memory performance at the cost of smoothness (in distribution of processing) than what we get from native F# MailboxProcessors. This implementation can be found here: http://fssnip.net/m8

We had most issues with Bluetooth connectivity. Once that part was sorted out it was relatively smooth sailing. I had to learn Android programming from scratch – a big learning curve. We still have Bluetooth issue with older Android phones but it is something that we have no control over. We did run into the Android fragmentation problem and so had to test the app on a wide variety of devices to resolve all of the issues. The app runs well on all new phones and most old (Android 2.x) phones.

With so much processing happening, battery consumption is an issue and the app consumes anywhere from 15% to 30% of the battery for a typical day. This means that users have to charge their phones everyday.

All-in-all it was a great (but humbling) experience. I have new respect for mobile developers. F# and Xamarin triumphed. I can’t imagine writing such a complex mobile app in another language. Instead of 6K, equivalent Java code would be in the 50K LOC range and of untenable complexity. I think F# is a great language for mobile computing. It is surprising how much you can do on these devices today.

Updated: Also see this InfoQ article for additional references.


11 thoughts on “Xamarin F# – Experience Report

  1. HI!

    Great to see real world apps being developed with F#. In theory, F# now is able to develop desktop, web and mobile apps smoothly… so it is reassuring to see real examples of that. Congratulations for it! I can’t wait till I get my hands on Xamarin + F#.

  2. Pingback: F# Weekly #13, 2014 | Sergey Tihon's Blog

  3. Pingback: F# on Android - Experience Report - Don Syme's WebLog on F# and Related Topics - Site Home - MSDN Blogs

  4. Very nice – thanks for sharing.
    As a small point concerning your snippet – you should only use “let xyz = new XYZ(..)” if XYZ is IDisposable – if not use “let xyz = XYZ(..)” … and beeing at it – if XYZ is disposable it’s usually best to use “use xyz = new XYZ(..)”

  5. Pingback: 4/5/2014 Article Links | The Puntastic Programmer

  6. Im currently learning F# in order to develop my first mobile app using Xamarin. It’s reassuring to see real world apps being written with a positive outcome.

  7. Pingback: 使用F#开发iOS和Android原生应用 | 我爱互联网

  8. Pingback: Xamarin Weekly Newsletter Issue #25 | Xamarin Fire

  9. The Android framework is all in Java. How does F# interact with that? Is there an FFI convention between F#/Java or is there a F# wrapper around the Java-based services? Or something else?

    • Basically the mono .Net VM runs in the same process as the JVM.

      Pure .Net objects live in mono and are garbage collected there. Similar for pure JVM objects.

      JVM objects that are also needed in mono (mostly UI objects) are proxied via JNI (I think), i.e. the mono objects are proxies of JVM objects.

      You may also have mono objects that are needed in JVM (i.e. an interface implementation). The JVM has Java proxies for such mono objects.

      All said, it sort of all works. I don’t remember being too concerned about the low level details when I was building this app.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s