Brainstorming for module system

[Zverik]

Hey everyone, it's time to have something new on mobile! I always envisioned some way of extending Every Door, given its core values and functions are pretty rigid and limited (as I like it). And with Dart + Flutter, we can have either Lua or Dart plug-in functions, so why not try imagining how it could work?

Please post your ideas on architecture! I have been collecting extension ideas in #119.

As I see it, we have several options:

1. PhpBB-like extension points. Basically you define functions like initConstants() or addCustomButtons or postDataDownload in which additional processing and initialization are done. Might be hard to wrap one's head around how it works, especially for frequently-updated things like micromapping legend entries. But one of the benefits is that currect constants can be made into UI-configurable values, or depend on a mode for example.
2. JOSM-like initializers with listeners and directive list modifications. E.g. adding editorInitialized function, which gets some main class on which you execute addModeWidget or setModes(...) or addPreset. Benefit is that the plugin code is executed once (probably). Also all plugin code would be localized in a single group of objects. May complicate removing a plugin at the run time.
3. Descriptive static object, as a JSON or TOML (omg). Just list all modes and enabled presets and constants etc etc. Would still make plugging into download/upload systems use some coding, idk how.

This would probably be an amalgamation of all that, idk. If you have any experience in writing plugins for any system or making a system support plugins, I'd be interested in hearing your ideas.

[tordans]

If this comes to EveryDoor, please make "shareability" a core feature of this. Much of my work with OSM is to get others to contribute. In those scenarios I need a super easy way to tell people to "use this link" and they are set up in the right way. StreetComplete added some shareability of app state with their QR code feature, which mostly checks this box for us for SC. Something similar should be possible in EveryDoor.

Or, to put it the other way around: Don't just look at the Persona of a power mapper who wants to do something special, but always consider the persona of someone new to EveryDoor who gets informed via Link and should be able to have the correct editing experience for that use case / that context without having to follow a "guide how to setup EveryDoor for some context".

[Zverik]

Good idea, I've added it to #119.

[Zverik]

The discussion was moved to OSM Forum.