Pull to refresh

Перевод: разработка для Android vs Windows Mobile

Reading time 7 min
Views 6.6K
Original author: Koushik Dutta

Вступление переводчика


Занимаясь разработкой для платформы Windows Mobile в течение последних двух лет, я не мог не слышать о новых платформах, таких как Apple IPhone, Google Android, Palm Pre. Какое-то время назад я натолкнулся на блог разработчика Windows Mobile, который вел свой блог в достаточно издевательском стиле, пародируя «30 days of Windows Mobile», его посты из той серии назывались «30 Days of Bitching about .NET CF», что переводится как «30 дней сплетен за спиной у .NET CF». В этих постах он описывал подводные камни, с которыми сталкивался при разработке.

Несколько месяцев назад этот блоггер приобрёл HTC G1 и погрузился в мир Android девелопмента. Выпустив пару приложений на Android Market, Кушик Дутта (а именно так его зовут) решил написать сравнительный анализ опыта разработки для Windows Mobile vs Android.

Оригинал находится здесь. Статья написана в ноябре 2008 года, на сегодняшний день некоторые сведения несколько устарели, но хуже от этого она не стала. В тексте есть несколько ссылкок вида [X], в самом конце идёт их расшифровка.

Android против Windows Mobile


Я хотел воздержаться от блоггинга на эту тему пока я не погружусь в достаточной степени в разработку для Andriod. И хотя я ни в коей мере не являюсь гуру Android платформы, я считаю, что могу спокойно делать некоторые достаточно общие утверждения, наступать кому-то на мозоли и быть в состоянии отстоять своё мнение.[0]

Байт-код


Google сделал несколько интересных архитектурных и стратегических решений касаемо Android. Самые заметные — это Java в качестве языка разработки и Dalvik в качестве виртуальной машины. Если коротко, то Dalvik это байт-код, который интерпретируется во время исполнения, как байт-код в Sun Java или Microsoft Intermediate Language (IL) [1]. Я не мог понять, зачем Google решился делать свою спецификацию байт-кода для Java, пока я не прочитал этот великолепный пост. А суть в том, что у компании Sun существуют заморочки с лицензированием Java ME и «открытый» альянс мобильных устройств (Open Handset Alliance) в действительности не может иметь открытую платформу без вероятности того, что какая-либо мега-корпорация не попытается навариться за их счёт.[2]

Но вопрос остаётся открытым — зачем изобретать новый байт-код, когда IL не защищён подобным лицензированием (это ECMA одобренный стандарт)? Может быть Google посмотрел и решил, что IL не годится для мобильной платформы, а может быть они не хотели спать в одной постели с Microsoft. Я полагаю, что вероятнее всего последнее.

Язык


Вообще говоря, байт-код, генерируемый за кадром, так же важен, как цвет моих носков. Я об этом регулярно не думаю. А вот что действительно важно — это язык, на котором вы пишете. Я могу понять, что Google выбрал Java, чтобы облегчить целевым разработчикам миграцию на новую платформу, но всё же… да, я всё-таки скажу это наконец. Java — отстой.

Почему Java отстой? Давайте посчитаем.
  1. Ужасные ограничения вокруг имен пакетов/файлов/каталогов/классов
  2. Отсутствие анонимных методов
  3. Отсутствие замыканий (closure)
  4. Отсутствие лямбда-выражений
  5. Отсутствие событий/делегатов
  6. Отсутствие partial классов
  7. Смешная имплементация перечислений
  8. Ужасная реализация generic-ов
  9. Отсутствие структур и как следствие невозможность хранить составные объекты целиком в стеке. Это существенно сказывается на производительности, там где это важно.
  10. Строки являются неизменяемыми (immutable), но не интернированы (см. intern)
  11. Нет доступа к unsafe-коду
  12. Нет get/set методов для свойств
  13. Нет перегрузки операторов
  14. Нет extension методов
  15. Наконец глупая и неинтуитивная расстановка скобок

