Ask HN: Mobile Data: On-Device Only or Remote API? | Hacker News Reader

Ask HN: Mobile Data: On-Device Only or Remote API?

3 pointsscribbles6 comments

A while back I was working on building a fairly simple app that lets me track some different aspects of my workouts. I know, there are 1000 apps out there that track workouts so this was more of just a fun thing to build :)

Now that I've got it on my phone and playing around with it I've had some requests from friends that they'd love to use it too, which leads me to my question.

When building for myself I didn't really care about where the data was stored. If I deleted the app off my phone I wasn't too worried if I couldn't get it back. Now there will be more users and more data, does it make sense from your experience to create an API to store the data remotely? I see some pro's and con's to a remote API:

Pros - Data Backups - Sync across devices - Easier analytics (via db lookups, though Google Analytics could be arguably easier...) - Easier(ish) feature enhancement with a versioned API (just add some new api endpoints vs modifying the local DB) - No local database, just a simple JSON API, ahh...

Cons - Building an API :) That being said, it's fairly simple setup with only a few models - Users would have to register (so we could authenticate them via the API and get their data) - Requires internet access - Obviously slower than having data stored locally, though how much slower isn't clear

So, what would you do? Would you rather the data be stored remotely or locally? Any experience that lead you to that conclusion that you wouldn't mind sharing?

I would store it remotely using an api, but cache it locally on the device. Storing it remotely makes it easier on users when they switch devices or want to view their data on a computer. You also get the option to send out alerts (email and push notifications) if the data is on a server. There could be some revenue possibilities there (sending out targeted offers for massage or smoothies after workouts, etc). You can also play with analytics on the workout data (e.g. if there are enough people, see how they compare to each other, see activity level by location, etc).

You may be able to use a PaaS backend like Parse to power your API.

I agree with just about every bit of that :) Thanks for the response! I think this makes the most sense, remote with some sort of local caching. Leads to a bit more implementation though and questions like:

1) What happens when they post something but don't have internet, would it store locally then sync up when it can? Or, just not allow posting without internet (curious how many people workout with an iPod Touch).

2) What happens when we get a new call from the remote server, kill the local table entirely or have some field on each record like "synced" that lets you check for records that need to be updated still?

Anyways, just a few things like that but thanks a ton, you gave me some more things to think about :)

Another approach would be to use the Backup API's provided by Google/Apple. http://developer.android.com/guide/topics/data/backup.html

I second this. Don't know how it works for iOS, but for Android it is straight-forward. And should be even more now with the new automatic backup for Android M [0].

You would have people keep their data as they update devices, no need to build an API, but would lose the analytics part that you mentioned.

[0] http://developer.android.com/preview/backup/index.html#overv...

This looks great! Yeah, I'm loving the idea of using something like Parse or the backup service.

You can easily create a backend free of cost on https://orchestrate.io/ https://parse.com/ http://apifox.com/

Reply on news.ycombinator.com