Intel INDE Multi-OS Engine / forpes.ru

Главная
Intel INDE Multi-OS Engine

Intel INDE Multi-OS Engine +14

11.09.2015 07:39

iLya84a 9 7368 Источник

Не так давно, в начале августа, на конференции Android Developer Conference (Andevcon) 2015, проходившей в Бостоне, корпорация Intel анонсировала INDE Multi-OS Engine — фреймворк для разработки нативных кроссплатформенных приложений на Java.

Разработку приложений, которые работаю одновременно на iOS и Android, нельзя назвать ни быстрой, ни дешевой. До недавнего времени, если вы хотели выпустить приложение сразу для двух самых популярных мобильных платформ, перед вами вставал непростой выбор. С одной стороны, вы могли использовать кроссплатформенный инструмент, например Cordova, и в результате получить условно недорогое приложение с достаточно качественным, но в то же время весьма ограниченным UI/UX.

С другой стороны, у вас была возможность разрабатывать два отдельных нативных приложения:

Оба подхода имеют свои плюсы и минусы. Однако, даже для крупных компаний с серьезными ресурсами этот выбор оказывался непростым. Но ситуация меняется. Теперь разработчики могут попробовать Intel’s Multi-OS Engine (MOE), который специально предназначен для значительного сокращения времени разработки, необходимого для создания отдельных нативных Android и iOS приложений:

Как вы можете знать, Intel INDE — кроссплатформенный набор инструментов для создания нативных мобильных приложений. INDE состоит из целого ряда SDK, библиотек, компиляторов, отладчиков и утилит анализа производительности — всего того, что требуется для полного цикла разработки ПО. А Multi-OS Engine можно смело назвать настоящей “вишенкой” на “торте” INDE!

Почему быть нативным так важно?

Современный пользователь мобильных приложений очень искушен, а магазины для любой платформы заполнены огромным количеством аналогов. Как выделиться среди них? Я сам из двух похожих приложений скорее выберу то, которое выглядит и ощущается по-настоящему согласованным со всей системой. Даже несмотря на то, что разработка нативных приложений занимает больше времени, нативный “Look & Feel” — это именно то, на что обращают внимание конечные пользователи, а значит, экономить на этом просто нельзя. По ряду причин нативные приложения имеют в этой области заметное преимущество:

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

Почему именно Java?

Чтобы ответить на этот вопрос, достаточно обратиться к следующему графику:
GitHub languages

Рейтинг языков GitHub, основанный на объёме кода, хранящегося в его репозиториях, совершенно четко объясняет, почему в качестве языка кросс-платформенной разработки для React Native в Facebook выбрали Javascript, а Intel выбрал Java для Multi-OS Engine.

Технические детали

Multi-OS Engine поставляется в виде плагина для Android Studio. С помощью него вы можете создать новый MOE проект, либо добавить MOE модуль в уже существующий проект. Таким образом, вам совсем не обязательно знать Objective-C, чтобы писать нативные приложения под iOS. При этом разработка под Android не претерпевает никаких изменений. Но у вас появляется замечательная возможность переиспользовать весь платформенно-независимый код. MOE не предлагает 100% переиспользование кода, но при правильной архитектуре эта величина может достигать 60%.

Вот как Multi-OS Engine обеспечивает поддержку Java на iOS:

Автоматически генерирует байндинги по заголовочным файлам ObjectiveC и C
Использует специальные Java-аннотации
Связывает Java с нативным кодом с помощью библиотеки NatJ
Избавляет от необходимости JNI вызовов
Полностью покрывает iOS API

Всё это позволяет сразу же начать писать iOS-приложения на Java.

Процесс разработки iOS-приложений на Java

