I would prefer not to make it statically linked because I am not the one writing the plugins. Each plugin is potentially going to be on a different branch of a repository, and I would like to code to continue working without undue hardship when I switch branches. Different versions of the project files specifying static dependencies on each branch is an option, but not a good one.
Where the classes will be loaded from is precisely the issue. DexClassLoader can either take a jar containing a classes.dex or an apk. I mentioned both options in the original post. I'm fairly certain I can get things working using the jar approach, but it is inelegant in some respects. I prefer the paradigm of installing an apk to install a plugin, and therefore I need to figure out how to explicitly exclude certain dependencies from being included in the apk. On Tuesday, October 2, 2012 4:11:20 PM UTC-4, Kristopher Micinski wrote: > > 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] <javascript:>> > 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] <javascript:> > >>> > 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]<javascript:> > > To unsubscribe from this group, send email to > > [email protected] <javascript:> > > 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