Сколько причин? 15? Ха-ха-ха!


Я не пытаюсь придираться — всё, что перечислено выше, я использую на регулярной основе. Тем не менее замечу, что мне до некоторой степени нравятся анонимные классы, но они почти бесполезны без событий/делегатов. Я понимаю, что всё то, что я перечислил — это, по большому счёту, синтаксический сахар, и ни Java, ни C# не мощнее один другого — оба языка могут делать всё, что вам нужно, просто в каждом языке это нужно делать по-своему. За исключением того, что C# позволяет вести разработку быстрее, эффективнее, изящнее.[3]

Среда разработки


Eclipse это огромный ароматный кусок… эх. Да, очень насыщенный, гибкий, но кто бы ни проводил юзабилити тестирование этого мусора, должен работать над тестированием сжимающей силы веревки вокруг своей шеи.


Моя самая любимая больная мозоль это невозможность просто кликнуть на Expressions view и отредактировать что-либо на месте. Обязательно надо нажать правую кнопку мыши и выбрать там Add/Edit. В результате открывается примитивный текстовый редактор без Intellisense, в котором можно напечатать выражение, помолиться, что оно без ошибок и кликнуть OK. Ошиблись — повторяйте всё сначала.
Ранее я хвалил возможности внутренних классов (inner class) в Java. Какими бы хорошими они не были, Eclipse почти сводит на нет их удобство: вы не можете увидеть значение переменной родительского класса у внутреннего класса! Это делает отладку сущей мукой: приходится загружать родительские классы в локальные переменные, если что-то пошло не так, иначе просто невозможно найти и поправить даже простейшие косяки. Правда, я не уверен, проблема ли это в Eclipse, Java или Android.

Авто-дополнение в Eclipse ужасающе назойливое. Нельзя же так насильно всё дополнять, вне зависимости от желаний разработчика. Я в итоге вообще всё поотключал, потому что то, что он мне вставлял, было по большей части бесполезным. Но даже с полностью отключенным авто-дополнением, Eclipse продолжает расставлять за меня скобки...

SDK


Несмотря на то, что я много жаловался на разработку для Android, я хочу отметить, что я не жаловался на сам Android. По сути любой API, о котором бы я мог подумать, стандартизирован и существует.
Моей лакмусовой бумажкой в этом смысле было портирование Klaxon на Android. Это здорово помогло подчеркнуть колоссальные отличия между двумя платформами.

Лично для меня наиболее заметной разницей были API для доступа к аппаратным сенсорам. Android SDK 1.0 предлагает простой класс SensorManager, в котором я разобрался за 5 минут. У Microsoft было 6 версий Windows Mobile без какого-либо Sensor API.

Во-вторых, запуск приложений по расписанию на Android бесконечно проще, чем на Windows Mobile. Сравним, как я разбирался с этим на Windows Mobile:
  • Я начал с CeRunAppAtTime. Написал большой P/Invoke. Это какое-то время работает, а потом полностью перестаёт. У других людей были такие же проблемы. Пришлось переключиться на иной механизм.
  • Далее я попробовал CeSetUserNotificationEx. Написал ещё один здоровенный P/Invoke.
  • Для того, чтобы это заработало, пришлось разбираться с тем, как правильно заполнить структуру UserNotificationTrigger.
  • Потом выяснилось, что если устройство спит, то Klaxon не всегда правильно срабатывает.
  • Ещё раз перелопатив документацию, я решил и эту проблему — оказывается нужно было в явном виде посылать устройству команду включения, иначе оно опять засыпало.
  • Klaxon работал ещё какое-то время, пока не приключился переход на летнее время. На некоторых телефонах нотификации срабатывают на час позже. Без понятия почему. Я сдался.

А теперь сравним с Android:
  • Обратитесь к AlarmManager
  • Настройте срабатывание события (intent) в определённое время
  • Обработайте событие


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


