Проектирование кросс-платформенной архитектуры современного приложения

Создаете вы проект с нуля или модифицируете существующее решение, важно знать ландшафт современных приложений. Это означает, что нужно понимать, какие устройства, операционные системы и браузеры актуальны и требуют внимания. Под устройствами подразумеваются не только смартфоны — к ним относятся планшеты и ПК с большими экранами. Однако продажи смартфонов до сих пор превышают продажи устройств любых других типов. Некоторые разработчики могут включать в свои кросс-платформенные архитектуры даже портативную электронику.

Из всего этого следует, что в наши дни писать программное обеспечение приходится с расчетом на множество типов устройств. Главная цель — сделать общим для разных платформ как можно больше кода, чтобы в последующем писать минимум дополнительного кода. Это поможет вам быстрее выходить на рынок со своими приложениями или отправлять их заказчику. Кроме того, это уменьшает вероятность ошибок, вызванных переписыванием одной и той же логики на разных языках.

Кросс-платформенная разработка для устройств

Подход к кросс-платформенной разработке будет зависеть от типа ПО, которое у вас уже есть. Если вы располагаете веб-сайтом, контент которого вы хотите сделать общим, то лучшим может оказаться гибридное решение. Если это зрелый сайт, вы могли бы преобразовать его в сайт с поддержкой адаптивного дизайна и мобильных устройств. Или напрочь отказаться от мобильного сайта и просто предоставлять веб-сайт и отдельные сопутствующие «родные» для конкретных устройств приложения. Другой фактор, который нужно учитывать, — является данное приложение просто еще одним способом представления контента сайта или оно может быть работать независимо.

Сначала создайте мобильный сайт, а потом создавайте «родные» для конкретных устройств приложения. Пока вы разрабатываете такие приложения и охватываете все платформы, мобильный сайт может действовать как приложение. Тем, у когда сайты уже работают, может понадобиться преобразование контента в «родные» для устройств форматы, чтобы он был доступен на каждом устройстве. Действуя таким образом, вы можете продолжать расширять базу своих мобильных пользователей, параллельно разрабатывая «родные» приложения. Когда вы будете готовы к написанию таких приложений, вам может понадобиться помощь в выборе языка, поэтому обязательно прочитайте мою статью в номере за сентябрь 2013 года «Understanding Your Language Choices for Developing Modern Apps» (msdn.microsoft.com/magazine/dn385713).

Несмотря на популярную точку зрения, что приступать к разработке следует на самой крупной платформе или той, на которой продается наибольшее число устройств, иногда более эффективное бизнес-решение — начать с платформы, функциональность которой соответствует вашим требованиям. Например, фитнес-приложение, которое ведет журнал потребляемых и расходуемых вами калорий, может предъявлять требование показывать сводку ваших приемов пищи и упражнений — хорошим примером такого приложения на платформе Windows Phone является myFitnessPal. Данные такого рода отлично подходят для отображения на активной плитке, доступной лишь на платформе Windows.

Вы можете выяснить, соответствует ли платформа вашим требованиям, перечислив все основные функции своего приложения. Проанализируйте каждую из них и проверьте, поддерживается ли она на конкретной платформе, и, если да, то до какой степени. Обнаруженные расхождения с вашими требованиями могут быть связаны с аппаратно-специфичными средствами, например наличием камеры, или средствами ОС, такими как плитки или распознавание речи. Доступные вам архитектурные варианты, рассмотренные «с высоты птичьего полета» позволят вам двинуться в одном из трех направлений: «родные» приложения (native apps), гибридные или мобильные веб-приложения на основе HTML5.

«Родные» приложения В этом случае вы будете на полных парах двигаться в направлении создания отдельного приложения для каждой платформы. Наиболее вероятные платформы — Windows Phone 8, iOS и Android. Для некоторых все еще имеют значение такие платформы, как BlackBerry. Каждое приложение будет в полной мере использовать специфические средства каждой платформы. Производительность «родных» приложений высока, но, конечно, вы должны писать соответствующий код, иначе, если вы недобросовестно отнесетесь к делу, производительность быстро деградирует. Вы должны создать для каждой платформы хотя бы UI «родного» приложения, поэтому данный вариант оказывается самым дорогостоящим.

Гибридные приложения Этот вариант находится где-то в серой области между вариантами с «родными» и веб-приложениями. Гибридные приложения обычно интегрируют контент от существующего веб-сайта в приложение для упаковки и развертывания по стандартам каждой платформы. Данный вариант особенно полезен, чтобы быстро застолбить свою нишу во всех магазинах приложений и присутствовать там, возможно, работая параллельно над полноценным «родным» приложением для данной платформы. Увы, производительность гибридного приложения заметно ниже, чем у «родных» или веб-приложений, поскольку гибридное приложение обычно конструируется обертыванием существующего HTML в контейнер. Например, в Windows Phone это элемент управления WebBrowser. Ну а когда у вас есть какой-то дополнительный уровень, всегда есть потенциальная угроза снижения производительности.

Зато этот вариант ускоряет разработку на «родной» платформе. Создание гибридных приложений требует использования любого из следующих инструментов:

• Apache Cordova/PhoneGap;
• шаблона проекта Windows Phone HTML5 в Visual Studio;
• Telerik AppBuilder (ранее Icenium);
• Xamarin Studio.

Из-за своей природы в гибридных приложениях веб-контент обертывается с помощью элемента управления WebBrowser (продолжая пример с Windows Phone), который является XAML-элементом:

<phone:WebBrowser x:Name="Browser"
HorizontalAlignment="Stretch"
VerticalAlignment="Stretch"
Loaded="Browser_Loaded"
NavigationFailed="Browser_NavigationFailed" />

