Как вы уже указали в своем плане, XML и REST - отличный способ взаимодействия с веб-приложением. Я хочу предложить несколько деталей о том, как на самом деле спроектировать и построить его, или что вы должны иметь в виду.
Прежде всего, я считаю, что важно придерживаться MVC. Я видел людей, создающих HTTP-соединения в контроллерах представления, контроллеры - это делегат NSXMLParser, контроллеры, содержащие данные в переменных-членах. Я даже видел UITableCells, устанавливающий HTTP-соединения. Не делай этого!
Ваша модель и ее базовый код манипуляции должны быть максимально извлечены из пользовательского интерфейса. Поскольку вы уже создали модель в своем веб-приложении, попробуйте воссоздать сущности в вашем проекте iPhone. Не бойтесь иметь некоторые простые методы в классах сущностей, но не заставляйте их использовать внешние ресурсы, особенно соединения tcp. В качестве примера методов в классе сущностей у вас могут быть методы, которые форматируют данные особым образом (даты в качестве примера или возвращают полное имя как объединение имени и фамилии), или вы даже можете иметь метод, подобный - (void)update, который будет действовать как обертка для вызова класса, ответственная за обновление модели.
Создайте еще один класс для обновления модели - извлечения XML-файлов из веб-приложения. Даже не рассматривайте возможность использования синхронных соединений, даже из выделенного потока. Асинхронные соединения с делегатом - путь. Иногда нужно сделать несколько запросов, чтобы получить все необходимые данные. Возможно, вы захотите создать какой-то конечный автомат, чтобы хранить информацию о том, на какой стадии загрузки вы находитесь, и переходить от этапа к этапу, пропуская до конца, если возникнет ошибка, и через несколько секунд повторно выполнить этап сбоя.
Загрузите данные куда-нибудь временно, и сначала, когда у вас есть все, сделайте переключение и обновите пользовательский интерфейс. Это помогает быстрее реагировать при запуске приложения - пользователь сразу же начинает работать с данными, хранящимися локально, пока механизм обновления загружает новые данные.
Если вам нужно загрузить много файлов, попробуйте загрузить их одновременно, если это позволяют зависимости между файлами. Это включает в себя создание соединения по запросу, возможно, делегировать экземпляр для каждого из них. Конечно, у вас может быть только один экземпляр делегата для всех этих соединений, но становится немного сложнее отслеживать данные. Одновременная загрузка может значительно уменьшить задержку, делая механизм намного быстрее для пользователя.
Чтобы сэкономить время и пропускную способность, рассмотрите возможность использования заголовков HTTP If-Modified-Since и / или ETag. Запомните время или тег, когда вы запрашивали данные в последний раз, и в следующий раз отправляйте их в заголовке HTTP. Ваше веб-приложение должно вернуть HTTP-код 304, если содержимое не было изменено. Приложение iPhone должно реагировать на этот код соответственно в connection:didReceiveResponse:.
Создайте специальный класс для анализа XML и обновления модели. Вы можете использовать NSXMLParser, но если ваши файлы не очень большие, я настоятельно рекомендую TouchXML, так приятно работать с XML в качестве документа (он также поддерживает XPath) вместо API, основанного на событиях. Вы также можете использовать этот синтаксический анализатор, когда файлы загружаются, чтобы проверить их действительность - повторно загружать, если синтаксический анализ не удался. Вот тогда пригодится специальный класс для разбора.
Если ваш набор данных невелик, если вам не нужно постоянно сохранять загруженные данные на iPhone, вам, вероятно, не нужно хранить их в базе данных SQLite, вы можете просто сохранить их в формате XML - просто простое кэширование. По крайней мере, так может быть в приложении для Twitter. Это становится проще, но для больших наборов данных XML потребляет много памяти и вычислительной мощности - в этом случае SQLite лучше.
Я бы предложил использовать Core Data, но вы упомянули, что это ваше первое приложение для iPhone, поэтому я советую вам не использовать его. Тем не менее.
Не забывайте о многозадачности - ваше приложение может засыпать во время загрузки, вам нужно прервать соединения и очистить механизмы обновления.При пробуждении приложения вы можете возобновить обновление.
Что касается части представления приложения - используйте Interface Builder.Вначале это может быть болезненно, но в долгосрочной перспективе это окупается.
Контроллеры представлений являются связующим звеном между моделью и представлениями.Не храните данные там.Подумайте дважды, что и где реализовать, и кому это следует называть.
Это не связано с архитектурой приложения, но я хочу напомнить, что Objective-C - это очень выразительный язык.Код должен читаться так же, как предложение.Расширить классы с помощью протоколов.Как пример на днях мне нужна была первая строка строки.Конечно, вы можете написать однострочник, где вы найдете первое вхождение новой строки, и получить подстроку от начала до конца.Но это не выглядит правильно.Я добавил - (NSString*)firstLine в протокол NSString.Таким образом, код выглядит намного лучше, он не нуждается в комментариях.
В архитектуре и дизайне любого проекта нужно учитывать множество вещей, и оба они должны идти рука об руку.Если одно создает проблемы другому, вам нужно адаптироваться.Ничего не написано в камне.