Top Posts Tagged with #xcode 6.1

“You must to know!” Collection - Core Data simple explanations

With Core Data framework you can managed your objects in your App. You can manage your object’s life cycle and object graph, so the attributes and relationships of your entities. You can edit, save modify and rebuild your database. You can group, filtering, organizing your data. I try to explain just the basics with my example.

I’m going to create a model with users who are listed some types (family, classmates, friends, love) and they have various hobbies.

In our model a user can belongs to only one type, but one type can contain multiple users. For example, the family type may contain brother, mother, and father as well. But Father user cannot be in the type of “classmates”, if it belongs to already “family” type.

1. ManagedObject, ManagedObjectModel and ManagedObjectContext

First you need to describe your objects or entities, so you have to create a schema, which can tell what is the property or name or class, and which attributes can you use to describe your object, which belongs to an array. This schema will be the Managed Object Model. For example:

Entity Description:

Name: “User”

Classname: “User”

Property: array

The array property consists collection of attributes and relationships. Example:

Attribute ————— collection

Name: “userName”

Type: “string”

ValueClass: “NSString”

Attribute ————— collection

Name: “userBirthDate

Type: “date”

ValueClass: “NSDate”

Relationship ————— collection

Name: “typeofuser”

Destination Entity: Type

More info about Managed Object Model in Developer Library

The ManagedObjectContext is the place or space, her you can manage your collections of managed objects. You can do any modification with your objects and relationships in the same context, so you can manage and follow their life cycle.

More info about ManagedObjectContext in Developer Library

2. PersistentStoreCoordinator

Developer Library gives you a very clear explanation:

"A persistent store coordinator associates persistent object stores and a managed object model, and presents a facade to managed object contexts such that a group of persistent stores appears as a single aggregate store. A persistent store coordinator is an instance of NSPersistentStoreCoordinator. It has a reference to a managed object model that describes the entities in the store or stores it manages.

The coordinator is the central object in a Core Data stack. In many applications you just have a single store, but in complex applications there may be several, each potentially containing different entities. The persistent store coordinator’s role is to manage these stores and present to its managed object contexts the facade of a single unified store. When you fetch records, Core Data retrieves results from all of them, unless you specify which store you’re interested in.”

Source

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

3. Relationships

In our example, we have one type with more users, so this will be a one to many, so “to-many” relationship. We can call this relationship “usersoftype”, which located at Type Entity, but the Destination is User Entity.

It has an Inverse, because we have more users with one type, so this relationship from this side, will be “to-one”. And we can call “typeofuser” which belongs to User Entity, but the Destination will be “Type”, because the connection end/belongs at/to “Type” Entity.

You can see in Xcode the Core Data model in Graph Editor Style, and you can check yourself:

"You can specify a relationship as being to-one or to-many. To-one relationships are represented by a reference to the destination object. To-many relationships are represented by mutable sets (although fetched properties are represented by arrays). Implicitly, “to-one” and “to-many” typically refer to “one-to-one” and “one-to-many” relationships respectively. A many-to-many relationship is one where a relationship and its inverse are both to-many. These present some additional considerations, and are discussed in greater detail in Many-to-Many Relationships.”

Source Core Data Relationships

4. Delete Rules

We have Type Entity and User Entity, and we have usersoftype and typeofuser relationships. When you do the settings, this will look like this:

User Entity

Relationship: “typeofuser”

Destination: “Type”

Type: “To One”

Delete Rule: “Nullify”

In this case we just tell to the destination object “null”, when the object deleted.

Type Entity

Relationship “usersoftype”

Destination: “User”

Type: “To Many”

Delete Rule: “Cascade”

In this case if you delete this type (family), you automatically delete all users, which belongs to this type (brother, mother, father).

"Relationship Delete Rules

A relationship’s delete rule specifies what should happen if an attempt is made to delete the source object. Note the phrasing in the previous sentence—”if an attempt is made…”. If a relationship’s delete rule is set to Deny, it is possible that the source object will not be deleted. Consider again a department’s employees relationship, and the effect that the different delete rules have.

Deny

If there is at least one object at the relationship destination, then the source object cannot be deleted.

For example, if you want to remove a department, you must ensure that all the employees in that department are first transferred elsewhere (or fired!) otherwise the department cannot be deleted.

Nullify

Set the inverse relationship for objects at the destination to null.

For example, if you delete a department, set the department for all the current members to null. This only makes sense if the department relationship for an employee is optional, or if you ensure that you set a new department for each of the employees before the next save operation.

Cascade

Delete the objects at the destination of the relationship.

For example, if you delete a department, fire all the employees in that department at the same time.

No Action

Do nothing to the object at the destination of the relationship.

For example, if you delete a department, leave all the employees as they are, even if they still believe they belong to that department.”

Delete Rules Core Data source

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

4. Fetch Request, NSPredicate and NSSortDescriptor

If you would like to edit, or show your objects or your object’s attribute, you should do a fetch request. You can call your Entity’s objects in an Array, and then you can work with them. You can use NSPredicate to tell in which parameters would you like to fetch your objects, and of course you can tell for example, that you want to order your results ascending alphabetical. You can do this with NSSortDescriptor.

"A fetch request tells a managed object context the entity of the managed objects that you want to fetch; optionally, it specifies other aspects such as constraints on the values the objects’ properties must have and the order you want the objects returned in. A fetch request is an instance of NSFetchRequest. The entity it specifies is represented by an instance of NSEntityDescription; any constraints are represented by an NSPredicate object, and the ordering by an array of one or more instances of NSSortDescriptor. These are akin to the table name, WHERE clause, and ORDER BY clauses of a database SELECT statement respectively.

You execute a fetch request by sending a message to a managed object context. The context returns an array containing the objects (if any) that matched the request.”

Fetch request source

5. Now you can start the Core Data tutorial

I create a serie, you can learn everything in these parts!

You can find the first part here:

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

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

If you would like to be notified of my new solutions, please subscribe to my youtube channel and/ or follow me on twitter!

Trending Tags

Last Seen Tags

#xcode 6.1

Trending Tags

Last Seen Tags

#xcode 6.1