как добавить core data в готовое приложение

Стартуем с Core Data! Сложное простыми словами

Тем с Core Data уже написано большое количество, но большинство этих статей на английском языке, а так же с использованием большого количества «умных» слов которые могут запутать новичков.

В данной статье я постараюсь рассказать о фреймворке от Apple понятным языком, чтобы даже «самые маленькие» программисты смогли вынести для себя информацию, и получить тот минимальный обьем знаний который поможет им в своих проектах.

Небольшой оффтоп

Core Data очень мощный инструмент, который позволяет вам сохранять данные в вашем приложении и использовать их в дальнейшем. В этой статье я НЕ буду рассказывать о работе с multiple context с последующей синхронизацией, как решать проблемы миграции и различные advance фишки.

Целевая аудитория этой статьи люди которые вообще не имели никакого опыта работы с Core Data.

Ну что ж… Начнем!

А теперь по-подробнее:

NOTE: Core Data проводит операцию конвертации и просто сохраняет число в секундах с 00:00:00 UTC 1 Января 1970 до вашей даты.

NOTE: Всегда ставьте чекмарк на поле Allow External Storage. Core Data проверяет обьем данных, и если он превышает 100 килобайт, то данные будут сохранены отдельно от Core Data а данное поле будет хранить ссылку на объект. Это улучшит производительность приложения и избавит от ненужных проблем с памятью.

У нас есть 3 Entities, Andrey, Home, Car.

Editor > Create NSManagedObject Subclass

Если вы хотите задать дефолтные значения для ваших атрибутов используйте метод:

Работа с NSManagedObjectContext и PersistentStoreCoordinator

Иерархия Core Data Stack:

Если простыми словами, то все ваши Entity изображены на данной диаграмме сверху как Managed Object. Все наши Managed Objects хранятся в NSManagedObjectContext. Context Ссылается на NSPersistentStoreCoordinator который хранит после обращения к SQL ваши сохраненные данные, в виде Row Cache, однако сейчас не об этом.

Чтобы создать экземпляр вашего ManagedObject(Entity), вы должны обратиться к своему NSPersistentContainer который является оберткой для вашего NSPersistentStoreCoordinator.

Далее мы должны обратиться к NSManagedObjectContext через наш PersistentContainer:

Теперь мы можем создать экземпляр нашего ManageObject из нашего контекста и присвоить ему значение:

Сохранение объекта

Для сохранения используем простую функцию:

В методе выше мы проверяем наш контекст на изменения и если они присутствуют мы делаем сохранение. В случае ошибки выполняется метод:

Метод делает возврат нашего контекста в первоначальное состояние и отменяет все изменения которые проводились над ним

Позволяет нам легко удалить объект из Core Data.

NOTE: Чтобы изменения вступили в силу, требуется выполнить сохранение контекста, иначе все изменения не сохранятся.

Получение всех объектов

Для того чтобы получить массив наших объектов из Core Data мы должный выполнить NSFetchRequest. Я не буду глубоко углубляться во всю мощь FetchRequest так как эта статься рассчитана на новичков.

Под капотом NSFetchRequest делает огромную работу:

NOTE: Пока выполняется NSFetchRequest Managed Object Context и Persistent Store Coordinator выполняется в синхронной очереди и все процессы блокируются пока другой процесс отрабатывается

Заключение

В данной статье я описал минимальную информацию необходимую для работы с Core Data по-моему мнению.

Теперь вы можете создавать свои собственные модели данных, сохранять, удалять и получать их.

В заключение хочу сказать что Core Data мощный инструмент, который доступен «из коробки» что делает отличным инструментов в арсенале любого IOS-девелопера

Источник

Add Core Data to Existing iOS Project

If you have ever struggled to add Core Data to an existing iOS project, I feel your pain. Years ago when I tried to do it I failed and decided to recreated the project from scratch.

But recently I decided that I should try and add Core Data into an existing project. It turns out that it is actually quite a simple task.

There are a few things that are required when adding Core Data to an existing iOS project. The main part being that if you did not check the “Use Core Data” checkbox when you created your project, then you won’t even have the data model file, which is a bit of an issue. The other issue is that you don’t have the correct code in your AppDelegate file.

