Добрый вечер, хабравчане! Сегодня хотелось бы написать о кросс-платформенной разработке в целом. Ведь по сути люди сейчас делят десктоп, сервер и мобильных клиентов и стараются искать кросс-платформенные тулы внутри каждого сектора, не заглядывая за рамки каждого из секторов. Это бывает по различным причинам. Одна из причин — Вася знает как делать десктоп на Java, а Петя — как делать приложеньки под iPhone на Objective-C. И никто даже догадаться не может что есть технологии, объединяющие все платформы воедино.

За катом много текста и статистики.

Мое выступление на Apps4All Forum. Выступление первое, все ошибки подачи материала уже намотал на ус.

Решаемые проблемы

Первая группа проблем — проблемы продукта

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

• Точно ли код под каждую платформу имеет единый flow? Эта проблема возникает при отсутствии координации и взаимоотношений в командах, пишущих под различные платформы. От того, что люди не видят другого кода и пишут каждый — свое.
• Нигде ли не разошлись по API? Возникает по тем же причинам, однако к ним добавляется еще одна: до одной дошла информация об изменениях, а до второй — нет. Причем если этот раздел API используется редко, то расхождение может быть вообще не замеченым пройти.
• Синхронизировались ли по схеме БД? Корни этой проблемы будут тянуться если нет общего хранилища документации (как, впрочем и в предыдущем примере). Каждая программа, использующая, например, локальное хранилище, может с какого-то коммита начать расходиться по схеме от других платформ просто потому что люди увлеклись и забыли уведомить об изменениях других
• Юнит-тесты под каждую платформу. Изменился API??? Это — огромная проблема. Если бизнес-логика покрыта тестами (что в хорошем проекте должно быть), то при изменении API или схемы БД, помимо кода, придется переписывать еще и все связанные юнит-тесты N раз, где N — количество платформ.

У менеджмента проблем не меньше:

• Необходимо координировать венегрет из Java/Objective-C/… разработчиков. Хорошо если менеджер отлично понимает каждую из платформ. А если он до того имел дело только с одной, а разработчики — не опытные? Тогда они смогут вещать лапшу на уши, говоря что некоторые вещи сделать не возможно, например (хотя на самом деле просто лень искать решение). А если заказчик — сам разработчик, то придется каждый раз краснеть за их выходки. 
• Вылетел разработчик? Необходимо найти под ту же платформу. Это не было бы проблемой, если бы не близящийся релиз, например. Если вы используете кросс-платформенный тулсет, то можете двигать разработчиков с других проектов. Как минимум, язык программирования будет им знаком. А это — большая помощь.
• Заказчик платит за один и тот же код много раз. Согласитесь, надо иметь огромные навыки продажи снега эскимосам, чтобы протолкнуть одно и тоже для 3-х платформ. «Сколько можно интегрироваться с нашим API? Вы уже это делали два раза!!». И вы молча их понимаете, но продолжаете настаивать на своем.
• Изменилось внешнее API? Тут менеджмент нервно ерзает в кресле, поскольку только что заплатили за три платформы, а начиная с сегодня надо переписать все, к чему относятся изменения.
• Fix-price добавляет боли, поскольку надо очень точко эстимировать под каждую платформу. А если при этом менеджер не варит в каких-то платформах, возникает проблема: придется понадеяться на оценки программистов, которые оценивать не умеют. «Вася, ты точно умножил на Пи?».
• Заказчик попросил все тоже самое, только под еще одну платформу. И, снова весь ворох проблем выше.

Что бы решило перечисленные проблемы? Их бы решило если бы все люди использовали бы единую платформу и максимально единый код. Тогда все изменения вносились бы только один раз, и ошибки исправлялись бы только один раз. И если вы пройдетесь по пунктам выше, то поймете что такой подход сократил бы практически все из них.

Вторая группа проблем — инструменты разработки