Это все, что нужно для того, чтобы приступить к разработке гибридного приложения. На других платформах концепции те же, хотя элементы управления могут быть другими. Будьте внимательны, создавая гибридные приложения, так как они могут не получить доступа или привилегий для выполнения операций, которые разрешаются «родным» приложениям. Это связано с защитой от потенциально опасных скриптов из Web, которые иначе были бы выполнены на клиенте. Вот почему у HTML-приложений много ограничений.

Создавая гибридные приложения, можно использовать Telerik AppBuilder или Apache Cordova вместо проектов Visual Studio. Эти сторонние инструменты помогают закрыть пробелы между UI «родных» и гибридных веб-приложений.

Мобильные веб-приложения на основе HTML5 Преимущество этого направления — широчайшие возможности спецификации HTML5. Мобильные веб-сайты могут иметь большой охват, но им не хватает привычного для «родных» приложений внешнего вида — их «духа и буквы». Кроме того, HTML5-приложение может не получить доступа к некоторым аппаратно-специфическим средствам целевой платформы, например к веб-камере или акселерометру.

HTML5 обеспечивает самую низкую стоимость разработки в расчете на каждую платформу, так как вы сможете написать код один раз и выполнять его в большинстве браузеров. Однако некоторые мобильные браузеры не отвечают современным стандартам. Это может стать крупной проблемой при разработке HTML5-приложений. Если «родные» средства важны в вашем проекте, отсутствие доступа в этой области может вынудить вас переключиться на разработку «родных» приложений.

Хотя HTML5 расширяет доступность, учитывайте, что в каком-то смысле разработка для Web аналогична разработке «родных» приложений. Вам действительно потребуется позаботиться о поддержке большого количества браузеров. Как и при разработке для устройств, веб-разработчики ориентируется на браузеры с наибольшим количеством пользователей: Internet Explorer, Chrome, FireFox и Opera.

Вам нужно создавать богатые пользовательские среды на клиентской стороне на различных устройствах, но вы не можете повторно использовать этот специфический для устройства код. Следующие «родные» средства вряд ли будут вести себя согласованно или будут доступны на разных платформах:

• всплывающие уведомления;
• бумажник;
• беспроводная связь ближнего радиуса действия (Near Field Communication, NFC);
• многозадачность/многопоточность;
• синтез и распознавание речи;
• схемы навигации;
• диалоги.

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

Проектирование кросс-платформенных решений

Определить, какие платформы вы будете поддерживать, — это лишь один из шагов. Вы также должны спроектировать решение и принять во внимание такие вещи, как время выхода на рынок и то, для какой платформы следует вести разработку в первую очередь. Как сделать общим максимально возможный объем кода между приложениями — тоже важный фактор.

Веб-сервисы и API на серверной стороне прекрасно работают в кросс-платформенном сценарии, потому что любая платформа поддерживает HTTP. Использование уровней сервисов на серверной стороне означает, что вам нужно лишь раз написать код для этих сервисов.

По мере расширения архитектуры с акцентом на клиент вы захотите, чтобы как можно большая часть кода была общей. Для Windows 8 и Windows Phone вы можете легко этого добиться, используя Portable Class Libraries (PCL), но это оставляет за бортом другие платформы вроде Android и iOS. Вы можете использовать код между платформами Windows 8, Windows Phone, Android и iOS, если будете писать его на C# и применять средства Xamarin для кросс-платформенной компиляции.

Смысл выбора разработки «родных» приложений в том, чтобы пользователи получали привычную им среду на своей платформе. Хотя такие инструменты, как Xamarin, позволят вам повторно использовать часть кода на UI-уровне, наилучшие результаты вы получите, если будете программировать каждый UI отдельно. Обычно это подразумевает модификацию сгенерированного Xamarin кода. И это самый подходящий момент добавить любые специфичные для платформы средства, чтобы пользователи каждой платформы получали требуемую UI-среду.

App Code Layer отображается на контроллер или ViewModel шаблона Model-View-Controller (MVC) или Model-View-ViewModel (MVVM). UI-уровень проецируется на View как в MVC, так и в MVVM. Конечно, Model является представлением данных. Это могут быть JavaScript-классы, которые сопоставляются с объектами базы данных в локальном хранилище или с удаленной схемой в базе данных. Локальные данные — это обычно не то, чем вы обмениваетесь с другими устройствами, так как они зачастую включают аппаратно-зависимую информацию.

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

Лично я предпочитаю платформы Windows 8, Windows RT, Windows Phone и считаю, что они обеспечивают лучшую UX (особенно Windows Phone) для всех доступных устройств. И вовсе не потому, что я работаю в Microsoft. Я думаю, что у iPhone тоже хорошая UX. Но такие средства, как плитки и сверхсовременные камеры Nokia, являются убедительными аргументами за выбор Windows Phone в качестве основной платформы для всех, кому нужна функциональность такого рода в приложениях. Кроме того, Windows Phone полностью интегрирует управление контактами, календарем и другими жизненно важными данными на всех устройствах Windows Phone с соответствующими облачными сервисами.

Заключение

С повсеместным распространением инициативы «использования собственных устройств сотрудников» (bring your own device, BYOD) на рабочих местах по всему миру разработка «родных» приложений стала повседневностью. Как видите, при создании приложений следует учитывать множество изменчивых факторов, которые могут повлиять на ваш успех. Если только вы не работаете на корпорацию, где требуются стандартные настольные клиенты, я не советую вам тратить на них свое время. Во всяком случае, не такое приложение должно быть первым на вашей платформе.

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