So in this tutorial I am going to show you how you can easily add these two requirements to your project so that you can use Core Data.

If you don’t want to read the article, you can always watch the video version:

Step 1: Adding the data model file

The first that you need to do is to add the data model file. To do this you will add a file to your project in the normal way.

Now you need to select the correct file. To find the data model file you will need to scroll down a bit until you see the heading “Core Data”.

It should look something like this:

If you are enjoying this tutorial, sign up for my email list to be notified about new tutorials. Sign Up

Step 2

Once you have added your data model file you need to update your AppDelegate file.

Like I mentioned previously, when you check that checkbox when starting a new iOS project, it will add all these things, and this is the code that it adds to your AppDelegate file.

The first thing you need to do is to add the following code at the top of your file by all the other imports you have.

Once you have done that you will be able to add the next part of the code.

When you add that code to your project it will not run. I have added a line of text that will not compile. You need to replace to be a string that is the same name as your data model file.

Something like the below:

let container = NSPersistentContainer(name: «TestModel»)

Conclusion

That should be it, you should now be able to use Core Data in your project. If you want to see me test the code you can watch the video that I have included at the top of the post.

If you found this post or my video tutorial useful, please share and subscribe to my YouTube channel, it is much appreciated 🙂

Источник

Core Data + Swift для самых маленьких: необходимый минимум (часть 2)

Это вторая часть трилогии о Core Data, первая доступна здесь: Core Data + Swift для самых маленьких: необходимый минимум (часть 1).

В первой части мы познакомились с общими сведениями о Core Data, основными компонентами (NSManagedObjectModel, NSPersistentStoreCoordinator, NSManagedObjectContext), Редактором модели данных и создали нашу модель данных.

В этой части мы будем работать с объектами, познакомимся с NSEntityDescription и NSManagedObject, автогенерацией классов, а также напишем вспомогательный класс, существенно повышающий удобство работы с Core Data.

NSEntityDescription и NSManagedObject

Начнем с NSEntityDescription — как можно догадаться из названия, это объект, который содержит описание нашей сущности. Все то, что мы нафантазировали с сущностью в Редакторе модели данных (атрибуты, взаимосвязи, правила удаления и прочее), содержится в этом объекте. Единственное, что мы будем делать с ним — получать его и передавать куда-то в качестве параметра, больше ничего.

NSManagedObject — это сам управляемый объект, экземпляр сущности. Продолжая аналогию с СУБД (начатую в прошлой статье), можно сказать, что NSManagedObject — запись (строка) в таблице базы данных.

Чтобы понять, как с этим работать, давайте создадим нового Заказчика. Так как у нас еще нет готовой интерфейсной части (мы займемся этим в следующей статье), то давайте немного попрограммируем прямо в модуле делегата приложения ( AppDelegate.swift ). Не беспокойтесь, это только демонстрация, которая важна для понимания, чуть позже мы все перенесем отсюда в другое место. Я воспользуюсь для демонстрации работы следующей функцией:

Создание управляемого объекта (в данном случае Заказчика) выполняется следующим образом:

Сначала мы получаем описание сущности (entityDescription), передав в соответствующий конструктор строку с именем нужной нам сущности и ссылку на контекст. Как это работает: контекст управляемого объекта, как мы помним из первой части, связан с координатором постоянного хранилища, а координатор, в свою очередь, связан с объектной моделью данных, где и будет произведен поиск сущности по указанному имени. Обратите внимание, что данная функция возвращает опциональное значение.

Затем, на основании полученного описания сущности, мы создаем сам управляемый объект (managedObject). Вторым параметром мы передаем контекст, в котором этот объект должен быть создан (в общем случае, как вы помните, может быть несколько контекстов).

Хорошо, мы создали объект, как теперь установить значения его атрибутов? Для это используется кодирование по типу Key-Value, суть которого в том, что есть два универсальных метода, один который устанавливает указанное значение по указанному имени, а второй извлекает значение по указанному имени. Звучит гораздо сложнее, чем выглядит.

