I am searching for a good solution to manage data updates through REST and JSON.
The client is an iPad and I want that client staying up2date.
The problem is, that the amount of data is very large and may be changed often.
Lets assume I have customer data in the backend. The client iPad should synch this data with the backend system. But customer data may be changed or deleted at any time. Further the amount of customers is >1000.
I do not really want the client to connect to http://www.example.com/customers/ causing to send a request for each of the 1000 customers in that list...
Any ideas to solve such a problem nicely?
Related
I'm actually working on a Rails Application API. I have models with a lot of data.
I would like to be able from my client application to send like a Token, a timestamp or whatever to get the new, updated, deleted content/datas since the last request. While providing a new Token, timestamp for the futur request.
In that way, I have just to update my local cached content on the client side depending on the result of the request rather than update all of my local datas at each request.
After many researches on Google, I didn't find anything convincing.
I don't now how can I manage that on the server side ? Is that a good practice ?
If yes what's the best way to do it ?
Let's say there I have an app that has model structure "Teams" and it's respective "members". This app then pulls data from a web service in json. How does the web service communicate which data has changed and how?
I'm thinking it passes certain JSON keys to notify the app which kinds of updates have occurred. For example:
{"operations": [{"delete":"member1"}, {"add": team2}, {"rename": team3} ... ]}
What are the conventions of doing this?
Edit 1: I am not looking for frameworks that solve this problem. I just want to conceptually know how this is usually done.
Generally the app will ask the server: "What has changed since XXX" and the server will reply with the objects that have changed since that date. The server generally gives full objects for the app to parse and consume.
With that assumption you can get the response from the server and then walk the objects in the JSON payload, loading objects that exist and updating them and then inserting new objects that do not exist locally.
Deletes can be more challenging as most servers that I have seen won't tell you about them. If you control the server then you could send a response with identifiers to objects that have been deleted since the last update.
I am working on an iPhone application and need to implement the Google Places auto-suggest functionality. However, I cannot use the textbox control provided by Google as I need to do some processing on the data before displaying the list to the user. The auto-suggest is a time critical functionality and therefore I need to know if I should call the Google API from my server and have my application make a call to the my server to do this (since the user's connection might be slow), or is there a good reason to still call the Google API from the Phone App itself.
Thanks
The advantage of using client side api calling is the processing and bandwidth will be shared among the client devices, which saves you from high server side costs after deployment
If the client side response time is the motive, I would suggest again the client side calling instead of server side calling, because there is only one request instead of two.Try to parse the JSON data in client side, and its less data intensive and reduce the number of records requested at a time.
Anyways, a slow internet connection gonna choke your app, so think twice before going for server side...
I'm just starting to learn about iOS development, and I figure the best way to get started is to build a simple (but non-trivial) app. My idea is this: have a web interface where a user can create a survey, and then access those surveys through the app and send responses back to the server. The web design part probably won't be terribly difficult -- I've done similar things with Django before. The part that will require learning/effort is the iPhone app.
I've got enough Objective-C that the data structures (model) won't be hard to code, and the UI (view, controller) part shouldn't be bad either. I predict that the interface between web and phone will be difficult, though. In particular, how will I be able to access the database on the server from the phone? I'd like to have a single DB that both web and phone apps use.
What I'd really like to have is a general, broad-strokes description of what I'll need to do to get this all up and running. Am I right in believing that the networking will be the hardest part? Are there any other possible snags? Any advice, or pointers to good resources on the subject, would be greatly appreciated.
Networking will probably not be the hardest part here, you're just guessing because that aspect is unfamiliar to you. For example, you can use NSURLConnection to take care of pretty much all the details of server connection. You can use NSJSONSerialization to convert your data to and from a format that is suitable for sending over the wire.
Basically what you might do is:
Mobile app sends a HTTP GET request to the server for survey info.
Server responds with a JSON description of the survey.
User fills out survey.
When done, the app sends the responses back in JSON format as a HTTP POST to the server.
Server stores the results in the database.
One of the key points here is that the app on the phone does not try to access the database directly. All requests go through your Django web app.
I'm developing a blackberry application to remotely access an external customer database.
Selected employees can change customer entries via a webinterface accessible in our intranet.
I don't want the blackberry to contact the database on every request, so I built in a local storage, which stores the top 50 selected customers of the blackberry user.
What the best practice to keep both records in sync? I thought about creating an hashcode of each record to reduce the datasize to transfer (and though the energy necessary to transmit it). Can anyone here tell me what they do, to reduce requests by a mobile device?
Thanks,
rAyt
In a couple of different situations I've added a created/modified timestamp to each record. On a successful sync with the server, you note the last server time, store it on the client, and on the next sync only get the records (if any) that have changed since the last one. This will reduce data but you may still have to deal with records that were changed on both client and server since the last sync.