I have an iPhone app that allows users to create content (mainly things that are stored as binary data) while recording video. So the output of the app are multiple files, the recording and the user generated content. Because between the two there is a relationship, I though of archiving them and present them to the user as a single file, a bundle. But since the video can be huge, archiving is becoming less of an option because of the time needed to archive/unarchive the file. What other options do I have? When I record I write buffers to disk, so I'm not loading the file in memory. Would be nice to be able to write into an archive, but I'm almost sure it's not possible.
Related
I am wondering why storing user profile images as Data to user defaults is ill advised. The reason being: I have already created an app that has some people using it. The app requires that users create a profile, on which they can upload up to 6 profile pictures. The images get pushed to my back end and also are stored as Data to the app's user defaults.
I've read that it is better to save these images to the document directory and save the file path as a string to user defaults. Why is this exactly? Is it such a big deal that I should take the time to write code that will convert images saved as Data to user defaults on already existing devices to images saved to the document directory?
The "why" is easy. The UserDefaults is not a database. It's just a plist file. Either the whole thing is loaded into memory at once or it isn't. If it is, there are all your UIImage data objects sitting in memory. Memory is limited and images are big. Plus you waste time during loading and saving.
The "is it such a big deal" part is a matter of opinion. In my own opinion, yes, it is. That's because I've gone through this process, and I was glad I did. Yes, it's a pain writing migration code, but once you've done it you just leave it in place and your app is now handling data saving correctly forever after.
In our iOS app we have close to a hundred image files in resources bundle. Now we want to make them network based since the images may change (updated/no longer needed/additions) at any time. We are debating at what approach would be optimal. From what I have read, I understand that the resource bundle will not be editable on the device. So, when I start the app, I will check from the server if there are any image updates. If so, I will download the changed images and then save them to documents directory. Then in the app, for every image, I will basically have to check if it is in the resources bundle, then grab it from there. Else pick it from documents directory and display it.
Another approach is I don't have anything in the resources folder, I download all images on app launch from the server and store them to documents directory and then on, download the changed files at subsequent app launch. Here I am eliminating the check on resources folder if an image is present or not and my app bundle size would be reduced.
The third approach would be to copy the files from my resources directory to the documents directory on first launch and thereafter continue from documents directory.
Any suggestions on what would be a better approach or all of them would be similar from the performance point of view?
IMO, option three offers the best balance between eliminating needless code and preloading as much data as possible. You don't want to make the user wait for 100 image downloads when the app starts the first time, so pre-load as many as possible. The copy code is simple and will only be used once. So that eliminates the runtime checks you'd have to do with the other options.
No worries, performance will not be an issue, unless you use a particularly unwise image lookup algorithm.
Filesystem traversal should be pretty fast for such a small amount of files.
Before implementing something yourself, I would recommend looking at something off the shelf for Image Caching. Namely EGOImageView from EnormEgo.
I have used it in several applications which are dependent on grabbing images from URLs. It handles everything for you, you just set up a 'background' image for it to show while it goes about it's business of grabbing the URL based image in the background. The second time you use it, it's available immediately. Definitely gets my vote for ease of use...
p.s. it's free to use
My problem is that my application size is very high,
is there any idea to reduce size of application?
if i make application without content and content is uploaded my server then how i sync the application with content put on my server?
i want to know that once user download application after that when he use application then we stream the content and save his document folder.
once user stream then never required for streaming.
is it possible????
Thanks,
Reducing the size of your application depends on the TYPE of contents of your application. I highly doubt that the application code is the cause, and since you did not mention what they are I am assuming they are some kind of resource.
If your resources are images, try to use image compression programs. Or convert them to smaller sized images or optimize the images.
If your resources are documents / text files / files that have a high compression ratio when zipped. Then you can try to zip your resources and access them inside the compressed file (this will mean additional coding, and probably slower in performance).
These are just examples.
It is not advisable to stream large contents because it uses the network bandwidth which, depending on the user's plan, can cause a big spike in phone bills.
Yes it is possible that you can download your content and can save to application's document folder, when user runs your application for the first time. Thought it may affect the first impression to your user as it will take time to download.
I'm currently working on an application that users a number of different views to obtain user information and I have just hit a snag.
My current method saves each user detail against a key value in a plist file, the problem is that when the user switches to another view and saves their data again, the old keys and data are overwritten.
So my question is what is more efficient, to a) have a different plist for each different view or b) read all the existing data from the file first then save the data back to the file along with the new details.
Bearing in mind eventually I will want to export all of this information as XML, though it shouldn't be too difficult to read form multiple files.
thanks in advance!
It would probably be more efficient to use multiple files. The most scarce resource on the iPhone is memory, and loading a huge plist could potentially use up a lot. Using multiple files means you don't have to load all of the plists into memory at once. If you have a lot of data, I'd also suggest taking a look at Core Data eventually.
My application will record and store some sounds to play them back later. Right now, I can record the sound which is saved in temporary folder.
Where is the best way to store sounds to play back later?
Do I need database or just store as files?
Files in your Documents directory. Or perhaps a subdirectory within Docs. Using a subdirectory has the advantage that you may want to store other data files somewhere in Docs dir, but keeping all the sound recordings in their own location lets you iterate through the files or delete the entire directory and its contents. I've seen plenty of messages suggesting it's less efficient and/or fast to store a bunch of binary objects in SQLite.