Plugins architecture for an Android app? [closed]

Answer 1

I have done a framework that works like Robo-guice with some of its primary IoC functions. (Cut down on boilerplate codes that load views/service etc...)

But the core of which, I believe is the solution to your problem, is the ability to load separate APK "plugin" files, that includes "res" as well as <layouts>.xml files. The <layouts>.xml file can be independently inflated by the classes within that APK. That is, you can load a CustomView (that inflates its own <layout>.xml) into an originating/parent App. All this is done without the Parent App APK knowing how the UI was inflated in the plugin APK.

Example of what I mean: I have a Mapping App, the framework will dynamically scan installed APK that matches the "contract" for a "add-on function" plugin, and loads the UI specific to it onto the App's View as a floating panel.

I would say a plugin framework for Android is do-able, as Android has most if not all of the necessary built in APIs to accomplish this.

These are your friends in this area of plugin development for Android:

1. PackageManager (Scan install packages, aka Plugins)
2. DexClassLoader (ClassNotFoundException will be a pain if you don't use the correct ClassLoader btw)
3. Java Reflection

Answer 2

Where can I find a good example of a plugin architecture?

Roman Nurik from Google has implemented a nice plugins framework in his open source app dash clock. The plugins themselves are Services that extend the DashClockExtension class in the API and are installed as completely independent APK files with their own resources. It's quite a lot of work defining the communication protocol via the AIDL, but it's nice and clean and works very well.

one of the plugins must add a button on a particular screen, and clicking this button increments a value in the app's database.

The parts of the main Layout which can be modified by the plugin will need to be pre-defined by the core app, and exposed via the communication protocol. It should be possible for the plugin to inflate an arbitrary layout, and send it to the main app, which could put that inside a pre-allocated area of it's own Layout.

Answer 3

If you are just going for an increase in modularity, I would recommend using a dependency injection container such as PicoContainer, Guice or Spring.

If you want a light-weight plug-in architecture, then go for Java Plugin Framework (JPF).

It allows you to define extension points, which can be implemented by your modules. The primary job of the plug-in framework is to provide a way that you can bundle these modules (as jars), which are dynamically found by the core application and given as implementations of the extension point.