Мультиплатформенность и кроссплатформенность чем отличаются
Как сделать сайт кроссплатформенным
Кроссплатформенность веб-страницы – это преимущество которое помогает владельцу сервера конкурировать на рынке. Веб-сайт должен быть читаем на любом устройстве вне зависимости от типа операционной системы.
Что такое кроссплатформенность
Кроссплатформенность – это свойство страницы, позволяющее работать сразу на нескольких видах операционных систем или платформ.
Как страница выглядит для ОС Windows.
На что влияет кроссплатформенность
Потенциальные клиенты и пользователи просматривают страницы на компьютерах, ноутбуках, смартфонах, планшетах. Эти приборы работают на разных платформах.
Кроссплатформенность отвечает за удобство формата страницы для просмотра с любого устройства.
Преимущества и недостатки
К минусам относятся:
Как сделать сайт кроссплатформенным
Существует несколько способов для перехода на кроссплатформенный режим.
Используйте кроссплатформенные языки программирования
Кроссплатформенный язык – это любой современный язык программирования. Например, С, С++, Free Pascal. Они хорошо подстраиваются под платформы и операционные системы.
PHP, Perl, Python, Tcl и Ruby – кроссплатформенные уникальные языки, которые подходят для всех ОС.
Сделайте кроссплатформенный интерфейс
Для решения проблемы по внедрению стандартных элементов сайта на различные платформы нужно сделать кроссплатформенный интерфейс. Используют три метода:
Ведите разработку в специальных средах
Для кроссплатформенности важны стандартизованные библиотеки времени выполнения. Стандартом стала библиотека языка С. Крупные кроссплатформенные программы: Qt, GTK+, FLTK, STL, Boost, GLSL, SDL, OpenAL и другие.
Адаптируйте код
При наличии нескольких версий кода, адаптированных под другие платформы, процесс настройки будет быстрее и проще. Например, браузер Mozilla Firefox имеет наборы иконок под разные ОС.
Сделайте адаптивный веб-дизайн
Адаптация сайта позволит ускорить процесс кроссплатформенности. Она включает в себя настройку интерфейса под любые устройства, независимо от привязки к операционной системе.
Существуют программы по адаптации сайта, которые позволяют сохранить единый стиль и дизайн для сайта на любых устройствах. Интерфейс настраивается в зависимости от ширины экрана. Это повышает конверсию сайта и привлекает новых клиентов.
Как проверить сайт на кроссплатформенность
Существуют специальные тесты, которые показывают как кроссплатформенное программное обеспечение выглядит на различных ОС.
Инструмент Microsoft Expression Web SuperPreview сравнивает выбранные участки страниц в браузерах и операционных системах и показывает различия в отображении элементов анализируемых страниц.
Помимо этого Microsoft Expression Web SuperPreview сравнивает проект сайта с тем, что получилось в процессе разработки. Это позволяет исправить обнаруженные ошибки в верстке.
Заключение
Кроссплатформенность – это важная составляющая функций веб-сайта, которая повышает конверсию страницы и ранжирование в списках поисковых систем. Посетитель будет дольше находиться на сайте с адаптированным и интуитивно понятным интерфейсом.
Нативное будущее кроссплатформенной разработки
Коротко о кроссплатформенности
Сейчас кроссплатформенная разработка не пользуется большой популярностью. Основная причина состоит в том, что существующие инструменты не в полной мере справляются со своей задачей.
Давайте рассмотрим несколько стандартных аргументов в пользу кроссплатформенной разработки: это принцип DRY («не повторяйся»), уменьшение рисков и паритет функциональных возможностей.
«Не повторяйся»
Следуя этому принципу, можно повысить эффективность разработки и снизить ее стоимость. Один раз напишите связный код, который затем можно будет развернуть одновременно и на iOS, и на Android.
Уменьшение рисков
Также кроссплатформенность помогает снизить риски, связанные с разработкой пользовательского интерфейса. Самый большой риск состоит в том, что приложение не будет соответствовать ожиданиям пользователей ни на одной из выбранных платформ, поэтому команды разработчиков часто принимают решение работать отдельно над приложениями для разных платформ. В то же время кроссплатформенные разработчики должны уделять больше внимания логике функционирования приложения и backend-разработке, чем созданию пользовательских интерфейсов, так как именно они определяют, как будут реализованы все функции в приложении.
Паритет функциональных возможностей
Следующий аргумент в пользу кроссплатформенности связан с паритетом функциональных возможностей и инклюзивностью, а именно с меньшими различиями в функциональности приложений на iOS и Android. Преимущество состоит в одинаковом отношении к пользователям обеих платформ, потому что вне зависимости от выбранной ими платформы они пользуются одним и тем же приложением.
Нативная мультиплатформенная разработка
Тем не менее кроссплатформенной разработке не хватает нативного подхода к разработке мультиплатформенных инструментов для работы с ЦП и пользовательским интерфейсом, а также инструментов разработки для iOS и Android. Чтобы кроссплатформенная разработка не стояла на месте, нужно чаще использовать нативный подход. Онпозволяетболее эффективно разрабатывать приложения с одним и тем же функционалом для разных платформ и устройств. Чтобы глубже погрузиться в тему, давайте кратко рассмотрим самые популярные кроссплатформенные решения и их ограничения.
Xamarin
Xamarin — одна из первых платформ для нативной разработки для iOS, Android и Windows, которая объединяет не только логику функционирования приложения, но и пользовательский интерфейс (с помощью Xamarin Forms). Однако у нативных инструментов Xamarin есть три ограничения: они ограничены собственной экосистемой, они используют Microsoft Visual Studio вместо Android Studio или Xcode, а также язык С# (не нативный с точки зрения разработки для iOS и Android).
React Native
React Native (RN) — это мощный кроссплатформенный инструмент, с помощью которого разработчики могут применить свои навыки веб-разработки при создании приложений для iOS и Android. Как и Xamarin, он существует в своей экосистеме. React Native использует нестандартные редакторы и Javascript. При работе с RN нужно обертывать собственные элементы управления, выстраивать иерархию с учетом интеграции и разрабатывать пользовательский интерфейс на его языке.
Flutter
Flutter — новый кроссплатформенный инструмент, с помощью которого можно разрабатывать приложения для iOS и Android, используя язык Dart. Flutter предлагает разнообразные виджеты, которые выглядят нативно на iOS и Android, однако сами виджеты не нативны. Flutter можно использовать для создания единого пользовательского интерфейса, но этот инструмент ограничен только мобильной разработкой и нераспространенным языком Dart.
Мы рассмотрели несколько примеров, которые показывают, насколько сложно использовать кроссплатформенную разработку. По моему мнению, это одна из причин, по которым нужно отказаться от термина «кроссплатформенность». «Мультиплатформенность» — более подходящий термин, потому что для такой разработки важно, чтобы написанный вами код раскрывал потенциал каждой платформы. Лучшего всего для этого подходит Kotlin Multiplatform.
Kotlin Multiplatform
Kotlin Multiplatform — это восходящая звезда мультиплатформенной разработки, более нативный инструмент, чем Xamarin, RN и Flutter. Kotlin — это самый распространенный язык для Android-разработки, который ценят за удобство использования. Работая в Kotlin Multiplatform, разработчик может один раз написать код, один раз его протестировать и затем использовать его в iOS, Android и Web-приложениях.
Это не первое мульплатформенное решение, которое позволяет отдельно работать над логикой функционирования приложения и пользовательским интерфейсом: например, Xamarin используется для логики и библиотек, а Xamarin Forms — для интерфейсов. Тем не менее Kotlin Multiplatform нативнее, чем Xamarin, RN и Flutter, потому что он использует общую логику и библиотеки ниже уровня пользовательского интерфейса, что позволяет работать в нативных средах разработки: Xcode, Swift и Objective-C для iOS; Android Studio и Kotlin для Android; JavaScript для web-приложений. Таким образом, для каждой платформы создается нативный код.
Язык Kotlin помогает разработчикам создавать более связные приложения. Это современный язык, согласованный с нативными платформами на Android, iOS, Java и Web: таким образом, команды могут использовать уже написанный код. Также, благодаря сходству между Kotlin и Swift, некоторые iOS-разработчики уже пишут на Kotlin.
Не менее важно, что Kotlin — это язык настоящего, на котором пишут приложения будущего. Такой код работает на всех платформах без привязки к компании-разработчику, в отличие от Xamarin и React Native. И какая бы платформа не была в будущем самой распространенной, Kotlin подойдет и для мобильной, и для web-среды.
Более того, командам разработчиков больше не нужно разделяться, они могут работать вместе, как единое целое. Унифицированный мобильный подход более эффективен с рабочей, технической, культурной и финансовой точек зрения.
Все указывает на то, что будущее за Kotlin. В мире, где все стремятся работать эффективнее и тратить меньше времени и ресурсов на разработку, Kotlin доказал, что он самый эффективный мультиплатформенный инструмент разработки.
Что такое кроссплатформенность. Объясняем простыми словами
Задача программистов, обеспечивающих кроссплатформенность — написать такой код, чтобы пользователи смогли получить доступ к сервису (сайту, игре и т.д.) с устройств, работающих на любой операционной системе, будь то компьютерные Windows, Linux и MacOS или мобильные Android, iOS и т.д.
Особенно актуальной кроссплатформенность стала в 2010-е годы на фоне резкого роста числа мобильных посетителей интернета.
Кроссплатформенность – это конкурентное преимущество сайта или сервиса. Она повышает конверсию и место в выдаче поисковых систем. Посетитель будет дольше находиться на портале с адаптированным и интуитивно понятным интерфейсом.
Пример употребления на «Секрете»
«Например, в 2010 году нам казалось неплохой идеей использовать для разработки интерфейса своего продукта Microsoft Silverlight. Он обеспечивал кроссплатформенность, но при этом не страдал от недостатков браузерных веб-интерфейсов. Но теперь, когда поддержка Silverlight прекращена, нам пришлось бы полностью переписывать клиентскую часть на другую платформу, потратив на это массу времени».
(Отрывок из рассуждений сооснователя компании «МойСклад» Аскара Рахимбердиева о том, как предпринимателю управлять разработчиками.)
Ошибки в употреблении
Не путать с кроссбраузерностью. Это способность сайта работать в Google Chrome, Opera, Mozilla Firefox и других браузерах, не теряя при этом скорости работы и читабельности страниц. Задача разработчика – сделать портал пригодным для удобного использования в любом браузере.
Нюансы
Адаптировать код под различные ОС можно с помощью современных кроссплатформенных языков программирования (например, C, С++). При надлежащем качестве кода достаточно будет переписать только некоторые фрагменты, не трогая при этом основной движок программы.
При работе с устройствами на разных платформах стандартные элементы интерфейса могут искажаться, поэтому в таких случаях нужно позаботиться об адаптивности – способности сайта автоматически «подстраиваться» под размеры экрана пользовательского устройства. Не адаптированные ИТ-продукты плохо приспособлены к тому, чтобы их можно было с удобством просматривать на мобильных устройствах.
Кроссплатформенность — это круто
Ни для кого не секрет, что сегодня мобильные игры очень популярны. Возможность написать одну из таких игр есть у каждого разработчика, даже начинающего. Часто возникает вопрос с выбором платформы. Конечно, хочется, чтобы игра была сразу везде: на iOS и Android, на WP7 и MeeGo, на десктопе и в браузере. И чтобы все это можно было лекго реализовать с помощью бесплатных инструментов.
В этой статье я расскажу вам, как сделать основную часть кода платформонезависимой, а для остального использовать удобные средства разработки для каждой конкретной платформы.
Цель игры, изображенной на рисунке выше — успеть попасть по яблоку, пока оно летит вниз. Со временем количество яблок увеличивается, и не пропускать их становится все сложнее. Яблоки падают под произвольным углом, вращаясь и реалистично отскакивая от границ благодаря физическому движку Box2D. Игра будет запускаться на Android, платформах с поддержкой Qt (Symbian, Maemo, MeeGo, Windows, Linux, Mac OS X) и в браузере Google Chrome.
Выбор удобных инструментов
Так как основную часть кода я буду писать на чистом С++ (почему, читайте в конце статьи), IDE для этого подойдет любая. Я выберу Qt Creator, хотя ничего не мешает мне использовать Microsoft Visual Studio или Eclipse, например.
Для платформы Android я остановлюсь на библиотеке libgdx. С ее помощью легко можно рисовать текстуры, проигрывать звуки и делать другие необходимые вещи.
В качестве инструмента для разработки игры на десктопе я возьму Qt. Я давно знаком с этой библиотекой, и она не перестает меня радовать. При использовании Qt я также получу приятный бонус в виде поддержки мобильных операционных систем Symbian, Maemo и MeeGo.
Также специально для этой статьи я с помощью HTML5, javascript и Google Native Client сделаю так, чтобы игра запускалась в браузере Google Chrome. Я буду использовать HTML5 Canvas и Audio, и вы увидите, насколько это легко и просто.
Реализация логики не сложная, поэтому я не буду писать о ней (желающие могут взглянуть на код). Вместо этого я сконцентрируюсь на том, как заставить игру работать на всех операционных системах.
Абстрагируемся от конечной платформы
Как я уже говорил, основная часть кода будет общей для всех платформ. Назовем ее «движок». Мне нужно будет решить две задачи. Первая — вызов методов движка на каждой платформе:
Для этого движок предоставит платформам следующий интерфейс:
Вызовы обработчиков рисования и ввода на различных платформах будут вызывать методы из класса Application, например, при использовании Qt это будет выглядеть так:
На Android выйдет немного сложнее, потому что из Java нужно попасть в C++:
После этого в C++ вызываются соответствующие методы:
При использовании Native Client в браузере из javascript нельзя напрямую обращаться к С++, вместо этого надо отправлять сообщения модулю, например, строки:
В С++ сообщения анализируются, и в зависимости от содержания вызывается тот или иной метод:
В итоге движку не важно, из какой платформы был вызов, он абстрагировался от этого. Но он знает, что произошло касание экрана в точке (x, y) или пришло время для обработки физики и вывода изображений на экран.
Обратное взаимодействие
Вторая задача — обратное взаимодействие движка с платформой:
Это нужно для того, чтобы движок командовал, когда выводить изображения и текст на экран, проигрывать звук, вибрировать. Для этого все платформы должны реализовать общий интерфейс. Назовем этот интерфейс Platform:
На уровне движка я не привязываюсь ни к какой конкретной платформе, я не загружаю картинки или аудио файлы, вместо этого я использую числовые идентификаторы. Когда я хочу вывести изображение на экран, или проиграть звук, я делаю следующее:
Таким образом движок абстрагируется от деталей реализации различных операций на каждой платформе. Привожу для наглядности диаграмму классов:
Сложно ли все это сделать? Вы убедитесь в том, что нет. Время, конечно, придется потратить, но в большинстве случаев им можно пренебречь в сравнении со временем, потраченным на программирование логики приложения. Я приведу код для платформ Android, Qt и Native Client для каждой необходимой операции:
Рисование изображения, Android (libgdx):
Рисование изображения, Qt:
Рисование изображения, javascript (HTML5 Canvas):
Рисование текста, Android (libgdx):
Рисование текста, Qt:
Рисование текста, javascript (HTML5 Canvas):
Проигрывание звука, Android (libgdx):
Проигрывание звука, Qt:
Проигрывание звука, javascript (HTML5 Audio):
Вибрация, Android(libgdx):
При реализации для Android придется немного повозиться с вызовом java кода из C++ — один раз получить ID нужных java методов:
и потом вызывать их:
Нетривиальная ситуация и с Native Client — нужно отправлять сообщения из С++ кода в javascript:
И в javascript эти сообщения парсить:
Результат
Эта простая игра называется «Поймай яблочко». Предлагаю запустить и попробовать продержаться пару минут, у меня вначале не получалось:
— Native Client версия (убедитесь, что у вас последняя версия браузера Google Chrome, и Native Client включен в about:plugins и about:flags). Размер исполняемого файла nexe — 4.2Мб для 32-битных систем и 4.9Мб для 64-битных, при медленном соединении придется немного подождать;
— Windows версия — для тех, кто не любит Google Chrome.
Игра прекрасно запускается на Android эмуляторе и моем LG Optimus. Та же ситуация с Qt Simulator (скриншот с Nokia N9 в самом начале темы).
Код можно взять тут, я думаю, он может пригодиться кому-нибудь, особенно участки, которые отвечают за связку Java и C++, javascript и C++ (если по этому поводу у вас возникнут вопросы — задавайте, не стесняйтесь, с удовольствием отвечу).
Зачем все это?
Многие из вас подумают, зачем писать велосипед? Если есть Marmalade или Unity, например. Есть, но они стоят денег, да и зачем такие тяжеловесы для простой 2D игрушки? Некоторые говорят также, что Qt заводится на Android и iOS, но на самом деле на Android не очень так заводится, без звука и OpenGL, а на iOS так вообще, только ролики на YouTube. Мне очень нравится Qt, и я надеюсь, что в недалеком будущем приложения для iOS и Android можно будет писать так же просто, как сейчас для MeeGo, но пока лучше пользоваться другими инструментами для этих платформ.
Преимущества
Используя подход, описанный в этой статье, вы не привязаны к платформе, вы можете использовать те инструменты, которые хотите, а в последующем легко их менять. На десктопе — Qt или GTK, на Android — libgdx или AndEngine, на iOS — cocos2d, выбор за вами. Можете вовсе отказаться от движков, используя API, предоставляемое платформой. Большую часть времени вы можете писать и отлаживать код в вашей любимой IDE на великом и могучем C++.
Недостатки
Недостатки, конечно, тоже есть, например, вы не сможете пользоваться готовыми UI компонентами — вам нужно будет реализовать их на C++. Либо выносить UI часть приложения в каждую платформу. Также вам обязательно придется тесно познакомиться с каждой платформой, но как показывает практика, полностью уйти от этого знакомства никогда не удается.
Кроссплатформенные приложения против нативных: сравнение и выбор подходов Статьи редакции
Генеральный директор компании-разработчика «Лайв Тайпинг» Александр Кузнецов написал для VC колонку об отличиях нативных приложений от кроссплатформенных, в которой объяснил, какой тип разработки будет предпочтительным в тех или иных обстоятельствах.
Время приложений
Как правило, выход любого бизнеса в интернет протекает по следующему сценарию: сначала компания запускает сайт, затем его адаптируют под мобильные устройства, и если наблюдается прирост трафика, появляется смысл закрепиться среди владельцев мобильных гаджетов, и компания выпускает приложение.
Сравнивать мобильный сайт и приложение нет смысла — второе однозначно выигрывает за счет широты своих возможностей и отзывчивого интерфейса, взаимодействовать с которым через телефон или планшет гораздо комфортнее. Кроме того, приложение может работать без постоянного подключения к интернету.
Вне зависимости от того, на чем построен ваш бизнес — на продажах, предоставлении услуг или просветительской деятельности, сегодня невозможно не учитывать время, которое люди проводят перед экранами мобильных устройств.
Эта статья призвана рассказать о двух подходах к разработке приложений — нативном и кроссплатформенном.
Каждый из подходов обладает своей спецификой, критически влияющей на конечный результат. И дабы облегчить понимание между заказчиком и разработчиком, хочется рассказать о том, что собой представляют оба подхода, разобрать их достоинства и недостатки, разрушить укрепившиеся стереотипы о разработке и дать ответ на главный вопрос: как сделать выбор в пользу того или иного подхода по принципу целесообразности.
Нативный подход
Нативными приложениями являются те, с которыми вы сталкиваетесь с первого дня использования устройства. Это установленные по умолчанию браузер, почтовый клиент, адресная книга, будильник, календарь и другие стандартные программы.
Если разработчики в процессе написания приложения пользуются принятым для конкретной платформы языком программирования, будь то и Swift для iOS или Java для Android, такое приложение будет называться нативным (от англ. native — родной, естественный). «Нативки» могут получать доступ ко всем службам, сервисам и примочкам телефона: камере, микрофону, геолокатору, акселерометру, календарю, медиафайлам, уведомлениям — в общем, полноценно обживаются и чувствуют себя как дома.
Кроссплатформенный подход
Большинство специалистов, создающих такие приложения, пользуются фреймворком PhoneGap. Его особенность заключается в том, что он позволяет открыть приложению доступ к аппаратным и программным возможностям платформы. Также кроссплатформенная разработка возможна на таких технологиях, как Xamarin, Unity и прочих, но они не так популярны для разработки приложений, как веб.
Гибридные приложения
Какие ситуации приводят к слиянию подходов? Предположим, что клиенту нужна незатейливая новостная лента, где не будет ничего, кроме текста и изображений. Исходя из этой задачи, разработчик принимает решение использовать кроссплатформенный подход. Но если через некоторое время заказчик пожелает, чтобы приложение хранило большое количество данных или обрабатывало звук и графику, задача усложняется. Для этих целей нужно писать нативный код под каждую конкретную платформу, и некогда полностью кроссплатформенное приложение превращается в гибридное.
Распространено заблуждение, что за любой иконкой на рабочем столе пользователя ждёт нативное приложение. Это заблуждение пустило корни настолько глубоко, что даже в профессиональных кругах грешат формулировками высокого градуса абсурдности вроде «нативное ». Но на рабочий стол можно вывести даже ярлык для сайта, поэтому иконка ничего не гарантирует, и по ту сторону с равной вероятностью может оказаться как нативное приложение, так и любое другое.
Сравнение подходов
Рынок предложений растёт. Статистика продаж мобильных приложений показывает, что год от года пользователи гаджетов всё чаще меняют стандартные сервисы на альтернативные. Так, родной менеджер задач заменяется на Wunderlist, почтовый клиент — на приложение Mailbox, Evernote оказывается предпочтительнее стандартных заметок.
Заказчику важно знать преимущества и недостатки каждого из подходов и не завышать ожидания, делая выбор. Проводить сравнительный анализ будет уместно по ряду критериев.
Зависимость от платформы
Могло сложиться впечатление, что кроссплатформенному приложению в равной степени комфортно на всех платформах, вплоть до самых непопулярных. Требуется оговорка: чтобы это убеждение соответствовало действительности, под каждую платформу, возможно, придётся писать кусок дополнительного кода. В случае же нативных приложений можно рассчитывать на их отличную работу, но для каждой платформы требуется разрабатывать свою версию.
Дизайн интерфейса
Не затронуть гайдлайны в контексте разработки мобильных приложений невозможно. Гайдлайны — это ценные указания от платформ в адрес разработчиков мобильных приложений, направленные на то, чтобы подогнать их дизайн и функциональность под стандарты. Гайдлайны — это фундамент, на котором зиждется психология и комфорт пользователей платформы. Проще говоря, элементы интерфейса имеют привычный внешний вид и расположение.
Языковая среда, в которой разрабатываются нативные приложения, обладает необходимыми инструментами для создания привычного пользователю интерфейса. Другая ситуация с : чтобы сделать кроссплатформенное приложение похожим на нативное, придётся приложить немало усилий. Разные кроссплатформенные фреймворки (Framework 7, Sencha Touch, Kendo UI, Ionic и другие) помогают с той или иной степенью достоверности имитировать нативный интерфейс, но чаще всего отзывчивость, скорость анимации, эффекты и дизайн будут другими. Этому и посвящен следующий пункт.
Пользовательский опыт
Первое, чего на подсознательном уровне ждёт пользователь от своего приложения — это отзывчивости. За действием пользователя тут же следует ответная реакция, прокрутка страницы и анимация протекают плавно и без подвисаний. Кроссплатформенные приложения в этом плане значительно уступают нативным, а если не ходить вокруг да около, они тормозят, и это их главная проблема.
Также пользователь уверен в том, что каждый элемент управления, каждая иконка будут иметь стандартный вид и положение на экране приложения. Для разных платформ эти стандарты будут разными, и если кроссплатформенное приложение сделано по гайдлайнам iOS, то пользователям Android это доставит дискомфорт, и наоборот.
Одним из ярчайших примеров может стать кнопка Back: это типичная для Android функция, которая не имеет аналога на iOS. Поэтому, когда вы создаёте кроссплатформенное приложение, компромиссов в этой ситуации может быть только два: либо дизайн един для обеих платформ, и пользователи одной из них вынуждены приспосабливаться, либо вы создаёте два разных дизайна с учётом особенностей каждой платформы. По сути, во втором случае создаются два приложения, но на одном кроссплатформенном языке.
Ограничения
Нативное приложение, написанное под конкретную платформу, чувствует себя её полноправным обитателем, получая максимальный доступ ко всем устройствам и сервисам устройства. Проектируя кроссплатформенное приложение, разработчик учитывает только возможности фреймворка, налагающего свои ограничения.
Может создать проблему и то, что у фреймворков есть множество версий, и чем старее версия, тем больше ограничений. В любом случае, кроссплатформенному приложению открыты двери далеко не ко всем фишкам платформы. Не всегда возникает необходимость в полной интеграции — её глубина зависит от задач, которые должно решать приложение.
Безопасность
Для всех популярных браузеров существует стандартный безопасный протокол передачи данных — HTTPS. Но если требуется особый уровень шифрования, решение этой проблемы ложится на разработчика. Обеспечение надёжной защиты данных возможно только при нативной разработке, так как связано с математикой, а подобные операции требуют максимально эффективного использования аппаратных ресурсов.
Обслуживание и поддержка
Комплексное обслуживание нативных приложений для двух платформ (поиск и исправление ошибок, обновление и любое незначительное изменение) в среднем занимает в два раза больше ресурсов по причине необходимости как минимум двух разных специалистов (iOS и Android). С кроссплатформенным приложением может управляться один разработчик.
Стоимость мобильной разработки и затрачиваемом времени опутана заблуждениями и мифами, а потому хотелось бы затронуть эти вопросы отдельно и если не расставить все точки над i, то хотя бы этому поспособствовать.
Быстрая и дешёвая кроссплатформенная разработка — миф или реальность
Кроссплатформенная разработка обходится дешевле, что объясняется меньшими объёмами работ относительно нативной разработки. Но и здесь есть свои подводные камни, разглядеть которые можно, только поняв принципы ценообразования.
Исходя из вышесказанного, был произведен расчёт стоимости мобильной разработки в случае нативного и кроссплатформенного подходов, представленный в двух таблицах. Результаты в таблице 1 отталкиваются от средней почасовой ставки фрилансеров из баз freelansim.ru и fl.ru в рублях, в таблице 2 — средней почасовой ставки фрилансеров и студий из международной базы upwork.com в долларах.
Когда мы сравнивали подходы по нескольким критериям, мы сказали, что степень интеграции приложения в платформу обусловлена сложностью задачи, решаемой приложением. Использование того или иного шаблона или готового решения может быть довольно дешевым способом сделать приложение, пока возможностей шаблона или решения достаточно для выполнения конкретной задачи.
Но есть нюанс
И он заключается в структурной особенности приложения. Чаще всего оно предполагает наличие серверной части, куда пользователи приложения сохраняют данные и через которую обмениваются ими с другими пользователями, и она тоже требует финансовых вложений. Работа над ней может занимать до трети всего времени разработки, и оно увеличивается при необходимости создания административной панели для удобного управления данными.
Резюме
К нативной разработке стоит прибегать, если:
Ваш вариант — кроссплатформенная разработка, если:
К выбору той или иной стратегии всегда приводят индивидуальные обстоятельства, ни одна статья не даёт универсального ответа.
Наш материал скорее дает вводную информацию общего характера, помочь заказчику и разработчику наладить диалог на понятном для обоих языке.
Окончательное решение стоит принимать после консультаций с разработчиками. Чем больше аргументов относительно того или иного подхода вы выслушаете, тем лучше.
Если у вас появились вопросы, то смело задавайте их в комментариях — ответы на них помогут дополнить статью. Также призываем делиться своей точкой зрения знатоков по теме.
Ваш вариант — кроссплатформенная разработка, если:
* приложению необходим постоянный доступ в интернет, чтобы загружать контент;
довольно спорный на мой взгляд аргумент. Приложение не обязано иметь доступ(постоянный) в интернет, взять те же игры написанные на стеке html+css+js. Да и приложения которые уже сейчас поддерживают всякие LocalStorage с IndexedDB.
Согласен. Вообще правильно при разработке опираться прежде всего на целевую аудиторию, т.к. кроссплатформенные решения на html покажут себя не лучшим образом на устаревших девайсах, но практически ничем не будут отличаться по производительности от нативных на смартфонах которым год/два, если речь идет именно о приложениях, а не играх. Тоже приложение VC.ru легко могло бы быть реализовано при помощи одного из вышеперечисленных фреймворков.
«если речь идет именно о приложениях, а не играх»
следует читать как
«если речь идет о мобильных вебсайтах, завернутых в приложение, а не качественных приложениях или играх»
Тоже поддержу. Статья выглядит немного устаревшей
Школьник писал какой-то видимо
Фраза «приложение не предполагает сложной анимации и не занимается расчетами» в развернутом виде звучит так:
Подытожив: с вероятностью 99.99% приложение будет унылым говном на выброс. Никогда не сможет тягаться с лидерами. И будет отсвечивать разве что в showcase’ах ионика и фонгапа, в окружении таких же лузерских поделий. Но никак не в топах аппстора.
Короче, не распыляйтесь, пилите натив под iOS. В случае коммерческого успеха переходите к Андроиду.
PS. Все вышесказанное неверно в случае, если вы хотите тупо мобильный сайт в оболочке приложения. Контентный проект без развеситых фич можно запилить и кроссплатформенно. Но реальные бивни такое за приложения не считают 😉