DOWNLOAD PDF CORE DATA PROGRAMMING GUIDE

Transcription

1 Chapter 1 : Core Data Programming Guide : Download Free Book Core Data is a framework that you use to manage the model layer objects in your application. It provides generalized and automated solutions to common tasks associated with object life cycle and object graph management, including persistence. What Is Core Data? Important This document is no longer being updated. For the latest information about Apple SDKs, visit the documentation website. Core Data is a framework that you use to manage the model layer objects in your application. It provides generalized and automated solutions to common tasks associated with object life cycle and object graph management, including persistence. Core Data typically decreases by 50 to 70 percent the amount of code you write to support the model layer. This is primarily due to the following built-in features that you do not have to implement, test, or optimize: Change tracking and built-in management of undo and redo beyond basic text editing. Maintenance of change propagation, including maintaining the consistency of relationships among objects. Lazy loading of objects, partially materialized futures faulting, and copy-on-write data sharing to reduce overhead. Automatic validation of property values. Managed objects extend the standard key-value coding validation methods to ensure that individual values lie within acceptable ranges, so that combinations of values make sense. Schema migration tools that simplify schema changes and allow you to perform efficient in-place schema migration. Grouping, filtering, and organizing data in memory and in the user interface. Automatic support for storing objects in external data repositories. Version tracking and optimistic locking to support automatic multiwriter conflict resolution. Effective integration with the macos and ios tool chains. Note This document uses an employees database-style example for expediency and clarity. It represents a rich but easily understood problem domain. However, the Core Data framework is not restricted to database-style applications, nor is there an expectation of client-server behavior. The framework is equally as useful as the basis of a vector graphics application such as Sketch or a presentation application such as Keynote. Page 1

2 Chapter 2 : Core Data Relationships and Delete Rules Much of Core Data's functionality depends on the schema you create to describe your application's entities, their properties, and the relationships between them. Core Data uses a schema called a managed object model â an instance of NSManagedObjectModel. In general, the richer the model, the. I am going to assume that you have a moderate level of knowledge and familiarity with creating ios apps. I will skip over areas such as setting up the user interface and similar basic functions. Instead I will focus specifically on the less obvious and trickier areas. Update History 29 August, Added a new notification which provides a summary of all changes and is better suited to triggering UI refreshing. Added new method that is called prior to migration to update creation dates for all objects. Added change notifications for local data changes. You are free to use the code in commercial and non-commercial apps. You can modify and redistribute the code as desired. No attribution is required but if you want to provide one that would be pretty awesome. I have preserved all license and readme files they have provided. Please respect their copyright and any license conditions. To add the library to your existing app drag and drop the ioscorelibrary. The Project Navigator should now look similar to below: Link to Library and Required Frameworks Now that we have the library included we need to tell the app to link to it. We also need to add some additional frameworks. The required frameworks are: The graphics frameworks are used to render the progress image. If you do not intend to use the Dropbox uploader you can delete the Dropbox framework and uploader from the library. To link to the frameworks select your project in the Project Navigator and then select your target. In the General tab there is a Linked Frameworks and Libraries section. These are packaged into a bundle which must be copied across with the resources for your application. There will be two files: At this point you should still have the target for your app selected if not select it now. This ensures that if you make any modifications to the ios Core Library that it will be rebuilt before attempting to rebuild your application. At this point your Build Phases tab should look similar to the screenshot below: If you have not previously used a library with categories then you may never have come across a quirk in how the linker behaves. If at this point we simply tried to use the library in the app we would see crashes with a message such as unrecognized selector sent to instance. This happens because the categories are not being compiled into your app. To work around this we use a special linker flag. There is a flag that force loads all libraries but I prefer to only apply the flag to the specific libraries that require it. With the target for your app selected navigate to the Build Settings tab. Find the Linking section. Layout of the Sample App At this point you should now be able to build your app. The data model for the app is a simple one comprised of three objects: Pet, Owner and Classification. The objects are setup as follows: Pet Has two attributes creationdate and name Has a single owner one to one relationship Has a single classification one to one relationship Owner Has two attributes creationdate and name Has multiple pets one to many relationship Classification Has two attributes creationdate and name Has multiple pets one to many relationship The relationships are all optional and the delete rule is set to nullify ie. As I recommended in an earlier post I have setup a category for each object to handle any customisation. There are two main methods that I always add as a starting point. The first method to add is automatic population of the creationdate attribute to all of the object categories. This is a simple matter of adding an awakefrominsert method and setting the creation date there. The creation date will be set automatically when a new object is created. Page 2

