Overlay Notifications

@rigrig obviously you're working on https://github.com/espruino/BangleApps/p­ull/2205 at the moment

As we are sending an event, do you think it's compatible with just sending the event direct from Android/iOS?

Right now the messages app probably wants to handle event.t=="remove" even if something else has got the event (so it can be sure it's 100% gone from the messages list) - but I guess it could do that and then check 'event.handled'?

I think it would really help to think about what we want to use this for

All I can think right now is:

Music

We get the event in the music app, mark it handled so it doesn't get stored in messages.json - all good.

Although if we split out the GUI for the existing music app in the messages app, that could maybe fix this more nicely, and would reduce duplication on the watch.

'new message' overlay

What this thread was initially about.

Personally, I'm imagining that the message (or part of it) would appear in an overlay in the current app, but then if you tap it, you go to the messages app where you can see it in more detail (maybe scrolling). Swiping the overlay could dismiss it and mark it read.

So in that case, we probably still want the messages library to be storing the message? but we don't want it to automatically load the messages app - we want to let the overlay do that.

So maybe we want msg.handled and msg.noMessageApp?

Or do we want to not store the message until there's a user interaction with the overlay? That could be tricky, and if something happens (maybe an alarm goes off and the alarm app is loaded?) the message could get lost.

Messages widget

We already have widmsggrid and it probably makes sense to split the messages widget into a separate app, and then users can install whichever one they want (or not have one, and have the message overlay instead)?

Calls

Again, I guess an overlay for this is good. And in this case maybe we don't want to store anything in messages.json? So we just set handled:true.

....

... is there any other use case I'm missing?

But I'm still struggling to see why we need to emit the event from Android/iOS (apart from it maybe being a bit tidier). I think we can pretty much do what's needed as-is?

As I mentioned in the last post, there can always be different apps implementing the message library - but I think it's important that you only have one installed at a time? *And that there is one always installed by default*.

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. It also doesn't ensure that when a user installs Android Integration they actually get a messages implementation that works.

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)