Таким образом, одна из двух сложных частей во время разработки для Windows Mobile, на Android оказалась проще простого. Напоследок — пользовательский интерфейс.

Windows Forms против Android XML Layout. Windows Forms работает с абсолютными размерами и позиционированием. Android работает с относительными размерами и позиционированием. «Статические» контролы против анимированных контролов. По сути сравнивать нечего, так что я и пробовать не буду.


Проще говоря, Android SDK рвёт на куски Windows Mobile SDK (не учитывая особенности языков и фреймворков).

У Windows Mobile гораздо лучше документация (MSDN), но такова участь любого молодого SDK.

Платформы


Android достаточно жёстко зажат с точки зрения безопасности. Приложения должны регистрировать возможности, которые им нужны, а пользователь должен подтвердить их. Но несмотря на то, что это очень и очень положительная вещь, у неё есть свои недостатки. Например, невозможно написать приложение, которое снимает скриншоты чего-либо, кроме самого себя, т.к. это считается небезопасным [4]

И хотя это не вина Android, но телефоны не такие уж и «открытые» получаются — операторы привязывали и будут привязывать телефоны к себе, т.к. они их субсидируют. Например, у пользователя нет доступа к учётной записи root. Это не даёт возможности настраивать/изменять стандартные приложения, установленные на Android. Но если вы всё-таки получили root-доступ, вы реально можете менять стандартные приложения, т.к. они есть в исходниках.

С другой стороны, Windows Mobile ничего не прячет. Разработчик может получить низкоуровневый доступ абсолютно к чему угодно. Например, если бы у Android не было Sensor API, у разработчика бы не было шансов (кроме установки бинарников вручную через ADB). Ещё один пример: в Android пока нет поддержки потокого видео через Media Player, и насколько я знаю, сделать с этим ничего нельзя, если только не пропатчить бинарники системы через OTA update.

А, да, Android Market! Ничего говорить не буду, из названия и так всё ясно.
Прим.пер.: Да уж, Marketplace ещё только осенью 2009 года появится...

Заключение


В 4 утра не напишешь какого-то фантастического заключения. Скажу только, что мне действительно нравится разрабатывать для Windows Mobile. Язык и средства разработки просто великолепны. Тем не менее, платформа и приложения не очень-то удобны в использовании. С другой стороны, хотя я не так уж и удовлетворён от разработки для Android, платформа, приложения и юзабилити просто фантастические! Наконец-то мне не нужно воевать с телефоном, чтобы выйти в Интернет. Так что угадайте, какой телефон всегда со мной. И подумайте, для какого из телефонов я более заинтересован в разработке.

Я очень надеюсь, что Microsoft сможет создать удобную для пользователя платформу, что сделает меня счастливым пользователем и разработчиком. Я не верю, что я это говорю, но я всё-таки скажу, что им надо вырвать страничку из книги Apple и сказать: «мы забьём на обратную совместимость, мы забьём на существующие приложения, мы просто сделаем абсолютно новую платформу, которая работает». Они слишком долго прибегали к мантре «обратная совместимость», что просто не даёт им двигаться дальше. А между тем они всё отдаляются и отдаляются от рынка, часть которого они так боятся потерять.

Сноски


[0] Я разработал два приложения для Android Market: Telnet и Klaxon, так что я полагаю, у меня есть представление о разработке для платформы Android. Klaxon очень помог подчеркнуть колоссальные отличия между двумя платформами.
[1] Да, я понимаю, что IL не интерпретируется на Windows Mobile. он проходит через JIT-компиляцию.
[2] Каким бы ни был Microsoft «злом», он не был замечен в новостях в попытках отстоять свои патенты. В отличие от Sun
[3] Хочу посмотреть на Ruby
[4] Возможно Google сделает это в будущем

Tags:
Hubs:
+43
Comments 151
Comments Comments 151

Articles