1. I don't see any examples for foreign key constraints (ON DELETE and ON UPDATE) or UNIQUE constraints. Are constraints still supported?
2. How is row-level privacy implemented? Are "forbidden" rows not synced by the server logic, or are they encrypted?
I'm integrating daily steps walked into my workout/nutrition tracking app EverBeat for Android. I've noticed that this is an important metric for many people interested in losing some weight.
I estimate burned calories on the minute-to-minute level for all activities, which is a fun challenge.
For the steps to calories conversion, I require time and distance walked. Unfortunately it's surprisingly difficult to get some kind of distance information from Android. Google Fit API provides this data, but will be killed soon. The RecordingAPI will hopefully provide this in the future, but not yet...
> I have a Renpho scale, the way it works for me is that when I step on the scale it turns it on and connects to my device via bluetooth which wakes the app. The weight is captured and synced in the background to both the Renpho cloud service as well as the local Health Connect.
I bought a Wifi scale specifically so I don't have to have my phone with bluetooth on, nearby. Does the BT-connection open the app itself, or just initiate a sync in a background service?
I was under the impression that it is impossible to access Google Health Connect in the background – I get access-errors in my log when I start my own app from the IDE while the screen is off.
> [...] they get a lot of write storage to health connect for free from the API
Is this really an issue that is solved by using Google Health Connect?
> As I understand it the access is 30 days prior to the first permission given.
You are right, I edited my original post accordingly.
> It's more secure and allows a wider more diverse suite of apps to integrate into it.
It's more secure, yes. But since the data stays on the device now, web apps cannot read or write health data anymore. You need to develop a dedicated app to access the data on the device. And the user has to interact with the app, or the data will not be accessible.
E.g. my Withings scale writes my body weight to Google Health Connect. But I need to open the Withings app every time for that to work. The app-developers cannot do this in the background afaik.
(The data flow is: scale -> cloud -> app -> Google Health Connect.)
Another issue I see is: There is no incentive for app developers to write data to Google Health Connect.
Even if you subscribe to the idea of using it as your data-store, you will lose access to the data if a user uninstalls your app. It's only possible to read data up to 30 days in the past, or however long the user has installed your app – hopefully they don't decide to reinstall it.
I really appreciate the inter-connectivity Google Health Connect allows between apps, though.
Titan looks similar to the workout app that I'm developing: EverBeat!
I'm also developing it for myself right now, that's why it is Android only atm.
My goal is to employ subtle gamification to get the user/me to the gym more often.
I was wondering where you got the data from to know what muscle group is used in each exercise?
Oh, I implemented something like that for my Android app. It seems to work quite well. I don't have many users yet, though.
I replicate the clients Sqlite DB to a central server (over a REST-API) where it is synced with existing data. I use an CRDT, so changes don't get lost and as long as the clocks of all the users devices are accurate, the merges are in the correct order.
This enables offline access, but also the use of my app without an account. You can always merge the data later.
Multi-device merge is also possible, if you create an account. Especially the multi-device merge was a big headache until I settled for this approach.
Since it is a home-grown solution I still have to do some manual stuff that could be abstracted away, like converting datatypes to and from JSON, Kotlin, PHP, MySQL. There's not always an equivalent datatype in those technologies.
This approach probably won't work well for big databases that share data between multiple users, though.
Okay, I guess you could attach that functionality to an existing component.
It just feels wrong to me, that you would put something that looks like a separate component into a hook to inject into another component.
I thought there was some benefit in doing it like this, that I cannot think of...