3 Chapter 3 : icloud and Core Data: Sample App Download "Core Data Programming Guide" in pdf format or read it online.. Description. The Core Data framework provides generalized and automated solutions to common tasks associated with object life-cycle and object graph management, including persistence. In general, the richer the model, the better Core Data is able to support your application. A managed object model allows Core Data to map from records in a persistent store to managed objects that you use in your application. The model is a collection of entity description objects instances of NSEntityDescription. An entity description describes an entity which you can think of as a table in a database in terms of its name, the name of the class used to represent the entity in your application, and what properties attributes and relationships it has. A source file for the Core Data model is created as part of the template. That source file will have the extension. Select that file in the navigator area to display the Core Data model editor. To create an entity A new untitled entity appears in the Entities list in the navigator area. Select the new untitled entity. In the Entity pane of the Data Model inspector, enter the name of the entity, and press Return. A new untitled attribute or relationship generically referred to as a property is added in the Attributes or Relationships section of the editor area. Select the new untitled property. The property settings are displayed in the Relationship pane or Attribute pane of the Data Model inspector. Give the property a name, and press Return. The attribute or relationship information appears in the editor area. Employee entity in the Xcode Data Model editor shows an entity called Employee, with attributes that describe the employee: Figure Employee entity in the Xcode Data Model editor At this point you have created an entity in the model, but you have not created any data. Data is created later, when you launch your application. These entities will be used in your application as the basis for the creation of managed objects NSManagedObject instances. Defining an Entity Now that you have named your entity, you define it further in the Entity pane of the Data Model inspector; see Entity pane in the Data Model inspector. The entity structure in the data model does not need to match the class hierarchy. Figure shows a class name with the recommended class name pattern of Objective-C, along with an MO suffix. An entity name and a class name are required. Abstract Entities Specify that an entity is abstract if you will not create any instances of that entity. You typically make an entity abstract if you have a number of entities that all represent specializations of inherit from a common entity that should not itself be instantiated. For example, in the Employee entity you could define Person as an abstract entity and specify that only concrete subentities Employee and Customer can be instantiated. By marking an entity as abstract in the Entity pane of the Data Model inspector, you are informing Core Data that it will never be instantiated directly. Entity Inheritance Entity inheritance works in a similar way to class inheritance; and is useful for the same reasons. If you have a number of entities that are similar, you can factor the common properties into a superentity, also known as a parent entity. Rather than specifying the same properties in several entities, you can define them in one entity, and the subentities inherit them. For example, you might define a Person entity with attributes firstname and lastname, and subentities Employee and Customer, which inherit those attributes. An example of this layout is shown in Figure Display the layout diagram by clicking the Editor Style buttons in the lower-right corner. In many cases, you also implement a custom class to correspond to the entity from which classes representing the subentities also inherit. Rather than implementing business logic common to all the entities several times over, you implement them in one place and they are inherited by the subclasses. Note Be careful with entity inheritance when working with SQLite persistent stores. All entities that inherit from another entity exist within the same table in SQLite. This factor in the design of the SQLite persistent store can create a performance issue. Among other features, each property has a name and a type. Core Data does track changes you make to transient properties, so they are recorded for undo operations. You use transient properties for a variety of purposes, including keeping calculated values and derived values. Note If you undo a change to a transient property that uses nonmodeled information, Core Data does not invoke your set accessor with the old value â it simply updates the snapshot information. You can specify that an attribute is optionalâ that is, it is not required to have a value. In general, however, avoid doing so, especially for Page 3

