Obviously it's a draft but there are some issues I can see...
it looks like this breaks music for Android at the moment
apps that work on the events can no longer mark a message as 'handled' (so all messages get saved and load the messages app)
no iOS support there either
As you say Bangle.on("message", .. require); doesn't add much extra memory use or load time. It will add some though, which I doubt Bangle.js 1 owners will be super happy about given how tight memory is for them at the moment.
If we did something like:
Bangle.on("message",function(type,event){
if (!event.handled) require("messages").pushMessage(event);
});
It would solve the 'handled' issue as long as other apps 'numbered' their boot code so they could ensure it got executed first. I'd be inclined to push call through the same message event too - I don't really see many benefits of having a new event type for that as it just means more handlers = more memory and boot delay.
What do others think?
Adding a handler for the Bangle.on("message" seems to work right now. So why are we doing this? does it actually let you do anything you couldn't do before, or is it just because you don't like the current arrangement?
Is it more efficient? When a message arrives it may save maybe 2ms of processing time.
Does it save memory? No - it uses slightly more RAM - all the time
Does it make things faster? No - it slows down boot slightly - for every app.
Right now, a message comes in from the phone, is handled by the Android app, goes to the messages library where it is stored, and then the messages app displays it.
Is it that you want to be able to display the message differently in the messages app? You were posting earlier about splitting out the GUI. We could do definitely something like that...
or 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?
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.
Hi - Thanks for the PR.
Obviously it's a draft but there are some issues I can see...
As you say
Bangle.on("message", .. require);
doesn't add much extra memory use or load time. It will add some though, which I doubt Bangle.js 1 owners will be super happy about given how tight memory is for them at the moment.If we did something like:
It would solve the 'handled' issue as long as other apps 'numbered' their boot code so they could ensure it got executed first. I'd be inclined to push
call
through the samemessage
event too - I don't really see many benefits of having a new event type for that as it just means more handlers = more memory and boot delay.What do others think?
Adding a handler for the
Bangle.on("message"
seems to work right now. So why are we doing this? does it actually let you do anything you couldn't do before, or is it just because you don't like the current arrangement?Right now, a message comes in from the phone, is handled by the Android app, goes to the messages library where it is stored, and then the messages app displays it.
messages
app? You were posting earlier about splitting out the GUI. We could do definitely something like that...