bool versus Boolean

Both in Java and in .NET there is a difference between the primitive value types (such as bool, int, etc.) and the boxed versions of these types (java.lang.Boolean). The reason for that is simple: you want to use fast value types but sometimes you have to use them as an object on the heap.

This article explains how dot42 maps the boxed java types into the .NET world.

The problem

The main difficulty in this mapping is the following: Java has both primitive types and boxed types publicly available, but .NET has not. In .NET the boxed types are "internal".
The Android API uses both the primitive type as well as the boxed types in method parameters, field types etc. So we still have to make a difference between a bool parameter of some Android method and a Boolean parameter. Mapping both to the same primitive .NET type is no option, because you have to express the 'null' possibility and it breaks dot42 at runtime. So how did we do this.

Our options

We had a couple of options:

1. Import the Java boxed types as normal .NET classes. This means that there would be a Boolean class, an Integer class and so on.
2. Use Nullable<T>. This .NET construct is intended for extending value types with the ability to be "null".
3. Use another generic class, e.g. Boxed<T>.

The third option was dismissed quickly, because it does not "fit" the mind of the C# programmer, nor does it fit the Java world.

The first option seems like the most obvious choice to make. It is a direct mapping from the Java world to the .NET world. The downside of this option is that it is very "Java" like, therefore it is less recognizable for C# programmers.

The second option eventually seemed like the best choice for dot42. It is a well known feature of C# and it expresses exactly what you want: A value that is either an actual primitive value or "null".

The implementation

Now that we chose the Nullable<T> option for dot42, we had to make it work. We have used a combination of compiler generated code and actual C# source code for the dot42.dll.

All (almost all) uses of boxed types (such as Boolean) in the Android API now map on a nullable type in dot42.dll. Our compiler (that compiles IL into Dex) implements most of the members of Nullable<T> using custom Dex code. For example Nullable<bool>.HasValue is compiled to a null check on the java.lang.Boolean instance that is used to implement it. It also converts Nullable<T> back to the original boxed types. For example Nullable<bool> (or bool?) is converted to java.lang.Boolean.

With this mapping in place, we have an API that matches the intend of the Android API methods and we have a construct that is well known to C# programmers.

Technology Preview - Setting Expectations

dot42 is a development tool for writing Android apps in C# with Visual Studio.

After more than a year of engineering, we have have just pulled the lever and put dot42.com live. The product is far from ready but following the now ubiquitous lean startup mantra "test your ideas with your customers before betting the bank on them", we decided that it is time to go public.

In this post we want to set realistic expectations for the technology preview by listing the known shortcomings:

• Limited .NET framework support. This means that not all classes and members that are available in the .NET framework are available when writing a dot42 app. We are continuously extending the supported set and we need your feedback to set priorities.
• No support for struct. This data type is not supported by dalvik in straightforward manner. We are looking for a way to solve this.
• Visual layout designer. The current version allows you to visually edit String and Menu resources. We are now working on an editor for Layout resources.
• It is not possible to build an Android component APK with an interface description.
• Debugger watch expression limited to simple expressions (variables only)
• Virtual device (emulator) setup is still very limited. We recommend to work with a real device.
• No AIDL (Android Interface Definition Language) support.
• API documentation needs more work.
• We need more code samples.
• Our Developer Center is still thin on the content. We need more articles!

Despite these limitations, we encourage you to download the technology preview and provide feedback using one of the following options:

• Send a tweet to @dot42news
• Leave a message on our Facebook page
• Leave a comment below
• Use the Contact us form
• Comment on articles in our Developer Center