You are reading a single comment by @Gordon and its replies. Click here to read the full conversation.
  • 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 :( ).

About

Avatar for Gordon @Gordon started