#fetchrequest

The Managed Object Context is the epicentre of all Core data Programming. Its strewn in every sentence while learning CoreData and finds itself between most of the method calls in a CoreData driven application.

But what exactly is a context ? 

Its crucial for anyone trying to learn CoreData programming to be able to picture what a context is. Context is better understood as something that is, rather than what it does.

So what it is ? 

A Managed Object Context is a space in RAM or fast memory.

Thats it ! You could probably close this tab and move on, because this blogs purpose has been fulfilled. 

Okay for those of you who want to stick around and know more.

A context is a space in fast memory which allows faster read and write, so that data can be retrieved and stored faster during an applications life cycle to provide a smooth user experience and can only be persisted when necessary. Here’s a pictorial representation to help you understand better.

As you can see, there are three main regions for any CoreData driven application. There is the persistent Store which is most probably an SQLite database in iOS which lies at the very end of any application, there is your application’s UI which lies right at the top level and in-between these two lies the the RAM which contains a space called the managed object context. 

Now obviously the managed object context is just not a space in RAM. Its actually an API to manage that space in RAM, meaning it contains methods and variables and a whole lot of other stuff to manage that space in RAM. Conventionally when you start a project with CoreData selected, there is a whole bunch of boiler plate code in your AppDelegate files which sets up your persistent store and managed Object Context. 

After your SQLite database has been set up, a space in RAM is also set aside for the Managed Object Context.

Assuming you have done a bit of CoreData programming, There are a set of imperative code you write for an CoreData driven application. 

Here’s a picture depicting some of the functions that are performed throughout your application.

                                Inserting Objects

When the need to persist data occurs the first method usually written is

[NSEntityDescription insertNewObjectForEntityForName:@"Your entity

Name" inManagedObjectContext:self.managedObjectContext];

If you draw your attention to only the name of this method, you can see the part insertNewObjectForEntityForName which means create managed objects of the model class having a name @"Your entity Name" and if you notice the last part inManagedObjectContext, it actually means store these objects in the context that you provide through the parameter.

This method returns a pointer to that managed object, just created in that space in RAM and you can now go ahead and treat this as an object. 

(Note: any object that belongs to Managed Object Context is referred to as a managed object.) 

So your new managed object now lies in RAM, inside a space given to your Managed Object Context. But as we all now, that any object will be flushed away if its not persisted. 

Hence the second method call

 [self.managedObjectContext save:&error] 

As its now evident that we need to tell the context to take this object we now created and store it permanently in your persistent store file which mostly is an SQLite database. 

This method returns a BOOL of YES or NO stating whether the save was successful or not, and takes a pointer of an NSError to debug incase if the save was not successful. This causes the managed objects information to be written and stored permanently in your SQLite database. 

Does this mean the managed object is removed from the Managed Object Context ? 

NO ! Your object still lies in the Managed Object Context.

                                     FETCHING

Now you have saved a whole lot of objects in the database, its time to fetch‘em.

Lets take a look at how fetching works. 

While Fetching managed objects there are two main criteria’s you need to specify to fulfil a fetch.

What are you looking for ?

Where do you want to look ?

The first part is handled by an instance of a NSFetchRequest which specifies what class does the managed objects your looking for belong and are there any particular kind of managed objects you need .

Heres an example : 

NSFetchRequest *request = [NSFetchRequest fetchRequestWithEntityName:@"Your entity name"]; 

Here your specifying what class does the managed objects you need belong too.

An instance of NSFetchRequest also has references to instances of NSPredicate which tells what kind of objects are you looking for, in other words your search criteria. And an instance of NSSortDescriptor which specifies any sorting order you need for these managed objects. 

This completes the first part of what managed objects you need. Now moving on to where to look for the objects. 

This is the most important part, where do you find these objects you are looking for? Obviously the same place you created them, in a Managed Object Context.

Hence you tell the Managed Object Context to execute a fetch request which contains what is your search criteria so that it can look around in that memory space in has in the RAM to return the objects which fulfil your criteria.

Heres an example of the method call to fetch. 

[self.context executeFetchRequest:yourRequest error:&error];

As you can notice you are asking the context to look for these objects by passing an instance of NSFetchRequest and an instance of an NSError to debug incase the fetch was not successful.

This method returns an array of objects that fulfilled the criteria or nil if there were no objects. 

Sometimes an Object may not exist but exist in your Sqlite Database, therefore the context automatically will retrieve the information from the database and create an object for you.

Thats what the Context is all about. And it should be clear now as to why its important to pass the same instance of the NSManagedObjectContext through out the classes of your app. Because you need to access the same memory space given to the Managed Object Context. 

Before you start, here is the first and second part of this series: 

Core Data tutorial Part 1 / 5 - Create Core Data Managed Object Model with Attributes, Relationships and Delete Rules

Youtube Video Part 1

Core Data tutorial Part 2 / 5 - Save Entity’s Attributes, Relationships, and make FetchRequest

Youtube video for part 2

Core Data tutorial Part 3 / 5 - Edit, Delete Objects

Youtube video for part 3

Check my article: “You must to know! Collection - Core Data simple explanations” 

IOS 8.1, Xcode 6.1

Steps in part 4:

Create Hobby Entity - change Core Data model

Create and Save hobbies to user.

SortDescriptor and NSPredicate

1. Create Hobby Entity - change Core Data model

1.1. Add New Entity, Name: “Hobby”, and add attribute: “hobbyName” as String, and then create relationship: “userofhobby” destination:User, type: to One.

1.2. Add the “hoobiesofuser” relationship to the User entity, set the Destination to Hobby, set the inverse, as “userofhobby”, finally set type to “to many”.

1.3. Now, you must to update your Core Data model. You have 2 ways to do this.

1. case you should just delete the entity’s earlier .h and .m files, and delete the App from the simulator. In this case you just work on the project, but this App not available in the App Store, so you do the changes just for yourself. We do now this.

2. case you have to do migration, before send the App to the Appstore. We will do in the fifth part of this series.

So just Delete (Move to trash), and then Editor - Create managedObject again

1.4. Open Simulator and delete the App. After that run the app, test that it works again. Create some user with type, and save them.

Great!

// <![CDATA[ (adsbygoogle = window.adsbygoogle || []).push({}); // ]]>

2. Create and Save hobbies to user.

2.1. Create a new TextField on storyboard, check delegate!, and declare in ViewController.h file property, and synthesize in .m file, and import Hobby.h file in your ViewCotnroller.m.

2.2. Set the Textfield3 properties as the TextField1 and 2. You should just copy them.

looks like this:

2.3. Change the prepareForSegue code to save the hobby for the user. Set hobby1 string with TextField3.text, and add to the user.

2.4. In MyTableViewcontroller.m import Hobby.h file, set the cell.detailTextLabel.text to show on first place the typeName string, and the second place the hobbyName string. You have to create an Array for the user1’s hobbies, and then from that detect hobby1 object, and use the hobbyName string.

2.5. Test you App!

You can see (null) where no hobbies of the user. So you can create a Predicate to check, if user has hobby we list, and in other case no.

3. SortDescriptor and NSPredicate

First of all do look at this SortDescriptor code, we use it, and then we can see our list just in alphabetical.