Как мне создать приложение для iPhone, чтобы поговорить с моим сайтом?

Я планирую свое первое приложение для iPhone, и я хотел бы получить информацию о том, как его создать, с самого начала. Приложение iPhone создается в сочетании с общедоступным веб-приложением, которое уже встроено в PHP.

Я хочу, чтобы веб-платформа была центральной (данные размещены в базе данных mySQL) и имеют Клиенты iPhone общаются с ним и используют методы REST'ful для выполнения функций сайта (получение последнего контента, размещение контента, голосование, управление учетными записями в качестве примеров).

Я бы хотел, чтобы клиенты получили локальную копию данных в базе данных SQLite, но обновлялись, чтобы получить последнюю версию фида (аналогично приложению Twitter).

Несколько мыслей, которые я имею прямо сейчас:

Используйте что-то вроде ASIHTTPRequest для отправки/получения данных в файлы PHP на сервере, которые прослушивают запросы
JSON - мне было бы лучше отправить GET/POSTS на PHP, который возвращает объекты JSON, и работать с какой-то оболочкой, которая управляет данными и передает изменения в локальную базу данных SQLite?
Я полностью отключаюсь от того, как я должен строить эту вещь, чтобы общаться с Интернетом? Является есть ли лучшая практика для этого?

Я бы очень признателен за любые данные о том, как вы планируете такую настройку.

Спасибо,

EDIT: после прочтения моего собственного сообщения снова я знаю, что это похоже на клиент Twitter, но это НЕ, хотя у него есть аналогичные функции/структура настройки типа Twitter. Спасибо!

Ответ 1

Как вы уже указали в своем плане, XML и REST - отличный способ общения с веб-приложением. Я хочу предложить несколько подробностей о том, как на самом деле его разрабатывать и строить, или о том, что вы должны иметь в виду.

Прежде всего, я считаю важным придерживаться MVC. Я видел, как люди создают HTTP-соединения в контроллерах view, контроллеры - делегат 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. Код выглядит намного лучше, так как он не нуждается в комментариях.

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

Ответ 2

В настоящее время я работаю над приложением, которое похоже на ваше. Я также предлагаю ASIHTTPRequest и, вероятно, что-то вроде TouchJSON для разбора JSON или расширения/создания делегата NSXMLParser, если вы хотите проанализировать XML.

Как было предложено Джозефом Х, в зависимости от того, как работает ваше приложение, вы можете рассмотреть альтернативные методы проверки подлинности: я бы посмотрел на что-то вроде токенов, таких как OAuth, у которого готовые библиотеки для людей, чтобы в них заглянуть.

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

Как общее предложение, не забудьте потратить много времени на размышления о каждом случае использования и случае с углом для подключения: легко предположить, что пользователь будет обращаться к серверу определенными способами и в определенное время, а затем после вас бросить многозадачность/входящие вызовы/заблокировать экран/предупреждения о памяти, все может стать волосатым без какого-либо планирования.

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

Ответ 3

У Apple есть совершенно новый фрагмент кода - MVCNetworking, в котором подробно описывается использование подклассов NSHTTPRequests и NSOperationQueues.

Ответ 4

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

Независимо от того, какой метод/библиотеку вы предпочитаете говорить со своими веб-службами, я считаю важным сделать четкое разделение в том, как вы разрабатываете свою модель данных на телефоне VS. модель данных в вашем веб-приложении. У вас есть 3 основных отличия, чтобы иметь в виду ваш дизайн:

Модель данных в веб-приложении (отраженная вашей существующей базой данных mySQL)

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

Здесь начинается веселье. Во-первых, вам нужно хорошее понимание того, какие данные необходимо отображать в приложении для телефона. Поэтому сначала создайте хороший дизайн на высоком уровне вашего приложения (используйте ручку и бумагу, нарисуйте макеты каждого вида и взаимодействия между ними, моделируйте навигацию между контроллерами просмотров и т.д.). Это действительно помогает понять взаимодействие между контроллерами вашего представления и различными битами и частями данных, которые вы хотите показать в приложении. Это поможет вам создать требования к модели данных на телефоне. На основе этих требований сопоставьте существующую (веб-) модель данных с новой моделью, подходящую для вашего iPhone-приложения. Эта новая модель может включать или не включать все таблицы и поля, найденные в вашем веб-приложении. Но общее представление двух моделей должно быть очень схожим (например, отношения, типы данных и т.д.).
Модель данных, используемая для связи между указанным выше (это ваш "протокол обмена данными" )

