[request] cron, background services in ciq

Thanks for the suggestion. We've discussed making background services of some kind available, and it's something we'd like to eventually do. Right now, battery life is high on the priority list and system resources are pretty limited, so it's not feasible. That doesn't rule it out in the future as Connect IQ matures and our hardware resources are less restricted.

We don't need more. I think 5ms/5min/slot will be enough. If app need get json from network one per 30min.

We don't write application 'in the background', but more conceptions/applications need to collect a data in time (battery widget graph, ABC data, inet services, positions).
We need some features to run small low power services with interval like cron. Its important if we will have good intersing applications in the store.

Maybe this can be combined with the ability to dynamically setup alarms to be fired even when a widget or app is not running?

On android devices we have a backgroundservices. And we can get some 'power' (wakelock) in interval do this service. I think is too complicated on the watch.
Cron looks like alarms table ;)

I thing so background app will be the part of any application type but defined in other 'background class'. On 'tik' this class are created, run and destroy. But share one storage with main app, send popup notify to user or generate sound, vibrate.
Main app can register/unregister 'background service' in crontab.

Other think is share variables/storage - between watchface and widget for example. I will be check/store something in one minute interval - on watchface, and recalculate, parse this on widget.

Thanks for the suggestion. We've discussed making background services of some kind available, and it's something we'd like to eventually do. Right now, battery life is high on the priority list and system resources are pretty limited, so it's not feasible. That doesn't rule it out in the future as Connect IQ matures and our hardware resources are less restricted.

Shared storage between a watch face and a widget would go a long way towards accomplishing this. The watch face could do some extra processing and store the result, and the widget could use those results. I wouldn't think that should impact battery all that much, at least not compared to a background service running. Another benefit of this approach is that widgets could be more lightweight, as some of the processing would be offloaded to the watch face.