iOS saving app data

[grandM]

So I was looking at ways to save data. As I can't be sure the phone is connected to the internet I thought about saving the data first using Core Data. Then I wondered if there was an easy way to synchronize that data with a remote server.

I did read that Core Data can save it's database on iCloud but what if different users are trying to interact? There is of course something like parse, but then I would have to save to Core Data and parse. Or is there an easy solution using restkit or something like that?

 

[AxoNeuron]

Parse has a local datastore. So if you use Parse, you shouldn't have to use Core Data at all.

I prefer to create a Node.js server with MongoDB to save data. For the local datastore I like to use Core Data with custom NSManagedObject subclasses. Normally, these objects are retrieved by querying my node server, then they get saved to the local datastore. I have a custom class to perform queries of the server, with methods like "whereKey: equalTo:". If there is no internet connection, these queries instead will query my local data store. In order to avoid conflicts, I basically write my apps so that people can still use the app and see data when offline, but can't make any changes (except in a few cases where this is impractical).

If you don't want to learn Node.js (you really should, it's absolutely fantastic), then you might want to look in to the Parse SDK for iOS. Parse is pretty good. But I still prefer the flexibility of writing my own Node.js server code.

 

[1458279]

As far as different users interacting with data, there's a couple of ways this can be handled.

Consider two people trying to update the same record and one is offline. You can compare the original with a new read of the same record to see if it's been updated, if it's changed, you can compare the two updates, if they differ, have a set rule like last one in wins or inform the last updater the data has changed.

Another method is to put a lock on something where it's read only to everyone but the one that has a lock.

Another is to request a lock before an edit can take place and then get the lock.

It can get complex.

I don't know if this is what you had in mind with user interaction.

 

[grandM]

Parse has a local datastore. So if you use Parse, you shouldn't have to use Core Data at all.

I prefer to create a Node.js server with MongoDB to save data. For the local datastore I like to use Core Data with custom NSManagedObject subclasses. Normally, these objects are retrieved by querying my node server, then they get saved to the local datastore. I have a custom class to perform queries of the server, with methods like "whereKey: equalTo:". If there is no internet connection, these queries instead will query my local data store. In order to avoid conflicts, I basically write my apps so that people can still use the app and see data when offline, but can't make any changes (except in a few cases where this is impractical).

If you don't want to learn Node.js (you really should, it's absolutely fantastic), then you might want to look in to the Parse SDK for iOS. Parse is pretty good. But I still prefer the flexibility of writing my own Node.js server code.

Interesting. I have been looking at parse too. My first instinct was to have a setup like yours. I was going to use mysql databases on a remote server with php and sql queries. Locally I was going to work with Core Data.

I did however not realize parse also had a local store.

1. Is this store saving the data when you have no internet connection?
2. Parse is charging in function of requests per second. How should I see this? What's a request per second?

Thanks again for your answer!

 

[grandM]

As far as different users interacting with data, there's a couple of ways this can be handled.

Consider two people trying to update the same record and one is offline. You can compare the original with a new read of the same record to see if it's been updated, if it's changed, you can compare the two updates, if they differ, have a set rule like last one in wins or inform the last updater the data has changed.

Another method is to put a lock on something where it's read only to everyone but the one that has a lock.

Another is to request a lock before an edit can take place and then get the lock.

It can get complex.

I don't know if this is what you had in mind with user interaction.

Hmm locking I hadn't thought about that. Isn't this an issue for the server code rather than the app code?

 

[AxoNeuron]

Interesting. I have been looking at parse too. My first instinct was to have a setup like yours. I was going to use mysql databases on a remote server with php and sql queries. Locally I was going to work with Core Data.

I did however not realize parse also had a local store.

1. Is this store saving the data when you have no internet connection?
2. Parse is charging in function of requests per second. How should I see this? What's a request per second?

Thanks again for your answer!

I would suggest reading their local datastore blog post, it's pretty intuitive stuff:

Yes, it saves data to the local datastore when you have no connection and will update the server the next time it comes online.

A request is simply that, a request. So if you want to query your database, ie. "find all Users with the username X", that query counts as one request. Same if your code saves an object, that is also a request. If I remember correctly it is limited to 30 requests per second. For example, even with 1,000 users online at a given moment (maybe 40,000 users total with 1,000 online at peak demand) that shouldn't be a big problem if you code efficiently.

I would still recommend learning Node.js + MongoDB over Parse. It's so much better. There is no one telling you "Hey, you made over 30 requests per second, so pay me money now". You have a lot more freedom and control. And there are so many great libraries out there for Node.js. But if you don't have the time or desire, Parse works pretty well too. I learned Parse before I got in to Node.js and I am happy I did.

 

[grandM]

I would suggest reading their local datastore blog post, it's pretty intuitive stuff:

Yes, it saves data to the local datastore when you have no connection and will update the server the next time it comes online.

A request is simply that, a request. So if you want to query your database, ie. "find all Users with the username X", that query counts as one request. Same if your code saves an object, that is also a request. If I remember correctly it is limited to 30 requests per second. For example, even with 1,000 users online at a given moment (maybe 40,000 users total with 1,000 online at peak demand) that shouldn't be a big problem if you code efficiently.

I would still recommend learning Node.js + MongoDB over Parse. It's so much better. There is no one telling you "Hey, you made over 30 requests per second, so pay me money now". You have a lot more freedom and control. And there are so many great libraries out there for Node.js. But if you don't have the time or desire, Parse works pretty well too. I learned Parse before I got in to Node.js and I am happy I did.

Actually I'm learning Core Data at the moment. A friend of mine is good in php and mySql. So he could perform the server side. I guess node.js does the same as php? I simply do not like that parse can change everything resulting in major payments to them. Moreover I can imagine some apps requiring local storage but not necessarily in the Cloud.

 

[1458279]

Hmm locking I hadn't thought about that. Isn't this an issue for the server code rather than the app code?

I don't know if servers handle this or not. They might offer a solution, but I'm not sure there is a standard for how this should be handled beyond "last written wins" ... It's really an issue of how the business needs things to work.

We used to write specific code to handle each table and created our own lockout rules. Don't forget to understand deadlock, some will lock a record and stop the whole system.

If you look up threads, it's similar. You send a thread out to do work, while other wait for the thread to return. It sometimes really needs custom code.