I am using a sql based database in one of my application with Core Data framework. I have not enabled any file protection for persistent store (using NSFileProtectionKey). But I am unable to open my database file store in a directory under 'Caches' folder in Library.
Have you ever come across such an issue. Below is the image I am getting when I try to open the sql file. However, a difference from iOS 6 I could see in that folder is there are two additional files (-shm and -wal) present with the same name of the sql store file.
Could anyone please help me to find a solution to open the file.
The -shm and -wal are journal files created using write-ahead logging. You need all 3 files for a complete database. I haven't seen an encryption error falsely triggered by not obeying this rule, but it doesn't seem out of the question.
See https://developer.apple.com/library/mac/qa/qa1809/_index.html and http://asciiwwdc.com/2013/sessions/207.
Related
I have developed a hybrid mobile app that has been running on IOS, Android and Chrome reasonably well for over 5 years. My app uses an indexedDB database to maintain the state of the app and save it between restarts, however there are some cases where IOS can clear the indexedDB particularly if the client device is running low on memory.
I would like some help on how to maintain a parallel copy of the indexedDB using the native SQL database on the IOS device, in order to increase the resilience of my app, based on the hopeful expectation that IOS will not arbitrarily decide to clear an internal SQL database belonging to the app.
I understand how to communicate in both directions between Objective C and Javascript but I have not the foggiest idea in Objective C how to:
Create a SQL database in the app file system
Choose where to place the SQL database in the app file system
How to write a new key value pair to the database
Overwrite an existing key value pair in the database
Read back all key value pairs from the database (I expect there could be up to 1000 of these in practice) and pass these efficiently back to the javascript code.
Clear the database and start again.
Any pointers to useful resources on how to achieve this or better still coded examples would be most appreciated.
I would just like to add that I am not using Cordova or any other similar app development environment, so please do not suggest a SQLite plugin that is part of a bigger environment. I have got to where I am with a bespoke coding approach and I would like to keep it that way.
I have explored the idea of paralleling up each indexedDB save with a write to a file in the IOS App Documents Folder with the hope that this is less likely to be wiped than the Caches Folder.
Following each indexedDB setItem with a key-value-pair I pass a request to the objective-C IOS app code to create a text file in a sub folder created with the App Documents Folder, with the name 'key'.txt and the contents set to value.
Following each indexedDB removeItem, I pass a request to the objective-C IOS app code to delete the corresponding text file 'key'.txt.
Following each indexedDB clearAll, I delete the entire sub folder created above.
Now when the app starts up and discovers an empty localForage database, I pass a request to the objective-C IOS app code to test if the sub-folder with key-items is there or not.
If it is not, then this is a fresh install of the app and continue as normal for such a case.
if it is, then this is a case of the indexedDB database having been deleted.
In such case, I request the objective-C IOS app code to return the set of keys, by examining the contents of the folder created above and stripping off the .txt bit and in the case of the IOS Simulator ignoring the DS_Store file.
One by one I then request the contents of each key file and load them back into the previously empty localForage database and when this has been done I can continue as if it had not been deleted.
I found that it is necessary to use a zero duration timeout in the javascript before requesting each value to prevent call stack exceeded errors when restoring large databases.
This approach seems to work and I can test this any time by using the Safari Developer Resources tab actions to clear the database and then manually restarting the app. Using the same tab you can watch the indexedDB database being repopulated.
Due to the size of my database, I actually created a set of sub folders of different types of key, so that I could choose the order in which the database items were restored, especially as my app is often brought back to life in the background following a significant location change and in such cases there is an imposed maximum time limit on how long the app is given to do such a recovery. This refinement is of course optional and only needed for large databases.
The following notes are for anyone who wants to try this approach and assumes using Objective C in XCode 10.1
Use NSHomeDirectory() and stringByAppendingPathComponent #"Documents" to get the Documents folder.
Use stringByAppendingPathComponent to create a sub folder path for the keys sub folder.
Use fileExistsAtPath to check whether the keys sub folder exists already
Use createDirectoryAtPath if it does not.
When saving or changing items in indexedDB use the stringByAppendingPathComponent to create the key file name path e.g. Base.txt for a key of 'Base'.
Use fileHandleforWritingAtPath to get the fileHandle for a file
if fileHandle does not exist then need to create it using writeToFile to create the 'key' file
if fileHandle does exist then truncateFileAtOffseyt:0 (important) to clear it and then use writeData to create a new version of the 'key' file.
In both of the above specify UTF8 encoding.
When removing items from indexedDB do the same to get the key file path and then use removeItemAtPath.
The device can be cleared by removing the entire sub folder using removeItemAtPath.
The restore process uses contentsOfDirectoryAtPath to read the set of keys in the sub folder.
The restore process for each item uses stringWithContentsOfFile to read data files and return the contents enclosed in quotes using a call to stringByEvaluatingJavaScriptFromString
Hope this helps.
Sorry for my english.
I have developed a mobile application that needs its own local data store. I chose Realm as the database management system. In the process of studying the Realm documentation I had no problems with the database design, it's normalization, the CRUD-operations and everything that is related directly to the code.
I was confused following. I test my application in the simulator. I did not create the local database. I’ve just done it as it is written in the documentation of Realm. Realm created by itself its database and I did not specify any settings. The location of my file with database is given below:
/Users/macbookpro/Library/Developer/CoreSimulator/Devices//EFECD945-285C-494F-8C1B-950D9AA05147/data/Containers/Data/Application/8D71FF0A-60D2-4875-96BB-36955E80D505/Documents/default.realm.
I quite inconvenient to apply each time this path for the analyzing of records in the database. The file is stored at this path is inaccessible for Realm Browser, because I need root privileges. I have seen that people store their .realm-files in project directory. Answer me please - how can I do it? Would it be the right alternative?
I have repeatedly seen the code, where paths to the database file appeared. For example, here: https://github.com/pietbrauer/CarthageRealmUploadFailureExample/blob/master/Carthage.checkout/realm-cocoa/examples/ios/swift/Migration/AppDelegate.swift
I'm not sure if it's the right direction.
As a result, I want to:
1) have on hand a database file and be able to quickly refer to it;
2) know the algorithm - how to set own path to the Realm-database
file;
3) know what realm configuration must be on a real device, to
ensure security and data integrity.
Thank you very much to all!
When you don't specify a path for the default Realm in your app, Realm will automatically create one named default.realm in the Documents directory of your app. On apps running in the iOS Simulator, this will save the Realm file in the appropriate Simulator folder, but you are correct in that it's not very intuitive to find it.
In response to your questions:
There is a cool utility called SimPholders that lets you inspect the Documents folders of apps in the iOS Simulator. This is the best way to get at any Realm files the Simulator has generated very quickly.
When creating an instance of a Realm object, you can supply a Configuration object to customise it. You can explicitly set the file path of the Realm file by setting the path property of that Configuration object.
iOS supplies an automatic layer of file encryption on disk, that makes files unable to be read when the device is locked. If you want additional security, then it's possible to set the encryptionKey property of a Realm Configuration object to have a Realm itself encrypt that Realm file on disk.
I hope that helped! Let me know if you need any more clarification!
1) and 2) does have very small effect on security and data integrity
3) if you are worry about security of you data, use Realm-level encryption like here
I am having problem reading a file. I'm using MagicalRecord as my CoreData wrapper. I successfully save or update object. With my NSLog I can see it, everything is fine and I can use it in my database. But every time I want to see SQLite file with my application (I'm using Datum LE), file is empty. I cannot access that file directly within my Library folder in my app. I copy that file to my desktop and it is empty. What am I doing wrong? So once more, everything inside my iOS application works fine, I can see records being saved and I can fetch them normally.
You are clearly looking at the wrong file. If your app is saving (I assume, across app restarts), the date is definitely saved.
One way to find out is to NSLog the persistent store URL and check the referenced file.
I believe the issue you are encountering is the new default journaling mode that Core Data uses.
See this article
https://developer.apple.com/library/ios/qa/qa1809/_index.html
Basically your changes are not written to the .sqlite file, but are found in .sqlite-wal. HOWEVER, most SQLite reading apps I have tried blow away the -wal when you open the .sqlite, so good luck.
You could try changing the journaling mode for debugging purposes
I developed an Ipad app which download different kind of files, but after a week or some days the downloaded files are removed and the app that open the file can find it anymore.
Could anybody help me, Where should I save downloaded files in my app to avoid that the file came automatically deleted?. IOS usually remove downloaded files after certain time?.
I already read this apple documentation
I know that maybe is not something complicated but I can't figure out why the file is removed If anybody can help me I'll appreciate that.
Put data cache files in the /Library/Caches
directory. Examples of files you should put in this directory include
(but are not limited to) database cache files and downloadable
content, such as that used by magazine, newspaper, and map apps. Your
app should be able to gracefully handle situations where cached data
is deleted by the system to free up disk space.
Most probably you are using caches/temp directory which the system can clear contents of in case of low space. To avoid deletion use Documents Directory.
If you are already storing in documents directory, then the file can appear missing if you are storing its hardcoded path , which can change during app update. Try storing relative path and log the contents of your documents directory to see what files exist.
save the files in your local sqlite db, data core or if you can serialize them with the standard user defaults
My app uses Core Data and I want some default entries to be inside.
What's best practices of how to do that?
If you're already loading the pre-load data via a temporary routine for testing in your current code there's no reason you can't use the sqlite file it creates in the simulator's directory (no need to write a separate Mac app).
If you're not already filling that db you can still write an iOS app that does it. Odds are you've already written the methods for adding data to your store so you can use them to import the pre-load data as well.
Either way you'd grab the sqlite file from the simulator's directory and add it to your app's bundle; on first launch you'll copy it into the appropriate place in the app's directory before pointing Core Data to it. If it's really large the downside is that there will be a copy in the bundle and another on disk, but there's not much you can do about that other than grabbing the data over the network.
As others have suggested, if the amount of data is small you can just import it at first launch, using the methods you've already written for adding data as part of the normal app's workflow.
See the CoreDataBooks example, which has sample code for copying a database at first launch.
EDIT: I've created a Core Data framework (read about it here: http://bikepress.org/?p=1120) that includes this feature.
I would just create a database and put add it to my target so that Xcode copies it into the app bundle. At the first launch just copy it from the app bundle to eg. the documents directory or wherever your app expects the database.
There is Core Data Editor at the app store. Alternatively you could build your own simple mac app just for this particular DB and manage it from there. If the amount of default entries is small, then you're better off storing it in a plist or something and loading it into DB after the first launch.
In iOS 5, my app was rejected if I put a database file into resource bundle. So, I have to download the database from internet instead.