Несколько месяцев назад я углубился в мир мобильных разработок и создал приложение ( Hudson Helper ) для iPhone и Android. В этой статье рассказывается о моем опыте, сравнивающем разработку для Android и iPhone с акцентом на инструменты, платформу и опыт разработчика.
Прежде чем идти дальше, я должен отметить, что мое сравнение со значительным уклоном. Я провел последние 12 с лишним лет в разработке Java, потратив большую часть своей карьеры инструментов разработки С января 2004 года я создаю плагины для Eclipse , а до этого плагины для NetBeans . Это смещение несколько смягчено несколькими годами разработки на C и C ++. На этом фоне я нахожу, что я очень критичен к инструментам разработчика. Производительность разработчика является ключевым фактором — все, что отнимает поток разработчиков в зоне, является реальной проблемой.
Язык, модель программирования и платформа
язык
Язык выбора для разработки iPhone — Objective-C . Objective-C — это язык, основанный на C, с расширениями для объектно-ориентированных концепций, таких как классы, наследование, интерфейсы, сообщения, динамическая типизация и т. Д. Язык Java используется при разработке для Android (хотя на самом деле он не компилируется байт-код).
Ява — легкая задача. Я должен сказать, что приятно не учить новый язык для мобильных устройств. Существующие навыки не так просты, так что повторное использование опыта стоит много.
Потребовалось немного времени, чтобы обернуть голову вокруг некоторых языковых функций, доступных в Objective-C. Вскоре я обнаружил, что мне действительно нравятся некоторые функции языка, такие как передача сообщений (вместо вызова методов), категории и именованные аргументы. Однако я обнаружил, что синтаксис Objective-C громоздок. Я до сих пор не привык к «+» и «-» для статических методов и методов-членов, требуется слишком много скобок, и в общем, я просто чувствовал, что мне пришлось набрать много, чтобы выразить простую концепцию. IDE тоже не сильно помогла в этом (подробнее об этом позже).
Одна вещь, которая действительно стала ясной для меня, это то, что Objective-C, хотя и, возможно, был дальновидным для своего времени, на самом деле является языком 80-х. Некоторые проблемы, такие как разделение заголовочных файлов и файлов реализации, а также нарушение режима DRY — это действительно пустая трата времени, причем не маленькая. Я обнаружил, что постоянно переключаюсь назад и вперед между файлами, что требует не только затрат на навигацию (какой файл открывать?), Но и с каждым открытым файлом ваше чувство контекста должно быть воссоздано (где каретка, что выбрано, где я нахожусь в файл, как этот файл организован).
Насколько СУХОЙ, я должен действительно сделать 5 вещей, чтобы объявить собственность ?? (объявить в определении класса, снова объявить getter / deposter, инициализировать в методе init, @synthesize в реализации, release в dealloc). Вот что я имею в виду:
server.h
@interface Server : Updatable {NSString *name; <-- declare the property }@property (nonatomic,retain) NSString *name; <--- declare the property again
Server.m
@synthesize name; <-- implement getter/setter-(void) dealloc {[name release]; <-- release memory}
Если вы спросите меня, все в Server.m должно уйти. Еще один недостаток — это позиционная актуальность @synthesize.
Java имеет аналогичную проблему со свойствами, хотя и не так уж и плохо — и IDE помогает вам написать ваш метод получения / установки.
Указатели в Objective-C, хотя и мощные, также являются другой тратой времени. Это где Java действительно сияет своей сборкой мусора. Я обнаружил, что постоянно размышлял, были ли выделенные объекты освобождены надлежащим образом. Поток кода плохой, поскольку логика приложения завалена управлением памятью. У меня только так много мозговых циклов — почему я должен думать об этом другом бесполезном деле, которое на самом деле не является основной заботой предметной области? Конечно, это становится еще хуже, когда вы пытаетесь понять, где что-то пошло не так, если вы допустили ошибку. Зомби помогают, но все же не дают понять, что вы получили доступ к тому, что было освобождено. Другие проблемы включают освобождение чего-то дважды, автоматическое освобождение чего-то дважды. Я также нашел не интуитивно понятным, когда сохранять возвращаемые значения из методов.
Еще один недостаток Objective-C — шаблоны, которым необходимо следовать: реализация правильных методов init и dealloc нетривиальна. @synthesized getters и setter для свойств с retain не должны вызываться в этих методах. Так много соглашений и правил, которые нужно запомнить!
Хотя я понимаю, почему существует разделение alloc и init, все еще слишком многословно указывать [[aloc Foo] initWithArg: arg]. Почему бы просто [новый Foo arg]? Или как насчет нового Foo (arg) — о, подождите, это так же, как Java!
Импорт Objective-C и предварительные объявления (@class) — это боль. Хотя эти проблемы существуют при разработке Java, JDT в Eclipse настолько хорош, что я почти забыл, что такое писать импорт. Все, что вам нужно сделать, это Ctrl + Пробел, чтобы автоматически заполнить имя класса или Ctrl + Shift + O, чтобы организовать импорт и вуаля!
Конечно, Java тоже не идеален, однако этот факт скрыт от меня из-за того, что я живу на Java очень давно. Иногда мне хочется, чтобы Java была более похожа на Groovy , однако я к этому привык и инструменты настолько хороши.
Платформа
На Android я обнаружил, что могу легко использовать классы времени выполнения Java. Некоторые, но не все, из стандартных классов Java RT доступны на Android. Я не нашел в этом проблемы, поскольку большинство стандартных библиотек Java IO, network и regex доступны. Классы Android RT, похоже, основаны на Harmony , который существует достаточно долго, чтобы быть стабильным.
С iPhone, с другой стороны, найти нужную мне функциональность было больно. Классы и методы плохо организованы. Когда искать статический метод по сравнению с классом с членами, мне было непонятно. Кроме того, в зависимости от используемой платформы, соглашения об именах и организация кода будут отличаться. Я полагаю, это наследие старой платформы. Области, в которых не хватало функциональности, которые мне показались болезненными, были регулярные выражения, обработка строк и синтаксический анализ XML. В итоге я использовал превосходный Regex Kit Lite для регулярных выражений. Для синтаксического анализа XML я реализовал абстракцию синтаксического анализатора над libxml , но позже обнаружил, что мне, возможно, было легче с NSXMLParser, который намного больше похож на SAX.
На iPhone, когда все работало не так, как ожидалось, мне пришлось прибегнуть к Google и надеяться, что другие столкнулись с той же проблемой. Эта техника была затруднена более ранней политикой Apple в отношении NDA, которая означала, что контент iPhone довольно тонок в сети. В некоторых случаях я прибегаю к догадкам и экспериментам, чтобы найти решение.
Android имеет то преимущество, что является открытым исходным кодом. В течение нескольких минут у меня был полный исходный код платформы Android в моей системе, и я пересобрал SDK из исходных кодов, чтобы убедиться, что исходный код соответствует классам времени выполнения в эмуляторе. Поэтому я не только мог видеть, как все реализовано на платформе Android, и учиться на собственном примере, я мог просматривать код платформы в эмуляторе и выяснять, почему мой код не дает желаемых результатов.
В целом я обнаружил, что соглашения о расположении, организации и именовании классов платформы Android были последовательными и предсказуемыми. Это сделало намного легче учиться.
Модель программирования
Платформа iPhone делает большую работу по поощрению шаблона проектирования MVC . С помощью этого шаблона проектирования, встроенного в платформу, создание пользовательского интерфейса стало простым, и мне не пришлось самостоятельно разбираться, как организовать дизайн компонента пользовательского интерфейса. Это также означает, что при рассмотрении примера кода все организовано одинаково.
Android также хорошо справляется с шаблонами дизайна, хотя их концепции значительно отличаются от iPhone. Благодаря поддержке Android нескольких процессов и повторного использования компонентов, сама платформа обеспечивает поддержку Intents и Activity (Intent — всего лишь вариант команды ). Дизайн обеспечивает лучший пользовательский опыт, однако он представляет некоторую сложность для разработчика: при запуске одного действия из другого используется намерение для передачи любых параметров. Эти параметры не могут быть переданы по ссылке — только по значению. Если на iPhone очень просто иметь экраны с одинаковыми структурами данных, то на Android это требует некоторой предусмотрительности. Очевидно, что приложения Android могут управлять кнопкой «назад» и иметь все, что происходит внутри одного действия, однако это не норма.
И Android, и iPhone предоставляют способ объявления пользовательских предпочтений в XML. Обе платформы предоставляют пользовательский интерфейс по умолчанию для редактирования этих настроек, и это здорово. XML-формат Android является расширяемым, что позволяет интегрировать пользовательские компоненты пользовательского интерфейса, что упрощает пользовательские настройки. Разработчики iPhone, желающие настроить предпочтения, должны будут реализовать пользовательский интерфейс с нуля, что требует гораздо больших усилий.
Тестирование и непрерывная интеграция
Я считаю, что все усилия по разработке должны включать юнит-тесты. Команды размером больше одного должны также включать в себя непрерывную интеграцию .
Разработчики Android будут рады узнать, что они могут писать тесты JUnit. Я мог даже запустить их из пользовательского интерфейса Eclipse после некоторого возмущения пути к классам. Хотя я этого не пробовал, я предполагаю, что запускать их из Ant и вашего любимого CI-сервера, такого как Hudson , тривиально .
Я видел некоторую документацию по тестированию устройств iPhone с iPhone SDK, но не потратил время на ее изучение — поэтому я не могу комментировать там.
Ресурсы
Apple делает отличную работу, предоставляя множество ресурсов для разработчиков. Важные концепции объясняются в видео, что облегчает понимание концепций — однако я обнаружил, что видео развивалось медленно, и я искал, казалось, часы, чтобы найти информацию, которая должна была занять минуты. К счастью, Apple также предоставляет множество примеров приложений и кода для демонстрации использования API.
Разработчики Android также имеют доступ к множеству ресурсов. Руководство и справочник по API устанавливаются вместе с SDK, поэтому все доступно в автономном режиме (что для меня важно, так как я выполняю большую часть своей работы в пути). Я обнаружил, что ресурсы для разработки Android лучше организованы и тратят меньше времени на поиск и больше времени на поиск. В частности, пример приложения ApiDemos предоставляет отличную отправную точку. Я также скачал много проектов Android с открытым исходным кодом для идей об архитектуре и использовании API. Это та область, где у Android есть преимущество, так как предыдущая политика Apple в отношении NDA была не слишком полезной для iPhone с открытым исходным кодом.
механическая обработка
Для меня оснастка стала настоящим шоком. Вот категории инструментов, которые я расскажу: IDE, UI builder, отладчик, профилировщик. Почти все остальное связано с предоставлением, и в этой области я не заметил особых различий между Android и iPhone.
IDE
Разработка Android использует превосходные инструменты JDT , которые в значительной степени стандартны для каждой установки Eclipse. Я использовал эти инструменты уже много лет, и они превосходны. Все, что Java индексируется, IDE имеет богатую модель исходного кода, и рефакторинг настолько прост, что изменил мою работу.
Возможно, лучшая особенность JDT — это инкрементный компилятор , который обеспечивает немедленную обратную связь с ошибками и предупреждениями при вводе. Это исключает цикл кода-компиляции-ожидания-обратной связи, который был так распространен в 80-х и 90-х годах. Ошибки и предупреждения обновляются в редакторе Java по мере ввода, что дает мне мгновенную обратную связь. Я не осознавал, насколько ценна эта функция, пока не начал кодировать Objective-C в XCode — когда я остро осознал, как ожидание обратной связи от компилятора может нарушить процесс программирования.
Другие ключевые особенности, которые делают Eclipse таким интересным для работы:
- контентная помощь
- Быстрые исправления
- организовать импорт
- открытый тип (CTRL + Shift + T)
- рефакторинга
Интегрированный Javadoc и помощник по содержанию, возможно, являются лучшим способом изучения незнакомого API. В Ecipse не только все классы и методы сразу доступны в контексте, в котором вы пишете код, но и представлена их документация.
Content Assist с интегрированным Javadoc
XCode настолько шокирующе плох, что я почти не знаю, с чего начать. Вот минимальный список вещей, которые, я думаю, нужно исправить, чтобы XCode стал жизнеспособной IDE:
- Content Assist, который на самом деле работает. Помощник по контенту, предоставляемый XCode, часто ошибочен и почти всегда предлагает небольшое подмножество того, что действительно доступно.
- Приличная система управления окнами / редактором. XCode и связанные с ним инструменты (отладчик) любят открывать множество окон. Хотите открыть файл? Как насчет нового окна для вас! Очень быстро я оказался в аду открытого окна. Управление окнами операционной системы предназначено для управления несколькими приложениями, а не несколькими редакторами в среде IDE. Он просто не способен обеспечить управление редакторами в такой сложной среде, как IDE.
- Представление дерева проекта, сортирующее файлы по алфавиту. В самом деле!
- Интегрированная документация API. Я обнаружил, что постоянно переключаюсь из IDE и ищу документацию по API с помощью Appkido . Это может показаться тривиальным, но это действительно нарушает поток.
Одной из областей Затмения, с которой просто невозможно сравниться, является Милин . Интегрированное управление задачами и сфокусированный интерфейс вносят огромную эффективность в любой проект, маленький или большой. Если вы еще не попробовали Mylyn, определенно стоит потратить время на то, чтобы взглянуть. Хорошее место для начала это Mylyn в Getting Started страницы.
UI Builder
Разработчикам приложений для iPhone предоставляется довольно хороший пользовательский интерфейс. Он отлично показывает интерфейс, как он будет отображаться. Он гибкий и может моделировать довольно сложные пользовательские интерфейсы, поэтому я был впечатлен. Я обнаружил, что использовать его было немного сложно — мне пришлось читать документацию два или три раза, прежде чем я действительно смог понять, как правильно его использовать.
Конструктор пользовательского интерфейса Android я нашел довольно бесполезным: он не может отображать интерфейсы, как они будут выглядеть на самом деле, а интерфейс слишком неэффективен. Я обнаружил, что закодировал все пользовательские интерфейсы непосредственно в представлении исходного кода XML для создателя пользовательского интерфейса. Там помощь с контентом и валидация были довольно хорошими, что облегчило мне создание пользовательского интерфейса.
дебаггер
Привыкнув к отладчику Java в Eclipse, я был шокирован состоянием отладчика в XCode. С Eclipse я могу видеть и изменять значения переменных. Не так в XCode. Может быть, это просто состояние дел при отладке нативного кода, но это, безусловно, влияет на полезность отладчика. XCode часто казался запутанным в отношении типа объекта и предоставлял мне значение указателя, а не детали. Это резко отличается от Eclipse, где я могу с легкостью перейти к графу объектов.
Я нашел интерфейс отладчика XCode чрезвычайно сложным в использовании. Нажатие на стек для отображения кода в редакторе привело к открытию новых окон, что в итоге привело к открытию десятков окон. Кроме того, я обнаружил, что выражения часов редко работают для меня.
Профилировщик и анализ кучи
Область, в которой инструменты разработки Apple выделяются, — это профилирование и анализ кучи. Эти инструменты казались зрелыми и простыми в использовании. Не имея предварительного опыта работы с этими конкретными инструментами, я смог лучше понять мое приложение за считанные минуты, найти и устранить несколько утечек памяти и повысить производительность.
Обнаружение утечек памяти в XCode
Разработчики Android должны использовать приложение traceview для Android, которое, как мне показалось, работало хорошо, но требовало значительно больше усилий для настройки и работы. Я был удивлен, обнаружив, что исходный код необходимо изменить, чтобы получить файлы трассировки, необходимые для анализа.
Я не уверен, что Android может предоставлять дампы кучи в формате hprof. Если это возможно, тогда можно использовать удивительный инструмент MAT для анализа использования кучи. В соответствии с этой статьей Android может выдавать данные кучи hprof, хотя я этого не пробовал.
Магазин приложений
Само собой разумеется, что магазин приложений для iPhone превосходен тем, что вы можете продавать его во многие страны мира с помощью одной настройки. Я смог предоставить номер своего банковского счета в Канаде, подписать несколько юридических соглашений, и я начал работать.
Однако получить приложение в магазине, по меньшей мере, неприятно. Apple должна одобрить каждое приложение, прежде чем оно будет принято в магазине. Моя была отклонена несколько раз. Каждый раз, когда он был отклонен, мне почти не давали информации о том, почему. Когда я послал им по электронной почте, чтобы прояснить проблему, я получил то, что выглядело как консервированный ответ, указывающий, что я должен сослаться на предыдущую переписку. Если бы это не было так неприятно, я бы нашел это забавным. Я настоятельно рекомендую прочитать « Отказ от приложения iPhone» Брайана Стормонта от Apple и продолжение Дана Григсби в части 2 .
Конечно, как только я начал продавать Hudson Helper, я понял, что Apple не отправит мне денег, если сумма выплаты не превысит 250 долларов. Это относится не только к первой выплате, но и к каждой выплате. С другой стороны, Google Market требует минимум 1 доллар за каждую выплату. Магазин приложений для iPhone и Google Market занимают около 30% от продажной цены вашего приложения. Приложения за 0,99 доллара должны иметь большой объем, иначе они просто не стоят вашего времени.
Рынок Google по сравнению с магазином приложений Apple ужасен тем, что продавать его можно только в нескольких странах . Вы также не можете видеть или устанавливать приложения, которые стоят денег на телефоне разработчика. На самом деле вы можете, но не если приложение имеет защиту от копирования — это почти все несвободные приложения. С другой стороны, когда вы загружаете свое приложение в магазин приложений, оно становится доступным в течение нескольких минут, поэтому вам не нужно беспокоиться о процессе утверждения.
Чтобы настроить торговую учетную запись в Google Market, мне пришлось указать адрес в США и номер банковского счета, поскольку Google не поддерживает Канаду. Для меня это было больно, но не так уж и плохо, поскольку я живу в нескольких километрах от границы с США. Я поехал на велосипеде в США и открыл счет в банке Horizon. Банку потребовались паспорт и водительские права, поэтому проблем нет. Почему Google не поддерживает больше стран, я не знаю. По крайней мере, Google Market должен принять альтернативные способы оплаты для стран, которые не поддерживаются Google Checkout.
Резюме
Платформа Android и инструменты разработчика превосходны. Использование Java и Eclipse IDE являются основными факторами победы для Android. Инструменты разработчика Apple шокирующе плохи по сравнению. Языковые и программные API-интерфейсы Objective-C громоздки и плохо организованы. В целом, при разработке для iPhone я чувствовал, что вернулся в 1993 году. Эти факторы, объединенные в моей оценке, делают разработку приложений примерно в три раза дороже при разработке для iPhone. Единственная область, в которой разработчики Apple преуспели, — это профилирование и анализ кучи.
Магазин приложений Apple с точки зрения пользователя и с точки зрения охвата всего мира превосходен. В этой области Google Market для Android слаб.
Разработка для iPhone может улучшить как инструменты , такие как iphonical (MDD для iPhone) и objectiveclipse (Eclipse , плагин для Objective-C) возникают.
Мы можем увидеть потрясение на рынке мобильных устройств: в этом году было выпущено не менее 18 новых телефонов Android. Пока этого не произойдет, iPhone останется лидером рынка, и разработчикам придется мириться с XCode и Objective-C.
Для меня моя любовь с Android. Конечно, iPhone великолепен, но вы можете установить новое ядро Linux?