Hi,

As I understand it, you can still do:

var _GB = GB;
GB = function(e) {
 // your stuff
 _GB(e);
}

But yes, what you suggest is a good idea.

My only concern would be that on Bangle.js 1 RAM is very limited, and storing all these handlers all the time (as opposed to one function that just sits in flash) would eat up a bunch more.

What we could do is just emit a GB event, so you can do:

E.on('GB', e => { ... })

That way no more memory is used unless you add a handler

E.on('GB', e => { ... })

it would definitely make everything cleaner

instead, what do you think of the "hard coded" call between "Android" and "Messages"? Do you prefer to keep the two apps as if they were a single thing or could you think of a RAM-friendly way to divide the two contexts?

for example the Message app registers its handler through E.on ("gb" ...) and the part relating to notify / call are removed from Android.

instead, what do you think of the "hard coded" call between "Android" and "Messages"?

I think for the moment it's best to keep it. Messages needs to work for iOS and Android, so the idea is the Gadgetbridge-specific stuff should live in the 'Android' app. If someone wanted to add notifications from Windows (for instance), they could then add a new 'Windows Integration' app which would also call to the messages library.

However, if you don't like the 'messages' app you can always uninstall it and create your own app that provides a messages library that does what you want? So I think it's still reasonably flexible?

At the end of the day, if there's a real use case that needs it then we can change it. But if it's just you that wants to try doing your own thing, I feel like it's better than you just modify the source of what's already there.

you are right,
the only "problem" that I detect (and by "problem" I mean that for a non-programmer user) is that to create a custom "messages" app you must also modify the "Android" app (unless you remove the app standard "message", as a dependency of the "Android" app, at each update / reinstallation).

The fact that I have implemented my own "message", "android", "alarm" app; I would like to publish them but I think it is confusing on the store to understand what and how to install it.

imagining to create a common interface for each notification manager, then the same methodology I proposed earlier could be much more RAM-friendly by passing only the name of the library to be called:

if ( event.t == "notify" )
{
require(handler["notify"]).pushMessage(event);
}

in theory only the names of the libraries remain in ram (which could also be saved on flash), the function is loaded only when needed.

I think actually the solution to that might be what we did with the old notifications... Give each one a 'type' or 'notify' (or in this case 'messages')

https://github.com/espruino/BangleApps/blob/master/apps/notify/metadata.json
https://github.com/espruino/BangleApps/blob/master/apps/notifyfs/metadata.json

and then the apps that need them have a dependencies field: https://github.com/espruino/BangleApps/blob/master/apps/gbridge/metadata.json

Then by default the default messages app gets installed, but if you installed your own messages app first (or you update) then that one is used.

The fact that I have implemented my own "message", "android", "alarm" app;

Is there any way we can just bring some of your improvements into the default app?

The alarm app especially strikes a chord with me as someone created 'Q Alarm' rather than tweaking the existing alarm and it's caused nothing but trouble (buggy, breaking other apps). It seems crazy to have a third alarm app.

Is there any way we can just bring some of your improvements into the default app?

yes of course, I was thinking of creating alternative apps because I have changed the graphics and functionalities enough.
(maybe someone doesn't like how I implemented it and prefers the current version).

I implemented the alarm app (based on qalarm) with the changes I requested to gadgetbridge (alarm repetitions).
The idea of the app is to work exclusively with GB (so I have not implemented the timer). I could create a pull request in WIP so we can discuss it better.
(I guess I'm a little OT)

I think actually the solution to that might be what we did with the old notifications... Give each one a 'type' or 'notify' (or in this case 'messages')

for this solution I do not know .... if it is "old" I think there is a reason.
honestly I don't know if it simplifies or complicates the code ...
maybe someone else's opinion would be interesting.
anyway, I think your solution:

E.on ('GB', e => {...})

allow to clean up the code.

Just wanted to tell you, that I would appreciate having an event: E.on('GB', e => { ... })