Overlay Notifications

do you want to be able to handle/display messages without them even being stored on the device? Do you still want to be able to store some messages? Or do you not want to store any?

The more I think about this, the more I feel like we could have one messages library that all apps can interact with to add/remove messages. But we make sure that library can be implemented by any app that wants to (eg like sched or textinput)

that's exactly what I meant, move all the logic ( saving messages, managing music... ) to an app/library/... and move the GUI to a separate app (perhaps with an app type like for example "clock" )
to make everything more compatible I thought of using events, so as to be able to manage each app independently, but I see that we don't really like that idea.

I believe this "library" should provide the basic methods which can then be used and configured by the user / by whoever will program the GUI.

for example I find it "wrong" that the pushMessage automatically saves the messages that arrive; I believe that the two things ( message management / message saving ) are 2 separate things and the library should give the possibility to use the two functions separately.

( PERSONAL OPINION: I find that the management of saves, views, etc via "handled"/"noMessageApp" is confusing and in the long run difficult to manage, maintain and document correctly; but I repeat it is a PERSONAL OPINION )

By having the event, we potentially end up in a situation where we have multiple apps storing the same message in different ways. And then if you delete the message on one app, it's not deleted in the other one.

however it could also be that different apps need to store different types of messages and therefore not centralize everything in a single list... mine are just hypotheses

For example right now we have require("textinput") - but textinput can be provided by any different keyboard app. Or require("sched") - we have a default scheduler, but any app can implement a new one. It's simple, it's fast, and efficient. I don't really see the issue with doing this for messages too.

this methodology for me has a "problem" (I'm not saying it's serious but more "annoying")
when you install the Android/IOS app, the messages app is also installed from the dependencies; at this point the user can also install the app he wants to view the messages which will overwrite the "messages" file by inserting his own code so that by calling require("messages") the custom app is called.
now in the custom "messages" file it is necessary to reimplement all the pushMessage,clearAll, getMessages, status, buzz, stopBuzz functions going to create a duplication of the code.
having overwritten the original "messages" you can't even recall the functionality of the other file.
(premise: I'm not sure about this point, I haven't done any tests) if the original "messages" app is updated, does it overwrite the "messages" file and therefore the custom app should be re-installed?
and even if you uninstall the "message" app, when the "Android/IOS" app is updated, for the dependencies the "message" app is also reinstalled (overwriting the files)?

in theory, these problems could be solved (at least partially) by providing a specific type of app for displaying messages. (I saw that the "notify" type exists but from what I understand it's an "old" method for handling notifications, right? )

TL;DR;

• create a library with the common features -> yes, perhaps providing more functions but which allow greater customization
  
  

a way to split off the GUI parts to different apps/files

• it is already done automatically with the creation of the library
  
• the methodology of overwriting the "message" file (or any other file) -> I think it needs an improvement to work smoothly (I'm talking more about user experience)
  
  
  

PS: with @rigrig 's suggestion i implemented a message app which i'll ask for a PR.
I overwrote the require function to make everything work; I don't like it, but it would seem to work.
PPS:

although nobody is yet to make a PR to actually just improve the standard message app :(

I think the problem is that everyone would like an ad-hoc app, and honestly I wouldn't want to touch the GUI/functionality of a program when others like it, I prefer to implement my own version.
But if there are shared choices and you need a helping hand, work permitting, I'm here :)