Как видите, все довольно просто. Идем дальше. Теперь надо сохранить этот объект в нашей базе данных. Разве то, что мы создали объект — недостаточно? Нет, любой объект «живет» в конкретном определенном контексте и только там. Вы можете его там создавать, модифицировать и даже удалять, но это все будет происходить внутри определенного контекста. До тех пор, пока вы явно не сохраните все изменения контекста, вы не измените реальных данных. Можно провести аналогию с файлом на диске, который вы открываете для редактирования — пока вы не нажали кнопку «Сохранить» никакие изменения не записаны. На самом деле это очень удобно и здорово оптимизирует весь процесс работы с данными.

Сохранение изменений контекста выполняется элементарно:

У нас даже есть в модуле делегата готовая функция для более «умного» сохранения (мы говорили о ней вскользь в прошлой статье), запись происходит только в том случае, если данные действительно изменены:

Таким образом, весь код создания и записи объекта будет выглядеть следующим образом:

Мы создали объект и записали его в нашу базу данных. Как нам теперь его получить обратно? Это не намного сложнее. Давайте взглянем на код.

Здесь мы создаем объект-запрос NSFetchRequest, передав в конструктор в качестве параметра название сущности данные которой мы хотим получить. Затем вызываем метод контекста, передав этот запрос в качестве параметра. Это максимально простой вариант извлечение записей, вообще NSFetchRequest очень гибок и предоставляет обширные возможности извлечение данных по определенным условиям. Пример фильтрации и сортировки данных с его помощью мы рассмотрим в следующей части статьи.

Важное замечание: функция managedObjectContext.executeFetchRequest всегда возвращает массив объектов, даже если объект всего один — возвращен будет массив, если объектов нет вообще — пустой массив.

С учетом вышесказанного, у нас будет следующий текст функции:

Как только вы получили объект, в вышеприведенном листинге это переменная result внутри цикла, то вы можете его произвольным образом редактировать (здесь нет никаких отличий от установки атрибутов для нового объекта), либо удалить. Удаление осуществляется вызовом соответствующего метода переменной контекста, которому в качестве параметра и передается удаляемый объект:

После удаления также необходимо принудительно вызвать сохранение контекста, не забывайте об этом.

Если вы хотите «пощупать» Core Data поближе, на уровне таблиц, то это проще чем может показаться. Если вы используете Симулятор, то файл базы данных лежит где-то здесь:

Не торопитесь искать этот файл вручную, гадая какой-же ID у вашего приложения. Есть замечательная утилита, делающая это все за вас — SimSim (Пользуясь случаем, хочу сказать спасибо авторам).

После запуска она висит в строке меню и выглядит вот так (значок летучей мышки):

Собственно, назначение очевидно: утилита показывает список хранилищ установленных на симуляторе приложений и позволяет сразу к ним перейти:

Для просмотра самого файла SQLite можно воспользоваться любым бесплатным просмоторщиком, например Datum Free

Автогенерация классов Core Data

Метод Key-Value, хорош тем, что он прост, универсален и работает «из коробки». Но есть два момента, которые портят впечатление: во-первых, кода больше, чем хотелось бы, а во-вторых, передавая имя реквизита каждый раз в виде строки, легко ошибиться (автодополнения здесь нет). И как нам быть, если захочется немного больше функциональности от управляемых объектов, например, вычисляемые поля или свои конструкторы? У Core Data есть решение! Мы легко можем создать свой класс (даже больше — Core Data сделает это за нас), унаследовав его от NSManagedObject и дополнив всем необходимым. В результате, мы сможем работать с управляемым объектов как с обычным объектом ООП, создавая его путем вызова своего конструктора и обращаясь к его полям «через точку» используя автодополнение (то есть вся мощь ООП в ваших руках).

Откройте Редактор модели данных и выделите любую сущность. Выберете в меню (оно контекстно-зависимое, поэтому надо выделить какую-нибудь сущность) Editor \ Create NSManagedObject Subclass…

Откроется окно выбора модели данных; да, в общем случае, может быть несколько независимых моделей данных, но у нас она одна, поэтому выбор очевиден.

