The Flowee Pay front-end is expected to need modules and contexts. You may think about an extra tab in a desktop application to place the idea. In Flowee Pay we expect that different functions and ways of using your Bitcoin Cash will all live in the same application. To make sure this stays simple enough to use it is important to modularize this for the user interface.
Modules are then a specific (set of) features which are grouped together. For a "Payment" application, as opposed to a wallet, there will be various features that are added which don't really have much to do with money per-see. For instance a page where you can time-stamp a document on the blockchain.
Application in the Application
A module is placed in the modules subdir where they are automatically picked up by the build system. The base requirement is to have a class that is the ModuleInfo, which has two methods and inherits from QObject. (example cpp, .h).
A module has its own translation context making translations possible to do separately from the main application. More on translations.
A module can use the library of CPP and QML classes part of the main application, but not the other way around. A specific page has to be created for every entry-point into the module which is loaded by the main application when the user requests it.
At this point the code only supports a 'send' button, the general approach is described further:
Modules in the GUI
The user has the ability to enable / disable such modules based on what they want to take valuable screen-real-estate. As we get some more modules we'll end up having a special module that allows people to discover modules. The normal is then to turn off many modules at first start and allow users to discover modules interactively at their own pace.
User Screens
Many modules will essentially be an extra screen in the app where module-specific GUI elements are shown and the main feature is accessed.
The CPP class MenuModel will be the main entry point for all those modules, the model is the one you see when you open the menu (hamburger many top left) on the mobile application. The entries there come from the model. The effect of this is that a new module can be added and when its configured to show up in the menu model, the user can click on the item to open the module specific screen. The user presses 'back' and the module closes.
Additionally we will have the ability for a user to make a module show up as a tab on (bottom of) the main screen. This will naturally be limited to the most used modules as the space there is quite limited.
Payment Plugins
Not all modules require a full screen to be usable. Various useful ones will simply fit into the main payment flow. That is where this type of plugin comes in.
The 'build transaction' screen in mobile, and the 'send' tab in desktop both already use this. The most used feature in a transaction is a new destination. Where normal money is sent. This you will find front and center in the UX. But the ability to select inputs is a payment plugin: a separate widget that allows the user to create a more specific transaction.
Additional expected plugins there are "templates". For instance a transaction can be built to send money to all employees and the plugin simply converts the templated amount in dollars to the current exchange rate.
Modules on the backend
Modules are packaged as normal part of the application, not completely separated or something super secure. As such it is relevant that we keep all of them in the main repo and avoid some ability to load plugins and run arbitrary code which then has access to the users funds and keys, as that would be really irresponsible.
When the menu-model is used, the module (at least its UI part) is loaded only when activated. And unloaded when it is finished. The backend can be handled the same way with some care, in order to avoid any bad things happening. But, again, it is up to the developers to ensure and we do this all in the main repository to keep the code sane and honest.
A module can be coded largely in JavaScript, if the creator so chooses. While still having access to the C++ objects (like the wallet) that are placed in its context. It would be interesting research to see how much isolation can happen in that JS context and if things like downloading files from the Internet are possible or not in that JS context.