Что ни говори, а разработку определяют инструменты. Ведь если они удобные и позволяют быстро рефакторить, упрощают ввод рутинного текста, автодополняют ввод, помогая работать в неизвестном API, то код становится качественнее и боле быстро написан, а значит — дешевле. Понимание этого приводит к мысли использовать лучшие средства разработки, которые есть на рынке, не жадничая на покупке лицензий. Зачастую имеено отсутствие грамотной IDE не позволяет программистам сделать выбор в сторону нового игрока на рынке инструментов для разработки. IDE — страшная? Не работает переход к определению символа? Ваша IDE не станет популярной. Согласитесь: переход на кросс-платформенную разработку означает что API вы скорее всего знать не будете. Причем зачастую там будет абсолютно свое API и его придется учить. Если IDE при этом не дает поддержки документации к коду и путем вывода в тултипах документации при наведении на методы и классы, становится совсем тяжко и начинаешь испытывать ненависть, поскольку любое обращение в Интернет — потеря времени и выход из потока сознания.

Третья группа проблем — различия в GUI платформ

Эта группа — группа не решаемых проблем. Вернее, их можно решить, сделав единый GUI для всех платформ, однако ни одному пользователю такое решение не понравится: оно будет не удобным и не привычным. Я слышал что эту проблему попытались решить в Delphi, однако продукт достаточно новый и я его не трогал: сказать ничего не могу. Так какие отличия делают решение проблем таким трудно выполнимым?

• Работа клавиатурой и мышью против касания пальцами по маленьким (физически) экранам.
• Устойчивый, постоянный интернет против редко включенного интернета, который временами пропадает.
• Расширяемое железо против медленного и ограниченного
• На десктопах приложение открывают на долго. Мобильные — на короткий промежуток времени.
• UI везде различен. Даже если и похож (десктопы), везде — различные горячие клавиши, различные отступы и правила верстки.

Однако давайте попробуем выделить плюсы и минусы обоих подходов:

• Нативный UI
  
  • плюс: привычен пользователю платформы
  • плюс: работает быстро
  • плюс: дает богатые вохможности (есть возможности, присутствующие на одной платформе и отсутствующие на остальных)
  • плюс: привычный UX
  • минус: везде различен.
  
  
• Кросс-платформенный UI
  
  • плюс: делать надо один раз
  • минус: везде выглядит одинаково
  • минус: одинаково не привычен для всех пользователей
  • минус: зачастую это — медленные решение (в силу необходимости унификации, не всегда аппаратной)
  • минус: не используются особенности платформы
  • минус: не привычный UX
  
  

Какие выводы можно подчерпнуть отсюда? Для того чтобы мы могли выпускать продукт не для себя, а для пользователя, нам необходимо иметь тулсет, позволяющий писать UI для каждой платформы в отдельности.

Пробуем выбрать инструмент разработки

Итак, кретерии выбраны:

• Есть отличная IDE, в которой много богатого и необходимого функционала
• Пишется код на одном языке, используя единый SDK
• UI пишется отдельно для каждой из платформ
• Максимальное количество единого кода. Т.е. в нашем случае все что не UI

Категории кросс-платформенных тулов

•  Applications Factories. Генераторы приложений. Мы их рассматривать не будем, тк наша цель — найти богатую на функции платформу, а не урезанную
• Web App Toolkits. Будем просматривать вскользь
• Cross-platform IDE.

Для того чтобы понимать самостоятельно, придется лично воспользоваться огромным числом средств кросс-платформеной разработки, которых сейчас существует около 90 штук (по данным research2guidance). Причем не просто воспользоваться, а написать на каждом из них достаточно сложное приложение и сдать его в магазин приложений. Это достаточно трудоемкий и затратный процесс, поэтому я решил поискать исследования на эту тему. Расследование привело меня на сайты двух организаций: research2guidance и VisionMobile.

Рассмотрим, пожалуй, не всю статистику, а только ту, где говорится о компании Xamarin, поскольку полная статистика занимает 40 страниц и обширна как для чтения так и для понимания. Полную статистику сможет прочитать каждый, а вот лично мои выводы — ниже и коротко.

Узнаваемость

