I was discussing the requirements of an app and I am a little lost with a few things.
1)
I will be getting data back from a web server via JSON. The user wants the data cached for a month so that there is no unnecessary data usage. My concern is that the data base on the webserver is about 300mb in size. If the user is very active this could mean there could be a lot of data cached on the phone. Is there a limit to the amount of storage you can use? Would 50mb of cached data be realistic to store?
2)
If i was to store all this data, what would be the best way to handle it? Since i would need to be able to search and manage the data from the device. Is this a realistic request from the client, or is the iphone really not suited to this kind of operation. Would it be best to not cache the data at all and just pull it down with JSON as required.
Many Thanks,
-Code
You can use CoreData framework with SQLite for storage.
According to the accepted answer to this question, there is no specific limit to how much data you can store other than the device's flash storage size.
Is there a limit to the amount of storage you can use? Would 50mb of cached data be realistic to store?
No, there is no limit except the capacity of the iPhone's flash memory. 50 MB is not that much IMO, considering there are apps that are hundreds of megabytes large.
Related
I looking for the best way to upload an image from mobile phone to my server. I am currently using html5 to open the camera and take the picture, then I convert the file into a base64 string, then I send to the server, then save it in MongoDB.
I am expecting around 1000 to 1500 user request per day ( upload image ) , so I have the following question :
Is it a good way to do it?
Should I compress the base64, if yes how?
Should use a specific server to handle this task?
My backend is node express and the front end is ReactJS.
Thanks
It all depends on your situation. Reading and writing images from a cdn via i.e. streams is usually faster than reading and writing binary representations of images i.e. base64 from a database. However, your speed if reading from a cdn will obviously be effected by what service you use. Today, companies like Amazon can offer storage to a very cheap price so if you are not building a hobby app for like a student project you can usually afford it. Storing binary representation of images actually end up a little bit bigger in size than storing the image itself. You don't compress the base64, you compress the image before converting it. However, if you can't afford a storage account and if you know your users won't upload that many images it is usually enough to store binary representations of the images in a database. Mongo Atlas, for example, offers 512 mb for free on their database clusters. Dividing tasks of your app such as database requests and cdn services from your main application is usually a good choice if possible. This way you will divide the cpu, memory, etc. of your hardware and it will lead to faster reading and writing tasks for the user.
There are a lot of different modules for doing this in node. JIMP is a pretty nice one with loads of built in functions like resizing images and converting them to binary, either as Buffer or base64.
I have a question about what to sync to iCloud.
I have an application that downloads data from my server and stores it in core data. The user can then mark some of the data as favorites.
What's the best way to use iCloud?
Should I sync the complete core database, or
should I just sync the favorites using NSUbiquitousKeyValueStore (an NSArray with references to the favorites.)
Since the user can download the data again, my first thought was to use NSUbiquitousKeyValueStore since the amount of data would be less. But I think it would be simpler to sync the core data.
The amount of data is at the moment less than 1 MB.
Any reflections are welcome.
I would think that just syncing the favourites would make for the better solution, otherwise any changes in the data would mean extra headaches as there might be differing versions between what is synched to iCloud and what is on your server (although you made no further clarification as to the type of data).
Besides this possibility for inconsistency, is there any good reason to push the extra data to iCloud?
I am working an app which stores some large amount of data (hundreds of mbs) in application's own library.
can anyone tell me if there is any size limit for an app to store data?
I also want to know the good method to store my data.Currently i am using pList to store name of my data files and the actual files are stored under "Document/"..
Should i use Blob or any other suggestion ..?
Not so sure but you can have a look on it - Memory Management.
For saving large amounts of data you should probably look at Core Data or SQLite (a good source is Mobile Tuts, plist wouldn't be a good choice. And so far I don't really know if there is a limit but if the total amount of data saved in your app is over 500MB it would be very unresponsive, so maybe you should save it to a server or something.
For a products catalogue app on iphone which approach is more efficient? Using sqllite db or directly parsing online from xml without db?
Small amounts of data can be loaded as XML directly into memory. Thus, XML would do just fine. When using a large amount of data, a database would be a better option, but it will decrease speed simply because it needs to read/write the data to storage.With iPhone apps and other mobile phone apps, the difference between memory and storage tends to be very small. Unfortunately, for an app to understand an XML file, it must load the XML in a DOM model. This will eat up additional memory of about the size of the XML. Thus XML is not suitable for large amounts of data. (Or huge records.)
If you have up to 50 products, the balance is in favor for XML. Over 50 and you're better off with sqllite.
An added bonus of XML is that you need to explicitly save back to storage to update your changes. With databases, any updates to the data tends to be done directly. Thus, with a database you have a bit more problems undoing any errors. However, with XML your changes will be lost if your application crashes. Personally, I prefer it to only update data explicitly on my command, thus I would prefer XML. (But not for large amounts of data.)
Add your products to sqllite and update only changed/newly added products to the db at every launch asynchronously.
Render your View from the data in DB.
Is there a limit to how much persistent storage a single iPhone app may consume?
What does save set the error argument to if the iPhone hits a per-app limit? What if it hits the hardware limit?
Is it possible to limit the number of objects stored for certain entities? If so, what's a good approach to doing this?
acani, an iPhone app I'm working on, downloads the nearest 20 users from the server and saves them to Core Data. After using the app for a while, the users SQLite table could become rather large. How could I limit it? What should I limit it to? Once this table has reached capacity, how could I make it so that newly downloaded users replace the oldest downloaded users?
Thanks!
Matt
I don't know the answer to the limits questions, but I would think you would want the maximum amount of data to be limited well ahead of that. There are some iPhone apps (games0 which take up a large amount of storage (I think Myst is something line 1.5G). But if you allowed your database to grow to those sorts of sizes you might start to impact on the storage the user has for their other applications.
I'd be inclined to suggest that your application needs to have some sort of database house keeping implemented. You will have to write this. Either automatically triggered or manually triggered by the user. For example you might want to setup a settings option where the user can specify how many "old" users it wants to preserve. If users are being added automatically based on location, what sort of algorythm would a user most likely want to cull the list with?
There is a 2GB limit for apps from the App Store but as far as user data goes, you should be able to basically fill the disk. When that happens, your saves will start to fail, I believe with 'NSFileWriteOutOfSpaceError' bubbled up from the PSC.
As far as limiting entity space, there's no Core Data support for this - you'd have to handle it programatically. You could extend the validation system to check for certain conditions (free space, number of entities) and fail an insert or update if these didn't match your criteria.
If you want to delete old users, just sort the results and delete the first/last one.