I was thinking it would be cool, to have a repository of compiled apps, and use the compileandload.py to load a chosen app from a site. Kind of like the Notification app can be loaded from the network.

Have a computer/android/blackberry app, that brings up a current list of available apps, and you just chose what one you want, and it gets loaded.

Yeah, we're thinking about a GUI for that!

What might be interesting is a format that would allow you to download an App(let) from your watch while it is running to execute. Imagine a UI similar the notification app, where along the bottom there is a button to see what Applets are on your phone to download and execute. When you click it, it would request a text list from a companion piece of code on your phone. It would list all the applets available. Say games and visualizers/screensavers. You click down to pick asteroids and the watch tells the phone to "give me the asteroids bin". These Applets would have to be small (5k?) and abide by a protocol to exit (press and hold for 3 seconds?), but the watch would download this data into memory.

After downloading, it would create a function pointer to the beginning of the data downloaded and deference it to start the applet running (e.g the equivalent of void main()). When the applet returns, the original app continues to execute.

Something along those lines to try to allow more apps be easily accessible without losing the base instance of what you want on your phone (i.e. time/alerts). Also, you could have easier access to a large memory footprint of apps without having the be installed. They would be loaded on-demand.

Just a thought for discussion purposes.

I think that could work. Duane and I were discussing this before, Duane brought up the fact that the original Macintosh actually had similar memory constraints. We'd need a resource manager to control memory access, but yeah...I think this could essentially work. Want to give it a shot? We could get your full access to the inPulse build environment if you're interested.

@Eric. Maybe someday. Just getting up to speed. Still in newbie mode, but will keep on trucking.

With that, had a thought. Relegate a single line on the top of the screen across all applets to render:

- Time (centered). Hidden if the current applet shows time
- Bluetooth indicator on the left
- Power indicator on the right

Ala iphone.

Either they would have to abide by it, or there would need to still be a resident amount of code that handles the interface to the rest of the runtime system.



I'd be hesitant to hand over all control the app; there should still be some form of a monitor that keeps track of outside things (like, say, battery state).

If the code is all compiled with -fpic, it wouldn't even matter where the loader put it. My thinking is that each app could expose a small structure of function pointers for the different events (init, loop, button, etc) and the monitor would dispatch through those tables (this is how my multi-app framework does it). And if all data were accessed through a pointer (i.e., no globals), then it wouldn't need the common block hack.

Eric -- when we get my watch working again, I'd be interested in doing some tests with storing code in the spiflash section to try to build a general purpose segment loader.

@hudson. Running your multi-app framework on my watch right now.

Good stuff. Thanks for posting.