3

Стартовые условия - есть уже работающие сервер (MSSQL->JSON) и клиент (JSON->CoreData) под iOS, и пишется клиент под Android который будет локально работать на sqlite. Руководство хочет уйти от привязки к JSON'у на iOS, которую сделал исполнитель, и перевести iOS-клиент на работу с sqlite, чтобы сделать в будущем highload-backend с которым потенциально смогут работать обе мобильные платформы (а не два бекенда для каждой платформы как сейчас). Передо мной (нынешний исполнитель) дилемма - перепиливать CoreData на прием из сети sqlite и ее засовывание в CoreData, или переписывать все для FMDB->sqlite. Все склоняется к тому чтобы использовать то, что будет быстрее работать на клиенте визуально. Причиной создания данного топика стало то что возможности попробовать нет, так как написание приложения на FMDB с нуля займет непозволительно много времени, и если оно не окупится по итогу то много времени будет потрачено зря. Прошу не разводить холивар на тему кому что больше нравится а описать какие-то практические данные с реальных проектов, околограничные проблемы обоих решений, свой личный опыт о том что из этих вариантов работает быстрее или имеет какие-то преимущества.

1
  • 1
    Хороший вопрос, подпишусь. Позже постараюсь отписать о своем опыте. 4 июл 2013 в 12:45

2 ответа 2

4

Я немного запутался в вашем вопросе, но все равно попробую ответить.

Мне странно, что ваше руководство "хочет уйти от привязки к JSON'у на iOS" и я, честно говоря, впервые слышу, чтобы работающий клиент (JSON->CoreData) перекраивали под то, чтобы работать с sqlite (то есть даже вообще впервые слышу, чтобы sqlite служил транспортом вместо JSON особенно в целях унификации платформ).

Возможно я не знаю каких-то особых подходов и тонкостей, но, кажется, JSON является абсолютным стандартом при передаче данных в сетевой схеме взаимодействия между клиентом-приложением и сервером-бэкэндом. Я ни разу не встречал, чтобы топовые библиотеки в мире Apple/iOS работали с чем-то кроме JSON. Достаточно назвать AFNetworking и RestKit. Сказав это, добавлю что такое решение вашего руководства выглядит вдвойне странным в виду того, что, повторю еще раз, если я правильно понял, они стремятся добиться максимальной универсальности решения.

Исходя из сказанного выше, мне кажется, что не должно быть никаких сомнений, что ваш сервер должен отдавать JSON (ну и замечательно будет, если все по REST-конвенциям спроектировано будет или уже), и должны быть клиенты iOS и Android соответственно, которые будут этот JSON переносить уже к себе с учетом своих специфик. Если сказанное до сих пор верно, можно уже поставить немного другой вопрос, на который я могу ответить тоже лишь частично и только про Apple/iOS: "ваш опыт налаживания подобных схем" и его подвопросы: стоит ли пользоваться RestKit (так как это единственное full-stack решение подобных задач, насколько я знаю работает только с Core Data), и если нет, то пользоваться ли Core Data или отказаться от него и использовать sqlite?

Мой личный опыт такой: я занимаюсь разработкой именно iOS-приложений около 11 месяцев, все это время я делаю приложение, которое можно, сказав грубо, назвать клоном FourSquare - говорю это для того, чтобы показать, что я достаточно плотно столкнулся именно с вопросами взаимодействия сервера, спроектированного в соответствии с REST и отдающего JSON, и клиента, которому нужно этот JSON разложить в Core Data.

Так получилось, что о RestKit узнал далеко не сразу. Поэтому оказалось, что научение тому, как сделать все грамотно, то есть разобраться с многопоточностью, GCD, Core Data, всему тому, что RestKit делает где-то за кулисами прямо из коробки, заняло у меня очень много времени (где-то месяцев 5). Позже оказалось (когда я-таки взглянул внимательно на RestKit), что для того, чтобы полностью реализовать работающую схему JSON<->Core Data, мне пришлось сделать код, весьма напоминающий по структуре код RestKit. Он не столь идеально абстрагирован по сравнению с RestKit, но с поставленными задачами справляется, и чем дальше продвигается мой проект, он все больше начинает на него походить, хотя и с небольшой разницей в наших подходах (кстати, судя по профилю на Гитхабе, автор RestKit работает на TripAdvisor - то есть вот against what он разрабатывает RK). Про свои недоумения относительно RestKit я задавал здесь на ХК вопрос, на который, к сожалению, так и не получил хотя бы одного внятного ответа: RestKit - за и против?. То есть после года экспериментов я все еще колеблюсь по поводу того, чтобы полностью перейти на RestKit, так как уже сам почти научился решать эти задачи и немного в более близком лично мне ключе, чем это делает RestKit, но, повторю, времени и усилий это заняло достаточно много!

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

Теперь отвечу совсем немного про "Core Data vs FMDB->sqlite". Я начинал изучать iOS строго по гайдам и там все время мелькало Core Data, поэтому я опять же не сразу узнал, что бывают просто разнообразные ORM и оболочки и key-value store, работающие с sqlite.

Мой результат - это то, что я вполне нормально освоился с Core Data и НИ РАЗУ не встретил СЕРЬЕЗНЫХ ограничений, которые заставляли бы меня подумать о переходе к каким-то другим решениям, хотя за это время я узнал о существовании не только FMDB, но и, например, таких вот решений: NanoStore, YapDatabase, iActiveRecord (особенно близкое и понятное мне, так как я имеющ опыт работы с ActiveRecord в Ruby on Rails).

