id | title |
---|---|
321715C4-3D56-C9EF-4846-CEB5DBF38D21 |
Preview 2 |
- 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
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.
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.
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.
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.
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.
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.
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.
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.