В следующем окне нам предлагают выбрать сущности, для которых необходимо сгенерировать классы, давайте выберем сразу все.

Следующее стандартное окно вам должно быть знакомо, единственное что здесь может насторожить, это опция «Use scalar properties for primitive data types». В чем смысл этой опции: если эту опцию не выбирать, то вместо примитивных типов данных (Float, Double, Int и прочее) будет использоваться своеобразная «обертка», содержащая значение внутри себя. Это скорее актуально для Objective-C, так как там нет такого понятия как Optional. Но мы используем Swift, так что я не вижу причин не выбирать эту опцию (возможно, более опытные коллеги в комментариях меня поправят).

В итоге, Core Data создаст для нас несколько файлов, давайте посмотрим, что это за файлы.

Хорошо, мы создали классы для наших сущностей, теперь мы можем обращаться к полям класса «через точку», давайте придадим нашему примеру более привычный вид.

Так гораздо лучше. Но создание объекта выглядит несколько тяжеловесно. Можно было бы спрятать все это в конструктор, но для этого нам нужна ссылка на управляемый контекст в котором должен быть создан объект. Кстати, мы до сих пор пишем код в модуле делегата, так как именно здесь у нас определен Core Data Stack. Может можно придумать что-нибудь получше?

Core Data Manager

Наиболее распространенной практикой при работе с Core Data является использование паттерна Singleton на базе Core Data Stack. Напомню, если кто не знает или забыл, что Singleton гарантирует наличие только одного экземпляра класса с глобальной точкой доступа. То есть, у класса всегда существует один и только один объект, независимо от того, кто, когда и откуда к нему обращается. Этот подход мы сейчас и реализуем, у нас будет Singleton для глобального доступа и управления Core Data Stack.

Создайте новый пустой файл с именем CoreDataManager.swift

Для начала давайте добавим директиву импорта Core Data и создадим сам Singleton.

Теперь давайте переместим из модуля делегата приложения все функции и определения, связанные с Core Data.

Теперь у нас есть Singleton и мы можем обращаться к Core Data Stack из любой точки нашего приложения. Например, обращение к управляемому контексту будет выглядеть так:

Давайте теперь перенесем все необходимое для создания управляемого объекта в его конструктор.

Снова вернемся в модуль делегата приложения и внесем несколько изменений. Во-первых, создание управляемого объекта у нас упрощается до одной строки (вызов нового конструктора нашего класса), а во-вторых, такую ссылку на управляемый контекст

надо заменить следующей

Теперь код будет выглядеть совсем знакомым, а работа с управляемыми объектами будет мало отличаться от обычных объектов ООП.

Теперь вернемся в модуль Customer.swift и изменим код следующий образом.

Вот теперь точно все, дублирование кода сведено к минимуму. Давайте создадим аналогичные конструкторы для остальных сущностей. Я приведу только один для примера, это просто и не должно вызвать никаких затруднений (абсолютно все то же самое, за исключением имени сущности).

Вместо заключения

Обратите внимание, что CoreDataManager, который мы создали, довольно универсален, в том смысле, что его можно использовать в любом приложении, основанном на Core Data. Единственное, что его связывает именно с нашим проектом, — это имя файла модели данных. Больше ничего. То есть, написав этот модуль один раз, вы можете им пользоваться постоянно в разных проектах.

Источник

Core Data + Swift для самых маленьких: необходимый минимум (часть 1)

Про Core Data и Swift написано не так много, как хотелось бы, особенно это касается русскоязычного сегмента Интернета. При этом большинство статей и примеров используют довольно примитивные модели данных, чтобы показать только саму суть Core Data, не вдаваясь в подробности. Данной статьей я хотел бы восполнить этот пробел, показав немного больше о Core Data на практическом примере. Изначально, я планировал уместить весь материал в одну статью, но в процессе написания стало ясно, что для одной публикации объем явно великоват, а так как из песни слов не выкинешь, то я все-таки разобью данный материал на три части.

Вместо Введения

Core Data — это мощный и гибкий фреймворк для хранения и управления графом вашей модели, который заслуженно занимает свое место в арсенале любого iOS-разработчика. Наверняка вы, как минимум, слышали об этом фреймворке, и не один раз, и если по каким-то причинам вы его еще не используете, — то самое время начать это делать.