Как только у вас есть 2 представления ваших данных выше, вам нужно "перевести" один на другой, в обоих направлениях. Создайте свой протокол обмена данными как можно проще и компактнее. Вы не хотите тратить байты на бесполезную информацию, поскольку передача по сети является дорогостоящей. (В качестве побочного примечания вы можете подумать о сжатии переданных данных позже, но так же важно иметь хороший дизайн с самого начала). Вероятно, лучше всего начать с протокола, в котором метаданные совпадают с таковыми в вашей модели веб-приложения (например, те же отношения, имена таблиц, атрибуты и т.д.). Но помните, вам нужно будет только сериализовать/де-сериализовать те сущности и отношения, которые вы указали в пункте 2) выше. Так дизайн соответственно. Ваш протокол обмена может также включать токены сеанса, информацию аутентификации, номер версии или другие метаданные, если вам это нужно.

Помните: ваш протокол обмена данными - это то, что отменит ваше приложение для веб-приложений и iPhone. Я обнаружил, что лучше их де-пара, потому что они могут развиваться со временем. Например, модель данных на iPhone может сильно развиваться, особенно если вы обнаружите, что вам нужно повторно моделировать некоторые отношения или добавлять/удалять атрибуты из ваших объектов, чтобы улучшить отзывчивость приложений или пользовательский интерфейс, навигацию, или что-то еще.

Поскольку это целая проблема и сама по себе, вам нужно разработать общий механизм сериализации/де-сериализации поверх вашего (JSON/XML/любой парсер, который вы выберете), который достаточно гибкий, чтобы поддерживать потенциал различия между вашими 2 моделями данных. Эти различия могут быть: имена сущностей/атрибутов/отношений, имена идентификаторов первичного ключа, типы данных, атрибуты для игнорирования, и список продолжается. Я бы определенно реализовал класс утилиты serializer/de-serializer в приложении iPhone, поддерживаемый конфигурационным файлом .plist, содержащим все поддерживаемые объекты, проблемы, псевдонимы, которые у вас могут быть. Конечно, каждый объект модели должен "знать", как сериализовать, десериализовать себя и свои отношения (т.е. Необходимую глубину графа объекта).

Последнее замечание, так как вы получите 2 представления своих данных, вам понадобится способ однозначно идентифицировать объект с обеих сторон. Например, подумайте о добавлении атрибута uuid ко всем данным, которые нужно обменять, или используйте любой другой подход, который подходит вашим потребностям.

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

http://itunes.apple.com/ca/podcast/linkedin-important-life-lessons/id384233225?i=85092597 (см. лекцию "LinkedIn: важные жизненные уроки по CoreData и GameKit (12 марта 2010 г.)" )

Удачи!

Ответ 5

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

JSON, ASIHTTPRequest и POST для PHP-скриптов звучат как отличный способ.

Если данные не очень чувствительны, я буду использовать http большую часть времени и использовать https только для страницы входа, которая либо устанавливает cookie, либо возвращает "токен", который вы используете в последующих запросах. (HTTPS может быть довольно медленным по сравнению с 3G-соединением, поскольку накладные расходы по количеству пакетов для установки SSL-соединения выше обычного TCP-соединения.)

Вы должны убедиться, что вы правильно передаете данные из ввода в скрипты PHP в базу данных, чтобы избежать любых атак SQL-инъекций, т.е. используя параметризованный SQL, не создавать sql-запросы, делая "SELECT * from users where username="+$_GET['username']"

Ответ 6

Я бы сделал это, как я сделал с большим количеством веб-страниц AJAX. то есть:.

У вас есть URL-адрес на вашем серверном пакете информации, которая будет передаваться в формате XML. (Это может быть через CGI/PHP script или что-то еще). Ваш передающий XML в теле сообщения - так легко читать и отлаживать человека со стандартного веб-браузера.
Используйте стандартные методы iPhone NSXMLParser для анализа отдельных полей данных из документа XML и записи обратно в вашу базу данных. Этот метод предоставляется как для получения данных из URL-адреса, так и для его анализа одним вызовом:

NSURL *xmlURL = [NSURL URLWithString:@"http://www.example.com/livefeed.cgi"];
NSXMLParser *myParser = [[NSXMLParser alloc] initWithContentsOfURL:xmlURL];

Пройдитесь по иерархии данных с помощью методов NSXMLParser и соответствующим образом заполните базу данных.