My application uses the PersistentStore to store data. The keys of the PersistentStore are created at runtime, so there's no way to know all the keys. I'd like to know if there's a way to retrieve or list the persistent store keys used by my application. I want to put them on a ObjectChoiceField and select the one I want to work with.
My application creates a name as a string, and then turns the string into a long value used as a key. I'm currently thinking to store the names of the PersistentStore on a single RMS, and with it retrieve the keys. But I would like to keep this option as a last resort.
The keys of the PS are created at runtime
You really want to use well-known keys rather than generating them at runtime. The persistent store is shared across all apps on the device, and I'm not aware of any way to list all the keys.
You could store all the keys as they are generated, which may be what you are suggesting as your last-resort. You would still need to keep one well-known key, and use that well-known key to store a Vector or array of all the other keys that have been generated.
Related
I am taking development courses for ios and I was wondering if I wanted to create a translation app would i use a array list to do so? As example code is:-
var dictionary = [“talofa”: “hello’, “faafetai”: “thank you”]
print(dictionary[“talofa”])
it shows up in the logs as “hello” but there has to be an easier way to do translations otherwise I would be fitting a whole language in a array list?
I also read online that people have been using third party services like google to make a translation app but my language is not on google (Hawaiian) what do I do?
First of all, what you are using in your example, in swift/objc it is called a dictionary.
Secondly, for such a huge amount of data, I recommend you use some sort of persistent storage. You can use plain text to store the dictionary (like creating a .plist file), but being iOS I would recommend setting up coredata.
CoreData will allow you to store the information on the device, and access it through a data Model.
Here you can find an example on storing in a file.
Here you can find an example on storing in CoreData.
I personally recommend using coredata for such a large quantity of data. Plist files are more suitable for storing low information quantities (like saving some credentials, some settings, etc).
You need to use DB for this. You can update it from your server when user will have connection, so you don't need to re-submit your app when you will update your vocabulary.
You can use CoreData as #Alex Bartiş told you or you can try another one which becomes popular: Realm
I am trying to add arrays,dictionaries via NSUserdefaults.
The physical path is rootOfMyApplication/Library/Preferences/bundleidentifier.appName.plist where I can see data that I stored via NSUserDefaults while testing on simulator.
Suppose I give simulator hash folder to a friend without source code, will it be possible for him to identify the keys that I have used while storing in NSUserdefaults?
There are other keys in the plist ,How can we differentiate between the ones that are stored via NSuserdefaults?
My experience looking at the NSUserDefaults plist file shows that keys that start with the following are from Apple:
Apple...
NS...
Web...
As long as you avoid those prefixes you should be able to find all of the app keys.
I always try to use a specific prefix to my keys to be safe but you don't have to.
I am wanting to add URL schemes to my iOS app, however the URL needs to be able to point towards a certain NSManagedObject from Core Data. I'm quite happy for my app to have to generate the URL for the user to use, but it just doesn't seem right to use the whole NSManagedObject URI in the URL.
When I retrieve the URI of the managed object, it is like this:
x-coredata://633EAF37-A03D-4954-976D-B3B0C32F8033/MyObject/p7
I'm guessing I can drop the x-coredata:// part which I can put back in my application:openURL method, but this still leaves me with a URL like this:
myurlscheme://event_to_perform?object=633EAF37-A03D-4954-976D-B3B0C32F8033/MyObject/p7
Is there more I can do to shorten this?
What about the has part 633EAF37-A03D-4954-976D-B3B0C32F8033? Will this be the same across every device the app is installed on, or is it unique?
If it was the same across devices then i'd only really need to use the final p7 as everything else I could add back in a string.
Any advice appreciated.
Thanks
Perhaps have a look at Permanent NSManagedObjectID not so permanent? first about the fragility of passing a NSManagedObjectID around. Marcus S. Zarra claims that the objectID can change during the life of a object.
That being said, the URI for a permanent managed object id seems always to be built like this:
x-coredata://<UUID>/<EntityName>/p<Key>
where
<UUID> is the NSStoreUUIDKey value of the metadata dictionary of NSPersistentStore,
<EntityName> is the entity name :-)
<Key> is the primary key that SQLite uses internally for the table (but which is invisible
to the Core Data API).
But note that this is only what I observed. The format is not documented and can probably
change at any time.
The <UUID> is generated when a store file is created, so it is not the same across every device the app is installed on.
So if the above analysis is correct and the URI scheme does not change in the future,
then you could indeed reconstruct the managed object URI from the final component p<Key>
alone.
That feels like exposing your implementation too much. I would highly recommend you maintain your own unique id property in the entity and use it to fetch the right entity from CoreData when you get a URL lookup.
This future proofs you should you ever, say, start syncing to a web-based version of your app or some other data store that is not CoreData.
First, Thank you for any help provided.
I have an iOS leveraging CoreData to retain various presentations, this data comes from a sqlite file and there is no server connection.
I will have to be able to provide App updates (via appstore), this update may add more data to the database.
The tricky part is that it can not simply overwrite the current database, there are a few user tables that I will not like touched.
Please provide any information I should consider when accomplishing this or any links are greatly appreciated.
Thank you.
Given your app has no server connection, you will have to rely on shipping data within the updated application itself. I would recommend using a plist file or define your own xml or json structure. You can then read this data to create/update core data nsmanagedobjects.
It looks like someone in the past was using plist->coredata on SO
Would you have relationships between user created data and shipped data?
If not, you might go the route of connecting two stored to the persistent store coordinator. The shipped store would be read-only. The store with user created data would be read-write. You can use this approach, too, if you have relationships between shipped and user-created objects, but it's a lot more complicated, since CoreData doesn't manage cross-store relationships for you, and you'll need to write your own logic (doable, but not straight forward).
If you need to have relationships between shipped and user-created objects, you can still ship a CoreData store. When the app launches for the first time (no user-created objects), you copy the store to the Documents folder and user this store to create your CoreData stack. User created objects will be added to this store. Once you have new 'shipped' objects (i.e. a new store in the app-bundle), you'll have to manually migrate that stores data into the store that the user has changed. You'll have to be able to find
(1) objects that need to be deleted
(2) objects that need to be updated (changed)
(3) objects that need to be added
If you mark your shipped objects with a special flag such that you can tell if it's a user created object or a shipped one, that would be doable. You also have to have some sort of ID to be able to tell which objects in the new store correspond to which ones in the existing (old) store.
You do not need to go the route of using plists. In fact, I'd recommend against it. You can easily open two stores at the same time. Either to use both stored, or just to migrate objects from one store to the other store.
i am trying to work on nsuserdefaults but few things are confusing me in apple reference and setting guide they says
Preferences are pieces of information that you store persistently and
use to configure your app. Apps often expose preferences to users so
that they can customize the appearance and behavior of the app. Most
preferences are stored locally using the Cocoa preferences
system—known as the user defaults system. Apps can also store
preferences in a user’s iCloud account using the key-value store.
The user defaults system and key-value store are both designed for
storing simple data types—strings, numbers, dates, Boolean values,
URLs, data objects, and so forth—in a property list. The use of a
property list also means you can organize your preference data using
array and dictionary types. It is also possible to store other objects
in a property list by encoding them into an NSData object first.
but what is users defaults system and further on in this guide they say users defaults database... if they are talking about database then why here they wrote use of plist?
similar question but not helping me
thanks in advance.
NSUserDefaults is a key value store for saving preferences. It works very much like an NSDictionary where you insert an object for a key, and pull it out.
Since the object needs to be saved to disk, only plist serializable objects work, unless you turn them into NSData first.
It is not the type of database you can run SQL queries on.