4 numeric values. Typically, you can get better results using a mandatory attribute with a default valueâ defined in the attributeâ of 0. Moreover, NULL in a database is not equivalent to an empty string or empty data blob. Relationships and Fetched Properties To define a relationship, select it in the Core Data model editor, and specify values in the Relationship pane of the Data Model inspector; Relationship in the Data Model inspector. Figure Relationship pane in the Data Model inspector Core Data supports to-one and to-many relationships, and fetched properties. Fetched properties represent weak, one-way relationships. The Type pop-up menu defines whether the relationship is a to-one type relationship or a to-many type relationship. Relationships are defined from one direction at a time. To create a many-to-many relationship, you would need to create two to-many relationships and then set them up as inverses of each other. The Destination pop-up menu defines what object or objects is returned when the relationship is accessed in code. If the relationship is defined as to-one, a single object or nil if the relationship can be optional is returned. If the relationship is defined as to-many, a set is returned or again, nil if the relationship can be optional. The Inverse pop-up menu defines the other half of a relationship. Because each relationship is defined from one direction, this pop-up menu joins two relationships together to create a fully bidirectional relationship. Page 4

5 Chapter 4 : Core Data Programming Guide: Creating a Managed Object Model Contents Introduction to Core Data Programming Guide 13 Who Should Read This Document 13 Organization of This Document 13 See Also 15 Before You Start 17 Prerequisites Let me illustrate this with an example. We have a category that contains several notes. If the category is deleted, the notes are not notified of this event. The notes on the other end of the relationship believe that they are still associated with the deleted category. I have never had a need to use this delete rule in a project. In most situations, you want to take some action when a record is deleted. And that is where the other delete rules come into play. Nullify Delete Rule If the delete rule of a relationship is set to Nullify, the destination of the relationship is nullified when the record is deleted. For example, if a category has several notes and the category is deleted, the relationships pointing from the notes to the category are nullified. This is the default delete rule and the delete rule you will find yourself using most often. Cascade Delete Rule The Cascade delete rule is useful if the data model includes one or more dependencies. Let me give you an example. If a note should always have a category, the deletion of a category should automatically delete the notes associated with that category. In other words, the deletion of the category cascades or trickles down to the notes linked to the category. The Deny delete rule is a better option in this scenario see below. If you are dealing with a Many-To-Many relationship, this is often not what you want. If a note can have several tags and a tag can be linked to several notes, deleting a tag should not result in the deletion of every note with that tag. The notes could be associated with other tags, for example. Deny Delete Rule Remember the previous example in which the deletion of a category resulted in the deletion of every note that belonged to that category. It may be better to apply the Deny delete rule. Deny is another powerful and useful pattern. It is the opposite of the Cascade delete rule. Instead of cascading the deletion of a record, it prevents the deletion of the record. For example, if a category is associated with several notes, the category can only be deleted if it is no longer tied to any notes. This configuration prevents the scenario in which notes are no longer associated with a category. Choose Wisely You cannot ignore delete rules when working Core Data. Take the time to understand the above concepts and leverage the power of Core Data. The default delete rule, Nullify, is often the correct choice. Make Core Data work for you. Page 5

