I've created an app that uses the Alloy framework to store data. I've found that the default Alloy database that gets created is called _alloy_.sql and is stored in the app's [APP_ID]/Library/Private Documents in the iPhone Simulator.
I was looking around on how to get this database backed up on iCloud, so that the users data would stay with them from device to device. But all the questions I found online where about turning this feature off, please see Support turning off iCloud backup for auto-generated model databases.
I have a few questions around this:
Does this mean that the default Alloy database is already backed up on iCloud?
Is there a way to confirm that this is the case?
How do I test that it is successful?
Should my app appear inside the iCloud settings section of the iPhone settings?
The Alloy database is exactly the same as every other database that you can create using
Ti.Database.open("db_name"); // _alloy_
or
Ti.Database.install("db_name"); // _alloy_
And it should be backed up by default ,so yes you are right it is already backed up.
You can find out more here https://developer.appcelerator.com/question/163013/icloud-backup-and-restore
Related
I have read so many blogs but still its not clear to me that whether iCloud backs up the keychain data which are stored programmatically using SecItemAdd or not ?
iCloud Keychain is a feature introduced with iOS 7.0.3 / OS X Mavericks 10.9.
In order to take advantage of this for data stored programmatically using SecItemAdd, you have to update the item with the key kSecAttrSynchronizable.
This key is not added by default so items without it will not be backed up to iCloud.
Also, even with kSecAttrSynchronizable properly set, bear in mind that users might not have enabled the iCloud Keychain feature from their point of view, meaning that they wouldn't be synced either.
I have an iOS 7 app, that is using Core Data. Some of the Core Data objects has a related (one to one relationship) images that are > 1MB & < 4MB and are stored in the app’s Document folder. Core Data objects only stores image names as string.
I want to integrate iCloud support for the app so I can sync data between devices. I am planning to use iCloud Core Data storage to sync Core Data objects. But what to do with the images?! After reading different posts, I found a couple of options that are highlighted underneath. I am struggling to pick one, that would suit me best. It would be nice to know someones experience/recommendations. What I should be careful with, or what didn't I think of? I also need to consider migration of the existing data to the option I will pick.
OPTION 1. Store UIImage in the Core Data as Binary Data with External Binary Data option (read here). At this moment is seems to be the easiest solution, but I guess not the best. From Documentation:
It is better, however, if you are able to store BLOBs as resources on
the filesystem, and to maintain links (such as URLs or paths) to those
resources.
Also will the external files be synced? If so, how reliable the sync would be if the user quits on minimises the app, will the sync process resume? From objc.io about External File References:
In our testing, when this occurs, iCloud does not always know how to
resolve the relationship and can throw exceptions. If you plan to use
iCloud syncing, consider unchecking this box in your iCloud entities
OPTION 2. Store images using UIDocument (good tutorial here) and somehow track relation between Core Data entry and UIDocument. From what I understand whatever I put in this directory will be automatically synchronised to the iCloud by a system daemon. So if the user quits the app, the images will still be synced to the iCloud, right?
OPTION 3. Using FileManager(more info here). I haven’t read a lot about this approach, but I think it can also work.
OPTION 4. Any other?
There are similar posts (e.g. Core Data with iCloud design), but unfortunately they don't fully answer my question.
Seems Apple will reject application because of large database iCloud synchronization.
I think the best solution is to store images on a remote host, and keep Image URL in CoreData.
And also Local path of image should be resolvable from remote URL.
So the algorithm will look like this ->
1) Getting Remote URL from CoreData.
2) Resolve local path of image.
3) If local image exists retrieve it, otherwise read it from remote and save it to local storage.
You can have a look to Amazon S3 server here.
I am using phonegap for IOS app development. Now, phonegap tries to find the db by default in 'NSCachesDirectory', but whenever IOS runs into memory problems, it tries to delete data from 'NSCachesDirectory', so, the data is not secured. If i am not mistaken, this problem was solved in cordova 2.1.0, where the back-up of data is taken and then restored afterwards. So, just wanted to confirm if i am heading in the right direction or data itself can be stored in 'NSDocumentDirectory' so that data is secured and somehow phonegap looks for db in 'NSDocumentDirectory' and not Caches direcory. Thanks.
Only documents and other data that is user-generated, or that cannot otherwise be recreated by your application, should be stored in the /Documents directory(You can store DB in Documents directory)
Data that can be downloaded again or regenerated should be stored in the /Library/Caches directory.
It would be useful for many people to know how to completely remove an application from your device when testing.
I have downloaded my app many times now, and likewise have deleted it many times. The problem is when deleting the app, it does not remove things like the persistent object related to my app, or the images downloaded through the app. So, when I download the next build, I have no idea if something broke that is related to building the persistent object or fetching the images since those elements already exist from the last build.
I don't know if this is a cache thing. I don't know if this is expected and I have to use some utility to wipe this data after deleting the app. I can't really find much info through basic web searches.
Any information would be appreciated.
Blackberry Bold 9000. 4.6 OS. tested with both SD card and no SD card.
Objects stored in the PersistentStore are automatically deleted on uninstall if their interfaces were defined in your project. If they are from the standard BlackBerry API then they will stick around until they're deleted. E.G if you save a String in the PersistentStore it will stay in the PersistentStore but if you save a class you created it will be deleted on an uninstall. So if you want to have those objects be deleted automatically just create a wrapper class and save that.
Images stored on the filesystem will not be deleted until you or some application deletes them. However, it should be easy for you to write an app that clears everything out.
Another solution you could implement is making your app somewhat self-aware of its data.
Create a simple String value that you persist (or optionally, persist it in a Hashtable so you can store many properties this way) that includes "Version".
At startup of the GUI app, compare the stored "Version" against the application's current version. If the stored version doesn't exist, or if it exists and matches, take no action.
If it exists and does not match, automatically clean up old persisted data; or alternatively prompt the user to see if they want that data to be deleted (which one is better will depend on your implementation)
You can also use CodeModuleListener to listen for an uninstall event -- when that happens, you can clean up at that time as well or instead.
(As an aside and a bit of shameless self promotion, I am actually currently working on a shareable library for Blackberry that makes managing persistence much easier, as well as desktop data backup/restore. I'm doing this as part of the BBSSH project, but I'll be splitting it off into a separate library of core components and publishing it under a dual GPL/optional commercial license. It will contain hooks for data cleanup and data versioning. )
I developing an app that is read-only. The data has relationships, so I cannot just use a plist or something similar.
Questions:
Should I use Core Data for such a requirement?
If so, how would I enter the data and then release the app with that data?
How would I make it so that the app doesn't need to re-populate a DB every time it loads?
Is there a way to create a Core Data model using sql commands with sqlite (i.e. insert into, etc)?
You may use an SQLite database to accomplish this.
Create the model in your iOS app.
Create and populate the database in a Mac OSX utility command-line app
Copy the sqlite file into your iOS app and link it with some code
Work through these two tutorials, line by line, and afterward you will have a good enough understanding (and code sample) to complete this task in your own app.
Core Data on iOS 5 Tutorial: Getting Started
Core Data on iOS 5 Tutorial: How To Preload and Import Existing Data
In my short experience with the iPhone, you have two options.
Write a data import function and run it on the first application launch.
Use solution 1, but build the initial sqllite file in the simulator, and then on first application launch, copy it into the app's documents directory.
From past experience, option 2 is much quicker for user experience, and the preferred solution.
You can write a utility project that imports the app's data model and use throwaway code n that project to populate the Core Data DB. Once the DB is populated, simply copy the actual file to the app project's resources folder and then when you set up your persistent store, use NSBundle to return the path to the DB file within the built app.
And you're done.