Hi I have to develop an application that consists of the world cup fifa stamp album.
I have all the stamps in a png format, so in the first module i need to show the stamps that i own and the ones that not.
My original idea was to store in a database an entity called stamp that includes the image, the name of the player, the id of the stamp and the quantity that i own of each one. I don´t know which storage option to use i know that localstorage can´t store the images so I think my only option is web sql.
Is this the correct approach or the other one is to save the images like in a local folder and then using local storage save the path to the image, the id, name and number of the stamps?
Your life will be easier if you would store the images in the file system and their locations in the database.
Images must be served as static files so you will be able to access them directly
You don't need additional code to extract and stream the images
Images are easy to cache and store on the file system
The database also stores the data on the file system
For a web app you would could use multiple servers to improve performance
So yes, save the images in a local folder and use localstorage or web database to save the image paths.
For storing large amount of data you have to use SQLite for iOS and indexeddb for all other platforms.
There are two ways to access SQLite in phonegap. Either use native websql or sqliteplugin.
You can try out my library which abstract these storage mechanism. See here for example app https://github.com/yathit/cordova-sqliteplugin-todo
For storing image in the database, see here in "Storing File and Blob data" section.
Related
I am working on a project where i want to make the data, text, images available in offline mode as well.
I fetch data from a web-service which includes image urls and other data. I store the text data in core data entities, however i don't save images locally but fetch them in realtime.
To view images in offline mode i will have to save them to local storage. However i am wondering if it would be the right approach. Saving images to local may possibly eat up a lot of storage on user's device.
What is the best approach to address this problem?
Should i save images to local or should i fetch them on run time only?
Use NSCache. With NSCache you can set a limit to how many images and so on are cached. See Apple's documentation for more details: https://developer.apple.com/reference/foundation/nscache?language=objc
Edit:
Never mind NSCache, just save the images as files. NSCache can still save you network usage and allow your app to be more responsive, but it is not what you want.
Should i save images to local or should i fetch them on run time only?
This question for you , you should decide what you need or what is will be more suitable for your app . at any way if you want to cache images i suggest to use this library SDWebImage
I want users to save the picked image and video within the app. So I wanted to know what is the best. Should i convert the picked images and videos to NSData and save in Core data? I search everywhere and everyone recommend to use Documents Folder to save images and videos because coredata is slower. I just started learning CoreData so I don't have much knowledge about it. Here is what I have come up.
Users pick the image or video -> App Saves it to documents folder -> Using coredata, application stores the filepath as string to access the image or video. (and User can backup anytime using icloud)
and Users can access those files in their other devices using iCloud. Please explain me if I'm incorrect or if you have better alternative or the question is wrong in any way. Thanks
I've done both ways and for me it's just a matter of how to use the database. If you'd like to to be able to backup the database and share with other, I would recommend storing files in CoreData as NSData. If it's just a local database it might be easier to store URL's to images stored on disk.
When you setup a Binery field in CoreData you can optionally select "Allows External Storage" which basically store the file on disk for you, but you can load it from the databas as if it was stored in the db. This is what I use most for images.
With this option, it is easy to create a zip file of the database and all binary files connected to it and also easy to unzip it to make a restore of the database.
So my iOS app has just been rejected because it's storing too much non-user-created data in the SQLite database, which lives in the Documents folder.
The app basically involves a relatively large library of images -- around 60-or-so megabytes of them to start, and there are also in-app purchases which each add an additional 60-or-so mb of images. Furthermore, the user can add their own images to the library.
Right now everything (images and all) is stored in an SQLite database, which is generated when the app is first launched. As the user adds more images, or purchases image packs, those images are added to the database. To the user, all the images (user-generated or not) behave the same in the app.
But Apple won't allow this: I can't have all that data stored in the SQLite database in the Documents folder unless I set it specifically NOT to back up to iCloud, as it's all recreatable data.
But if I set it to not back up, then the user-generated data won't back up either, which I definitely don't want.
Any suggestions how I might "split up" the database, such that all the user-generated stuff can be backed up, but the included-or-purchased stuff isn't?
The reason you are being rejected is not following the Data Storage Guidelines. Data created or edited by the user belongs within NSDocumentsDirectory, while application data should be stored elsewhere (i.e., the Application Support directory). These requirements are a result of how iCloud backup and disk space purging work on iOS.
For a Core Data application, this means your persistent stores must be split into two different sets of files, in two different locations. This, in turn, ends up driving much of the application architecture and data model. To have relationships between the user data and application data, for instance, you must use two different managed object model configurations and the relationship must be a fetched property.
There is more detail on how to implement this in this answer.
An alternative for your specific case would be to save the images on the file system, in the caches directory or elsewhere. User images could exist in NSDocumentsDirectory while application images could exist in NSCachesDirectory. This would remove the images from Core Data and instead your model objects would have the path to the image on the file system. This would be a short term fix to get you through submission, and would probably work.
One option will be, storing your data to a server and calling is using web service. During first launch. Or as per requirement.
I'm working on an Application that uses Core Data with iCloud (with the great improvement given by iOS7). This application stores data to describe a task with this information:
name a NSString
date a NSDate
image a NSString which describes a path to the picture
The pictures could be stored in Documents or Library Directory (I have to decide which is the more convenient folder), by the way, in the same folder with a unique name.
Now I'd like to activate iCloud sync for the images too otherwise the experience of the user will be incomplete (I just sync DB data.. no images, a strange/wrong behaviour for an app).
I'm really confused by Apple Documentation. I can't find a way to understand exactly how iCloud data works for this kind of needs. I just want to sync every file of a folder as soon as they will be created. So my questions are:
Could you share some good resources to learn how to use iCloud for file sync
Have I to use UIDocument and other iCloud API? or is there something "automatic". Quite a new bye/stupid question, I know :(
Are there any problem using Core Data and Document based iCloud synch in the same app?
Note: I know that I can sync data just by adding file in the document folder and hoping that users activate document sync... but this is not what I want obviously.
It is pretty straight forward to use both Core Data transaction log synchronisation and file based synchronisation in the same app to achieve what you want to achieve.
So you would set up your Core Data stack to use iCloud options and synchronise data changes via iCloud. At the same time you would store your images in the Apps iCloud container so they get synchronised as well. Just remember you need to use a relative reference to the images in your Core Data fileURL because the full pathname will vary depending on the device the app is running on. So for example you would just store the image filename in Core Data and use a standard directory such as 'iCloudContainer/Documents/Images/' to store them. 'iCloudContainer' being the URL you get by calling the [[NSFileManager defaultManager] URLForUbiquityContainerIdentifier:] API.
I have uploaded sample Core Data apps that use iCloud for transaction log synchronisation (i.e. synchronising data in Core Data) and that use file synchronisation for storing Core Data backup files in iCloud which can then be accessed by any device. You should be able to use the same code for moving backup files to and from iCloud for your images. Just remember you have to trigger download of files from iCloud before you can use them either by doing a coordinated read or by initialising the download using NSFileManager.
http://ossh.com.au/design-and-technology/software-development/sample-library-style-ios-core-data-app-with-icloud-integration/
http://ossh.com.au/design-and-technology/software-development/sample-library-style-ios-core-data-app-with-icloud-integration/sample-apps-explanations/
Download and run the sample apps and use the built in Backup File Manager to make backup files and to copy them to and from iCloud using different devices. Then just use the same code when storing your image files.
Your App does have to handle things like the user changing iCloud account, logging into or out of iCloud etc. and them move the core data file and image files accordingly.
The only way to have this happen automatically is to create a binary data attribute in your model for the images. If you do this, you will probably want to check the external binary storage allowed option, so the photos end up stored as files and not in the database.
If you would rather store the photos external to your store, you will have to do more work. You will need to migrate the photos into the iCloud container yourself, using the NSFileManager methods, for example. You could also use a class like iCloud Access if you find that easier.
The downside to handling the photos yourself is that you can never be sure that they have all arrived on your device when the Core Data store syncs, so it could be one or more photos are missing, even though there are entries for them in the store. You would have to make sure your app could handle this scenario, perhaps showing a placeholder image until the real photo was accessible.
There are no issues using Core Data and Document syncing in one app. In fact, they are exactly the same under the covers. From iClouds point of view, they are all just files to be transferred.
I am very new to core data and am trying to learn how to store large files, like images and short .mp3s. My app has about 300 different images and short .mp3s that are triggered to be displayed/played by user interaction, and as far as I can tell, I should use core data for storing these files.
I added a core data .xc file to my xcode project, and created an entity with attributes. I chose an attribute named "binary data" and checked the box "Allows External Storage," which from what I've read allows me to easily persistently sore files on 5.x or newer iOS phones. I know that I can program the app to get and set these attributes, but how do I just store my images and music files here?
Please help with me with code/understanding. It seems to me I should be able to somehow use the core data interface to set up a bunch of entities containing attributes of "binary data" that are my images and .mp3s, and whenever I need to display a pic or play a sound, I could call the entity and its attributes.
Thanks for the help!
I store compressed images (jpegs) with Core Data and it seems fast enough. But these are compressed to < 100K.
If you want to store items bigger than 100K, you might want to just save the file to "disk" doing something along the lines of Write a file on iOS
Then, save the file path to a string in Core Data. To load the file, get the file path from core data then read the file in.
I think Apple recommends the cutoff at 100K.