Overlay Notifications

You are reading a single comment by @rigrig and its replies. Click here to read the full conversation.

•

Rarder44
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(event);
```
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.

•

rigrig in reply to @Rarder44
it would be convenient to be able to change the app that is called by the Android/IOS app

smessages has this in a boot file:
```
  global.load = (_load => file => {
      if (file==="messages.app.js") file = "smessages.app.js";
      _load(file);
  })(load);
```
It feels rather hacky, but it works, and is cleaned up automatically when you uninstall the app.

•

Rarder44 in reply to @rigrig

It feels rather hacky, but it works

yes it works, but I don't really like the approach... I think that keeping these methodologies leads to some apps struggling to communicate with others in the end.

At this point I would override the "require" function so as not to directly load the "message" library (and its pushMessage )

Overlay Notifications

About

Espruino