Создайте Multi-OS Engine проект в Android Studio
Если вы используете Mac, добавьте новую Run/Debug конфигурацию “Intel MOE iOS Application” для сборки на локальной машине. На Windows-хосте доступна конфигурация “Intel MOE Remote Build” для сборки “в облаке”.
Вы можете создавать UI прямо в XCode либо использовать специальный MOE UI designer, встроенный Android Studio.
Свяжите ваш UI с Java, используя аннтотации и библиотеку NatJ.
Используйте автодополнение кода для легкой работы с iOS SDK.
iOS-приложения могут быть запущены на симуляторе и устройстве прямо из Android Studio.
Отлаживайте ваши приложения прямо в Android Studio.

Чтобы попробовать Multi-OS Engine, вы можете немного рассказать нам о себе через специальную форму. Это позволит нам сделать MOE ещё лучше. Но если вам не терпится, вы можете сразу перейти на страницу загрузки: Хочу MOE прямо сейчас! На этой же странице вы найдете подробное руководство пользователя.

P.S.
Команда, разрабатывающая Multi-OS Engine, почти полностью находится в России (Нижнем Новгороде и Москве). И если у вас есть вопросы, которые вы хотите задать лично, у вас есть отличная возможность — посетить конференцию Droidcon в Москве 26 сентября.

Комментарии (9)

agent10
11.09.2015 10:58
#8569037
Глянул пример.
Я правильно понял, что UI для iOS всё равно придётся писать самому, но только уже на Java + всякие хелперы типа аннотации?
1. iLya84a
  11.09.2015 12:10
  #8569175
  +3
  Вы правильно поняли! Но кода будет не больше, чем при использовании Objective-C.
  Вот сравните код на ObjC:
  
  - (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender { if ([segue.identifier isEqualToString:@"showDetail"]) { NSIndexPath *selectedIndexPath = [self.tableView indexPathForSelectedRow]; // Set data ... }
  
  и Java:
  
  @Override public void prepareForSegueSender(UIStoryboardSegue segue, NSObject sender) { if (segue.getIdentifier().toString().equals("showDetail")) { NSIndexPath selectedIndexPath = getTableView(). indexPathForSelectedRow(); // Set data ... } }
  1. agent10
    11.09.2015 19:15
    #8569843
    +3
    Ну смотрите как получается.
    Скажем для «раздельной» разработки нужно 1 Андроид разраб и 1 iOS.
    1) В вашем случае получается, что всё равно нужен 1 Андроид разраб + нужен разработчик со знанием сразу и Java(Android) и iOS SDK. Т.е. всё равно 2 человека надо.
    2) Будет ли меньше багов и упростится ли поддержка кода? Во-первых, вы сами пишете про платформенно-независимый код, что
    эта величина может достигать 60%
    Т.е. я предполагаю, что помимо двух отдельных UI будет ещё и зависимый код под платформу + общую часть также нужно будет архитектурно создавать сразу независимой от платформы(что в целом хорошо, но может быть сложнее).
    
    Вероятно, такая схема работы хорошо пойдёт, когда в приложении много сложной постоянной меняющейся логики, которая сдобрена небольшим кол-вом UI.

anisart
11.09.2015 14:38
#8569469
+2
Подскажите пожалуйста, есть ли возможность подключить сторонний фреймворк к iOS части? Допустим тот же AFNetworking? Или придется сначала портировать его на java?
1. iLya84a
  11.09.2015 18:20
  #8569797
  +1
  Такая возможность есть. Но пока мы не включаем в поставку генератор Java-байндингов для сторонних нативных библиотек. Это произойдет в одном из следующих релизов.

iLya84a
11.09.2015 18:17
#8569795
-

spall
11.09.2015 19:29
#8569857
+2
60%?

Теперь для проекта надо 160% явиста и 40% айосника. Плюс полтора землекопа чтобы биндить java к objectC :)
1. alexeyknyshev
  12.09.2015 15:34
  #8570343
  +1
  Так ещё и поддерджки Linux, как я понял, нет.
  1. iLya84a
    14.09.2015 10:59
    #8571185
    +1
    Linux поддержки пока действительно нет, но может появиться. Всё зависит от интереса пользователей!