Кроссплатформенность

Но моя вики выглядит сносно на моём телефонеПравить

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

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

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

Смарт-часы

Что выбрать

У вас уже наверняка пошла голова кругом, а понимания что выбрать, так и не появилось. Давайте представим простой список вопросов, который вам поможет:

• должно хоть как-то работать на любом устройстве? Выбирайте HTML как основу;
• у вас достаточно средств, нет спешки и вы хотите самое качественное приложение?
  Вам прямой путь в нативную разработку;
• у вас есть «встроенный» веб-разработчик или вы просто хотите быстро и просто попробовать мобильное приложение в деле?
  Тут можно рекомендовать Cordova/HTML или PWA;
• у вас есть собственная CRM-система и поддерживающий ее C#-разработчик? Берите Xamarin;
• вы «хотите попробовать», но надо сделать всё красиво и модно?
  Смотрите в сторону React Native или Flutter.

Можно зайти и с другой стороны. Посмотрите на функциональность, которая вам потребуется в приложении, и исходите из этого:

• простое приложение-визитка?
  Возьмите React Native или HTML5 и вы получите две платформы за минимальную цену;
• у вас есть сайт с большой посещаемостью и вам нужно протестировать гипотезу присутствия в мобильном пространстве?
  HTML5;
• сложные приложения с доступом к нужным функциям устройств?
  Нативная разработка, Xamarin, React Native.

React Native

Инструмент от Facebook. Его цель — сделать кроссплатформенные приложения такими же производительными, как нативные.

Кто использует

React Native достаточно популярен, поскольку его уже применяют технологические гиганты. Среди них Instagram, Facebook, Walmart, Tesla, Pinterest, UberEats и другие.

IDE и написание кода

С момента запуска React Native прошло около 5 лет, поэтому его поддерживают почти все ведущие IDE. Изучать React Native и писать код на нём довольно просто благодаря использованию JavaScript (разумеется, если вы знаете JavaScript).

Архитектура и исполнение кода

«Learn once, write anywhere», что можно трактовать как «научись один раз, используй везде» — главный принцип React Native, который подразумевает применение одного и того же кода для разных платформ. Также в Native есть функция Hot Reloading, позволяющая добавлять новый код и вносить правки прямо во время выполнения — это очень полезно, когда вы настраиваете пользовательский интерфейс. Среда поставляется с большим набором готовых компонентов, однако они не всегда адаптируются под разные платформы, что требует дополнительных корректировок в коде. Благодаря обширной поддержке сообщества также есть богатый выбор сторонних библиотек.

Производительность

Так как React Native нацелен на результат, сопоставимый с нативной разработкой, в погоне за производительностью чаще всего отдают предпочтение именно этому фреймворку. Native также позволяет разработчикам использовать кастомные модули на языках для нативной разработки, но их придётся писать отдельно для каждой платформы.

***

Нужна ли мне кроссплатформенная разработка

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

Также рекомендуем выбирать кроссплатформенное приложение в следующих ситуациях:

• Когда нужно, чтобы приложение выглядело одинаково на разных платформах. Навигация между экранами, поле поиска, системный календарь на iOS и Android выглядят по-разному, но кроссплатформенные решения позволяют вам взять лучшее от обеих ОС и реализовать единый вариант дизайна.
• Когда разрабатываемое приложение для своей работы не требует задействования всех вычислительных ресурсов устройства. В целом, кроссплатформенные технологии позволяют реализовывать практически любые виды приложений, однако есть исключения. Например, игры или приложения с дополненной реальностью, которые сильно загружают процессор и оперативную память (иначе говоря — «требовательны к производительности»).
• Когда приложение ориентировано на «card material design», который сегодня довольно популярен. То, что на Android является тривиальной задачей, для iOS-разработчиков становится настоящей головной болью. Они тратят значительно больше времени на разработку интерфейса. С кроссплатформенными технологиями (в частности, с Flutter) разработчики «из коробки» (то есть им не нужно дополнительно устанавливать библиотеки и что-то настраивать) имеют доступ ко всем нативным UI-компонентам обеих платформ, благодаря чему работа ускоряется в разы.

I. Кроссплатформенность ERP-систем: что это такое

Следуя Декарту, сначала договоримся о значении слов.

В нашем понимании, кросс-платформенность — способность одинаково работать на различном оборудовании под управлением различных операционных систем: Linux, Mac osX, Windows, Windows Phone, QNx etc.
Естественно, здесь предполагается что конечный пользователь работает в приложении, родном для использующейся операционной системы — без эмуляторов, виртуализаторов etc.