На этом пока все. Возможно позже я дополню свой ответ, если придумаю, как сделать его лучше.

ОБНОВЛЕНО ПОЗЖЕ

Я могу себе представить только один возможный случай, когда работа с sqlite (без JSON вообще) может оказаться адекватной - это случай так называемой оффлайн-работы. Приведу простой пример: у вас есть приложение с картами (Яндекс карты) и вы в момент начала пользования приложением скачиваете разом NN мегабайтовую карту и с этого момента пользуетесь исключительно скачанной картой, так как карта обновляется очень редко и вы можете быть уверены, что скачанная карта будет служить вам верой и правдой, хм, адекватно отражать местность и завтра и послезавтра. То есть, если база, с которой будет работать ваше приложение, является более или менее статичной, вы можете при первой загрузке приложения (в момент начала использования приложения) просто разово передавать ее одним большим файлом (чуть ли не дампом базы) и просто импортировать её средствами местной на клиенте DB (не узнавал, возможно ли такое в Core Data или в SQLite, но очевидно, что подходы должны существовать). Таким образом вы на корню рубите вопросы синхронизации, JSON, весь этот парсинг, маппинг, асинхронность и много других слов и проблем. Единственное требование к специфике приложения - это, чтобы оно не должно было постоянно лазить за чем-то очень свежим и постоянно обновляющимся на ваш сервер, в сеть. Мне кажется, мое описание этого случая вполне ясно.

ОБНОВЛЕНО ЕЩЕ ПОЗЖЕ

Интересный топик на SO, открытый авторами вопроса и ответа на эту тему: Improve process of mirroring server database to a client database via JSON.

3
  • Спасибо вам за хороший ответ. Возможно автор либо опечатался, либо предыдущий исполнитель хранил данные в json-файлах (и такое бывает, да, лично видел :) ). З.Ы. как автор iActiveRecord советую быть с ней осторожным, "продукт" вышел сырым, и все еще может содержать баги. Но несмотря на это знаю людей которые используют его в production,да и работа все еще в процессе ;) 15 июл 2013 в 18:05
  • В том-то и дело, что похоже, что нет, не опечатался. В том-то и дело, что скорее всего они хотят передавать какие-то куски sqlite. Это звучит дико, но я вполне допускаю, что это возможно. Я попробую дописать вариант, когда это может оказаться уместным (только что подумал про него). 15 июл 2013 в 20:18
  • да, коллеги, не опечатался) Большое спасибо за развернутый ответ и комментарии. @AlexDenisov, хотелось бы еще услышать Ваше мнение по поводу sqlite vs CoreData
    – AlexThumb
    16 июл 2013 в 7:16
4

Последний раз с CoreData (с нуля) работал довольно давно, но периодически приходилось поддерживать существующие проекты. С sqlite приходилось работать в паре проектов, но последние проекты были в основном тонкими клиентами.

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

CoreData это не аналог и не замена sqlite. Это два абсолютно разных инструмента, и у них разные области применения. Если нужно делать какие-то очень хитрые запросы (например вычислять географическое расстояние), то здесь будет удобнее sqlite. В остальных случаях будет достаточно CoreData'ы.

CoreData

- Контекст и невалидные сущности. Если в контекст попала невалидная сущность, и вы проморгали ее удаление оттуда то сохранить контекст уже не удастся.

- CoreData - отдельный стек, не похожий на SQL с которым мне приходилось работать до этого. Причем стек довольно большой, а т.к. область применения относительна невелика, то зачастую очень тяжело найти решение какой-нибудь нетривиальной проблемы.

+ Работает "из коробки", при использовании сторонних оберток (MagicalRecord, ObjectiveRecord) работа с ней становится гораздо приятней.

+ Система миграций, не нужно писать raw sql (зачастую это излишне)

SQLite

- Приходится много писать относительно низкоуровневых вещей, либо пользоваться каким-то враппером, но даже с тем же FMDB приходится писать много, т.к. это всего лишь адаптация sqlite3 API для Objective-C. Как я указал в комментарии, пытался писать свою обертку, но задача далеко не тривиальная, вылазит много граблей/костылей

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

+ Это все же SQL и используется на многих платформах, а потому гораздо проще найти решение проблем/вопросов.

+ Полный контроль над взаимодействием с БД.

Резюме

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

2
  • 1
    Спасибо! Ответы тех людей которые мне были тут интересны - получены. Теперь мне легче будет аргументировать в общем принятие решений относительно использования этих технологий в конкретных случаях
    – AlexThumb
    16 июл 2013 в 8:04
  • 1
    Да, и здесь спасибо за очень хороший ответ. Я вчера уже не осилил написать сходное сравнение, поэтому просто подпишусь под тем, что вы сделали за меня: +1 про геолокационые расстояния (однозначно плюс в пользу sqlite), +1 про инвалидные сущности (именно поэтому я с ними научился очень внимательно обходиться в Core Data), и еще скажу, что обертками типа MagicalRecord пока вообще не пользуюсь, так как написал один небольшой класс-обертку, который включает в себя хелперы для тех моментов, которые в CD для меня были неприятны в этом смысле. 16 июл 2013 в 9:52

Ваш ответ

By clicking “Отправить ответ”, you agree to our terms of service and acknowledge you have read our privacy policy.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками или задайте свой вопрос.