July - new features!
Tl; dr:
- New integrations: Renpho, Dexcom
- Writing nutrition data to Fitbit, Apple Healthkit
- Background data fetching for Terra Apple, Samsung, Google Fit SDKs
In July, summer's around the corner but Terra is working hard at it as always. We've been working on expanding the breadth of what we allow devs to access through our unified API. Here are some of the top features we feel are most noteworthy (for a full list, please look here)
Integrations
New integrations have arrived! (as always 😉 )
- Renpho (#1 smart scale manufacturer on Amazon UK )
- Dexcom ( Low latency bluetooth-enabled Continuous Glucose Monitor)
Feel something is missing from this list? Add it here! (integration requests)
Writing data to providers:
Terra has so far always revolved around getting data TO you from different sources. We've added more and more features as we went along: webhooks, retries, asynchronous requests to name a few. As we grow, we figured we need to start expanding and looking at areas beyond what we've been building upon. As such, we've now taken you guys' feedback and enabled writing data to integrations.
Why?
We've gotten requests for it from devs asking to write data back to integrations, to have two-way communication between fitness data providers and their apps, which makes sense from a user perspective.
How?
We've streamlined this as much as possible: our normalizers take a provider data model and return a Terra data model, so writing back to integrations should be the exact same thing in reverse. Hence this is unified by letting you POST a Terra data model to the same endpoint you'd hit with a GET, and we convert this to each provider's data model
What?
We've enabled this feature on our nutrition endpoint, and allowed it to support users corresponding to Fitbit for the web API as well as Apple Healthkit for the Terra SDK.
Background data delivery:
We've added in additional support for background data delivery relating to on-device SDKs
Why?
iOS apps are often constrained by the OS itself, which limits or blocks HTTP requests in the background. We understood that users may not always open the app often, and as such data could eventually be lost due to this behavior. Therefore we wanted to make sure that no matter what the user does with the app.
How?
We now submit a background scheduler task (on iOS) or start a service (on Android) to run in regardless of whether the app is in the foreground or not (in both cases the app should not be terminated explicitly by the user). In both cases, each of these runs a scheduled task periodically to fetch data, submitting it to the OS manager which will then prioritize it accordingly and run it when it deems appropriate to do so.
Additionally, upon re-opening the app (even if it was explicitly terminated) we check when the last fetch was performed, and then trigger a fetch for any potential data that wasn't sent so far.
What?
What this means for users is that there will never be any gaps in data retrieved by the SDK by default - no need to add additional scheduled tasks from within your app to fetch data, and we schedule that for you instead.
Overall, we look forward to more input from you to build out a product you will love using!
