Choosing between two API flavors

When writing an Android application in C# using dot42, the entire Android API and a large subset of the .NET framework API are available.

At the time of writing this article, coverage of the .NET framework API is far from complete, but this will improve over time. Coverage will however never be fully complete because some parts of the .NET framework simply don't make sense for Android. E.g. System.Windows that includes types for Windows Presentation Foundation will never be covered. A notable principle of dot42 is that we do not emulate Windows on Android. In fact, we don't want to emulate the .NET framework on Android. Our main aim is to offer the richness of C# and the comfort of Visual Studio to Android developers.

Even when the .NET framework coverage is almost complete, you as a developer will have both API's (Android and .NET) at your disposal. In some cases, it is an easy choice what framework to use. For example all Android related services, such as Activities or Android preferences, have no counterpart in .NET so the Android API is the only choice. The same is true for some parts of the .NET framework.

This article helps you choose between the two API's when the choice is not so obvious.

An example

The most obvious example of an arbitrary choice is a list of objects. The .NET framework provides System.Collections.Generic.List<T> and Android provides Java.Util.ArrayList<T>. Both give you very similar functionality such as adding, retrieving and removing objects by index. So which should you choose?

Benefits of choosing the Android API

The .NET framework implementation in dot42 makes extensive use of the Android framework. For example the List<T> type mentioned above is implemented using ArrayList<T>. This is done to minimize the extra code that has to be included in each APK.

But still, little code is more than no code. By choosing the Android API over the .NET API, you avoid  code in your APK that implements the .NET List. Due to the restricted memory on mobile devices, it makes sense to minimize extra code whenever possible. This results in smaller packages and faster code.

Benefits of choosing the .NET API

After outlining the clear benifits of choosing the Android API over the .NET API, you may wonder why we bother to support the latter. A strong case for using the .NET API is the reuse of existing code that originally targeted the .NET framework. Another good reason is that you are writing code that targets both Android devices and .NET centric devices and you want to maintain a single code base only.

But even if you are writing a new application that targets just Android, you may choose the .NET API because it's what you like and used before and therefore are more comfortable with.

Mixing both

Sometimes you want or have to use both API's. To make them fit together easier, we have added overloads and conversions methods to both API's.

For example, the IO part of the Android API, usually uses Java.Io.File to identify a file path. The .NET framework on the other hand uses a string to identify a file path. For this reason, we added a casting operator from Java.Io.File to string (as an extension of the Android API). This allows the use of Android functions resulting in a File object in combination with .NET functions. Here is a code sample:

void WriteSomethingInCacheDir(
        Android.Content.Context context)
{
  // Context.GetCacheDir() returns a Java.Io.File.
  // File.WriteAllText uses a string path as
  // first argument.
  File.WriteAllText(
        context.GetCacheDir(), // cast happens here 
        "Somecontent");
}

Final thoughts

We have argued that both API flavors have their own benefits. Therefore, we are committed to extending the .NET framework coverage. Also we will continue to add overloads and conversion methods that make it easier for you to mix both.