Preview 2

Bug Fixes / Enhancements

  • Add Tools->Start Android Emulator Manager menu item.
  • 633032 - AndroidRuntimeException in RequestWindowFeature
  • 633334 - No scrollbar in application properties window in VS2010
  • 633376 - Unable to get Invoker for abstract type 'Android.Widget.AdapterView`1
  • 633489 - No need for "build failed" modal dialog
  • 633717 - AdapterView.ItemClick events do not fire when items are clicked
  • 633814 - Android.Content.Intent.SetClass method is missing
  • 634700 - Mono.Data.Sqlite support (for Android 2.2+)
  • 635129 - View.Tag, View.SetTag(), View.GetTag() don't support C# objects
  • 635565 - OpenGLES 2.0 support in AndroidGameView
  • 636465 - Improve support for generic types
  • 637192 - Insert "generated by a tool" message into R.cs

API Changes

On top of the usual bug fixes, we are slowly making changes to the Mono.Android API to make it more .Net-ish and easier to use. Unfortunately, as pre-release users, this means you may be forced to change your code to the new API.

Activity Proxy

We now automatically generate and launch a proxy activity that loads the Mono runtime and such. If you changed your AndroidManifest.xml, there is a good chance your changes will no longer work, and you will need to get the updated <activity> elements from the generated one in obj/Debug/android to apply your changes to.

Byte Arrays

API elements which were exposed as sbyte[] in the previous previews are now byte[] to facilitate interaction with the mono class libraries. Java byte API remains sbyte, however, since the java fundamental byte type is signed. Most byte[] API is treated as binary data, so the change should not produce any overflow issues. If you encounter any API that would be more appropriately exposed as sbyte[] we encourage you to open bug reports so can convert them.

Constants and Enumerations

We have taken a lot of the int constants in the Android API and turned them into enumerations. This means that the enumerations now pop up in Intellisense when you try to use them, rather than having to go look up the constants values in the documentation.

For example:

Old:
Activity.RequestWindowFeature (int featureID)
New:
Activity.RequestWindowFeature (WindowFeatures featureID)

However, this is a very manual task for us, and we have no doubt missed places and made mistakes. If you come across a place where:

  • Some constants got left out of an enum
  • A constant is in the wrong enum
  • A method should use an enum, but still uses an int
  • A method is mapped to the wrong enum

Please, please, please file a bug! The workaround is to simply cast with (int) or (Enumeration). If you just do the cast without filing a bug, we will likely remove you from our Christmas card list!

It is trivial for us to fix, the hard part is finding them all throughout the Android API.

Generic Collections

It's been very difficult to work with both Java and .Net collections in the Android API, like System.Collections.Generic.IList<T> and Java.Util.IList<T>. To fix this, we've written some proper .Net collections to wrap the Java ones, and we now expose these throughout the API.

Old:
Camera.Parameters parameters = camera.GetParameters ();
Java.Util.IList<Camera.Size> sizes = parameters.SupportedPreviewSizes;   

New:
Camera.Parameters parameters = camera.GetParameters ();  
System.Collections.Generic.IList<Camera.Size> sizes = parameters.SupportedPreviewSizes;

In this case, what you are really getting is the type we wrote, JavaList<T>, that behaves just like a .Net collection. The key difference is this type is a wrapper around a Java collection, so we don't have to make a copy of the data to send to Java. If you need to pass a collection object to a method, you can make a JavaList, JavaDictionary, or JavaSet to avoid the copying penalty. You are also free to use the standard .Net collection types, it will just cause a copy when sent to Java, at a slight performance cost.

.Net Events

We are slowly replacing the Android On*Listener style of handling events with actual .Net events. In this release we replaced and removed most of the ones in the common classes like View, DialogInterface, and AdapterView. In future releases, we will continue to remove the remaining Listener interfaces.

IRunnable

Java utilizes the java.lang.Runnable interface to provide a delegation mechanism. The java.lang.Thread class is a notable consumer of this interface. Android has employed the interface in the API as well. Activity.runOnUiThread and View.post are notable examples.

The runnable interface contains a single void method, Run. It therefore lends itself to binding in C# as a System.Action delegate. We have provided overloads in the binding which accept an Action parameter for all api elements which consume a Runnable in the native API.

Old:
class MyRunnable : Java.Lang.Object, Java.Lang.IRunnable {  
    public void Run ()  
    { 
       do some stuff
    }  
}  
    Java.Lang.Thread t = new Java.Lang.Thread (new MyRunnable ());  
    t.Start ();

 

New:
Java.Lang.Thread t = new Java.Lang.Thread (delegate {  
       do some stuff 
    });  
    t.Start ();

We left the IRunnable overloads in place instead of replacing them since several types implement the interface and can therefore be passed as runnables directly.

OpenGL

OpenGLES version can now be selected with :

gameView.GLContextVersion = GLContextVersion.Gles2_0;

or

gameView.GLContextVersion = GLContextVersion.Gles1_1;

on AndroidGameView. This should be set before CreateFramebuffer() Or Run() is called.

If the device doesn't support the selected OpenGLES version, then an exception would be thrown.

Xamarin Workbook

If it's not already installed, install the Xamarin Workbooks app first. The workbook file should download automatically, but if it doesn't, just click to start the workbook download manually.