Ресткит с (сложными) отношениями и Core Data / RAILS

Пожалуйста, терпите меня, поскольку я только изучаю Какао. Я прошел через несколько руководств по Core Data, теперь я пытаюсь использовать RESTkit с приложением Rails. Я также прочитал все документы и рецепты решений на вики-странице RESTkit (особенно был очень полезен iOS SDK: Advanced RestKit Development).

Для простоты я буду использовать в этом вопросе очень ограниченное количество моделей / отношений.

Предположим, у меня есть следующие модели: компания, человек, язык со следующими отношениями:

company many-to-many person
language 1-to-many person

и что RAILS и приложение iOS синхронизированы.

В определенное время в приложение Rails вводится новый человек, связанный с существующей компанией и существующим языком: например. Стив Джобс> Дисней, Стив Джобс> Английский В то же время в новую компанию добавляется новый человек и новый язык, например. Anna Kourinikova> Nike, Anna Kournikova> Русский

Как мне настроить решение для синхронизации? Я мог бы попросить дамп JSON всех новых людей:

[{"person": {
    "id": 123,
    "name": "Steve Jobs",
    "language": {
        "id": 1,
        "name": "English"
    },
    "company": {
        "id": 1,
        "name": "Disney"
    }
  }},
  {"person": {
    "id": 124,
    "name": "Anna Kournikova",
    "language": {
        "id": 22,
        "name": "Russian"
    },
    "company": {
        "id": 47,
        "name": "Nike"
    }
  }}]

Теперь мои вопросы:

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

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

3) может быть подход, состоящий в том, чтобы сначала получить все новые языки, все новые компании, а затем получить всех новых людей, с использованием только идентификатора языка / компании, с которой они связаны, в этом случае лучше (для сохранения пропускной способности ), но я не делаю вручную многие вещи, которые RESTkit может делать автоматически?

4) что, если существующее лицо связано со второй компанией?

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


ios cocoa-touch objective-c core-data restkit
person Community    schedule 13.09.2011    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Позвольте мне попытаться ответить на ваши вопросы по очереди:

  1. Да, при правильной настройке сопоставления RestKit может создавать новые компании и языки из указанного выше JSON.

  2. Да, вы можете избежать получения вложенных данных о компании и языке в пользу внешних ключей company_id и language_id, которые можно использовать во время сопоставления для подключения нового человека к существующим компаниям и / или языкам в вашем локальном магазине. Ознакомьтесь со следующим API сопоставления:

    • (void)connectRelationship:(NSString*)relationshipName withObjectForPrimaryKeyAttribute:(NSString*)primaryKeyAttribute;

Для № 3 и № 4 вам нужно будет укрепить дизайн API вашего сервера, прежде чем на них можно будет дать конкретный ответ. Вы предложили использовать в вопросе вложенный JSON, но также задали вопросы, предполагающие, что вы не можете использовать вложенный JSON и даже можете разбить указанный выше JSON на несколько запросов. Сценарий, который вы описываете в # 4, может быть обработан RestKit, но особенности того, как действительно зависят от того, какие вызовы вы делаете на сервер и какая полезная нагрузка возвращается в ответ на эти вызовы. Рад предоставить здесь дополнительную помощь, но, в конце концов, я абсолютно уверен, что RestKit может справиться с вашими вариантами использования, при этом особенности вашей конфигурации сопоставления в значительной степени зависят от того, как вы завершаете серверный API.

person jeffarena    schedule 13.09.2011
comment
Большое спасибо Джефф. Если я вас правильно понимаю: вариант 1) легко реализовать за счет более высокой пропускной способности, вариант 2) с разбивкой JSON и использование метода, описанного в 3), уменьшит пропускную способность, но мне придется вручную склеить все, используя API сопоставления connectRelationship - person ; 13.09.2011