I'm attempting to make the values in a .plist Multi Value dynamic. Specifically, I want to download a list of options from a web site and populate the values with the returned data. I have read a couple of posts stating that changing the app bundle during runtime is impossible. Is it not possible to make the values refer to a data source outside the app bundle, for example if I put the alternatives in NSUserDefaults and read from there?
If this is totally out of the question, what alternatives are there?
What I do is copy the plist into a hidden folder in the documents directory and work with that copy
If the file does not exist, copy it entirely, and if it does, do some merging or overwrite completely, whatever fits your needs
Working with NSUserDefaults is also a possibility
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.
I have created a plist file in the bundle, and I'm trying update the user's information into the plist. I know that I should copy the plist file from the bundle to the document directory, and edit it from there, but I still have a couple questions:
When I copy the plist file to the document directory, is it permanent? I mean, if I close the program and open it again, I can simply edit the plist file in the document directory, right?
If so, does it mean that I should only execute the code that copies the plist file to the document directory once the app is launched for the first time?
/main question/ Since I want a blank plist file for the user to update their data with, should I just simply create a plist file on the first launch? It'll be a lot easier without the copying around bundles and stuff.
I mean, what is the point of creating a plist file in the bundle in the first place? We will copying it into the document directory anyway, so why not just create one in code?
Yes. Writing a file is permanent, as long as you obviously don't delete/move the file somewhere else.
That is a valid option
Yes. If you need a blank file, you don't need it from the bundle. A better idea would be to create it when you need it (when there is something to write). Usually file creations are managed like so
Check if file exists
If not, create it.
Use the file.
If you need a template file (with already some stuff written in it), then a copy from the bundle is more appropriate. But even then, a lot of developers will like to do everything from code, it's not that heavy of a task, and it forces you to create/prepare the right objects and methods from the get-go.
Like Rooe N said, the NSUserDefaults IS a property list, so if you're talking about very simple data, say, like a username and a last-time-I-logged-In-date, you could store it there.
Note that NSUserDefaults are loaded all the way, every time you load the app, so you don't wanna use it as a database. But since you're going for .plist, I'll assume you've already ruled DBs out.
I'm not completely sure what you are trying to achieve, but you should think of plist as a place for global Constants not something that should be updated on runtime.
Maybe you should look at this:
NSUserDefaults
My iOS app uses CoreData and some tables need to be filled with default values every first time the app is opened since CoreData device-dependent.
So I am using NSUserDefaults to check whether it is first time open. If it is first time, I fill tables (on CoreData) with the values which I have already created and formatted lines from the txt file by reading line by line and separating in a way.
And my question is, is it safe and fastest way to use txt file for such operation?
A better option would be to keep a "canned" sqlite file in your app bundle and check for the existence of the SQLite file in your documents directory. If the file does not exist, copy the canned data from the app bundle to your documents directory.
That will skip the entire parsing logic and will allow your application to launch faster.
Marcus' approach is also what I would recommend. But you can still keep using your parsing code during development in order to have a convenient way to create the seed SQLite file. When you ship your app, package the newest seed store as a bundle resource and disable / delete your parsing code.
I need to be able to configure my app via configuration file.
How do I go about it?
The first thing that comes to my mind is having a .plist file that stores values and to have an singleton class and ask that class for values whenever I create element in question in code.
Or is there any better way to do this?
Depends on the amount of content and size of the configuration file.
If it's a couple of key-value values, I would just go with NSUserDefaults.
If it's a bit more, arrays or more advanced data models, I would go with a .plist. But remember to move the default .plist into the /Documents folder, you are not allowed to edit files in the app bundle.
I got an app I'm working on that uses static data from a sqlite database to do various things, While I only need read only access to the database, depending on the episode they pick from the first screen I want it to use a different database file and I want the list of available episodes to be updateable on the fly. and I got help to get the list of available episodes updated, and the proper content downloaded and stored in separate folders, So I know I could when the episode is selected delete the sql file in the documents folder and copy in the new one each time and that would work well enough for what I'm trying to do. but it seems like a bit much extra work to have to check for file, delete file, copy in new one. then open it from there each time the user wants to pick a different episode. and I don't want to put all the sql files together as that will be a bigger hassle then the first route especially if this app stays around long enough to have a long list of episodes.
so my question here is: can I get at least read-only access to an sql file that I've downloaded (or one in the bundle for testing) with out having to first copy it to the documents? and if so how would i open the file?
Can I get at least read-only access to an SQL file that I've downloaded (or one in the bundle for testing) without having to first copy it to the documents directory?
Yes. Files in the app bundle are readable (if they weren't, there would be no point in storing files in the bundle).
And if so, how would I open the file?
It's not clear what you're asking here - if you want to perform SQL queries on the file, you should use the sqlite3 library which is available on iOS.