> > Our current idea is to keep this library running in monodroid as an > android service (and by this share the main "heavy" buisness logic code > between WM/android projects), and to create a UI wrapper. (it most probably > will be in native java). > Using Mono for Android to create a UI wrapper makes sense, but why do you > want to run your library as an Android service? >
We don't want to 'reimplement' our whole business logic in java - thats why we are looking into mono-android. We also have a requirement for our app to work as a service (collecting data from BT device in background, without UI). Therefore, a separation between ui-app and service is quite natural (plus this allows external apps/plugins to attach to the service for data fetching). We also don't have problems with using java in contrast with popular trend "hey I hate java(read: don't want to learn) but love .net, thats why I love monodroid". Therefore I prefer 'native' solution where it is possible (and use java for UI). it is _not_ the thread you want to be doing high data throughput algorithms > on that thread, as it would lock up your UI. You want to use some background > thread (e.g. a dedicated System.Threading.Thread) instead. > Thats for sure. BTW, could you give some insight into System.Threading.Thread usage.. As I understand monodroid arch now - for dalvik its a kind of JNI layer (working eventually as a .net vm). How then its possible to run native .net threads in there? How you can run both mono and dalvik in a same linux process? Or may be you don't? > > How efficient it'll be in terms of data transfers? > I don't know. Unfortunately, you would need to profile. Furthermore, I > don't know if the emulator emulates bluetooth or not; you may need to > profile on actual hardware to see what the overhead is (and you'd probably > want actual hardware anyway to see if it's fast enough). > I see. Emulator has no BT support, but we can create a Socket connection with host machine, which'll emulate our device (or even tunnel via tcp socket to real device). As mentioned above, I'm not sure you want to use a Service here. That said, > there is currently no built-in support for AIDL files. If necessary, you > could probably hack something together by invoking the aidl compiler as a > pre-build step and including the Java sources (both generated and > potentially hand-written) into the final app by using the AndroidJavaSource > build action, then using Android.Runtime.JNIEnv to interact with the Java > types. We intend on improving AIDL support in a future release, but there is > no timeframe. > This is what I meant, yes. Ultimately it should be possible to generate c# AIDL interface stubs and autogenerate all underlying jni code. Tough task.
_______________________________________________ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