Достаточно важный фактор как для разработчика так и для заказчика — узнаваемость того, что будет использоваться. Для разработчика узнаваемость важна поскольку при поиске работы легче вступить в дискуссию с работодателем, да на резюме смотреть чаще будут. А для заказчика узнаваемость тулсета важна, поскольку при выборе подрядчика скурпулезный заказчик будет искать знакомые буквы в услугах компании. Если при этом он не поленился поискать в Интернете что сейчас используется, то если вы назовете в качестве используемых инструментов что-то из набора столбцов слева, это повысит шансы на начало сотрудничества. Как вы видите, самыми узнаваемыми сейчас являются Adobe Air, Phone Gap, Xamarin, jQuery Mobile, Unity и Titanium. Среди этих платформ Adobe стоит особняком. Возможно, это связанно прежде с известностью самой фирмы Adobe. Однако полный спектр платформ покрывает только она, Xamarin и Unity 3D. Причем Unity же — игровая платформа и не заточена под обычные приложения. И для игр — она — номер один. Однако для бизнес-приложений выбор идет таким образом: Если выбираем Web frameworks, надо смотреть более детально. Если же cross-platform IDE, то в данной категории выигрывает Ксамарин.

© research2guidance

Уже используют в разработке

Вторая немаловажная статистика: сколько человек уже используют в разработке тулсет.

© research2guidance

Однако, напомню что эта диаграмма крайне не благодарно относится к новичкам. Например, Delphi XE3, которая вышла за несколько месяцев до того как провели это исследование. Чудо что она вообще сюда попала. Однако, вернусь к фаворитам и добавлю дату первого релиза для каждой из платформ:

1. PhoneGap – 2005 (~31%)
2. Adobe Air – 2008 (~17%)
3. Unity 3D – 2008 (iPhone/iPad) — (~13%)
4. Titanium – 2008 (~13%)
5. jQuery Mobile – 2010 (~28%)
6. Sencha – 2010 (~12%)
7. Marmelade – 2011 (~12%)
8. Xamarin — 2011 (~12%)
9. Qt Creator – 2012 (не mobile) (~14%)

C QT Creator лично у меня возникли вопросы: он не отрелизился для мобильных платформ и, возможно, в отчете закралась ошибка. Однако если посмотреть на индекс роста и текущей популярности, я выделю следующих фаворитов:

1. jQuery (почти столько же за 3 года, сколько PhoneGap за 8 лет)
2. Marmelade и Xamarin (уверенный рост за 2 года)

Но вспомнив наши кретерии, понимаем что ни jQuery ни Marmelade нам не подходят. Ни первая ни вторая не дают доступа к платформенным фичам, что для нас — важно. И в этой категории остается Xamarin.

Производительность при разработке

© research2guidance

Эта диаграмма говорит, насколько разработка на том или ином средства разработки ускоряет процесс разработки и тестирования, вплоть до сдачи в маркет. Из диаграммы можно сделать выводы, что самыми быстрыми в разработке тулсетами являются Unity 3D и Xamarin, а самыми проигрышными — Marmelade и Titanium. Причем, заметьте, что оба фаворита основаны на одной и той же технологии.

Ну и последняя диаграмма: если я до сих пор не сагитировал использовать cross-platform tools

© by research2guidance

По вертикальной оси отложено процентное количество опрошенных людей, а по горизонтальной — их ответ на вопрос: насколько ускорила/замедлила кросс-платформенная разработка ваше время? Соответственно большая часть ответила что ускорила и меньшая — что замедлила.

 О платформе Xamarin

Итак начнем. Если копнуть немного истории, то мы выясним, что платформа компании Ксамарин, о которой я веду речь, далеко не новая. Она достаточно древняя и берет свои корни с кроссплатформенной реализации .Net Framework от компании Microsoft. Реализация эта называется mono runtime и содержит она практически все из мира .Net за исключением библиотек графического вывода (они есть, но сделаны не полностью). Однако этот минус с легкостью компенсируется огромным плюсом: на десктопах она работает везде. На Windows, Linux и на Mac OS и при этом прекрасно  отлажена.

Поскольку платформа распространяется с исходниками, и является бесплатной, денег с нее никаких разработчики не имели и однажды решили начать ее монитезировать при помощи мобильных приложений. Ведь если посравнивать, то получится что для десктопа не так много поводов искать заказы на разработку кроссплатформенных приложений. А вот для мобильных устройств заказов сделать приложение под часть платформ или под все платформы намного больше. Причем есть убрать из .Net Framework все что относится к UI, получится богатейшая инфраструктура с превосходной архитектурой, отлаженном кодом и прекрасной поддержкой среди уже существующих IDE.

