I have gone through many resources online but could not get the memory architecture used by HTML5 local storage. Is the data from local storage brought in memory while working over it (something like caching)?
Also in case I want to implement my app working in offline mode (basic purpose of storing into local storage), is it fine to store data as global JSON objects rather than going for local storage.
In short , I am getting a lot of JSON data while I login to my app(cross platform HTML5 app). Shall i store this data as global object or rather store it in memory.
Well, it depends on how sensitive is your information and the approach you want to follow.
Local storage
You can use local storage for "temporal" data, passing parameters and some config. values. AFAIK local storage should be used with care in the sense that the stored information is not ensure to be there always, as it could be deleted to reclaim some device memory or cleaning process. But you can use it without much fear.
To store JSON in local storage you will have to stringify your object to store it in a local storage key. JSON.stringify() function will do the trick for you.
So far I haven´t found official information, but I think there is a limit of MB that you can store in local storage, however I Think that is not controlled directly via cordova. Again, is not official data, just take that in mind if your data in JSON notation is extremely big.
Store data as global objects
Storing data as global objects could be useful if you have some variables or data that is shared across functions inside the app, to ease access. However, bear in mind that data stored in global variables could be lost if the app is re-started, stopped, crashed or quit.
If it is not sensitive information or you can recover it later, go ahead and use local storage or global variables.
Permanent storage
For sensitive data or more permanent information I will suggest to store your JSON data in the app file system. That is write your JSON data in a file and when required recover the information from the file and store it in a variable to access it, that way if your app is offline, or the app is re-started or quit, you can always recover the information from the file system. The only way to loose that data is if the app is deleted from the device.
In my case I am using the three methods in the app I am developing, so just decide which approach will work the best for you and your needs.
Related
The main purpose is to store data locally so it can be accessed without internet connection.
In my React application I will need to fetch JSON data (such as images, text and videos) from the internet and display it for a certain amount of time.
To add flexibility, this should work offline as well.
I've read about options such as localStorage and Firebase but all of them so far require either access to the Internet, or are limited to 10Mb which is too low for what I'll need.
What would be my best option to persist data in some sort of offline
database or file trough react?
I'd also be thankful if you could point me to a good tutorial about
any provided solution.
To store large amounts of data on client side you can use indexedDB.
IndexedDB is a low-level API for client-side storage of significant amounts of structured data, including files/blobs.
You can read more about indexedDB api here
I am in the process of building my first live node.js web app. It contains a form that accepts data regarding my clients current stock. When submitted, an object is made and saved to an array of current stock. This stock is then permanently displayed on their website until the entry is modified or deleted.
It is unlikely that there will ever be more than 20 objects stored at any time and these will only be updated perhaps once a week. I am not sure if it is necessary to use MongoDB to store these, or whether there could be a simpler more appropriate alternative. Perhaps the objects could be stored to a JSON file instead? Or would this have too big an implication on page load times?
You could potentially store in a JSON file or even in a cache of sorts such as Redis but I still think MongoDB would be your best bet for a live site.
Storing something in a JSON file is not scalable so if you end up storing a lot more data than originally planned (this often happens) you may find you run out of storage on your server hard drive. Also if you end up scaling and putting your app behind a load balancer, then you will need to make sure there are matching copy's of that JSON file on each server. Further more, it is easy to run into race conditions when updating a JSON file. If two processes are trying to update the file at the same time, you are going to potentially lose data. Technically speaking, JSON file would work but it's not recommended.
Storing in memory (i.e.) Redis has similar implications that the data is only available on that one server. Also the data is not persistent, so if your server restarted for whatever reason, you'd lose what was stored in memory.
For all intents and purposes, MongoDB is your best bet.
The only way to know for sure is test it with a load test. But as you probably read html and js files from the file system when serving web pages anyway, the extra load of reading a few json files shouldn't be a problem.
If you want to go with simpler way i.e JSON file use nedb API which is plenty fast as well.
Does data stored using Shared Object persist across mobile app updates?
Are there any gotchas that I should know before relying on this?
Would it be safer to store data using the file system API?
Shared object is not a reliable type of data storage since it's up to the device owner to allow or limit shared object capacity. Shared object can also be cleared by the owner at any time. You would see tremendous amount of AIR apps done using shared object not because it's a good solution but because app author save a few lines of code using it. More reliable is SQLite as3 built in capability. A simple txt file would do for short amount of data. For more amount of data SQLite is unbeatable and 100% reliable and ultra fast.
Using ActionScript, When several clients are connected to a remote SharedObject it functions as a 'live' data exchange, where all clients are updated whenever any client makes a change. It obviously works because only the server has actual access to the file, and simply broadcasts the change.
Is there a way to enable the same type of functionality between several local swf files loaded into stand-alone projectors?
Specifically: A user can run several (some have 60 or more....) instances of an online game client, which includes a map of the identical virtual world. Rather than have every instance load the same map into memory, it would save MUCH (The map is larger than Georgia..) memory if they could all access the same data.
A sharedObject would obviously create file access headaches since each client needs read/write access. Is there some other technology available or a way to load an auxiliary swf perhaps to function as the 'server'?
Yes you can do similar things with Flash SharedObject. You've pretty much found the name, you just had to search for it :)
Check out the getLocal method - it allows you to access a locally persisted information from multiple files.
Few things:
Keep in mind to set a proper localPath in order to be able to read the data from multiple files.
Keep in mind that this storage is first limited, and this limitation is commonly defined by the user.
Another crucial thing is that the local storage can be denied by the user. Which means that it's not sure that you can always write there.
While it can be used with a Flash Media Server, the standard local storage won't dispatch events when the property is changed. You need to create your own script if you need real time updates.
Hope that helps :)
I'm developing web app that user can save his/her work to server. The data will be saved is in variable-length binary form, it's size mostly under 20KB (sometimes little bigger < 100KB). The data will often be changed / updated.
I have 2 options saving the data in server: as BLOB (mysql) or as filesystem with reference to its filepath stored in db server. I heard that each option have pro and cons.
Which is best for my app ?
Thanks
I'd probably go for the DB approach. The speed difference isn't likely to be that much, and I'm a big fan of having all data stored in one place. It's much easier to get a consistent back up of a database then it is to backup a database, filesystem, and associated data (and preserve consistency)
It also provides a uniform access method, consistent permissions, and allows you to access things remotely without setting up a separate service.
That said, it may be worth your while to keep your options open and not tie it to the db too tightly in case you want to move later.
I recommend placing it in the DB. It makes little sense building a special format for storage and access of this data, just to avoid going through the DB. What about simultaneous accesses from multiple instances of your application (a likely scenario in a web app)? With a DB you can leave these worries to the DB engine if you just use it correctly. With your home-cooked file format you'll be in trouble.