One reason I'm a bit against this is that you assume that require("messages").pushMessage(event); should only go to the messages app.
As I'd said above we can trivially modify the dependency field in the app loader (the code for this is already there now I've pulled out the icons to messageicons) so that the 'messages' library can be provided by any app that wants to handle messages.
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.
I don't think you ever really answered this, but IMO it's important:
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?
It makes a difference where we need to open up the API.
For instance it's no use implementing the event as you say if all you want to do is change the way messages are displayed in the messages app - because then you'd just end up duplicating all the code to handle reading/writing messages.json.
In that case, what we really care about is what you said initially - a way to split off the GUI parts to different apps/files. And I'm all for that, because I think it solves a real problem - one of the main complaints is people want to display messages differently (although nobody is yet to make a PR to actually just improve the standard message app :( ).
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
One reason I'm a bit against this is that you assume that
require("messages").pushMessage(event);
should only go to the messages app.As I'd said above we can trivially modify the dependency field in the app loader (the code for this is already there now I've pulled out the icons to messageicons) so that the 'messages' library can be provided by any app that wants to handle messages.
For example right now we have
require("textinput")
- buttextinput
can be provided by any different keyboard app. Orrequire("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.I don't think you ever really answered this, but IMO it's important:
It makes a difference where we need to open up the API.
For instance it's no use implementing the event as you say if all you want to do is change the way messages are displayed in the messages app - because then you'd just end up duplicating all the code to handle reading/writing
messages.json
.In that case, what we really care about is what you said initially - a way to split off the GUI parts to different apps/files. And I'm all for that, because I think it solves a real problem - one of the main complaints is people want to display messages differently (although nobody is yet to make a PR to actually just improve the standard message app :( ).