For better UX mobile apps store data on the client side (on the device) to provide immediate information when loading an app without having to wait for data from the internet and providing data even when the device is offline. Of course data is updated/fetched whenever possible later on.
I am building an app (in flutter) which is a social network/information feed like app: there are users, profiles, feed, posts etc. When the user opens the app I would like to show data that was available the last time the app ran.
My question is what is the right way to implement cache? There are two main ways I can think of, an easier/uncertain way and a more difficult/stable way, and I would like your opinion about them. I have time/resource constraints ofc. Most information is through HTTP requests, so:
The easier way: HTTP Cache interception
I would use an out-of-the-box cache plugin for my HTTP client. I think I can just cache the response for each request I make (for some time) and rely on the cached info. Images are also cached based on url. When I make a request on application load I return the cached result if there's any, and if it was a cache hit I fire the request again, so when you open the app you will see immediate information, but after a sec or so you will get the fresh data too. Usability of this solution ofc depends on how well I design my API.
Harder: Store data in a structured database.
This is the option I try to avoid, because it's more time implementing this. It could be either a SQL or document store, and I would have to implement the cache look up/save/update mechanism. Since I am just building the app, I think this would slow me down because data types/ architecture might still change. But is this the ultimate way to go with mobile side caching?
Thank you
I think the easier way is your best bet the only time i can think of that cache could be a problem is if you need critical data that has to be correct and not a old cache value, but you can avoid this problem by not caching the critical values.
Also if you use firebase it does some automatic caching which might be useful.
Related
My Android app is fetching data from the web (node.js server).
The user create a list of items (usually 20-30 but it can be up to 60+). For each item I query the server to get information for this item. Once this info is fetched (per item), it won't change anymore but new records will be added as time go by (another server call not related to the previous one).
My question is about either storing this info locally (sqlite?) or fetching this info from the server every time the user asks for it (I remind you the amount of calls).
What should be my guidelines whether to store it locally or not other than "speed"?
You should read about the "offline first" principles.
To summarize, mobile users won't always have a stable internet connection (even no connection at all) and the use of your application should not be dependant on a fulltime internet access.
You should decide which data is elligible for offline storage.
It will mainly depend on what the user is supposed to access most often.
If your Items don't vary, you should persist them locally to act as a cache. Despite the fact that the data mayn't be really big, users will welcome it, as your app will need less Internet usage, which may lead to long waits, timeouts, etc.
You could make use of Retrofit to make the calls to the web service.
When it comes to persisting data locally within an Android application, you can store it in several ways.
First one, the easiest, is to use Shared Preferences. I wouldn't suggest you this time, as you're using some objects.
The second one is to use a raw SQLite database.
However, I'd avoid making SQL queries and give a try to ORM frameworks. In Android, you can find several, such as GreenDAO, ORMLite, and so on. This is the choice you should take. And believe me, initially you might find ORMs quite difficult to understand but, when you learn how do they work and the benefits they provide us, you'll love them.
I am running into an issue with rate-limiting and think I have found a good solution.
I would like to create a server which periodically requests data from 2 different APIs (Twitter, RSS feed) and caches it on the server. The client would then request the data from the server and display it. I only have limited experience in server-side development. Can anyone provide any tips or point me in the right direction in order to implement this. I was thinking about using Amazon Web Services to host the server? Any pointers are much appreciated! Thanks!
Lots of ways to do this, but if you want to use AWS, you could choose S3 as the place to store a copy of the RSS feed (perhaps in JSON format), and your android ap could just request it from there.
S3 is super cheap, super redundant and super fast - plus you can use http://aws.amazon.com/cloudfront/ and push out copies to geographically closer regions around the world (for pennies), if you think you would benefit from that reduction in latency (and assuming you have geographically diverse users).
The only part you would still need to do would be a small/simple back-end process that polls the two source API's, on a schedule you determine, and writes the data to S3.
For something like this a micro-EC2 instance would probably be plenty of horsepower and only cost a few dollars per month.
I think you might have a bigger privacy concern if you started saving other peoples data yourself (I'm not sure how many people would be ok with you to saving their Twitter data on your server).
I'm sure you can cache Twitter and RSS data locally, and just ask for whatever has changed? which might reduce the number of requests your sending?
Alternatively, you could save the API key your using on a web service and get your apps request that key each time. When you've run into limitations with one API key, just switch to using another? Google actually recommend this method for using their own API's (this way you can revoke an API key easily without having to upload a new app).
Hope that makes sense,
Danielle
This is a theory question more than an implementation question. What, in your opinion, is the best way to create a mobile application that syncs data to a server?
I have been writing an application that has a user sign-in, allows them to create notes and then selectively share them with other users. I have been doing this with a Rails webapp that returns JSON data to my iOS app. It seems like a lot of overhead for something that so many apps are doing. Is there a better way? How would, or do, you do it?
You should optimize the data quantity you exchange between server and device. You need to set up a flag that indicate you if something changed, case you need to sync.
Let say you have an app that allow to a group of users to update/load from the same file. you can save on the server the time of the last changes, and on mobile device you have the last update time you get. When you want to update your app data, on the request you can include the time you got the last updates. if the time you send and the time you have on the server differs, update; else... do nothing.
Because the request/response is minimal (Req = time; resp = empty), you can check for updates as often as you like.
The option I found that proved to be the easiest and allows you to focus on mobile development while virtually ignoring the data storage element is Parse. I wish I had found this months ago.
I really don't think there's necessarily anything wrong with maintaining a simple Rails web service as a REST interface for your database, but I can see how that might seem like unnecessary overhead. You could find a DB which has a REST interface by default. Here are two to start you off:
CouchDB
Amazon SimpleDB
I have a database and I need to present a data via HTTP using JSON web services. Currently, I'm designing JSON datasets that will be provided as web services. The data from the tables will be aggregated to suite an app needs.
If the data size is large and we will try to download that at once then it might take too much time and an app will not be responsive at start. That's bad. It's well known we should minimize the number of http requests the app will make to download the data. However if we would split the data into small chunks then during every app action step an app will performe http requests and that might be unresponsive solution too.
We are talking here about mobile app development, so internet will be exposed over cellular ISP or wifi, so the speed might be quite slow. I understand the split process depends on app workflow process and etc., just curious are there any general guidelines? For example: if JSON data is larger than 1MB then definitely split it into smaller chunks...
Look at how your mail read work. You probably have tens of thousands of emails in your account. The app will show the first ones then provide a button at the bottom of the list to display more items. It's a pretty good solution usually to provide a lot of data.
Also #Selvin ideas are just great. Don't use UI thread to download stuff, use a different thread. Services are pretty good for getting data asynchronously.
One of the way is to create a service which gets started when there is network. All downloaded data can be cached in sqlite and use a content provider to get the data. But it depends on your app.
Sometimes it depends on your UI Screen. For eg. You can create a Listview with load more. On click of it load extra data.
Other way is to create API such as which gives only updates based on timestamp. But its all depends on the app. Just sharing my ideas. Might not be perfect. Others can surely give a better one.
I need help figuring out the best, cross-browser compatible way to "SAVE" user input and STORE them locally(offline mod) AND on a server(online). Program will be used by Android and iOS.
I want to know the best way to track user progress while the device is online OR offline.
Hello I have been researching AJAX, JSON, XMLHttpRequest, REST, Java, and HTML5 (specifically, localStorage).
The scenario: (Read a book online/offline, save page progress)
A user logs in to a Web Service and the Web Service allows the user to download an "html webpage book" (view with HTML5 browser).
After every page turn, a REST API uses a GET request to post the Progress data to a Web Server. Simultaneously, a JSON string is created and saved in a file on the server. (let's say "ProgressData.txt")
In the background, a separate "copy" of ProgressData.txt is saved LOCALLY on the mobile device. The user then leaves the internet connection and continues to read the HTML Book.
When the user regains connectivity, the ProgressData.txt is uploaded to the server using a REST API where it will update the old server file with the NEW .txt file with all of the user ProgressData.
Possible solutions:
HTML5 localStorage solution looks good. jQuery even simplifies it:
http://plugins.jquery.com/project/html5Storage
Straight Javascript looks good for Server-Side storage, however it doesn't have access to a mobile device's physical hard-drive, thus preventing any kind of offline saving.
Java applets look possible. Plus not sure how Java runs with Android/iOS.
I don't want to have to run a localhost(PHP/Apache/Python) from a mobiledevice every time the user goes offline, however that may be where the solution lies. I did stumble on this powerful tool: http://couchdb.apache.org/
Question:
I need to know the best way to track user progress while the device is online OR offline. What is the best way to do this?
I stumbled across store.js the other day which might help solve the cross browser local storage. It was from this article about local storage.
I think your best option for tracking online/offline is to ping the server via an AJAX call when the page is turned. Always try and update the server on a page turn, but if it fails, handle the failure and store the progress locally. Each page turn will either amend the locally stored progress file or if connection is restored then simply update the server with the progress.
The issue I am thinking might occur is if a book is finished offline then there are no more clicks that would trigger the syncing, regardless of a restored connection. You may want to think about a manual sync link/button at the end of a book. Or maybe have a manual sync available at all times anyway? Give some control to the users and describe the whole offline/online reading scenario. You might find that it is easier to just let the users do the work… if they don't sync then it's their problem!
Here are 2 screencasts what will help you with your problem.
They are in Ruby on Rails but maybe you can get the idea. It is using the html5 cache manifest.
Hope it will help you!
http://railscasts.com/episodes/247-offline-apps-part-1
http://railscasts.com/episodes/248-offline-apps-part-2
some more resources (sorry i dont have experiences myself with html5 cache manifest)
http://diveintohtml5.ep.io/offline.html
http://developer.apple.com/library/safari/#documentation/iPhone/Conceptual/SafariJSDatabaseGuide/OfflineApplicationCache/OfflineApplicationCache.html
I'd suggest just using a cookie to store the current state. That way it is automatically sent to your server with every user request (so no need to build out a custom server-side API for receiving the state after a lost connection, and no need to have any custom client-side code for sending the data to the server), and still updateable even if the user has lost Internet connectivity. Also it doesn't rely on HTML5 features, so you don't need to restrict people to HTML5-capable browsers.
In any case, the best way to handle storing the current state would be to have a simple onclick handler on your "next page" link (or button, or whatever it is) that calls a function and sets the cookie value to whatever the current position is. Note that because the state is always available client-side, and sent to the server on every request, there is no need to maintain any explicit copy of the state server-side, unless you want to be able to remember the user's place even when they manually delete their cookies (which is overkill in my opinion).
You may want to look at the W3C Example Code for setting/getting cookie values in JavaScript.
Also, here's a website that demonstrates functionality similar to what you want to build. It uses cookies to keep track of a user's place when reading various webcomics. Pretty much the same as what it sounds like you want, except with comics instead of books.
It would be wise to track the progress in both a server side database and in the client's local storage if a constant internet connection is not necessary.
Evercookie is a controversial javascript api that aims to provide local storage using any means available including standard cookies, Flash shared object, Silverlight, browser history and HTML 5 storage. Data should persist when the user is offline and when the connection is restored, sync the cookie and database with whichever data has greater page number for the given book. Droid has Flash and the Flash shared object data is a "cookie" available to both desktop and web-based apps.
With great power comes great responsibility:
http://samy.pl/evercookie/