Так как голая теория, как правило, довольно скучна и плохо усваивается, рассматривать работу c Core Data мы будем на практическом примере, создавая приложение. Такие распространенные примеры работы с Core Data, как «Список дел» и им подобные, на мой взгляд, не слишком подходят, так как используют всего одну сущность и не используют взаимосвязи, что является существенным упрощением работы с данным фреймворком. В данной статье мы разработаем приложение, где будет использоваться несколько сущностей и взаимосвязей между ними.

Предполагается, что читатель знаком с основами разработки под iOS: знает Storyboard и понимает MVC, умеет использовать базовые элементы управления. Я сам переключился на iOS недавно, поэтому, возможно, в статье есть ошибки, неточности или игнорирование best practices, просьба за это сильно не пинать, лучше аргументированно ткнуть носом, чем поможете мне и другим начинающим iOS-разработчикам. Я буду использовать Xcode 7.3.1 и iOS 9.3.2, но все должно работать и в других версиях.

Общие сведения о Core Data

Как было сказано выше, Core Data — это фреймворк для хранения и управления объектным графом вашей модели данных. Конечно, управлять и, тем более, хранить данные можно и без Core Data, но с этим фреймворком это намного приятнее и удобнее.

На мой взгляд, важно понять основные компоненты и принцип работы Core Data сразу целиком. То есть кривая обучения предполагает порог входа, немного выше среднего, если так можно выразиться. Ключевыми компонентами Core Data, которые используются всегда, являются следующие:

Давайте, продолжим рассмотрение Core Data на примере.
Создайте новый проект на основе шаблона Single View Application и на странице выбора опций нового проекта поставьте флажок «Use Core Data».

При установке данного флажка Xcode добавит в проект пустую модель данных и некоторое количество программного кода для работы с Core Data. Разумеется, можно начать использовать Core Data уже в существующем проекте: в этом случае надо самостоятельно создать модель данных и написать соответствующий программный код.

По умолчанию, Xcode добавляет код для работы с Core Data в класс делегата приложения ( AppDelegate.swift ). Давайте рассмотрим его более детально, он начинается с комментария:

Следующее определение — managedObjectModel — более интересно, так как имеет самое непосредственное отношение к Core Data:

Идем дальше, — persistentStoreCoordinator — наиболее объемное определение, но, несмотря на несколько устрашающий вид, не стоит его пугаться — большую часть кода занимает обработка исключений:

Последнее определение — managedObjectContext — уверен, проблем с ним не будет:

Также у нас здесь есть одна вспомогательный функция для удобства сохранения контекста. Смысл ее очевиден — запись данных происходит только в том случаем, если они действительно были изменены.

Здесь важно отметить: вся работа с данными (создание, модификация, удаление) всегда происходит в рамках какого-либо контекста. Фактическая запись в хранилище будет выполнена только при явном вызове функции сохранения контекста.

Создание модели данных

Для создания Модели данных используется встроенный редактор. Так как мы поставили флажок «Use Core Data» при создании нового проекта, то у нас уже есть пустая модель данных, автоматически создания Xcode. Давайте ее откроем и создадим модель данных для нашего приложения.

Мы будем создавать приложение для учета заказов от контрагентов на выполнение определенных услуг. Это приложение не будет очень сложным, но в нем будет несколько различных сущностей, тесно связанных между собой. Это позволит показать различные аспекты и приемы работы с Core Data. Итак, у нас будет два справочника: «Заказчики» и «Услуги», и один документ «Заказ», в котором может быть несколько услуг.

Термины «Справочник» и «Документ» я взял из терминологии «1С: Предприятие», потому что именно эту систему мне очень сильно напоминает Core Data. Схожая логика построения сущностей (справочников/документов), аналогичные параметры атрибутов, инкапсулирование операций чтения/записи данных, кэширование и много другое. Я бы сказал, что «1С: Предприятие» — это следующий уровень абстракции работы с данными по отношению к Core Data.