6 Chapter 5 : icloud Programming Guide for Core Data - Apple Developer I'm currently reading through Apple's Core Data Programming Guide and came across Merging Changes with Transient Properties (last paragraph of Managed Objects and References). Metadata uploaded 36 Store initialization: Transaction logs downloaded 36 Content changes: Transaction log uploaded 37 Content changes: High save frequency 37 Content changes: Other peers download the changes to keep your app up to date. To help you persist managed objects to the cloud, icloud is integrated with Core Data. The icloud service and Core Data take care of the rest: The system manages the files in the ubiquity container that make up your persistent store, and Core Data helps you keep your app up to date. To let you know when the content in your container changes, Core Data posts notifications. At a Glance When you use Core Data, you have several storage models to choose from. Using Core Data with icloud, you have a subset of these options, as follows: Atomic stores work best for smaller storage requirements. Transactional stores work best for larger, more complex storage requirements. Use document storage in combination with either an atomic or a transactional store. When you decide on a storage model, consider the strengths of each store as well as the icloud-specific strengths discussed below. Binary and XML store files are themselves transferred to the icloud servers; so whenever a change is made to the data, the system uploads the entire store and pushes it to all connected devices. This means that changes on one peer can overwrite changes made on the others. Continue reading this document to learn more about how to use icloud with an SQLite store. Changes to managed documents are automatically persisted to icloud. By default, managed documents are backed by SQLite-type persistent stores, but you can choose to use atomic stores instead. While the steps you take to integrate the UIManagedDocument class into your app differ, the model-specific guidelines and best practices you follow are generally the same. In addition, this guide assumes a working knowledge of Core Data, a powerful object graph and data persistence framework. Follow the implementation strategy in this chapter to create a robust, high-performance icloud-enabled app. Using these guidelines and sample code, you will learn how to: This effectively links the two together. You perform two tasks to add icloud to a new Core Data app: Apps that use icloud cannot use wildcard identifiers. Set your project to code-sign using the App ID you just created. Enable icloud in Xcode. Click the switch next to icloud, as shown in Figure Xcode configures your App ID in the developer portal and adds entitlements to your app. These entitlements give your app permission to access its ubiquity container s. By default, Xcode creates one ubiquity container identifier using your App ID. Figure Enabling icloud capability Note: Adding an icloud-enabled Persistent Store to Core Data After you enable icloud, your app can begin persisting documents and data to your ubiquity container. Therefore, you must create an icloud-enabled persistent store to start using icloud. You pass the following key-value pair in the options dictionary to enable icloud. If you need a reference to the persistent store, use the URL generated by the coordinator rather than the one you created. Checkpoint At this point, your app can create an icloud-enabled Core Data persistent store. Create a Core Data stack and add a persistent store with the ubiquitous content name option. Run the app on a device. Core Data tells your app about these events using notifications. Otherwise, your app could receive notifications from other persistent store coordinators. Notifications may not be posted on the same thread as your managed object context. It is especially important to test an icloud-enabled ios app on an actual device. Core Data Configures Your Persistent Store The first icloud event happens after you add an icloud-enabled persistent store to your persistent store coordinator. Core Data returns your persistent store from the method invocation and immediately posts an NSPersistentStoreCoordinatorStoresDidChangeNotification notification to let your app know that the persistent store has been configured for use. In Figure, your app adds an icloud-enabled persistent store, which causes Core Data to post a notification and begin container setup. Because this notification is posted immediately after you invoke addpersistentstorewithtype: Checkpoint At this checkpoint you have configured Core Data to tell your app when an icloud-enabled persistent store is ready for use. After adding a new icloud-enabled persistent store in the previous section, you created a notification handler to respond to NSPersistentStoreCoordinatorStoresDidChangeNotification notifications. Add an NSLog statement inside of Page 6