Если же речь идет о работе через веб-приложение (когда пользователи получают функционал через браузер), то правильно говорить о кросс-браузерности.
То есть, одно и то же web-приложение одинаково работает в различных браузерах (Internet Explorer, Safari, Chrome, Firefox etc) на различных устройствах (планшеты, смартфоны, ноутбуки…)

Миф 3. Костыль на костыле

Здесь стоит понимать, что нативные API по умолчанию костылями не считаются (хотя и здесь есть разные мнения), поэтому все негодование направлено на кросс-платформенную часть. Очевидно, что исполняющую среду (например, WebView, JavaScript-движок или Mono) костылем тоже назвать сложно — взрослые зрелые решения с длительной историей.

Похоже, что костылем называют то, как кросс-платформенная часть интегрируется с нативной. Чтобы лучше понять, как работают различные фреймворки, мы на примере PhoneGap, Xamarin, Qt и React Native рассмотрим те механизмы операционных систем, которые используются для связывания кросс-платформенной и «нативной» частей.

Начнем мы с PhoneGap. Ниже представлена верхнеуровневая архитектура приложения на базе этого фреймворка.

Приложение на PhoneGap — это по факту нативное приложение, которое в качестве единственного UI-контрола отображает WebView. Именно через него и идет взаимодействие с нативной частью. Все стандартные WebView в iOS, Android и Windows UWP поддерживают возможность добавить свои нативные обработчики для JS-свойств и методов. При этом JS-код живет в своей изолированной среде и ничего не знает о нативной части — просто дергает нужные JS-методы или меняет нужные JS-свойства. Все внутри стандартного вебовского DOM, в который просто добавляются новые элементы, связанные с нативной реализацией.

Далее рассмотрим React Native.

При создании приложений на React Native разработчику практически всегда будет необходимо реализовывать нативную часть на Objective-C, Java или C#, а само управление нативным приложением будет идти из JavaScript. По факту JavaScript-движок — это элемент WebView, который доступен отдельно. Взаимодействие идет через такой же JS-мост, как и в случае с PhoneGap. Однако в React Native JS-код управляет не вебовским DOM-деревом, а нативным приложением.

Необходимо учитывать, что из-за ограничений iOS (нет возможности реализовать JIT) код JavaScript на лету интерпретируется, а не компилируется. В целом это не особо сказывается на производительности в реальных приложениях, но помнить об этом стоит.

Теперь рассмотрим классический Xamarin.iOS и Xamarin.Android, так как Xamarin.Forms (поддерживающий Windows UWP) — это надстройка над ними.

Xamarin использует библиотеку Mono для взаимодействия с целевой операционной системой, которая позволяет вызывать нативный код с помощью механизма P/Invoke. Он же задействуется и для общения с нативными API в iOS/Android. То есть для всех публичных нативных API-методов создаются обертки на C#, которые, в свою очередь, вызывают системные API. Таким образом, из Xamarin-приложения можно обращаться ко всем системным API.

И в завершение рассмотрим Qt, так как о нем появляется много вопросов от опытных разработчиков.

Qt — «вещь в себе», в этом есть и плюсы, и ограничения. Библиотеки Qt просто подключаются к системным API на C++, которые есть во всех операционных системах. Для отрисовки пользовательского интерфейса используются механизмы низкого уровня, но свой графический движок, поддерживающий стилизации «под нативку». При этом на Android приходится обращаться к Java API через специальный мост (JNI bridge), а для Windows UWP использовать конвертер вызовов Open GL ES в DirectX, так как Open GL недоступен для UWP.

Подведем итог: все кросс-платформенные фреймворки используют стандартные нативные возможности операционных систем, являются зрелыми, создаются опытными командами и сообществом open source при поддержке гигантов IT-индустрии. И наконец, пришло время для самого «сильного» аргумента.

Xamarin

Xamarin — платформа для создания мобильных приложений от Microsoft, которая также поддерживает разработку для Windows.

IDE и написание кода

В качестве IDE можно использовать, например, Visual Studio 2019 или Rider. C# достаточно распространён, поэтому с написанием кода и освоением Xamarin проблем возникать не должно.

Архитектура и исполнение кода

У Xamarin есть два основных инструмента: Xamarin.Android/iOS и Xamarin.Forms. По части кроссплатформенной разработки Xamarin предлагает использовать единый API Xamarin.Essentials.

Frontend Developer (React.js/ Electron.js)

Xsolla, удалённо

tproger.ru

Вакансии на tproger.ru

Xamarin.Android и Xamarin.iOS наделяют приложение теми же возможностями и интерфейсом, которые есть у нативных решений. В случае Xamarin.iOS программа компилируется непосредственно в машинный код (AOT-компиляция), тогда как в Xamarin.Android сначала происходит компиляция в байт-код, который затем интерпретируется виртуальной машиной (JIT-компиляция).

