Hello,
long time Sleep as Android user here. I’ve been following the journey and loving the app every day a little more, with all the improvements and features you are developing. I greatly appreciate your effort.
I currently have a Ticwatch E and plan to upgrade to a Ticwatch Pro 3, both running Wear OS. My request is very straightforward: a standalone app.
Nowadays, every major wearable platform has some kind of sleep tracking, most of which have it available even when disconnected from a phone. Wear OS was one of the few platforms to not feature sleep tracking (without third party apps like Sleep as Android) - however, with most recent watches (Oppo Watch, Ticwarch Pro 3, Suunto 7…) all those companies have started implementing their own sleep-tracking functionality, which is available, as all other ones, even offline.
This clearly means that moving to a newer Wear OS watch that implements the same feature, but with offline-tracking support, would probably make new and old users just stick to that, as the advantages are many. I will still try and avoid using the Mobvoi sleep tracking app because it seems to not track REM phases, and becomes pretty much useless. However, I have to admit that offline mode is appealing, also because of the battery saving implications.
Now, I know that this question has been asked multiple times since about 2018, however, making it at least partially standalone seemed like a simple thing to implement (see here).
I thought of some possible ways to do this, and I came up with two main possibilities:
- Make the watch simply collect all data, and save it locally in a small SQLite DB or JSON file, which can then be synced to the watch all at once in the morning.
- Make the app really standalone, as other manufacturers are doing.
Both things imply very different advantages and disadvantages - however, I think that in 2021 it is becoming very important to have at least a little support for such a feature. Transmitting data over BT is one of the most battery-heavy operations on WearOS, and even if you optimize it such that data is only sent every few minutes, being able to enable airplane mode would save a huge amount of battery overnight, given that the phone also does many other network-related background tasks such as checking notifications, updates, syncing other apps, and so on. I have no way to accurately test this, but I’m pretty sure that (for example) on a low-performance Ticwatch E, this would make a big difference. If I enable airplane mode and don’t track sleep with Sleep as Android, but use a third-party app to constantly monitor my heart rate (every 1m), battery goes down by only about 8% overnight. Moving it to 5m means a 5% decrease overnight. Not tracking anything means about 2% loss overnight. This is clearly promising, as Sleep as Android pretty much only tracks gyroscope/accelerometer and heart rate sensors for calculating data. Just for reference - currently, the Ticwatch E, in your table with all devices is listed as having a 17% battery decrease overnight.
Now, back to the two implementations.
Clearly, number 1 would be the easiest and fastest to implement, and would probably be pretty sufficient for the time being. You pretty much just need to collect the data exactly as you are doing right now, but allow doing it while disconnected from the phone, and then promt to connect when you stop tracking OR (better) auto-sync it in the background, or again, make the Smartphone app contact the phone and download data as soon as you open it (pretty much what Fitbit devices do: they sync when you open the phone app). This would be great, but have a few drawbacks: for example, determining when a person falls asleep (or even wakes up in the morning) would be impossible because the watch is only collecting sensor data and not analyzing it, thus making it necessary to start and stop tracking manually. Side note: Fitbit devices sync only when you open the mobile app, but they still implement the sleep tracking algorithm on-device, thus being able to auto-detect important moments such as falling asleep and waking up.
Here, option 2 comes into play. This is what other companies are now gearing towards, both WearOS, Tizen, and even very simple fitness bands. Having a truly standalone app would be the best possibility ever. It would mean being able to automatically detect fall-asleep and wake-up times, automatically starting and stopping tracking, sync to mobile app/Google account/Google Fit, and in the future it would even make possible (although clearly of minor importance) implementing smart alarms, and Google Fit-like tabs (when you swipe from right to left on the watchface); allowing to see data and cool graphs directly on the watch (again, like other brands are doing…) and so on. This would clearly require more work and dedication, but given that the algorithm just needs to be ported from the Smartphone app, it wouldn’t even be particularly hard - it would just require a little bit of time, and that’s why imho it’s important to start working on a standalone version ASAP. It would pretty much just be a light version of the Smartphone app, with more simple controls, less buttons and clutter, and support for small screens. I have heard that sideloading the mobile APK works pretty good, so that is another consideration to make - to start from that app instead of starting from scratch.
I am an experienced Java developer and relatively good at Android; this month is going to be very hard and full of commitments and appointments for me, but if the Sleep as Android API allows for it, I could eventually start looking into this, this summer. I think, however, that an experienced team that really knows how Sleep as Android is structured would be better suited for such a big app.
I obviously don’t expect you to do it now, and even in the future - this is just me explaining why I think it’s becoming everyday more important, and why this would be a great feature for the community and the whole platform. I am always available to help testing, debugging and even developing the app.
Thank you very much,
Lorenzo.
