Can someone please what are Object Handles and Persistent Object handles in Blackberry ? and how are they different ?
Each object that you use in your application will use one Object Handle (and if you had say a vector with 5 elements that would be 6 object handles since the vector itself is an object). Each object in the PersistentStore uses a persistent object handle in addition to the regular object handle that it already uses. You have a limited number of object handles and persistent object handles on the device and when you run out of handles your application will get an error.
Let me know if that doesn't make sense.
Source
Related
I'm building a simple app in Swift using Core Data and trying to decide if I should store a unique id in my entities. In my research, I have found examples of that do and examples that don't, but I haven't found any clear reasoning behind this kind of decision.
Please note:
- I come from a RDBMS background and I know that Core Data is an object graph, not a relational db
- I do know that Core Data creates an NSManagedObjectID, but how do I determine if that will be enough
I see threads like this (from 7 years ago, by the way) which lays out these options:
Use -[NSManagedObject objectID]. Note that this ID is temporary until
either the object is saved for the first time or you call
[NSManagedObjectContext obtainPermanentIDsForObjects:error:] Use the CFUUID family of functions to generate a UUID for each object in your
-awakeFromInsert method
Create your own primary key-like system that stores an integer in your model and increments it with the creation of each object
but I haven't been able to find much information about which options are appropriate for which situations.
What questions should I be asking myself to figure out if Core Data's unique identifier (NSManagedObjectID) is all I need or if I should go beyond that and choose to include one of my own into the mix.
The only reason to use your own unique IDs with Core Data is if you ever sync the data to another device or web service. NSManagedObjectID is sufficient for local use but they don't work well for syncing. For example, if you get data from your back end server, it probably has unique IDs, but you can't force Core Data to use them. Likewise even if your syncing is to another iOS device, you can't force Core Data on the second device to use the same NSManagedObjectID as on the first.
For local use, NSManagedObjectID is all you need. If you need to save a reference to a managed object in user defaults, you can store that. Later you can use object(with:) or existingObject(with:) to quickly retrieve the managed object.
if Core Data's unique identifier (NSManagedObjectID) is all I need
Need for what purpose exactly?
Core Data maintains its object's primary keys internally, so you basically don't need to implement them yourself. In CD you interact with objects that already have a mechanism to establish relationships. You just have to assign one NSManagedObject to a property of another NSManagedObject and that will represent a O2O or O2M relationship like this:
anotherObject.parent = oneObject;
For many- side there will be a set for that. Have a look at the documentation.
The only scenario when you need some sort of foreign keys is when you syncing your data with some web-service.
You may be interested in this post if you need to store a reference to some particular NSManagedObject in user defaults.
And by the way, there is [[NSUUID UUID] UUIDString].
Within my Swift application, there are two classes that I interact with in almost 75% of the app. One is a set of settings called UserSettings, and the other is called Job. These both are stored in sqllite.
Most of the time it's just reading values already set, and on one areas it also writes. It seems strange to have to keep reinstantiating my settings and job services to communicate with my database to get back to me the same object i'm accessing across the board.
In a case like this, the options to me see to be either
constantly reading/writing to the database, or
do some sort of singleton accessed throughout the entire app.
I'm not sure how much Swift changes anything in terms of arriving at an answer to this question, but I wanted to seek the help of Stack Overflow. How do I set an object that I can access throughout the entire app? Or is it not ideal and instead I need to get it from my db every time?
Thanks so much.
I recommend you to read how core data works, I know you are managing your own store, but the architecture works fine. As a summary you can create a "context object"(this could be your singleton) who interacts with your store (sqlite) creating managed objects, you will work with this objects who are associated with the "context object", and when ever you need to save the changes, you ask the "context object" to write all the managed objects in the store.
Your managed objects need to be only a copy of the "context object" objects, so when you ask to "save" data to the "context object" you only copy back this managed objects. This will help with save multithread coding. (Your context object should work on a serialized queue).
Again this is just a summary, you should read how core data works to get a better picture.
Edit:
Read this blog: http://www.objc.io/issue-4/core-data-overview.html
The difference is that you only need one store and one context object.
I am currently using singleton instances to access and maintain various NSObject in the app.
For instance, I have :
VariableStores, that maintain several objects such as currentUser (custom NSObject), lastLocation (CLLocation), etc.
TaskManager, containing a NSMutableArray of NSOperations that have failed in order to be re-executed later (such as Instagram with failed upload).
If I kill the app, singleton instances are destroyed and :
- some data must be retrieved from the server side (for instance, the currentUser) which increase the length duration
- some data cant be retrieved from the server-side, such as the NSOperation in the TaskManager (as they are only managed locally)
Thus, I would like to go further and maintain that kind of objects even if the app is totally killed.
What should I consider as a good practice? Serializing object into NSUserDefaults and deserialize ? Is there other best practices?
In case of serializion, serializing objects in -applicationWillTerminate delegate and deserializing them in appropriate -init methods of singleton (that are instantiated in the appDidFinishLaunching) can be considered as acceptable ?
the idea of singleton pattern is just to transfer data between controllers without worrying about details ..
what you need to do is a persisting data of your App ..
you can use core data if you see that the data that you need to store is a little big for plists.. or you can use sqlite but that will give you a little pain for writing a lot of sql statements..
or you can use regular plist or nsUserDefaults (i don't like that option) but it's a little slow if the data is too much ..
you can save this data when app go to background or terminated..
I'm coding iOS 6.1 and learning Core Data.
If I have a Core Data entity/object in memory and I write it out, can I continue to hold a copy in memory, update it and write it out again?
Or, once I've written it out, do I have to read it in again to update it and then write it out again?
As you probably know already, Core Data uses both a persistent store and a managed object context. Data is loaded and saved using the managed object context.
The answer to your first question is yes. As long as your local reference variable is still in scope, you are able to update/save the content of the variable as many times as you want; remember, though, that it won't save to your back end unless you explicitly save your managed object context: [NSManagedObjectContext save:(NSError*)error].
Once that reference variable has gone out of scope, you'll need to fetch the managed object again if you want to edit it in any way.
My app needs to be able to disconnect from a server and connect to another one at whim, which necessitates dumping whatever persistent store we have. Issue here is that releasing the 'main' managed object context means whatever objects in it that I have laying around fault, which causes all sorts of unexpected little issues and crashes.
Is there a better way to 'reset' my stack/managed objects littered around the program than just calling release on everything in my Core Data stack?
You need to close down you Core Data stack from the top down.
Make sure that no managed objects are retained by any object other than the managed object context e.g. make sure the objects aren't held in an array owned by a UI controller.
Save the managed object context to clean up any loose ends.
Fully release the context and nil it. The context should never be retained by more than one object e.g the app delegate, anyway.
Send removePersistentStore:error: to the persistent store coordinator.
Use standard file operations to delete the actual store file.
Changing Core Data like this on the fly is difficult because Core Data isn't just a little database hung off the side of the app. It is intended to serve as the apps entire model layer. Since Apple is really into Model-View-Controller design, then the model is the actual core of the program (hence Core Data's name.) As such, you can't really turn it on and off the way you would a mere SQL database.
You might actually want to rethink your design so that you can change servers without having to shut down your entire data model. E.g. simply delete all managed objects associated with an unused server.
If you mean you want to fault all objects so they will be fetched again from your persistent store,
[managedObjectContext reset];