Ладно, давайте напишем свое «1С: Предприятие» с блэкджеком и с нормальным дизайном!

Создание справочников

Можно провести следующую аналогию с СУБД:

Следующая важная часть — Инспектор модели данных, вы видите его справа от редактора модели данных. С его помощью можно задавать различные атрибуты и параметры для сущностей, атрибутов сущностей (уж простите за тавтологию), взаимосвязей и других объектов. Например, сущность можно отметить как абстрактную, либо задать для нее родительскую сущность (принципы такие же, как и в целом в ООП).

Для атрибута сущности список доступных параметров меняется в зависимости от типа атрибута. Например, для числовых значений можно задать нижнюю и/или верхнюю границу, для даты можно задать допустимый диапазон. Также для большинства типов значений можно задать значение по умолчанию.

Важным свойством атрибута является Optional (опциональный). Смысл у него точно такой же, как в программном коде Swift: если атрибут помечен как Optional, то его значение может отсутствовать, и наоборот, — если такой пометки нет — запись сущности будет невозможна. По умолчанию, все атрибуты отмечаются как опциональные. В нашем случае, атрибут name не должен быть опциональным (надо снять флажок Optional), так как Заказчик без имени лишен какого-либо практического смысла.

Создание документа «Заказ»

Переходим к документу «Заказ» — здесь все немного сложнее. Так как в одном документе у нас может быть несколько различных услуг, а для каждой услуги будет своя сумма, то документ у нас будет представлен двумя сущностями:

Начнем с «шапки» документа — создадим новую сущность «Order» и добавим три атрибута (здесь все уже знакомо по созданию предыдущих сущностей):

Обратите внимание, что взаимосвязи по умолчанию тоже являются Optional. Кроме того, в Инспекторе атрибутов присутствуют следующие очень важные свойства, которые мы сейчас подробно рассмотрим:

Type (тип связи)

Если вы работали с какими-либо базами данных, то это понятие вам наверняка знакомо. Здесь нам предлагается на выбор два варианта: To One и To Many. To One — означает, что наш Заказ связан к одним конкретным Заказчиком, To Many — с несколькими заказчиками. В нашем случае надо оставить значение по умолчанию — To One.

Delete Rule (правило удаления)

Очень важное свойство, здесь надо выбрать одно из возможных поведений сущности в том момент, когда данная связь по каким-то причинам удаляется. Возможны следующие варианты:

Inverse (обратная связь)

Мы добавили связь «Заказа» с «Заказчиком», но «Заказчик» ничего не знает о «Заказах», в которых он участвует. Об этом же нас предупреждает и Warning.

Для того чтобы это исправить, надо создать реверсивную связь у сущности «Заказчик» и указать ее в качестве обратной. Надо заметить, что официальная документация по Core Data настоятельно рекомендует делать всегда реверсивные связи — так мы и поступим. Строго говоря, вы можете этого не делать (все-таки это Warning, а не Error), но вы должны четко понимать, почему и зачем вы так поступаете.

Важное замечание! После создания модели данных ее нельзя менять — при первом запуске приложения Core Data в соответствии с моделью данных создает хранилище, а при последующих — проверяет структуру хранилища на соответствие. Если по каким-либо причинам структура хранилища не соответствует модели данных, то происходит критическая ошибка времени выполнения (то есть приложение у вас будет неработоспособно). Как же быть в случае, если модель данных требуется изменить — для этого необходимо использовать механизм миграции Core Data, это отдельная тема повышенной сложности, и мы не будем ее рассматривать в рамках данной статьи. Есть и другой вариант — можно просто удалить приложение с устройства (или эмулятора), а при старте приложения Core Data просто создаст новое хранилище с новой структурой. Очевидно, что данный способ уместен только на этапе разработки приложения.

В заключение данной статьи давайте взглянем на ее графическое представление, для этого переключите Editor Style редактора модели данных (находится внизу) в положение Graph.

Вы видите созданные нами сущности с атрибутами и все их взаимосвязи в виде графической структуры. Линия с обычной стрелкой на конце означает связь To One, с двойной стрелкой — To Many. Графический вид хорошо помогает сориентироваться в объемных моделях.

Источник