absolutely nothing stops you from forking the app loader and providing your own messages app implementation (or even a separate app that overrides some functionality).
you are right; this is the solution i am currently using.
the problem is that in order to have different graphics, a lot of code is duplicated between the apps, making it very difficult to maintain them. (I currently have a modified version of android and message, "updated" a few months ago).
I think it can be an interesting thing to divide the logic from the graphics in order to further customize the device.
another solution (a little less event-driver, I don't know if you like it) is to divide the graphics from the logic into 2 separate files (or something similar) in the message app; the graphics file could be a standard name (message.GUI.js) and so if everyone wants to customize the graphics, they could "just" write their own app, which overwrites that file.
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.
I believe this can be a good solution.
you are right; this is the solution i am currently using.
the problem is that in order to have different graphics, a lot of code is duplicated between the apps, making it very difficult to maintain them. (I currently have a modified version of android and message, "updated" a few months ago).
I think it can be an interesting thing to divide the logic from the graphics in order to further customize the device.
another solution (a little less event-driver, I don't know if you like it) is to divide the graphics from the logic into 2 separate files (or something similar) in the message app; the graphics file could be a standard name (message.GUI.js) and so if everyone wants to customize the graphics, they could "just" write their own app, which overwrites that file.