Overlay Notifications

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

Well, I'm working on my own messages app, but it makes big changes to how messages are displayed, so I'd be reluctant to make a PR to "completely replace" the messages app.

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

My idea was that msg.handled = don't take any visible action (like loading apps)

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.

We can save it in on("kill")

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.

A problem with music specifically is that you expect a lot of those events to happen, we don't really want to write any of them to flash anyway, but need to for the app to pick them up.
An idea: maybe simply not handle them in the messages app at all, and we can have a separate overlay app to show music?

the messages app probably wants to handle event.t=="remove" (...) but I guess it could do that and then check 'event.handled'?

Yeah, that was the idea. Same goes for widgets.

move all the logic ( saving messages, managing music... ) to an app/library/... and move the GUI to a separate app

I find it "wrong" that the pushMessage automatically saves the messages that arrive

I agree, and I think right now things are confusing because a) we bundle the library with the default GUI, and b) the library+GUI are too tightly coupled.

What I'd like to do:

• completely split out the default GUI from the messages library, and make it event-driven.
  
• keep pushMessage in the library: it would be much simplified but just to deduplicate android/ios code (and combine musicinfo+musicstate events)
  
  

I think that since this commit, we can split the library into a "module".
android/ios could still depend on messages(the default GUI), which would depend on the library, so fresh installations still work out of the box, and custom apps would set events to handled, without needing to uninstall the default.

Proposed require("messages") API:

pushMessage(event): emit appropriate "message" event, *does not save it*
save(message): save message to flash (if not already saved), sets `message.saved=true`
status(): checks saved messages, returns "new"/"old"/"none"
getMessages(): returns array of saved messages
accept(message): send positive message response
dismiss(message): send negative message response, erase message from flash, only if it existed: emit "message" event with `{t:"remove"}`
launch(message): launches the default GUI by emitting a `type="launch"` event
write(messages): replace all stored messages with given array (for use by GUI on exit)
// not 100% sure about these, but otherwise it would be duplicated in most message apps...
buzz(message): start buzzing for new message
stopBuzz(): stop buzzing

The overlay notification app can then

• listen to on("message", (type,msg) => if (type==="text") // set msg.handled=true, display msg, etc.
  
• On tap: launch the full app by doing require("messages").launch(msg)
  
• On swipe: require("messages").dismiss(msg)
  
• Do on("kill", ()=>require("messages").save(msg) to prevent them getting
  
  
  

And we could think about adding music/call overlays either to the default GUI, or as separate apps.