Если же нужно ускорить процесс написания кода, лучше использовать Xamarin.Forms — более простой инструмент, в котором почти все элементы полностью совместимы с любыми платформами.

Производительность

Производительность Xamarin также считается близкой к нативной, но зависит от того, используете вы Xamarin.Android, Xamarin.iOS или Xamarin.Forms. У Xamarin.Android/iOS хорошая оптимизация благодаря нативным компонентам. Xamarin.Forms же основан на 100% совместном использовании кода, что в целом снижает его производительность по сравнению с Xamarin.Android/iOS.

***

Основные сведения Править

Главная страница: Справка: Инфобоксы

На странице статьи вы можете использовать модульный инфобокс так же, как и классический:

{{Инфобокс персонаж
 | название         = Маргаритка
 | изображение      = Пример.jpg
 | подпись          = Маргаритка в саду
 | класс            = Садовый цветок
 | возраст          = 2 месяца
 | статус           = Жива
 | рост             = 5 дюймов
 | вес              = 20 граммов
}}

Запрашиваемый шаблон (в нашем случае Шаблон:Инфобокс персонаж) использует модульную разметку, которая выглядит так:

<infobox>
     <title source="название" />
     <image source="изображение">
         <caption source="подпись" />
     </image>
     <data source="класс" />
     <data source="возраст" />
     <data source="статус" />
     <data source="рост" />
     <data source="вес" />
</infobox>

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

<infobox>
     <title source="название">
        <default>{{PAGENAME}}</default>
     </title>
     <image source="изображение">
        <caption source="подпись" />
     </image>
     <data source="Класс">
        <label>Класс</label>
     </data>
     <data source="возраст">
        <label>Возраст</label>
     </data>
     <data source="статус">
        <label>Статус</label>
     </data>
     <data source="рост">
        <label>Рост</label>
        <format>{{{рост}}} дюймов</format>
     </data>
     <data source="вес">
        <label>Вес</label>
        <format>{{{вес}}} граммов</format>
     </data>
</infobox>

Кроссплатформенная разработка

Современные подходы к разработке софта в этой области можно описать так:

1. Единое стилистическое решение. В этом случае программа должна выглядеть одинаково под всеми операционными системами. К положительным сторонам этого подхода относят «жесткое» закрепление элементов управления, а к отрицательным – отличие стиля программы от общего стиля ОС.

2. Адаптивный интерфейс. Подразумевается, что программа, построенная по такому принципу, должна легко вписаться в интерфейс операционной системы за счет изменения тем оформления. Предполагается полное или частично автоматическое определение языковых параметров и оптимальных размеров экрана, под которые должно подстроиться программное обеспечение. Положительные стороны – относительно свободная интеграция под стиль ОС. Недостаток — сложность и, соответственно, высокая стоимость разработки.

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

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

Время приложений

Статья была впервые опубликована здесь.

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

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

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

Эта статья призвана рассказать о двух подходах к разработке приложений — нативном и кроссплатформенном.

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

Зачем нужны кросс-платформенные инструменты?

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

Нативные инструменты = предоставляются владельцем экосистемы.

Все остальные признаки «нативности» ВТОРИЧНЫ — поведение и интерфейс приложений, доступ к возможностям ОС, производительность и прочее.

К тому же практически всегда оказывалось, что нативные инструменты несовместимы друг с другом не только на уровне языков разработки, принятых соглашений и архитектур, но и на уровне механизмов работы с операционной системой и библиотеками. В результате для реализации одних и тех же алгоритмов и интерфейсов требовалось написать приложение для нескольких сред на разных языках программирования, а потом его поддерживать из расчета «одна команда на платформу». При этом возможности и внешний вид приложений на разных платформах практически всегда идентичны на 90%. Сравни ради интереса реализацию любимых программ для iOS и Android.

Второй важный момент — наличие необходимых знаний и опыта внутри команды: если их нет, то потребуется время на обучение.

Для того чтобы решить обе эти проблемы, на рынке уже давно появились инструменты кросс-платформенной разработки (не только mobile), предлагающие:

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

Так как языков программирования (и сред) сейчас наплодилось очень много (и специалистов, владеющих этими языками), то и инструментов для кросс-платформенной разработки существует изрядное количество. Мы в качестве примера остановимся на популярных в наших краях PhoneGap, Xamarin, React Native и Qt.

Теперь можно поговорить и о мифах.

CSSПравить

Оформление целой строкиПравить

Тогда как вы можете применить инлайновые стили к некоторым элементам инфобокса, этого будет недостаточно для того, чтобы поменять настройки целой строки и её заголовка одновременно — например, изменить цвет фона всей строки. Каждая строка с тегом состоит из его значений (и его , если есть) внутри тегов , находящихся внутри других тегов . Чтобы заполнить каждую строку желаемым цветом, вам нужно сосредоточиться на самом внешнем теге . Для этого вам потребуется найти нужный .

