Android Question Late binding of libraries?

[Troberg]

Is it possible to make a plugin framework, so that you can, in runtime, decide which of several plugins you want (not all these may exist at compile time for the host, and, may, even be made by someone else altogether).

I'll try to explain an example I've done in VB6, VB.Net and C#, just to try to explain what I mean.

In this example, I have a pretty typical administrative database frontend app. As with all such apps, one soon runs into very differing needs for import, export and reports. I don't want to recompile and redeploy everything just to deliver a report, so I made a plugin framework.

Basicially, the framework specifies two interfaces. The first is the same for all types of plugins, and is just how the plugin can present itself to the host and some basic plugin control (name, version, description, enabled). The second is the specific interface for this host interface.

So, for example, say that I want to add an export. What do I do?

I'll make the export as a DLL, which exposes two interfaces, the plugin interface and the export interface. In this case, the export interface would probably contain stuff like database connection, file name, options and so on.

Then, I just drop it in a plugins directory, where the host finds it, asks it about itself and, if needed calls it when an export is needed.

Now, I don't need anything exactly like that, but I'd like something which allows me to build a host, onto which I can, in runtime, attach modules (my own or third party). The plugin will need to be able to show UI in the activities of the host.

Possible?

Edit: I realize that the fact that B4A isn't fully object oriented will make it hard to do exactly as I described. It's not about how, it's about what I can do, so don't feel locked down.

 

[Erel]

It has nothing to do with object oriented features. You cannot load load compiled code at runtime. All the code must be inside the (signed) APK file.

 

[Troberg]

I think you misunderstood my comment about OO. I meant that my example relied heavily on OO:

Does this mean that the only way for me to build something that can, dynamically, communicate with other code not known at compile time is through intents (which isn't exactly a very tight integration, even though it would work in the examples above, as they are all pretty much fire-and-forget, no real lasting connection)?

 

[thedesolatesoul]

Your best bet is Intents. I did make a plugin framework into one of my apps using nothing but intents.
However your plugin cannot show a UI in the main app's activity. You can either use transparent activities with dialogs, so it just seems like a new window popped up (but not integrated into the main app's activity). Alternatively you can do something like bal-to-json, i.e. your plugin writes out a layout to a textfile, and the main activity finds it and loads it.

 

[Troberg]

However your plugin cannot show a UI in the main app's activity. You can either use transparent activities with dialogs, so it just seems like a new window popped up (but not integrated into the main app's activity).

Well, in my case, the main activity needs to show popups over the plugin activity (or vice versa), and, without changing their Z-order, both be able to interact with user input.

What I'm thinking about is a car computer, where the basic framework is little more than an empty shell with a menu, esttings and so on. Then, things like navigation, SMS display, black box, media playing, dashboard instrumentation and so on would be plugins. That way, I could do, for example, a mean, lean media player, while someone else who was better at navigation did a kickass navigator. However, the media player control panel, SMS alerts, nav instructions and miniature dashboard instrumentation could, depending on circumstances, overlay any fullscreen activity. So, for example, if I have a movie going in the media player, the instruments could still be visible at the top, but if a nav instruction appears, the instruction would take their place. Likewise, if an SMS appears, it would pop up on top of any screen. If I switched to navigation, the media player control panel would still be accessible at the bottom of the screen. I think you get the point.

As it is now, it looks like it would probably be easiest to do as a single activity app, but, then I exclude other developers.

I just saw it as an idea for a fun community project. A common framwork, which everyone can plug into with cool functions (and trust me, the list of cool things to do with a car computer is long, very long).

 

[thedesolatesoul]

Intent binding is weak, if the OS kills the background app you be left hanging.
I'm not so sure about this one. You seem to want an 'always on top' window.

 

[Troberg]

Intent binding is weak, if the OS kills the background app you be left hanging.
I'm not so sure about this one. You seem to want an 'always on top' window.

Yeah, probably. Basically, it would be a "one app device", at least if one used an Android car stereo system (if you haven't checked them out yet, try googling Android Car Computer).

Easy enough to do with one activity and a several panels, but hard to do if one wants an open design for others to contribute.