Copnclude: single app runtime environment. --- Yes, multi app runtime environment asks a lot from the platform - HW and SW (say Espruino). but have you given it a though?

Enabling for multi app runtime environ means that a lot of other elements / processes have to be aware of it. In a multi app runtime environment each app would be like an object that understands onInit()... on the other hand - matter of fact of js - there would be isolation from each other... so probably not practical...

Building applications as modules and have a module loader vs. an application loader could do it. The challenge of shared modules though remains... and reentrance becomes a topic.

Yeah, I think right now we don't want to do multitasking. Not just the memory, but how you handle the screen. Since everyone has direct access to it, it'd be very difficult to make sure there wasn't flicker/overwriting.

However widgets are something which doesn't use much space and which would make sense to run alongside apps. For instance battery or 'steps taken today'. It'd be nice to keep those running, but the more I think about it the more sense it makes from a stability point of view just to reload them each time.

So I think...

• load(filename) addition to allow a specific file to be loaded
• E.on('kill' event to handle saving of data when JS is torn down
• Bangle.loadWidgets function to allow an app to explicitly request widgets are loaded - should help with app development as well

So this is not about reset that is done when holding button 3 (and already clears the memory?) but also when pressing middle button to show the app list? At that time app shown would be killed like this?

I would still like keep something running on background without interrupting it. How would you do e.g. receiving messages from phone when something is running? Would this reset bluetooth services too?

Correct, yes.

Yes, it would reset the Bluetooth services (but only if disconnected), which isn't ideal. My concern is that stability/memory usage would really suffer with any buggy apps/widgets if we're not doing a proper reset.

In terms on Bluetooth services/UART/etc it should be fine. The reset is done in one go, so any data that comes in (via services or UART) gets shoved in a queue. It'll just be put aside until all the required code is running, and then it's executed as normal.

Potentially the non-reset approach could be added as an option in settings, but I think in most cases it won't cause a great deal of trouble.

well, yes, true about the stability. Maybe there could be white list/flag for some apps/widgets to keep state ,but then the next non-whitelisted app would cause restart and state is lost anyway. Or maybe some subtree of variables can be kept between restart? So there would be safe place for app to store small state. Maybe when app exits it could be kept in single variable per each app - serialized heatshrinked json. Or is letting apps save state to flash all the time good idea?

Saving state to flash isn't that bad, especially if it's in response to a user input it's never going to happen enough to cause a problem - but I figured E.on('kill' would allow stuff to do that if it wanted to (rather than all the time).

Keeping a variable subtree is possible, but it'd require some serious hacking around with Espruino and I'm not sure it's a great idea.

I think having a core enabler E.on('kill'... in place and choosing a reasonable default lays a good foundation and benefits in most situations. For more intricate handling, hooking into core enable is good enough, for sure now, until more experience has been accrued.

Just added E.on('kill' to Espruino, so just the 'load' functionality to do

'load' sorted too, Bangle.loadWidgets added, apps updated