Основная проблема — пробросить платформенный API для каждой платформы.

Для Java поднимается своя виртуальная машина, поскольку Джавовская не устраивает по нескольким параметрам, среди которых — не честные дженерики (о которых — позже), а в iOS используется трансляция готовых сборок, полученных из C#, в Obj-C. Что мы имеем на выходе?

• Огромное количество языков программирования, на которых можно писать кроссплатформенные приложения. Среди них C#, VB.NET, Boo, Nemerle, JavaScript.

  
  

• Богатейшую инфраструктуру .Net Framework, и неимоверное количество библиотек, уже написанных под .Net и ожидающие вас в репозиториях github, codeplex, и прочих, прочих, прочих

  
  

• Возможность использовать любые уже существующие библиотеки с android и ios;

  
  

• Широчайшее сообщество самого популярного на данный момент языка программирования — C# не оставит ваши вопросы неотвеченными.

  
  

• Стабильную команду разработчика, влюбленных в свой продукт, и быстрорастущее комьюнити (на данный момент около 500 000 регистраций и это количество не думает останавливаться)

  
  

• Сокращение штата программистов и возможность брать на работу программистов с других платформ. Например, Windows программистов, знакомых с C#.

  
  

• Сокращение стоимости разработки конечного продукта и, соответственно, более заинтересованных заказчиков.

  
  

Я вижу перед собой непаханное поле для компаний-разработчиков и фрилансеров. Я ведь сам пришел с разработки под Windows и считаю эту платформу прекрасным тулсетом для быстрого старта. Придя в компанию Touch Instinct чуть больше чем пол-года назад, сегодня я могу писать под под любую платформу.

Почему стоит учить C#?

Статистики, опубликовавшие индекс популярности языков программирования за 2012 год назвали C# языком года. Они подсчитали что популярность C# выросла аж на 2.3%,  что стало самой большой цифрой из всех языков, находящихся в индексе. Конечно же свою роль сыграло и то, что Microsoft запустила Windows 8, где C# является основным языком программирования. Но на самом деле все обстоит несколько иначе. Нэт Фридман, сооснователь компании Xamarin, выделил в своем посте 8 причин, по которым C# является лучшим языком программирования для мобильных платформ:

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

   
   

2. Богатые возможности — объектно-ориентированное программирование и инкапсуляция позволяют очень легко структурировать код под максимальное переиспользование. А такие возможности как Рефлексия и Иньекция зависимотей предоставляют поистине богатые возможности для расширяемости и гибкости приложений;

   
   

3. Продвинутый Runtime. Garbage collection очень упрощает разработку, снимая с плеч разработчика бремя управления памятью приложения. Разработчики могут фокусироваться на решении алгоритмических и прочих задач, вместо того чтобы бороться с указателями и контролировать утечки памяти;

   
   

4. Как в языке со строгой типизацией, C# делает большинство проверок на приведение типов во время компиляции, что уменьшает количество досадных ошибок и тем самым ускоряет разработку.

   
   

5. Легко адаптироваться. C# — очень простой язык и к нему очень легко привыкнуть. Но если вы привыкли, отвыкнуть от него будет очень сложно, поверьте мне. А если к этом прибавить безумное количество материала, которое лежит ну просто везде, это дает гарантию любому начинающему разработчику, что он никогда не застрянет на одном месте.

   
   

6. Быстрое исполнение. C# на iOS использует оптимизирующий компилятор LLVM, который используется языками C и C++, на которых основана операционная система, что дает вам самое лучшее из обоих миров: высокую продуктивность программирования на C# и высокую эффективность низкоуровневых языков программирования. На Андроиде дела обстоят ничуть не хуже: C# отрабатывает даже лучше чем Java. Что можно объяснить  несколькими путями: C# поддерживает Value Types, настоящие, в отличии от Java, generics, и не виртуальные по умолчанию, методы. Также, конечно, это можно объяснить что Dalvik — более молодой чем проверенный и более выверенный Mono Runtime.

   
   

