Преобразование приложения запрограммированных данных в приложение основных данных

#iphone #core-data #queue

#iPhone #core-data #очередь

Вопрос:

я много читал о Core Data в разделе для разработчиков Apple и здесь, в stack overflow, и я хотел задать несколько вопросов, прежде чем я начну пытаться внедрить их в свое приложение, которое в настоящее время работает только с запрограммированными данными.

Идея приложения такова: пользователь — гонщик. Он ездит по разным схемам. Каждая схема имеет несколько именованных кривых, которые проходят с определенной скоростью и с определенной эффективностью. Таким образом, приложение должно хранить схемы, количество кривых для каждой схемы и множество (например, 200) проходов по отдельным кривым, сохраняя максимальную скорость и эффективность (например, строка «Выдающийся», «Хороший», «Плохой»). Проходы используются в приложении в очереди, где последний вход означает первый выход, как только вы достигнете, скажем, 200 проходов, чтобы улучшить статистические данные с течением времени и опыта водителя.

Я создал объекты с соответствующими параметрами и отношениями.

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

1 — я предполагаю, что, поскольку объем данных невелик, я мог бы генерировать данные при первом запуске, сохранять их в core data, а затем при каждом запуске приложения каким-то образом проверять, есть ли основные данные или нет, и на основе этого либо создавать новые, либо использовать текущие. Я читал о хранении данных в plist и их импорте через xml и прочее, но мне не нужно делать это правильно? Я могу создать, сохранить, а затем проверить, присутствуют ли какие-либо данные, чтобы узнать, является ли это первым запуском приложения или нет?

2 — я не совсем уверен, как сохранить очередь в core data. На данный момент я разработал его в своей голове так, чтобы очередь для каждой кривой состояла из сквозных объектов со многими отношениями к кривым с параметром index, чтобы я знал, какой проход был первым, а какой последним. Тогда я не уверен, как я смогу реализовать возможности очереди для удаления первого проходного диска. Буду ли я вынужден загружать все данные, обрабатывать их в очереди, а затем сохранять все данные в core data? Или он примет какой-то способ удаления первого диска и пересчитает индексы?

3 — правильно ли я говорю, что вся загрузка моих данных должна выполняться в моих контроллерах просмотра в «viewWillAppear»? И сохранять их мгновенно после того, как пользователь нажимает кнопку сохранения или ввода для каждого прохода?

Я не прошу код, я просто хотел бы, чтобы кто-нибудь сказал мне, является ли это в целом хорошим подходом или вы бы сделали это диаметрально по-другому.

Спасибо.

Ответ №1:

1) Сохранение данных во внешнем файле plist, затем импорт в NSDictionary via dictionaryWithContentsOfURL: , затем итерация по этому словарю и импорт в ваше хранилище Core Data в этом случае не требуется. Это было бы необходимо, если бы вы хотели сериализовать данные своей схемы извне, чтобы пользователь мог импортировать схемы, или чтобы вы могли вручную изменить исходную схему, отредактировав XML-данные в списке.

2) До iOS-5.0 объекты хранятся в Core Data как неупорядоченные NSSet . Если вы ориентируетесь на iOS 4.x, вам нужно будет добавить атрибут для сохранения заказа в очереди, который позволит вам вычислить, какой элемент был добавлен последним. Вам также нужно будет написать метод для поиска объектов и возврата атрибута сортировки с наибольшим номером, чтобы вы знали, что использовать для следующего атрибута сквозной сортировки. Если вы ориентируетесь только на iOS 5.0, вы можете пометить связь как упорядоченную, которая сохранит ее как NSOrderedSet . См.: Примечания к выпуску Core Data для iOS 5.0 — Управляемые объекты

3) Запуск кода загрузки данных -viewWillAppear: зависит от того, сколько времени требуется для генерации или загрузки данных. Если это займет заметное количество времени, вы не захотите делать это синхронно, так как это заблокирует основной поток, в котором выполняется UIKit, если выполняется код -viewWillAppear: , если время не является тривиальным (по крайней мере, менее 100-200 мс), вы захотите сгенерировать данные в фоновом потоке, которыйможет быть запущен -viewWillAppear: в. Самый простой способ добиться этого — использовать очередь отправки и dispatch_async()

Комментарии:

1. Вы имели в виду -viewDidAppear: для фонового потока? Или вы имели в виду действительно -viewWillAppear: и поэтому я этого не понимаю?

2. Если вы загружаете данные -viewDidAppear: и показываете вид активности или индикатора выполнения, то это не проблема. Но меня беспокоило то, что если процесс загрузки займет слишком много времени, -viewWillAppear: он не вернется, пока не будет выполнен код загрузки (если только не выполняется в фоновом потоке).