I'm in the process of planning an offline music player with nw.js.
Im going to want to cache GB's of data for offline use within nw.js. What's the max size of nj.js application cache?
Html5 cache size is 5mb. For media data is better to use simple disk data storage.
Related
I'm developing a mobile app with React Native and Expo managed workflow. The app is supposed to serve as a song book with lyrics to songs and hymns. All of the lyrics are stored in Firebase' Firestore database and clients can load them in app. However, I also want to implement offline functionality, where all of the lyrics are stored on the user's device.
When researching how to achieve this, I came across two packages: Expo FileSystem and AsyncStorage. I'm wondering which one of these is a better fit for my application. I tried to find some comparisons but couldn't find anything relevant. Can anyone advise me on this?
I've read that AsyncStorage has a cap of 6MB of data you can store. I did some math and found out that if I have a double headroom for my data, the total size would be around 2MB. (lyrics for one song which I have stored in .txt file are between 500-900 bytes, there will be around 1000 songs. So if I take 1000 * 800 bytes = 0.7 MB and if I double the number of songs, which will probably not happen, it's around 1.5 MB)
The songs are stored as objects in database, I used the .txt file just for size calculations, so I think the final size will be even smaller.
So, is there anyone who can tell me the difference between FileSystem and AsyncStorage and maybe advise me on which one to choose for my project?
You don't have to store them yourself, you can access them directly from Firestore local persistence.
From the Firestore docs:
This feature caches a copy of the Cloud Firestore data that your app is actively using, so your app can access the data when the device is offline. You can write, read, listen to, and query the cached data. When the device comes back online, Cloud Firestore synchronizes any local changes made by your app to the Cloud Firestore backend.
Full docs here.
Also a nice tutorial here here.
If I have the free account,with a JAR size limit of 1mb,I want to understand
approximately what can or can't I do with this limit;Is this limit too small to make an app?I want that my app have access to camera,web browsers and that cointains images,few videos,a lots of documents??
The 1mb size applies to the jar sent to the server, this is around 6kb for a barebones application. All of our demos and many 3rd party apps in the stores fall under this limit which is generally a good approach.
It doesn't limit the size of the final application or 3rd party libraries used which means you can still use a large library like google maps without hitting this limit. If you use a very heavy theme or many images (within the app JAR not downloaded dynamically) you will hit this limit.
There is a bit of an overview here on how to shrink the JAR overhead https://www.codenameone.com/blog/shrinking-sizes-optimizing.html
Notice that I'm currently working on a fully functioning clone of the Uber application which is currently under 600kb.
I need to work with a database which can be >20MB.
I read a lot about the size Limit of 5 MB and how the SQLite Plugin would
solve this issue.
https://github.com/lite4cordova/Cordova-SQLitePlugin
I wrote a little test filling a table with dummy data, using the build in Phonegap functionality. Turns out (on iOS) I can easily create a database with 20MB without warnings.
It is stored under AppData/Library/WebKit/LocalStorage/file_0/0000000000000001.db
So what is the real difference between the mentioned Plugin and Phonegap 3.1 database functionality?
Could it be that the limit only applies to Mobile Safari and not to a UIWebView?
Check out the link sqlite.org and it says under Maximum Database Size as shown:
The maximum size of a database file is 2147483646 pages. At the
maximum page size of 65536 bytes, this translates into a maximum
database size of approximately 1.4e+14 bytes (140 terabytes, or 128
tebibytes, or 140,000 gigabytes or 128,000 gibibytes).
The third party sqlite plugin you mentioned has these features over built in sqlite (as their claim, you can check it). And you don't need to worry about db size limit in your case since 5MB limit is about Web SQL API not for built in sqlite support of phonegap.
You are using the WebSQL-Database under iOS. The WebSQL-Database is limited to 50 MB (see here).
The 5 MB you read about is the limit of the (localstorage API).
The Phonegap SQLLite-Plugin provides a database with no limits (except the storage cap of the device itself).
I was wondering if there are memory limits for metro style apps. I am not talking about the RAM. That I already found out has a limit of 150 mb, right?
I want to know, if there is a restriction of using the local memory (the hard discstorage). I am creating a database to save alot of data. Can i do so until the device runs out of storage? (I am not actually planning to do so. But occupying like 80mb of the memory would be nice)
Thanks in advance.
There is no limit on local data.
Local application data should be used for any information that needs to be preserved between application sessions and is not suitable type or size wise, for roaming application data. Data that is not applicable on other devices should be stored here as well. There are no general size restriction on local data stored. Location is available via the localFolder property. Use the local app data store for data that it does not make sense to roam and for large data sets.
From here. There is a limit on roaming data. Same document has that.
Suppose I have files in blob storage, and these files are constantly used by my web application hosted in Windows Azure.
Should I perform some sort of caching of these blobs, like downloading them to my app's local hard-drive?
Update: I was requested to provide a case to make it clear why I want to cache content, so here it goes: imagine I have an e-commerce web-site and my product images are all high-resolution. Sometimes, though, I would like to serve them as thumbnails (eg. for product listings), and one possible solution for that is to use an HTTP handler to resize the images on demand. I know I could use output-cache so that the image just needs to be resized once, but for the sake of this example, let us just consider I would process the image every time it was requested. I imagine it would be faster to have the contents cached locally. In this case, would it be better to cache it on the HD or to use local-storage?
Thanks in advance!
Just to start answering your question, yes accessing a static content from Role specific local storage would be faster compare to accessing it from Azure blob storage due to network latency even when both compute and blob are in same data center.
There could be a solution in which you can download X amount of blobs from Azure storage during startup task (or a background task) in Role specific Local Storage and reference these static content via local storage however the real question is for what reason you want to cache the content from Azure blob storage? Is it for faster access or for reliability? If reason is to have static content accessible almost immediately then I could think of having it cached at local storage.
There are pros and cons of each approach however if you can provide the specific why would you want to do that, you may get much better to the point response.
Why not use a local resource? It gives you a path to a folder on the HD, and you can get a lot of space. You can even keep it around between restarts.
Another option is Azure Cloud Drive. It's fast, and would allow you to share the cache among instances (but only can write at once).
Erick