I'll give a little more detail. The Impl class is supposed to be one of several pure-java implementations of the service in Main that I might drop in. The purpose of Main is to abstract all Android-specific code away from this implementation. In particular, the service in Main *already* has an AIDL interface, so putting on in Impl would just be silly.
On Tuesday, October 2, 2012 3:47:52 PM UTC-4, Lindley wrote: > > For a variety of reasons, most notably because the plug-in portion is not > supposed to be Android-specific, I don't want to use AIDL here. > > Static linking is a fallback option. I don't like it but I'll do it if > that's the only way. There really ought to be a cleaner fix for this. > > On Tuesday, October 2, 2012 3:31:58 PM UTC-4, Kristopher Micinski wrote: >> >> So instead of doing this (ClassLoaders being bad...), I would use an >> AIDL service stub for the methods you needed... >> >> Alternatively, I would suggest you look at using an Android library >> project, if you can statically link. >> >> What kinds of things do you need. >> >> Multiple functional looks very much like you might want a single app, >> and not a collection of plugins. >> >> kris >> >> On Tue, Oct 2, 2012 at 3:00 PM, Lindley <[email protected]> wrote: >> > I am using Eclipse with the ADT plugin, as well as ant. >> > >> > I am trying to design a plug-in architecture. I have three projects, >> call >> > them Main, Plugin, and Impl. Main builds a service apk, Plugin is an >> Android >> > Library. Plugin just defines two classes, AbstractPlugin and >> PluginFactory. >> > AbstractPlugin is an interface, and PluginFactory does what is >> necessary to >> > set up a DexClassLoader and instantiate by reflection a class from Impl >> > which implements that interface. Main uses the resulting AbstractPlugin >> in >> > some way. >> > >> > Therefore, the compile-time dependencies are Main -> Plugin and Impl -> >> > Plugin. There is no compile time dependency between Main and Impl, >> since the >> > class in Impl is instantiated by reflection. Therefore, when the >> Main.apk is >> > built, classes from Plugin are included but classes from Impl are not. >> > >> > The problem is then how to get those dex'd classes in Impl into the >> phone in >> > a place where DexClassLoader can get at them. >> > >> > There are two options. First, Impl can be built as an Android library, >> then >> > the resulting classes.jar can be manually dex'd with dx, and then the >> > resulting classes-dex.jar can be pushed into some predetermined >> directory on >> > the phone. This works, but I am not entirely thrilled with it. For one >> > thing, it prevents Impl from having any resources of its own, only Java >> > code. >> > >> > Second, Impl can be built as an apk which just happens to contain >> neither a >> > service nor an activity. This can be installed normally, and then >> > PluginFactory can get the path to the apk from the PackageManager to >> pass it >> > to DexClassLoader. The problem with this approach is that in each >> > configuration I have tried so far, Impl.apk ends up pulling in the >> classes >> > from Plugin as well since there is a compile time dependency. Therefore >> when >> > DexClassLoader tries to resolve something, it realizes there are now >> two >> > different AbstractPlugin implementations in the system (which are >> really the >> > same one in two different apks), and bails out. What I would like to do >> is >> > keep Plugin on the classpath during the build of Impl, but exclude its >> > classes from the apk. Is there a way to set this up either in Eclipse >> or in >> > Ant directly? (What about in maven?) >> > >> > This does not necessarily solve the resource problem since the active >> > Context in Main would not necessarily know about the resources in Impl >> if it >> > had any, but it would be a start. >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Android Developers" group. >> > To post to this group, send email to [email protected] >> > To unsubscribe from this group, send email to >> > [email protected] >> > For more options, visit this group at >> > http://groups.google.com/group/android-developers?hl=en >> > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
