Я не совсем объективен в этой области, поскольку являюсь соучредителем кроссплатформенного инструмента мобильной разработки поставщик. Тем не менее, я постараюсь быть максимально объективным и помочь направить вас в правильном направлении. Я думаю, что есть много замечательных инструментов, которые сделаны не нами, и это не рынок “одного размера для всех”.
Но прежде чем мы двинемся дальше, я хотел бы обсудить, почему вы должны использовать кроссплатформенный инструмент. Часто люди совершают ошибку, глядя на стоимость создания собственного приложения и думая: “Почему бы и нет”?
Вы можете передать разработку приложения на аутсорсинг и создать собственное приложение для операционной системы примерно за 20 тысяч долларов США. Главная проблема такого менталитета заключается в том, что в долгосрочной перспективе техническое обслуживание обходится гораздо дороже. Каждая ошибка, функция и обновление в конечном итоге будут стоить гораздо дороже в долгосрочной перспективе в зависимости от срока службы вашего приложения. Возможность сократить циклы разработки имеет решающее значение, поскольку частые обновления/быстрое реагирование, вероятно, являются наиболее важными аспектами успешного приложения.
Проблема в том, что люди часто используют кроссплатформенные инструменты для сокращения затрат вместо того, чтобы использовать их для перераспределения затрат. Возьмите деньги, сэкономленные на разработке/обслуживании, и потратьте их на контроль качества, дизайн и т.д. Вот почему некоторые из этих инструментов получают неоправданную плохую репутацию.
Это не новость, так было всегда, и именно поэтому кроссплатформенные инструменты взяли штурмом рабочий стол более 20 лет назад. Причина, по которой это не было так ясно в мобильных устройствах, связана с проблемами зрелости этих инструментов и самих платформ, которые значительно повзрослели за последнее десятилетие.
система
Когда меня спрашивают, как выбрать кроссплатформенное решение, которое “подходит именно вам”, у меня есть очень простая система. Обратите внимание, что я игнорирую решения “без кодирования”, поскольку они слишком упрощены для большинства случаев использования. Он состоит из следующих 4 вопросов с множественным выбором:
Какой язык программирования вы предпочитаете: C#, Java, C++, Ruby, JavaScript, HTML +JavaScript, Basic
Верите ли вы в Write Once Run Anywhere (WORA) – многим разработчикам нравится кроссплатформенность, но они хотят, чтобы она была как можно ближе к родной. Другие хотят удобства и мощи одного кода для всех устройств
На какие платформы вам нужно ориентироваться: Android, iOS, Windows Mobile, Настольный компьютер, Веб
Требуются ли в вашем приложении специальные функции, например, Карты Google, дополненная реальность, системные виджеты и т.д.
Основываясь на ответах на эти вопросы, довольно легко определить лучший инструмент для данной работы.
Вопрос 1: Выбранный язык программирования
Каждый инструмент имеет свой собственный язык программирования по выбору. Возможно, это и не является решающим фактором, но часто является отличной отправной точкой:
- C# – Xamarin
- Java – Кодовое имя One
- C++ – Qt
- Ruby – RubyMotion
- JavaScript – (См. HTML+JavaScript) React Native, Appcelerator, NativeScript/Telerik
- HTML +JavaScript – PhoneGap, Ionic, Sencha и т.д.
- Базовый – Basic4Android/iOS
- Котлин – Родной Котлин, Кодовое имя Один
- Дротик – трепетание
Вопрос 2: WORA (Запись После Запуска В любом месте) против переносимости общего кода
Это концептуальный вопрос. Более портативные инструменты обычно обеспечивают более быстрые циклы разработки и часто упрощают разработку за счет уменьшения различий в платформах.
Цена оплачивается на расстоянии от базовых платформ, эта цена может стоить того и может быть преимуществом, поскольку она позволяет вам более тщательно применять корпоративный брендинг/брендинг приложений.
Я большой сторонник WORA так что я далек от объективности в этом вопросе, но я нахожу, что во многих случаях это скорее религиозные дебаты, чем фактические дебаты (есть факты но они различаются и открыты для интерпретации). Если вы считаете, что приложения WORA изначально или обычно имеют недостатки, то выбор ХУДШЕГО решения может быть проблематичным.
Другие решения используют уровни переносимости, которые позволяют вам совместно использовать общий код, по моему опыту, это обычно составляет 50% общего кода. Некоторые разработчики утверждают, что до 90% из них я лично никогда не видел, и предполагают, что они просто определяют такие вещи, как код пользовательского интерфейса XML, как “не код”. Обычно подобные решения экономят гораздо меньше, поскольку вам нужно абстрагировать общие части кода, что приводит к большему количеству кода…
Это не обязательно плохо, поскольку абстракция – хорошая инженерная практика но это действительно делает вещи более сложными и подробными.
Если вы верите в WORA, то одно из этих решений может быть вам полезно:
Кодовое имя One, flutter, QT, PhoneGap (ионный, Сенча и т.д.)
Если вы этого не сделаете, то один из них может сработать лучше:
Xamarin, RubyMotion, Appcelerator, NativeScript, Basic4Android/iOS, Kotlin Native
Вопрос 3: Целевые платформы
Все вышеперечисленное поддерживает iOS и Android. Если вам нужно больше, чем эти платформы, поддержите их:
- Windows Mobile (UWP) – Xamarin, Codename One и PhoneGap (Ionic, Sencha и т.д.)
- Веб – Кодовое имя One, flutter, PhoneGap (ионный, Сенча и т.д.), Уроженец Котлина
- Рабочий стол – Xamarin, кодовое имя One, QT и PhoneGap (через electron). Обратите внимание, что в настоящее время существует экспериментальная поддержка flutter. Неясно, насколько хорошо Kotlin native работает на настольных платформах, но, похоже, в этом направлении ведется определенная работа
Вопрос 4: Особые характеристики
Это то, что вам нужно перечислить и спросить у соответствующего поставщика, например, если ваше приложение использует карты Google, вам нужно знать, может ли платформа поддерживать встраивание такой функции в приложение. Все вышеперечисленные решения поддерживают общие функции, такие как местоположение, камера и типичный пользовательский интерфейс.
Однако, если у вас есть конкретные требования, вам необходимо выполнить их по каналу поддержки поставщика или просто выполнить поиск в Google по этому вопросу. Я бы посоветовал спросить в любом случае, поскольку этот мир быстро меняется, и результат, который вы можете получить от Google, может уже устареть.
Дополнительный совет
Не верьте мне на слово в этом. Существует хороший сайт сравнения под названием property cross , который является проектом сообщества с открытым исходным кодом. Он определяет стандартное приложение сообщества, управляемое веб-сервисами, которое каждый поставщик реализует с помощью своего инструмента. Затем вы можете просмотреть различные реализации и сравнить их друг с другом.
Некоторые реализации различаются из-за стиля кодирования, но они очень четко показывают различия между различными кроссплатформенными решениями.
Окончательно
Я пропустил множество инструментов в этом обзоре, потому что их много, я попытался сосредоточиться на соответствующих инструментах, применимых в бизнес-среде, поэтому я проигнорировал решения, ориентированные на игры, такие как Unity, которые повлияли бы на эту статью и сделали ее намного более запутанной.
Если есть какой-то конкретный инструмент, который вам интересен, не стесняйтесь спрашивать в комментариях, и я постараюсь поместить его в приведенный выше ответ.
ПРИМЕЧАНИЕ : Это репост оригинальной статьи, которая была написана несколько лет назад (до появления flutter и до появления kotlin native). Я обновил его но большинство фактов остаются такими, какими они были в те далекие времена.
Оригинал: “https://dev.to/codenameone/how-to-pick-the-right-cross-platform-solution-25d0”