So wait, I'm not clear, why can't this be statically linked, and why is this a plugin type architecture..
It seems like you're trying to get code reuse, but still, I'm not sure why something like a ClassLoader is required from. From where will the classes be loaded? kris On Tue, Oct 2, 2012 at 3:51 PM, Lindley <[email protected]> wrote: > 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 -- 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
