Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removing widgets/existing apps when loading a new app #65

Closed
gfwilliams opened this issue Dec 12, 2019 · 9 comments
Closed

Removing widgets/existing apps when loading a new app #65

gfwilliams opened this issue Dec 12, 2019 · 9 comments

Comments

@gfwilliams
Copy link
Member

gfwilliams commented Dec 12, 2019

Following on from... aca3ce8#commitcomment-36387513

I'm not happy about the current solution (of manually removing listeners from objects) at all - so yes, having a destructor would help, but there'd have to be one for the clock app too. I'm considering maybe just modifying the Bangle.js firmware to allow load(appname) which would tear down everything and start afresh with the supplied JS file from Storage?

That obviously means you then can't have widgets that stay running - but they'd get removed anyway every time you long-press BTN3.

What I could do is add a E.on('kill' event which gets fired just before everything is torn down, so widgets/apps could save their state. It might be a useful thing for Espruino in general.

gfwilliams referenced this issue Dec 12, 2019
…oading an app

remove hasWidgets for now - need to reconsider how this should work
@muet
Copy link

muet commented Dec 12, 2019

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.

@gfwilliams
Copy link
Member Author

gfwilliams commented Dec 12, 2019

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

@fanoush
Copy link

fanoush commented Dec 12, 2019

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?

@gfwilliams
Copy link
Member Author

gfwilliams commented Dec 12, 2019

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.

@fanoush
Copy link

fanoush commented Dec 12, 2019

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?

@gfwilliams
Copy link
Member Author

gfwilliams commented Dec 12, 2019

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.

@muet
Copy link

muet commented Dec 14, 2019

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.

@gfwilliams
Copy link
Member Author

gfwilliams commented Jan 16, 2020

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

@gfwilliams
Copy link
Member Author

gfwilliams commented Feb 4, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants