Plugins architecture for an Android app? [closed]

Question

THIS QUESTION HAS MOVED TO https://softwarerecs.stackexchange.com/questions/27841/plugins-architecture-for-an-android-app

---

I want to implement a plugin system for an Open Source app, because it has become really large, with many features that only a few users need. Releasing different apps is not a good solution, because userA wants feature7 and feature24 whilst userB wants feature39 and feature24.

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

Here is what I would like a plugin to be able to do:

• Redefine the layout of a particular screen (load deflated XML?)
• Redefine a method of a class (load dex class?, AOP?)

For instance, one of the plugins must add a button on a particular screen, and clicking this button increments a value in the app's database. This is not doable with Content Providers and Intents, as far as I know.

I want to avoid making the core app's code complex with tons of hooks everywhere.

The form of the plugin could be a file on the SD card, an app, or anything else.

Answer 1

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 2

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 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.