7 your stores-did-change notification handler. Completely remove your app from your device and then click the run button in Xcode to reinstall your app and reopen it. If Core Data successfully created and configured an icloud-enabled persistent store, the framework invokes your notification handler and your NSLog statement will print to the console in Xcode. Ubiquity container initialization is a long-running operation that relies on network connectivity with the icloud service. Because of this, the Core Data framework provides you with a temporary local persistent store that you use while the work is performed in the background. On subsequent app launches, the ubiquity container is already initialized and Core Data is associated with the icloud-enabled persistent store. When Core Data finishes moving all of your data, the temporary local store and the contents of your managed object context s are invalid. To prepare you for this event, Core Data posts two notifications after it finishes moving your data: In your notification handler, you reset your managed object context and drop any references to existing managed objects. As soon as your handler finishes executing, these objects are no longer valid. You must also prevent any interaction with the temporary local store while Core Data transitions to the icloud-enabled store. Disabling your user interface is the simplest way to do this in a UI-driven app and is in most cases invisible to the user. This is because the time between the will-change notification and the did-change notification is extremely short. Checkpoint At this point, your notification handlers disable, enable, and refresh your user interface when one-time setup is finished. On your ios device, begin with airplane mode enabled. Completely remove your app from your device as well. Run your app and create a few records. Core Data invokes your notification handlers and your records disappear. Your notification handler behaves slightly differently: Rather than immediately resetting your managed object context, you check for changes in your managed object context and invoke save:. Otherwise, you follow the same process as described in the previous section, resetting your context and disabling your user interface. Core Data continues to post this notification until you no longer invoke save: This loop is illustrated above in Figure and implemented below. Begin with airplane mode enabled on your ios device, or all network interfaces disabled on your Mac. Disable airplane mode or reenable a network interface. Core Data invokes your notification handlers, and your records persist after your notification handler executes a new fetch request. Core Data represents this event as shown in Figure Therefore you can merge in changes from other peers in the same way that you merge changes from other managed object contexts. Install your app on two devices. Run your app on both devices, and create a few distinct records on each. A transition occurs for all of the following four events: Reacting to Account Transitions When the system informs Core Data of an account transition while your app is running, Core Data works with your app to prepare for the event. Figure shows the timeline of an account transition event. You can use this information to find out why a transition is happening. You must also prevent any interaction with the icloud-enabled store while Core Data finishes transitioning. In a UI-driven app, disabling your user interface is the simplest way to do this. When the current icloud account is removed, Core Data saves your store to an account-specific archive. If the user signs into the same account again in the future, Core Data unarchives the data and resumes uploading. Because ios periodically removes stores associated with accounts that are no longer active, there is no guarantee that records saved after you receive the NSPersistentStoreCoordinatorStoresWillChangeNotification notification will be persisted to icloud. Again, because ios deletes old stores associated with icloud accounts that are no longer active on the device, your changes may never be saved or sent to the cloud. As illustrated in Figure above, saving your managed object context does not cause a loop. Install your app on a device with icloud enabled. Run your app on both devices, and create a few distinct records. Seeding Initial Data If your app is packaged with a prebuilt database or if a previous version of your app did not persist to icloud, your persistent store coordinator can create an icloud-enabled persistent store and migrate the records in a single step. Pass in your existing persistent store as the first argument in the method. Migrating a persistent store is a synchronous task, unlike adding an icloud-enabled persistent store. You dispatch migration onto a background queue and then update your user interface after migration is complete. Finally, mark seeding as complete using icloud key-value storage so that other peers do not seed the same data. Page 7

