I am using the ImagePicker (https://pub.dev/packages/image_picker) plugin to record videos and I noticed the recorded videos are stored in app's cache folder (example: /data/user/0/com.example.app/cache/999b6a18-114b-4fd3-b089-09ce4574bf765726458033916036262.mp4")
In the plugin docs it says
Note: Images and videos picked using the camera are saved to your application's local cache, and should therefore be expected to only be around temporarily. If you require your picked image to be stored permanently, it is your responsibility to move it to a more permanent location.
Here's what I am wondering about:
How long will the files remain in the cache folder? (I am concerned on too many video files being accumulated)
What is the mechanism on the cache data? does the Android/IOs system has some limitations on the size of the cache folder?
If there is some sort of limitations, what will happen if users record more videos will the system delete the older videos to make room?
Overall would you guys recommend that I delete the recorded cached video immediately after processing it (Example uploading it to my server)?
How long will the files remain in the cache folder?
Usually, cached files remains in the folder until you uninstall the application or when you use a "Clear Cache" option (also works with "File Cleaner" applications). In the case of images fetched from a web API they might contains a Cache-Control header which will help to define directives to invalidate them from the cache.
Sometimes, a different behavior can occur on Android phones depending of the software overlay, for example Honor software (EMUI) is known for clearing cached files by itself from time to time, but it does not seem like the exact duration is mentioned anywhere.
Does the Android/iOS system has some limitations on the size of the cache folder?
The cache folder does not have a size limitation, it will grow as big as needed (or until your phone runs out of available space), this is why people tends to recommend clearing the cache of certain applications manually when it becomes too big.
Related
I am limited to the size of web applications I can build by the "Build\application.data" file.
I.e if its over a certain size I cannot upload it certain hosts, github, etc.
Ideally I would like to split the application into multiple data files under a certain size, while the application is still executable.
How would this be possible? Is this something I can do from Unity build configuration?
Can I do it after the build is done?
Can I split the file into chunks by archiving it with zero compression, and somehow still execute it from the browser? There is a file called Build.Loader.js, is it something that can be edited for this purpose?
This is for the purposes of using the application after it has been uploaded, not sharing it, I do not want to compress it into separate archives, or use gitlfs, I've tested this and the application does not work from the browser with github and gitlfs.
Thanks
Unity has 2 technologies for split data file:
Asset bundle
An AssetBundle is an archive file that contains platform-specific
non-code Assets (such as Models, Textures, Prefabs, Audio clips, and
even entire Scenes) that Unity can load at run time
Addressbles
The Addressable Asset System allows the developer to ask for an asset
via its address. Once an asset (e.g. a prefab) is marked
"addressable", it generates an address which can be called from
anywhere. Wherever the asset resides (local or remote), the system
will locate it and its dependencies, then return it.
Both technologies create separate files that you can host on a server and download as needed. Addressable is a newer technology that Unity team recommends.
Probably the total size of the bundle will grow, but user will be able to download only the necessary assets and the amount of data for the user may decrease
If you do not use Unity solutions, you can divide data file into parts. But on the client side (javascript) you will need to download all the parts, connect them and pass to Unity loader. You probably won't be able to use the browser's built-in gzip or brotli (not sure). It seems to be quite difficult.
Before going to ask the question, I will explain what kind of requirements I need.
In my game, there are a lot of textures needed in order to play it. Because of this and the limitation of ipa size (iOS), I think using assetbundle is a must. Because the existing code implementation, I create the assetbundle, 1 asset bundle for 1 image. For example: I have 100 images, then I will create 100 assetbundle(with the mainasset will be the texture), with the same name.
I want my game can be played offline AFTER at first time the user has downloaded all the needed assetbundles. So if the user play for the first time or download the updated version of my game, the game will be forced into special scene where it will download all needed assetbundle, after that, the user can play the game without internet connection.
I thought there are 2 ways regarding of how to download these assetbundle:
The normal way: I put all 100 assetbundles in my server, and put 1 xml file, which consist all assetbundles information and its version. At the special scene, the game will download the xml file, and from that it will download 100 assetbundles via WWW.LoadFromCacheOrDownload. The purpose is just to store the needed assetbundles to the cache of game. After successfully downloaded all of them, user can play offline and if the game need the assetbundle to be loaded, then I just callagain the WWW.LoadFromCacheOrDownload, since it is still in the cache, it can be played offline. Of course, I assume the cache is still there as long as I dont clear the cache explicitly.
The hard way: I will zip all 100 assetbundle to 1 zip file. The game will download the xml file, and the zip file. I will decompress the zip, and put all 100 assetbundle in the mobile storage (iOS and Android). So after that, in case the game need to load the asset, I just call the WWW.LoadFromCacheOrDownload with the url is using file:/// scheme that point to the path of mobile storage.
Summary:
The Normal Way:
Minus: I assume the cache is still there, but if there is something wrong in the cache, the user can't play the game.
Plus: simple implementation, because the assumption that cache will be fine.
The Hard Way:
Minus: well, i don't know it is minus point or not, but this one, I have to implement the unarchived zip file and store them in storage. More implementation needed at server side and the application side. And since I am newbie, I don't know the best practice in this area.
Plus: more robust
So which one is better ? or any better recommendation?
We have essentially implemented a mix of your normal and hard way for our application. As yours, it's rather texture heavy, so most groups of texture assets are packed into their own asset bundles. (In our application texture have a logical grouping, so we don't pack them individually). We however don't download them directly to the cache. We download these to the sdcard and from there load them (or get them from cache) as we need them. (i.e. LoadFromCacheOrDownload).
It depends a bit on your situation, but I would generally advise against packing them into a single zip file. Primarily with regards to updates. It has happened in our case that an asset needed some updates, or that we wanted to add assets later on. By having an XML file or database containing versioning data, updating the data on the device is trivial. And if only one bundle changes, you only need to download that single bundle. And 2MB vs 450MB in our case is quite the difference.
I am planning to cache the images from a server and use show it as a sort slide show in my App. I would be asynchronously loading the images.
I have two options:
Either to cache the images as a File and use it whenever necessary.
Cache the images objects in memory and use it when ever necessary and write it in to files when Application quits.
Which one would be better?
Please let me know if you you have any kind of suggestions regarding caching images.
Your second approach has 2 major flaws:
If there's too many images then your application will get low memory warning and you'll have to dispose your images from memory anyway
It's also not a good idea to save all images to file on application quit - it is not guaranteed that your saving code will finish on application exit (e.g. if it takes too long system may just terminate your app and your images will be lost)
I'd suggest saving images to files right after you download them and keep in memory reasonable number of images you need to show without visible delay (loading extra images when required and disposing of unnecessary ones)
I would recommend you the first option. Leaves you more flexibility, e.g. when the data size increases the memory size.
I'd do it like this: Have a NSMutableDictionary with the cached images (as UIImage objects). If the image is not in the cache, look whether it's available as a file. If it's not available as a file, load it, put it into your dictionary and also write it to a file.
As for where to write the files to: you can either use the NSTemporaryDirectory() or create a directory inside your NSLibraryDirectory (use NSSearchPathForDirectoriesInDomains to locate it). The later has the advantage/disadvantage that it will be in the iTunes backup (whether that's an advantage or not depends on the use case). Using the Library directory is Apple's recommended way of storing data that is backed up but does not appear in the iTune's file exchange thingy (Documents directory).
I have started using EGOImageView to handle my caching; it's very versatile and handles the intricacies of caching for you.
It works very well for pulling images via http, you can find it on the EGO developer website here
http://developers.enormego.com/
For image caching solution on iOS platform, you might want to consider SDWebImage framework available at: https://github.com/rs/SDWebImage. It is very easy to integrate and takes care of all your image caching worries.: read more about the working here: https://github.com/rs/SDWebImage#readme
We recently picked this up for our app and it works great.
I am saving data to iphone directory which i have created, in PNG format,,,but my app getting heavier,
what should I do ?
Seems like the choices are fairly obvious: either delete data from the documents directory that you don't need anymore, or use a file format with more compression than PNG (eg, lossy JPEG). You'll have to make a compromise somewhere, so it's about what's better for you app: more compression on the images, or keeping lossless images but automatically deleting (or offering users the option to manually delete) files older than a certain date, etc.
You are probably not releasing used memory (such as images, view, etc). Try running your application with Build & Analyze.
Can someone explain to me in simple term the concept of caching in GWT. I have read this in many places but may be due to my limited knowledge, i'm not being able to understand it.
Such as nocache.js, cache.js
or other things such as making the client cache files forever or how to make files cached by the client and then if file get changed on the server only then the client download these files again
Generally, there are 3 type of files -
Cache Forever
Cache for some time
Never Cache
Some files can never be cached, and will always fall in the "never cache" bucket. But the biggest performance wins comes from systematically converting files in the second bucket to files that can be cached forever. GWT makes it easy to do this in various ways.
The <md5>.cache.js files are safe to cache forever. If they ever change, GWT will rename the file, and so the browser will be forced to download it again.
The .nocache.js file should never be cached. This file is modified even if you change a single line of code and recompile. The nocache.js contains the links of the <md5>.cache.js, and therefore it is important that the browser always has the latest version of this file.
The third bucket contains images, css and any other static resources that are part of your application. CSS files are always changing, so you cannot tell the browser 'cache forever'. But if you use ClientBundle / CssResource, GWT will manage the file for you. Every time you change the CSS, GWT will rename the file, and therefore the browser will be forced to download it again. This lets you set strong cache headers to get the best performance.
In summary -
For anything that matches .cache., set a far-in-the-future expires header, effectively telling the browser to cache it forever.
For anything that matches .nocache., set cache headers that force the browser to re-validate the resource with the server.
For everything else, you should set a short expires header depending on how often you change resources.
Try to use ClientBundle / CssResource; this automatically renames your resources to *.cache bucket
This blog post has a good overview of the GWT bootstrapping process (and many other parts of the GWT system, incidentally), which has a lot to do with what gets cached and why.
Basically, the generated nocache.js file is a relatively small bit of JS whose sole purpose is to decide which generated permutation should be downloded.
Each individual permutation consists of the implementation of your app specific to the browser, language, etc., of the user. This is a lot more code than the simple bootstrapping code, and thus needs to be cached for your app to respond quickly. These are the cache.html files that get generated by the GWT compiler.
When you recompile and deploy your app, your users will download the nocache.js file as normal, but this will tell their browsers to download a new cache.html file with the app's new features. This will now be cached as well for the next time they load your app.