Что фантастичного в 10к записей? Простой кейс — облачное хранилище фотографий, коих у юзера вполне может быть и больше, и соответсвенно initial sync на свежей установке.
NSFetchedResultsController — это не часть Core Data стэка, не нужно его хранить в нем. Если ваши данные представлены таблицей, то вам нужно использовать этот контроллер как обычный табличный контроллер, если в другом виде, то в ваше контроллере экрана просто создаете новый NSFetchedResultsController на контексте в главном потоке например в viewDidLoad и используете его данные для показа. Разграничивать 2 таких контроллера не надо, все будет сделано за вас внутри.
Понимаю вашу боль. Хотя сама Apple в своих сессиях говорит о том, что миниатюры, хранимые в Core Data — это OK, меня терзают на этот счет смутные сомнениями… тем более, что сами они хранят миниатюры в EXIF'ах фоток.
Меня еще терзают сомнения, стоит ли упрощенный стек этих ухищрений с модельно, но тем не менее мое мнение выражается в том, что любой подход имеет право на жизнь, если он работает и его работа всех устраивает :) Попробуйте, кстати посмотреть на методы performBlock: и performBlockAndWait: контекста, с ними не нужно реализовывать свою очередь.
Оу, большое спасибо за замечание. До нового API еще толком не дошли руки, а WWDC видео было просмотрено уже довольно давно, что-то в памяти значит каратнуло. Действительно, новое API пополнилось NSBatchUpdateRequest, название которого говорит само за себя.
Лишнюю сложность в проектировение стеков я отметил и в своей статье. Действительно, нужно исходить из требований. Если у вас приложение, где вы одновременно работает с 1-2 записями, а максимальное их количество не превышает скажем тысячи, то вам нет особого смысла вообще усложнять себе жизнь работой с бэкграундом, Core Data достаточно быстра, чтобы совладать с такими масштабами прямо на главном контексте.
Ваш подход мне кажется своебразным, но интересным. Мне хотелось бы узнать подробности как вы обрабатываете fault для ваших NSObject объектов и пагинируете большой объем данных? А также интересно как вы реагируете на изменения в контексте? Возможно это материал для написания статьи? Я бы с удовольствие почитал о вашем опыте. ;)
Испокон веков завелось, что read быстрее write. Часть времени съедается на построение индекса(как минимум primary index), часть на I/O с постоянной памятью. Обычные приложения, направленные на потребление контента, большую часть времени занимаются read и write можно пренебречь. Если же ваше приложение критично к записи, то вам противопоказано разделение сущностей.
Вы уверены, что делегат должен быть strong? Это же 99% приведет к reference cycle (контроллер ссылается на вид, вид на контроллер). По идее, здесь нужен weak.
@property (strong, nonatomic) UIViewController *delegate;
Вы сначала сами уровень зарплат сравните с другими развитыми странами, спросите у своих бабушек и дедушек сколько пенсии на руки они получают. Потом посмотрите на теже цифры в регионах. Подумайте. Потом еще раз на цифры и еще раз подумайте. Продолжать до доведения до кондиции.
Вот это больше всего и беспокоит, начнут с простой программы, а закончится глобальной слежкой с тотальным контролем населения. Только напишешь другу «Можно у тебя стрельнуть пару тысяч до зарплаты?», а к тебе уже бобик выехал, сработав на ключевое слово.
Мне вот интересно, а где гарантия, что в этот регулирующий софт не будут встроенные другие средства слежки. Скажем он будет парсить очту, личные сообщение? Наверняка это софт будет с закрытым кодом и никто и не узнает, на что он будет способен на самом деле.
Ваш подход мне кажется своебразным, но интересным. Мне хотелось бы узнать подробности как вы обрабатываете fault для ваших NSObject объектов и пагинируете большой объем данных? А также интересно как вы реагируете на изменения в контексте? Возможно это материал для написания статьи? Я бы с удовольствие почитал о вашем опыте. ;)
Там все довольно просто, кинул контент в друга и он «полетел».
@property (strong, nonatomic) UIViewController *delegate;