8 Chapter 6 : Core Data Programming Guide: What Is Core Data? Search among more than user manuals and view them online blog.quintoapp.com Metadata uploaded 36 Store initialization: Transaction logs downloaded 36 Content changes: Transaction log uploaded 37 Content changes: High save frequency 37 Content changes: Other peers download the changes to keep your app up to date. To help you persist managed objects to the cloud, icloud is integrated with Core Data. The icloud service and Core Data take care of the rest: The system manages the files in the ubiquity container that make up your persistent store, and Core Data helps you keep your app up to date. To let you know when the content in your container changes, Core Data posts notifications. At a Glance When you use Core Data, you have several storage models to choose from. Using Core Data with icloud, you have a subset of these options, as follows: Atomic stores work best for smaller storage requirements. Transactional stores work best for larger, more complex storage requirements. Use document storage in combination with either an atomic or a transactional store. When you decide on a storage model, consider the strengths of each store as well as the icloud-specific strengths discussed below. Binary and XML store files are themselves transferred to the icloud servers; so whenever a change is made to the data, the system uploads the entire store and pushes it to all connected devices. This means that changes on one peer can overwrite changes made on the others. Continue reading this document to learn more about how to use icloud with an SQLite store. Changes to managed documents are automatically persisted to icloud. By default, managed documents are backed by SQLite-type persistent stores, but you can choose to use atomic stores instead. While the steps you take to integrate the UIManagedDocument class into your app differ, the model-specific guidelines and best practices you follow are generally the same. In addition, this guide assumes a working knowledge of Core Data, a powerful object graph and data persistence framework. Follow the implementation strategy in this chapter to create a robust, high-performance icloud-enabled app. Using these guidelines and sample code, you will learn how to: This effectively links the two together. You perform two tasks to add icloud to a new Core Data app: Apps that use icloud cannot use wildcard identifiers. Set your project to code-sign using the App ID you just created. Enable icloud in Xcode. Click the switch next to icloud, as shown in Figure Xcode configures your App ID in the developer portal and adds entitlements to your app. These entitlements give your app permission to access its ubiquity container s. By default, Xcode creates one ubiquity container identifier using your App ID. Figure Enabling icloud capability Note: Adding an icloud-enabled Persistent Store to Core Data After you enable icloud, your app can begin persisting documents and data to your ubiquity container. Therefore, you must create an icloud-enabled persistent store to start using icloud. You pass the following key-value pair in the options dictionary to enable icloud. If you need a reference to the persistent store, use the URL generated by the coordinator rather than the one you created. Checkpoint At this point, your app can create an icloud-enabled Core Data persistent store. Create a Core Data stack and add a persistent store with the ubiquitous content name option. Run the app on a device. Core Data tells your app about these events using notifications. Otherwise, your app could receive notifications from other persistent store coordinators. Notifications may not be posted on the same thread as your managed object context. It is especially important to test an icloud-enabled ios app on an actual device. Core Data Configures Your Persistent Store The first icloud event happens after you add an icloud-enabled persistent store to your persistent store coordinator. Core Data returns your persistent store from the method invocation and immediately posts an NSPersistentStoreCoordinatorStoresDidChangeNotification notification to let your app know that the persistent store has been configured for use. In Figure, your app adds an icloud-enabled persistent store, which causes Core Data to post a notification and begin container setup. Because this notification is posted immediately after you invoke addpersistentstorewithtype: Checkpoint At this checkpoint you have configured Core Data to tell your app when an icloud-enabled persistent store is ready for use. After adding a new icloud-enabled persistent store in the previous section, you created a notification handler to respond to NSPersistentStoreCoordinatorStoresDidChangeNotification notifications. Add an NSLog statement inside of your stores-did-change notification handler. Completely remove your app from your device and then click the Page 8