Читайте код вашего инфобокса сверху вниз и считайте каждый тег , пока не дойдёте до того, чью строку вы хотите настроить. Не засчитывайте теги , или , так как они не содержатся в элементах . Для примера возьмём инфобокс с тегами , и тремя тегами : Возраст, Пол и Город.

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

Если вы уже знаете номер нужного при счёте сверху, вы можете использовать следующий код, заменив 1 в вашим номером (в нашем примере это 1 для Возраста, 2 для Пола, 3 для Города).

.pi-theme-name div:nth-of-type(1) {
    background-color: #000000;
}

Код вверху выберет целую первую строку (Возраст) вместе с заголовком. Чтобы затронуть только , содержащий нужное значение, используйте:

.pi-theme-name div:nth-of-type(1) div:first-of-type {
    background-color: #000000;
}

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

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

Как работать с необязательными полямиПравить

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

1. Расположите нужную вам строку ближе к концу или даже в самом конце вашего инфобокса. Если вы не знаете количество предшествующих строк, но знаете, сколько строк будет после, вы можете посчитать снизу вверх. Для этого используйте вместо . В нашем примере, эта функция выберет самым первым выберет строку Город.
2. В зависимости от вашего кода, вы можете попробовать использовать тег для тех записей, которые сложно указать точно. Поскольку этот тег использует HTML-элементы вместо элементов , вы можете считать их отдельно и, возможно, определить их позиции вне зависимости от необязательного контента, если только вы не используете сразу несколько , которые могут не отображаться. Просто выберите их с помощью или по ситуации.

Миф 2. Ненативно!

Итак, у нас есть кросс-платформенная часть приложения, живущая в виртуальном окружении и взаимодействующая с операционной системой через инфраструктуру фреймворка и мост.

• WebView (встроенный в приложение веб-браузер) используется в гибридных приложениях на базе PhoneGap и фактически выступает средой выполнения локального веб-сайта;
• JavaScript-движки используются в React Native и аналогах для быстрого выполнения JS-кода и обмена данными между Native и JS;
• OpenGL ES (или DirectX) используется в игровых движках и приложениях на Qt/QML или аналогах для отрисовки интерфейса;
• UI-подсистема отвечает за нативный пользовательский интерфейс приложения, что актуально для React Native и Xamarin.

Кросс-платформенные приложения имеют нативную часть и такой же полный доступ к системным API, что и «нативные» приложения. Разница в том, что вызов системного метода идет через мост и инфраструктуру фреймворка:

WebView — приложение живет в своем веб-браузере по аналогии с одностраничным веб-сайтом. Нет доступа к нативным контролам (кнопки, списки и прочее), все основано на HTML/CSS/JavaScript. С другой стороны, веб-разработчик почувствует себя как рыба в воде.

JavaScript-движки стали популярны относительно недавно, так как в iOS подобный механизм был добавлен только в версии 7.0. Из особенностей стоит учитывать необходимость сериализации в JSON сложных структур данных, передаваемых между средами JavaScript и Native. Если коротко описать подобный класс решений, то в JavaScript-среде выполняется JS-код, управляющий нативным приложением.

OpenGL ES и DirectX являются подсистемами низкого уровня и используются для отрисовки пользовательского интерфейса в играх и, например, Qt/QML. То есть при использовании OpenGL/DirectX разработчики сами рисуют контролы и анимации, которые могут быть лишь похожи на нативные. С другой стороны, это подсистема низкого уровня с очень высокой производительностью, поэтому она используется и в кросс-платформенных игровых движках.

Все кросс-платформенные приложения имеют нативную часть, а следовательно, потенциально такой же полный доступ к системным API, что и «нативные». Также кросс-платформенные приложения собираются и упаковываются «нативными» инструментами в «нативные» установочные пакеты. Ключевой вопрос — как организовано взаимодействие между кросс-платформенной частью и нативной. Например, внутри WebView или с помощью Open GL ES / DirectX нет возможности создать пользовательский интерфейс с полностью нативным look’n’feel, но при этом есть полный доступ к GPS, Push-уведомлениям и другой функциональности. А код на JavaScript или C# вполне свободно может управлять нативным приложением и его поведением, обеспечивая полностью нативный look’n’feel.

Если резюмировать — то да, «ненативно» с точки зрения используемых инструментов разработки (не от Apple, Google). Но приложение может быть полностью нативным с точки зрения доступа к системным API и обеспечивать полностью нативный внешний вид и поведение. А мы движемся к следующему мифу.