[restructuring] Special "Apps", plugin system

[hg42]

I want to start a discussion about special app infrastructure.

At first, the name "App" is too special. I would prefer "Package".

With our current structure (which could be improved later), I think special packages should be implemented as classes derived from SpecialAppMetaInfo.

The following parts could simply call methods (e.g. prepare() and cleanup()) of these derived classes:

if (app.packageName == "special.smsmms.json") { BackupSMSMMSJSONAction.backupData(context, filePath) } if (app.packageName == "special.calllogs.json") { BackupCallLogsJSONAction.backupData(context, filePath) }

...

if ( app.packageName == "special.smsmms.json" || app.packageName == "special.calllogs.json" ) { for (filePath in appInfo.specialFiles) { File(filePath).delete() } }

So the methods of BackupSMSMMSJSONAction would be part of SMSMMSJSONAppMetaInfo.

These kinds of special packages would be derived from something like FileBasedAppMetaInfo.

Derived classes should register themselves at a registry (as classes with something like an activate function).

getSpecialPackages would simply ask the classes in that registry for AppMetaInfo objects (let's call the function load for now) and gather them (this may be conditional in some way, e.g. depending on Android version, the class decides itself, possible decision variables could be given to the function or globally reachable).

load would provide a list of AppMetaInfo, which allows to load a bunch of FileBasedSpecialAppMetaInfo from JSON files in a search path (using the asset infrastructure, that already does this for script files) or may be later also compiled plugins (e.g. as libs or apps).

[hg42]

redesigning for Compose would be affected by this (in a positive way I think), so I think it should be changed together.

I am thinking of a general class (may be "Package"?), that would be the interface for the main list(s) and be respsonsible (=capsulating) backup and restore. Separating backup and restore is not really object oriented from my POV. Both operations are very dependent on each other. Everything you do on one side must be considered on the other side. So I think there must be one object that does both. That said the discussion here has the wrong title...

[machiav3lli]

Yeah,an abstract "Package" with different implementations e.g. AppPackage, SpecialPackage... This is already one of the things am considering while designing the new cache/database classes.

[hg42]

exactly!

[hg42]

another thing I am thinking of, is integrating a scripting engine.

Plugins + Scripting = Power for plugin creators

On unix you would simply use normal scripts because unix has a tradition to provide commands for access to data and a plugin could use any installed scripting language. On Android this is not as easy, normal users will not have scripting engines installed (e.g. via Termux etc.), installation is more complicated, and Android doesn't provide it's data via commands (though via databases it would still be possible).

The easiest way would probably be to add Kotlin scripts (I need to have a look, how this is done). For SpecialPackages the scripting will not be very complicated. There are a lot more users out there being able to create such scripts than integrating the operations into an existing app.

Some years ago, I implemented a scripting interface in an experimental Android app based on Java, using an abstract interface and with exchangeable scripting implementations (in this case mostly different javascript engines, that are outdated now, like Rhino). You could theoretically program a complete app via script, because it had access to the whole Java world, though this could also be limited.

Another way to do this would be providing an extension interface to apps. Then one of these apps could be a scripting host, that could load several scripts that provide SpecialPackage implementations. As a consequence this means, the extension interface should be able to provide multiple packages (PackageProvider?).

Anyways, this would all be based on an abstract Package type and SpecialPackage and derived implementations. The nice thing is, once there is such an abstract interface, derived or alternative implementations can be added without making others invalid. Newer better implementations would automatically overtake when becoming capable enough.

[hg42]

something I wrote lately, closely related to this topic:

It's unlikely, that we foresee all the future development (in NB and in Android). So, the plugin interface should allow for different kinds (classes) of plugins and this should be extensible. Ideally plugins could also extend those classes. I would prefer them to be scripts, because this enables ordinary users to write such plugins (e.g. by looking at existing ones and modifying) and this allows for experiments.

I would have added something already, but there are some unsolved problems:

• the scripting language interface (jsr223) in Kotlin is a moving target, sometimes it works for a short time, then it is broken again. The ups and downs were quite frustrating. So, some months ago, I decided to wait some time to let the scripting system become more stable.
• one question is, if Kotlin is the best language for creating plugins
  • it would be the most powerful option, because NB is written in Kotlin
  • it is more like an expert language
  • it is not a more common knowledge like python or javascript, resulting in less users that would write plugins (and I expect only a few that do this anyways)
  • jsr223 would allow to use the language of your choice (well, it seems it must be added to the compilation), but this would fragment the plugin creators into smaller groups (and the groups will be very small anyways)
• the way Jetpack Compose works seems to prevent scripting of the UI It uses a tweaked compiler to create hidden code. I have some hope that it might still be possible, because for jsr223 the compiler is included in the app as a library. But the results of my experiments didn't look hopeful at all. They play too much tricks and officially they don't even think of supporting this. They seem to be happy, Jetpack Compose works in normal situations. And they generally follow an 80/20 principle. Scripting seems to be a minor activity in the whole picture without any priority.