We are developing a social networking iOS application. The application loads lots of data from back end server. I have following doubts which is still unclear .Please help
What is the best approach for handling these much data from back end server?.
How does social networking mobile applications like facebook loads and update friends data?
Does these kind of application uses a local database to store these data?? If so when is the values in the local database updated?
Is making an synchronous call on a separate thread same as making an asynchronous server call?
Please provide your suggestions.Thanks in advance
Ideally, load data "on demand". Request from the server the data the user is seeing at the moment, or that you think she will see soon. Also, request data in batches (for example, last 50 posts, or post between certain dates).
Considering the answer above, Facebook does something similar. The key is to be smart on the server side. Let the client ask for a feed, for example. The server returns the last 50 posts and a "next page" attribute. The client can store that attribute and when the user scrolls down to the last post, send a request to the server asking for more news and passing the "next page" attribute that the server previously returned. The server of course will return a new "next page" with the new request. In this way, what is returned to the client is decided by the server.
Yes, you should use a local database which acts like a client cache. This is used to present the data that was shown to the user the last time she opened the app, so that you can show something while the request is loading from the server. You should update your database when the server sends a response to your request. This is also valid for friend lists, messages, etc. Don't forget, though, that the server has he most up-to-date information and the client database is mostly a cache to display temporary information.
Not exactly the same but for your use case it will be very similar. Ideally some operating systems provide low level asynchronous network operations, which is much better than handling it on your code with a background thread.
Related
I'm trying to set up a front end UI for the webApp I've been working on and have a clarification question before proceeding further.
Right now I have multiple sensor units streaming data to the server that is saving it to a database and then set up a crude api, to be expanded on later, to interface with the server and DB.
Now, moving to the front end, I feel like I'm bashing my heading first trying to learn react and now vue. The first feature of the UI I'd like to have is to constantly see the sensor data displayed in a table on the browser.
Should I be calling this data from the server using the API http requests or have it sent using websockets?
After spending a few hours trying to get vue connected to the socket opened on the server I wanted to check if I'm just looking in the wrong direction to begin with?
Thanks!
It would be best to create a websocket connections since your data is continuously changing. You are definitely on the right track.
Just create an vuex action that will commit your data to the store. It does't really matter which websocket tool you use. Most of them work quite the same. There will be most likely a callback function which gets triggered when new data has been sent to the front-end. This is where you would call your vuex action and pass through the data. If you can edit your question with some sample code, I can help you in more detail.
Just to some it up:
1) Open Websocket connection to backend service
2) Create action which would save the data to store via mutations
3) Specify websocket callback function to call action
We have Intermec CK71 mobile devices (WiFi). There will always be a scenario in which the device sends a request (GET, PUT, or POST), then loses connection. What methods can we use to prevent duplicate PUTs or POSTs? How does the client device know whether or not the server processed its request before losing the connection?
I have seen similar posts like this but the marked answer doesn't go into much detail. I'm not even sure where to begin. Should I be looking into caching (ETag, last modified), or some type of handshaking?
The client device has the .Net Compact Framework 3.5 on it and is hitting the server via its Web API 2 endpoints.
If someone can point me to the right direction or offer any suggestions it would be much appreciated. Thanks.
I am not using REST but as far as I read the information there is no easy way to get an acknowledge and avoid duplicate POST.
As with other high level API frameworks you are tied to what the API offers and it looks like the designers did not think about connection aborts.
The easiest way to workaround this seems to use an unique ID with every post and check the server for knowing these UID before re-posting. If the server does not response with OK for an POST, you have to assume the connection has broken or other things went wrong. Then query the server for the UID you posted to know if the pervious POST was succesful before you try another POST with the same data and UID.
Possibly there is some transaction encapsulation available with REST as available for sql server. A 'transaction' protocol would ensure that a POST has been processed succesfully or will be 'rolled' back, if something failed.
Sorry, but I do not know much about REST.
I am working on a project which is built on Springs MVC and Google App Engine with Objectify.
The major functionality of this app is: If someone posts something new to the Datastore then it should be auto published to the browsers to which it is connected without refreshing the page content. Basically it is a news like site. The data sent to browser is REST APIs based JSON Data.
For implementing this functionality I thought of using the following ways:
AJAX : I thought of using AJAX call in every 2-3 minutes to get updated. But this solution doesn't seems to be feasible as there are many datastore read operation due to many AJAX calls from many browsers.
Web Socket : This concept is pretty new to me. I am not aware of this thing. Some pusher.com uses this technology for establishing such connections.
Now I need your suggestions, using which of the two above or I am also open to other solutions.
Google app engine does not support web sockets, however it supports something similiar called the channel api which works on older browsers as well. This may not be feasible depending on how many people you will have connected (channels cost 1c per 100). Channels also have some caveats: https://developers.google.com/appengine/docs/python/channel/overview#Caveats
As for using Ajax - if you cache the response in memcache and flush the key every 3 minutes then you won't be doing any data store reads unless a new instance is fired up or the key expires.
When creating a service like Google Analytics or StatCounter, I want to do it a little bit different in the data storage part:
A user visits my client's website.
JS code or 1 pixel image is downloaded from my server.
Request sent to my server, where the data is processed.
Things like country, returning customer, bounce rate, etc are calculated.
Instead of storing this data in my server, I want to store it in the client's server.
The client is an individual or business who is using my "service" for web analytics of their website.
Assuming that they are prepared to create a db schema that I choose, what is the recommended way to send the data to them to store?
The only thing I can think of is, asking them to give me a URL in their server, to which I will POST a JSON string, which they can store or do whatever they want.
Apart from HTTP POST, are their any other choices I have to send the data to them?
You could store the data on your own server then provide a mechanism for the client to download it. This would save you the burden of entering and testing a different URL for each customer.
It would also mean that you would only need one SSL URL and authentication method for security. Otherwise you would need to make sure each customer has a working SSL and get your script to log onto each of them when it deposits the data.
I have found very little on this topic. I'm trying to work out a way to synchronize pages cross-web without having to constantly reload pages to get new information, since the rate at which this would be necessary would cause the page to be outrageously slow.
The flow I'm thinking is this:
User A alters info displayed on Page A.
Page A sends info to server.
Page B checks server for new info every 10ms or 100ms.
Page B loads Page A's new info.
I can see AJAX as being sufficiently fast to retrieve info from the server, but have found no way to send data to a server without having to refresh every 10ms, which, even using an iframe to avoid reloading the whole page, seems far too slow to me. Correct me if I'm wrong.
So my question is, is there any way of which I am unaware to do what I am attempting? I have seen methods involving a Java server applet, but that's a bit above my head at the moment. If that's the only way, I'll learn it, but I'd love to avoid that if possible.
There are two possible interpretations of what you wrote, the first which seems to be what you've actually said is that you want to know how to send data with an Ajax request, the second is that you want to know how to push unsolicited data from the server to the client.
Ajax can easily add data to a request it makes - just add query-string parameters, or make a POST request and use XHR's send method
Use comet - i.e. keep open a long-lived connection and send data only when there is something to send.
One of the possible way to implement what you want is to use Comet technology. For example - facebook uses it to interact with their servers.
If you are retrieving info fast using AJAX, then you are also sending info fast with AJAX...
GET requests are still telling the server something. For example, lookup RESTful web-services.
You could use updater of Prototype.