I have been looking around for a class to manage the caching of the data from a URLLoader call but been unsuccessful. Does URLLoader cache by default?
I am building an app that fetches a bunch of information on the user (profile details, friend lists, profile image etc) and I would prefer not to call URLLoader each time. I am caching their profile image on first load and hope I can do the same with the rest of the data without having to create a clone of the DB locally.
Cheers
Yes, the URLLoader caches requests, and there are various solutions to break that cache request (generally by adding a random element to the end of the web request). You can see the documentation here for the URLRequest object that's returned, and it's various cache options.
However, I recommend persisting the data locally upon receiving the request and using the platform's database / data storage pattern that you're on. Then, check for internet prior to making the request: if you can make a connection, make the request to retrieve and update the local data. If there's no internet / connection, just load the data you have saved locally. Using the "cached" version of the request isn't a trustworthy pattern.
Related
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.
I am using firebase offline capabilities to fetch data from cache once it load all data in local disk even if my internet is on.I successfully managed to do it but when ever I read data in my app, my firebase data download size increases. I am confused: when I get data from local cache, my data download size increases every time I am reading data in my app. If anyone knows please help me out.
Even when the data is already in the cache, the Firebase client will connect to the server and check if the cached data is up to date. This check is typically significantly smaller than downloading the actual data, but you'll still be charged for the bandwidth it consumes.
If you want to work completely offline, and don't want the client to check with the server at all, you can tell the Firebase client to goOffline when the app starts.
The use case is a dual platform mobile app for an event. There is a schedule with photos, links, bios of the speakers and talk descriptions. If all of the attendees happen to download and open the app at the same time and in the same place, they might not get the best experience -> the WiFi might slow the calls into the data server, calls into the FireBase server side will spike.
Is it possible to export a database from the server side and preload the event schedule data into the mobile app download? Upon launch the app can sync any last minute updates, as needed, with a connection and a short sync to Firebase.
If this type of architecture is not available, is there an alternative that the Firebase team would recommend?
There is no way within the Firebase Database API to preload data into the disk cache.
Two things I can think of (neither of them very nice):
Have the client read the JSON file from your app's resources and write it to the location. The end result of this will be that the data on the server stays unmodified. But it does result in each client writing the same data to the server, so the inverse of your original problem (and likely worse performing).
Have a wrapper around the Firebase API calls that loads from the JSON file and then have them later attach listeners after a random delay (to reduce the rush on the app).
As said, neither of them is very good. For both of them, you can download the JSON from the Firebase Database console.
In my experience the usage of conference apps is a lot lower than most developers/organizers imagine. It's also typically quite well spread out over the duration of the conference. So reducing the amount of data you load might be enough to make things work.
On android you can ship a sql database in the assets directory with the app and then reconcile it with the updates when the users open the app. The Firebase database is a json file. You could also ship that in the assets directory and then reconcile on first load.
I'm doing a photosharing app with account authentication using phonegap.
We will be using jquery(client),CSS3(no-images and animation)/codeigniter(server) and we already structure our database from the server.
I can't decide how should I retrieve my data and what to do with it after I pull it from the server.
I should retrieve the data base from the login that is used it pulls out the friends/followers/people who comment to the pictures just like instagram did but it is more like a combination of facebook and instagram.
The data should be synchronized or auto update everytime there's a new comment from the photos,friend request,etc,.
Should I cache the data when I pull it from the server?What is the best way to CRUD cache data?
Generally, you can prefetch some amount of necessary data when the user log in, and you can have a background service to schedule batch transfers and batch update data. It should not automatically sync data everytime (unless you really need it), because internet connections will shorten the battery life rather quickly.
You can read this good document about this: http://developer.android.com/training/efficient-downloads/efficient-network-access.html#PrefetchData
The document is for Android, but I think it can be applied for other platforms.
Hope it help you something :)
i want to keep my app in sync with the Server. The communication between client (android app) and server is handled through JSON Objects / HTTP. What is the best strategy if the connection is not available anymore? It is important that the user can continue his work with the app. Does there even exist frameworks for such sync-problems?
i thought about a queue of transactions?! Any reccomendations or experiences?
Thanks
For fetching... I once wrote a caching URL manager that would load read the JSON from reply from the server and write it to the SD Card. When if the user did another request for the same URL a short time later, the URL manager would simply return the cached json from the filesystem as the JSON reply. This made the communication code somewhat transparent, in that I was always dealing with JSON replies, whether or not they were cached or real time.
For sending information to the server, you could write all information to the database, and use a background service that pushes the data to the server. That way the UI will always succeed in writing the information and your sync service would push data if there was a network connection. Using a Service you can simply pass the data in the Service intent and it can worry about the writing to db and syncing, etc.
http://developer.android.com/training/cloudsync/aesync.html
i think this is what i will use in my next project :)