Где разместить «основной стек данных» в приложении Cocoa / Cocoa Touch
Вы можете проверить для locationServicesEnabled и если служба определения местоположения разрешена для вашего приложения по этому коду:
if([CLLocationManager locationServicesEnabled] && [CLLocationManager authorizationStatus] != kCLAuthorizationStatusDenied) {
//do your works
} else {
//show an alert
}
6 ответов
]Резюме: Нет необходимости создавать одиночку для управления стеком Core Data; на самом деле, это может оказаться контрпродуктивным.[
] []Стек Core Data создается делегатом приложения. Важно, однако, что, как показывают все примеры, стек (в основном, контекст управляемого объекта) - это []а не [], извлекаемый непосредственно из стека(*). Вместо этого контекст передаётся на первый контроллер представления, а от них на контроллер представления или управляемый объект передаётся от одного контроллера представления к другому (как описано в []Accessing the Core Data Stack[]). Это следует основной схеме для всех приложений iPhone: данные или контроллер модели передаются от одного контроллера представления к другому.[
] []Типичная роль одиночной кнопки, описанная здесь, - это контроллер модели. В случае с Core Data контекст управляемого объекта уже является контроллером модели. Он также предоставляет возможность доступа к другим частям стека, если это необходимо. Более того, в некоторых ситуациях (как описано в документации) вы можете захотеть использовать другой контекст для выполнения дискретного набора действий. Поэтому подходящей единицей валюты для контроллера представления обычно является контекст управляемого объекта, в противном случае - управляемый объект. Использование и передача однокнопочного объекта, который управляет стеком (и из которого вы получаете контекст), обычно в лучшем случае вводит ненужный уровень идирекции, и в худшем случае вводит ненужную жесткость приложения.[
] [](*) Ни один пример не извлекает контекст, используя:[
] [[[UIApplication delegate] managedObjectContext];
У меня есть одноэлементный класс, которому я позволяю управлять основными данными, и я не оставляю его делегату приложения. Я бы предпочел не загромождать класс делегата приложения методами, которые могут мне понадобиться для уверенности, например, получение определенных объектов и т. Д.
Я оставляю логику основных данных в делегате приложения по следующим причинам:
1) Я не вижу никаких реальных преимуществ в переносе этого кода в другие классы: концепция делегирования полностью реализуется логикой основных данных, обрабатываемой делегатом приложения, поскольку основная модель данных на самом деле является фундаментальной частью вашего приложения. ;
2) Во всех примерах кода, которые я видел, включая образцы Apple, основные данные обрабатываются делегатом приложения;
3) Даже в книгах Core Data это обычная практика, когда делегат приложения обрабатывает код, связанный с основными данными;
4) Лично я не думаю, что удобочитаемость или что-то еще else на самом деле улучшается за счет наличия специальных классов для основных данных, но это вопрос личного вкуса, и я не буду здесь спорить, какой подход является лучшим. Для меня важна простота при сохранении функциональности.
В вашем случае я задаю себе вопрос: «Кто делает стек Core Data? 'принадлежит?" Сами данные действительно являются областью применения, не так ли? (CF Core Data на Mac, где у вас может быть приложение, способное работать с несколькими документами одновременно, поэтому стек Core Data принадлежит каждому документу.)
В любом приложении Cocoa / Cocoa Touch делегат приложения является обычно это предпочтительный способ настройки поведения приложения, так что это естественное место для стека Core Data.
Теперь я подозреваю, что у вас возникла проблема в том, что вам кажется неправильным постоянно писать такие вещи, как:
NSManagedObjectContext *context = [(MyAppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext];
В таких случаях я обычно пишу такие функции (не методы):
NSManagedObjectContext *UIAppManagedObjectContext() {
return [*(MyAppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext];
}
Я пишу аналогичную функцию для NSPersistentStoreCoordinator и NSManagedObjectModel . Я помещаю все это в файлы .h / .m делегата приложения, так как они тоже являются объектами уровня приложения.
Я выступаю за то, чтобы делегат приложения знал, где начинается модель, и чтобы модель знала, где Контекст управляемого объекта есть. Основные данные - «сущность» модели мне кажется деталью реализации модели, классы контроллеров (например, делегат приложения) должны просто спросить: «Дайте мне эту информацию о модели», и модель должна знать, как ответить. этот вопрос.
Я просто перечислю это в новом ответе. (Я отказался от своего предыдущего класса FJSCoreDataStack в пользу этого)
Мой новый способ справиться с этим заключался в использовании категории в NSManagedObjectContext. Айв добавил следующие методы класса:
+ (NSManagedObjectContext *)defaultManagedObjectContext;
+ (NSManagedObjectContext *)scratchpadManagedObjectContext;
+ (NSManagedObjectModel *)managedObjectModel;
+ (NSPersistentStoreCoordinator *)persistentStoreCoordinator;
+ (NSString *)applicationDocumentsDirectory;
Это позволяет исключить все из моего делегата приложения и дает доступ к одиночному элементу, если я решу его использовать. Однако я все еще использую внедрение зависимостей из делегата приложения (как сказал mmalc, он привносит негибкость в мой код). Я просто переместил весь код «Core Data Stack» в категорию NSManagedObjectCOntext.
Мне нравится передавать ссылку, тем более что у меня есть хороший метод «контекста блокнота». Это обеспечивает гибкость моих контроллеров представления, поскольку я не закреплял их в «defaultManagedObjectContext». NSFetchedResultsController and constructing NSFetchRequests