9 run button in Xcode to reinstall your app and reopen it. If Core Data successfully created and configured an icloud-enabled persistent store, the framework invokes your notification handler and your NSLog statement will print to the console in Xcode. Ubiquity container initialization is a long-running operation that relies on network connectivity with the icloud service. Because of this, the Core Data framework provides you with a temporary local persistent store that you use while the work is performed in the background. On subsequent app launches, the ubiquity container is already initialized and Core Data is associated with the icloud-enabled persistent store. When Core Data finishes moving all of your data, the temporary local store and the contents of your managed object context s are invalid. To prepare you for this event, Core Data posts two notifications after it finishes moving your data: In your notification handler, you reset your managed object context and drop any references to existing managed objects. As soon as your handler finishes executing, these objects are no longer valid. You must also prevent any interaction with the temporary local store while Core Data transitions to the icloud-enabled store. Disabling your user interface is the simplest way to do this in a UI-driven app and is in most cases invisible to the user. This is because the time between the will-change notification and the did-change notification is extremely short. Checkpoint At this point, your notification handlers disable, enable, and refresh your user interface when one-time setup is finished. On your ios device, begin with airplane mode enabled. Completely remove your app from your device as well. Run your app and create a few records. Core Data invokes your notification handlers and your records disappear. Your notification handler behaves slightly differently: Rather than immediately resetting your managed object context, you check for changes in your managed object context and invoke save:. Otherwise, you follow the same process as described in the previous section, resetting your context and disabling your user interface. Core Data continues to post this notification until you no longer invoke save: This loop is illustrated above in Figure and implemented below. Begin with airplane mode enabled on your ios device, or all network interfaces disabled on your Mac. Disable airplane mode or reenable a network interface. Core Data invokes your notification handlers, and your records persist after your notification handler executes a new fetch request. Core Data represents this event as shown in Figure Therefore you can merge in changes from other peers in the same way that you merge changes from other managed object contexts. Install your app on two devices. Run your app on both devices, and create a few distinct records on each. A transition occurs for all of the following four events: Reacting to Account Transitions When the system informs Core Data of an account transition while your app is running, Core Data works with your app to prepare for the event. Figure shows the timeline of an account transition event. You can use this information to find out why a transition is happening. You must also prevent any interaction with the icloud-enabled store while Core Data finishes transitioning. In a UI-driven app, disabling your user interface is the simplest way to do this. When the current icloud account is removed, Core Data saves your store to an account-specific archive. If the user signs into the same account again in the future, Core Data unarchives the data and resumes uploading. Because ios periodically removes stores associated with accounts that are no longer active, there is no guarantee that records saved after you receive the NSPersistentStoreCoordinatorStoresWillChangeNotification notification will be persisted to icloud. Again, because ios deletes old stores associated with icloud accounts that are no longer active on the device, your changes may never be saved or sent to the cloud. As illustrated in Figure above, saving your managed object context does not cause a loop. Install your app on a device with icloud enabled. Run your app on both devices, and create a few distinct records. Seeding Initial Data If your app is packaged with a prebuilt database or if a previous version of your app did not persist to icloud, your persistent store coordinator can create an icloud-enabled persistent store and migrate the records in a single step. Pass in your existing persistent store as the first argument in the method. Migrating a persistent store is a synchronous task, unlike adding an icloud-enabled persistent store. You dispatch migration onto a background queue and then update your user interface after migration is complete. Finally, mark seeding as complete using icloud key-value storage so that other peers do not seed the same data. Page 9

10 Chapter 7 : ios - Core Data Programming Guide: Merging Changes with Transient Properties - Stack Overf Beyond simple persistence and querying, core data offers change tracking and undo support, futures, value validation, UI synchronization, and automatic multi-writer conflict resolution. Use it because it's mature, proven, robust, efficient, and integrates well with the development toolchain. A. This post compatible with Xcode 6. Make sure to download it here using your ios Developer account. This data is persistent and lasts even through a complete shut down of your phone. The first thing to know about Core Data before diving in is that it is not a relational database, and although it uses SQLite as a backing engine, is not an ORM to a relational database either. The SQLite backend is more of an implementation detail, and in fact binary files or plists can be used instead. The official Apple documentation describes Core Data like this: Create a new Xcode 6 project using a single-view template, Swift as the language, and with Core Data enabled. Looking for something more in-depth than a tutorial? Most of these are setting up the Core Data stack. The defaults are fine for now. The primary object that needs to be used to work with Core Data is the managedobjectcontext defined here. If you used the Core Data template as shown above, this code will already be present. Knowing this we can access the managedobjectcontext from our ViewController. For example in viewdidload of ViewController. How about if we just store it as an instance variable on the ViewController? In viewdidload we cause this variable to be computed by printing it to the console. If your application is set up right you should see something like this: Opening up this file you can see the Core Data model editor. Our log app will show a list of LogItems, which have a bit of text in them. From here we can rename the default name, Entity, to LogItem. Name this attribute title, and give it a type of String. From this point on, any changes you make to your Core Data model, such as adding a new Entity or Attribute will lead to an inconsistency in the model of the app in the iphone Simulator. If this happens to you there is a very easy fix: This will erase all out of date versions of the model, and allow you to do a fresh run. Now that we have our first Entity created, we want to also be able to directly access this entity as a class in our code. Xcode provides an automated tool to do this. Then, check the LogItem entity, and press next again. A file save window should appear with an option to specify the language as Swift, select this. Finally hit Create, and you should now see a LogItem. String NSManaged var itemtext: The entity we created is represented by the similarly named class LogItem, and the attributes are turned in to variables using the NSManaged identifier, which gives the variables special treatment allowing them to operate with Core Data. For most intents and purposes though, you can just think of these as instance variables. Because of the way Swift modules work, we need to make one modification to the core data model. But this is not the best approach because it leaves too much opportunity to mis-type an attribute name, or get the wrong object type unexpectedly and have hard crashes trying to access these attributes. What this means, simply put, is that we can set the title and itemtext like this: This is a really nasty way to work with the Core Data API as it relies heavily on determining object classes, entities, state, and more at runtime based on string comparisons, yuck! Next, we create a fetchresults variable by using the executefetchrequest method of managedobjectcontext. The only thing we have specified in our fetchrequest is the entity, so this particular fetch just returns every record. Run the app and you should see the item presented to the screen. This is the first step in to building apps with persistent storage. Page 10

