Overlay Notifications

Obviously it's a draft but there are some issues I can see...

yes yes, I know there are some problems, before continuing I wanted to know if the methodology could be good.

It would solve the 'handled' issue

that's more or less the solution I was thinking of (and which is currently implemented as a workaround in the "message")

I'd be inclined to push call through the same message event too

at the beginning I had implemented only one event; logically it seemed clearer to me to divide it ( message, call, music, other... ).
It actually consumes slightly more ram; I might go back to the "old" method. (only the "message" event for all )

So why are we doing this?

certainly a more "open" program uses more resources but I think it's more convenient, in a modular environment like this, to manage the various apps as separate things.
write, hardcoded, that an app calls another app ( require("message").pushMessage directly from the android/IOS app )
it means creating a bond that goes against the logic of apps.

the point is to try to understand if we want to implement a logic where multiple apps can manage various types of messages, or if the "notifications" world must be closed (it is true that everyone can implement their app as they see fit, but this means code fragmentation and poor management/updates).

I think so:
android/IOS raise an event -> any app can handle it
(the "official" message app is capable of event handling).

Does it save memory?
not directly, it depends on the implementations:
currently my version of message is lighter than the official one because it doesn't store messages in mass memory and has a "cleaner" UI with fewer settings.

if, on the other hand, we don't want to give the possibility of managing notifications to multiple apps, it would be convenient to be able to change the app that is called by the Android/IOS app

give the possibility to write the name of the app to be called in the "android.settings.json" file (by default it would be "message") and then replace the occurrences with:

require(settings.appName).pushMessage(ev­ent);

so that if one wants to implement his own app he could do something like this:
in the settings of the app create a button like "set me as message manager" which calls

require("android.lib.js").setAppName("my­_custom_app.js")
//( or IOS )

all apps should work as usual and you would have the possibility to manage messages with any app (if desired, the custom app could still call the require("message").pushMessage(...) )

let's say this solution is a hybrid.

it shouldn't add any boot code, just an additional variable in the "android.settings.json" file (which is already read during boot so it doesn't slow down / take up more space)

splitting out the GUI

it was an idea, but perhaps much more complex to apply and which made everything even more restrictive in some respects.