On Dec 7, 2011, at 1:30 AM, lynnlu wrote: > I realize that monodroid can generate > http://docs.xamarin.com/android/advanced_topics/architecture/android_callable_wrappers > ACW which is needed for Android runtime, does that mean, it actually > generate some Java code (and maybe I can take that and build them into a > JAR?)
Yes, you could, but (at present, and for the foreseeable future) you probably don't want to. 1. http://docs.xamarin.com/android/about/limitations#Limited_Java_Generation_Support is the biggie -- only Java.Lang.Object subclasses get ACWs generated, and for those types the only members present are overridden methods and interface methods. Unless your pre-existing C# code is already subclassing Mono.Android.dll types, this won't be immediately useful. Furthermore, unless there's an Android type or interface that provides an API similar to your C# class, you won't be able to provide a useful API to Java. 2. ACWs contain `native` method declarations, which are implemented in C#. This requires that your "downstream" developers embed (a) the mono runtime, which requires a commercial license, and (b) all assemblies that are required for those `native` methods (e.g. mscorlib.dll, Mono.Android.dll, etc.). 3. Getting all this working outside the Mono for Android toolchain would probably be an exercise in frustration, as you'd need to use the Android toolchain to embed libmonodroid.so, modify the AndroidManifest.xml to use the mono.MonoRuntimeProvider type, ensure that there's an //application/@android:name attribute with a type that subclasses mono.android.app.Application, etc., etc. (Plus, this list is likely to only get longer over time... Trying to do this from Android will be brittle as well.) I suspect that the only people willing to pay the licensing for (2a) are those already using Mono for Android, which rather reduces the need to provide a .jar containing ACWs in the first place. Assuming that there was such a group, (2b) will complicate their build process, as the assemblies need to be stored in the .apk (not compressed), and zipalign needs to be run on the .apk (which is common practice, but isn't often required in Android/Java apps). > It also says that Monodroid produce applications that > http://support.xamarin.com/customer/portal/articles/140416-will-my-users-need-to-install-mono- > do not require users to install monodroid because the mono mobile runtime > is linked to application, then does it mean I can produce a library file > that does not require developer to use monodroid to reference it? The resulting app needs the mono runtime (and a fair bit of bootstrap code, e.g. the generated mono.MonoRuntimeProvider type), or nothing works. Your shipping a .jar containing ACWs places an implicit requirement on your downstream developers to also ship the mono runtime; the mono runtime can't be embedded into a .jar that you then provide your downstream developers. (I'm not even sure how that could work, either...) > There is a post similar to my question but there is no practical answer > given: > http://mono-for-android.1047100.n5.nabble.com/Calling-a-MonoDroid-library-from-native-Java-td4403364.html > > older post - I know I can sorta use monodroid make the library class into a > Android library class and if I also use monodroid to write the andriod > application I can directly use this class - but what if I write the > application in java? I cannot reference a .dll in java right? Correct, you can't reference a .dll in Java. > The summarized question is here: Can I use Monodroid to convert the C# > library to a JAR or any type of file that can be used by Android java > developers? If I can, how? The (current) worldview for Mono for Android is that it's to support writing Android applications from C#. As part of this, ACWs are required (simply to allow Android to instantiate C# types and invoke methods on them), and we have a set of facilities to include Java source and .jar files into the build so that they'll be part of the resulting .apk (useful for (re)using pre-existing Java libraries, though we do need to improve this scenario as well). Consequently, consuming Java code from C# is far easier than consuming C# from Java. Calling C# from Java, beyond what was required just to get things working, hasn't been a priority. That's where we are, and where we'll likely remain until we've smoothed out many of the issues that C# developers are hitting. Add in the commercial licensing issues that would be endemic with attempting to embed a Mono for Android-generated .jar into a normal Java app... - Jon _______________________________________________ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