11 Chapter 8 : Core Data Programming Guide blog.quintoapp.com Apple Footer. This site contains user submitted content, comments and opinions and is for informational purposes only. Apple may provide or recommend responses as a possible solution based on the information provided; every potential issue may involve several factors not detailed in the conversations captured in an electronic forum and Apple can therefore provide no guarantee as to the. The main thread is tied into the event cycle for the application so that processpendingchanges is invoked automatically after every user event on contexts owned by the main thread. This is not the case for background threadsâ when the method is invoked depends on both the platform and the release version, so you should not rely on particular timing. If the secondary context is not on the main thread, you should call processpendingchanges yourself at appropriate junctures. If necessary, the Core Data will create additional private threads to optimize fetching performance. You will not improve absolute fetching speed by creating background threads for the purpose. This means that if a fetch is complicated or returns a large amount of data, you can return control to the user and display results as they arrive. Following the thread confinement pattern, you use two managed object contexts associated with a single persistent store coordinator. You fetch in one managed object context on a background thread, and pass the object IDs of the fetched objects to another thread. This technique is only useful if you are using an SQLite store, since data from binary and XML stores is read into memory immediately on open. Saving in a Background Thread is Error-prone Asynchronous queues and threads do not prevent an application from quitting. Specifically, all NSThread the documentation for pthread for complete detailsâ and a process runs only until all not-detached threads have exited. If you perform a save operation in a background thread, therefore, it may be killed before it is able to complete. If you need to save on a background thread, you must write additional code such that the main thread prevents the application from quitting until all the save operation is complete. You also need to consider that: Any time you manipulate or access managed objects, you use the associated managed object context. Managed objects themselves are not thread safe. If you want to work with a managed object across different threads, you must lock its context see NSLocking. If you share a managed object context or a persistent store coordinator between threads, you must ensure that any method invocations are made from a thread-safe scope. For locking, you should use the NSLocking methods on managed object context and persistent store coordinator instead of implementing your own mutexes. Typically you lock the context or coordinator using trylock lock. If you do this, the framework will ensure that what it does behind the scenes is also thread-safe. For example, if you create one context per thread, but all pointing to the same persistent store coordinator, Core Data takes care of accessing the coordinator in a thread-safe way the. Chapter 9 : Core Data by Tutorials blog.quintoapp.com Store AppleInc. Â,AppleInc. Allrightsreserved. Nopartofthispublicationmaybereproduced, storedinaretrievalsystem,ortransmitted,in anyformorbyanymeans,mechanical. Page 11