7. Доступ к платформенным функциям дает возможность использовать не только функции операционной системы, но и сторонние библиотеки, изначально написанные под конкретную платформу, пополняя арсенал поддерживаемых, годами наработанных библиотек.

   
   

8. И самая главная причина: возможность спортировать приложение на различные плотформы. Если вы пишите на платформе mono, то включая все поддерживаемые платформы, можете охватить своим приложением аудиторию в 2,2 миллиарда устройств во всем мире. Только вдумайтесь в эту цифру. Одна только эта цифра заставит любого хотя бы попробовать эту платформу в разработке.

   
   

И потом, когда заказчик приходит к вам в офис, он хочет заказать не приложение под Андроид, например… Или под айФон. Заказчик прежде всего хочет мобильное приложение. Чтобы его приложение стояло на максимальном количестве устройств. И если вы находитесь на данной платформе, это позволяет вам говорить о снижении затрат на разработку. Ведь вы не только сокращаете саму разработку. Но и выправку ошибок. Код бизнес-логики будет исправляться и на Андроиде, и на iOS, и на Windows Phone. Да, необходимо разработать все что относится к UI заново на каждой из платформ. Но весь остальной код будет общим, без изменений. Работа с базой данных, игровая логика, да все что угодно.

Минусы

Среди такого разнообразия плюсов было бы не честным не рассказать о некоторых минусах. Тут, я думаю, те из вас кто начинает засыпать, резко приосанились в краслах. Ну наконец-то, мол, дошли. Как и у любой разработки такого масштаба, минусы, естественно, имеются.

• Xamarin Studio — прекрасная IDE,  но иногда бывают проблемы с отладчиком. Проблемы имеются, о них все знают, и я надеюсь, это приоритет номер один в ближайшее время, тк иногда отваливающися отладчик делает жизнь немного более печальной чем хотелось бы

  
  

• Надо настраивать bindings к платформенным библиотекам. Если вы хотите использовать некую скомпилированную, нативную библиотеку, то придется немного помучаться, построив binding. Облегчающий жизнь тулсет есть, но не всегда срабатывает как хотелось бы: иной раз приходится допиливать ручками

  
  

• Придется подзапариться с очисткой памяти. Дело в том что поскольку мы работаем не вместо, а вместе с Java/Obj-C, то в Java, например, работает два Garbage Collector’a. Только не пугайтесь! Не уходите из зала! Все отлично, они прекрасно уживаются. Но для того чтобы освободить объекты в обоих, необходимо провести дополнительное действие — освободить ссылку. Чем-то это похоже на C++. Но что же поделать. Ничего не поделать.

  
  

Однако эти минусы с лихвой компенсируются той легкостью и наслаждением разработки поистине кроссплатформенного кода, где выделив общую логику приложения в отдельую библиотеку и заюзав, например, MVVM, можно сделать платформенно-зависимым только UI приложения. И тем самым сократить время разработки кода для конечной платформы до 80%. Это огромный процент.

Юзкейсы

• Как вы все, может быть, знаете, чтобы программировать под iOS необходимо иметь Маки. Это некоторе финансовое ограничение, которое может вас расстроить, если вы идете с платформы Windows. Однако не стоит печалиться. Если у вас уже есть лицензии на Visual Studio, есть любимый всеми нами, продукт компании JetBrains, ReSharper и прочие прелести платформы Windows, вы можете поставить всего один Мак Мини или любой другой мак и использовать его в качестве билд-сервера, разрабатывая при этом в Visual Studio.

  
  
• Если же денег на столь не дешевый инструмент как Visual Studio у вас нет, у компании Xamarin есть решение и на это. Для вас абсолютно бесплатно поставляется IDE Xamarin Studio, которая является MonoDevelop 4.0 версии и содежащая огромное количество рефакторингов и прочих удобных плюшек, коотрые необходимы в разработке.
  
• Также вы можете разрабатывать под Маком, используя Xamarin Studio. Вся наша компания так и делает. Windows мы используем только для WinPhone приложений.