Comments 13

Я, как настоящий хипстер, хочу писать Xamarin.Forms на F# в VSCode на своём Arch linux.
Скажите пожалуйста, это когда-нибудь будет возможно?

разрабы xamarin говорят что не планируют этого forums.xamarin.com/discussion/1599/xamarin-studio-in-linux,
хотя юнити тоже когда-то так утверждали, но таки запилили ее под линуксы, правда на слабых видеокартах запустить нормально все-равно не получается (

Ну Unity подразумевает что я делаю графиконагруженные игрухи. А тут — как бы ничего не подразумевается.
А на счёт F# что?

насчет F# и VSCode не знаю т.к не использую. Юнити я привел в пример того, что он построен на той же технологии что и xamarin — (пока еще) mono.

Отлично! Ждем вторую часть. Интересует в частности разработка на Qt

При создании приложений на ReactNative разработчику будет необходимо также реализовывать нативную часть на Objective C, Java или C#, которая инициализирует JS-движок и свой JS-код.

Неакутально вроде уже. Там теперь все через expo делается. линк
К сожалению, инфа по ReactNative устаревает достаточно быстро.
Хотя Expo, вроде как, больше года назад появилось.
Ну здесь все просто :) В реальных проектах практически всегда требуется доработка UI-контролов и часто нужен доступ к какой-нибудь специфической нативной функциональности (вроде фоновой синхронизации), которую хочешь или не хочешь, но надо делать на Objective C и Java.

Про Expo полезное дополнение, спасибо!
Оценка экономии трудозатрат в количестве строк shared-кода это несколько лукаво.
Лукаво прежде всего потому что (как минимум в случае Xamarin) нет линейной зависимости между человеко-часами и итоговым количеством строк кода — и IDE играет в этой зависимости далеко не последнюю роль.
Из особенностей Xamarin, которые солидно увеличивают количество человеко-часов можно отметить:
— иногда бесконечное время сборки проекта (как правило это лечится удалением папок bin / obj)
— периодическими отваливаниями отладчика после обновлений Xamarin

Хочу предложить другое деление по типам архитектуры.
image


Среди кросс-платформенных принципиальное деление на "нативные" и "гибридные".
Нативные это те где вам просто предлагается программировать на одном языке под все платформы, но обычно вам надо осваивать на каждой платформе API этой платформы.
Гибридные это те где весь код, а это HTML/CCS/JS запускается в WebView в котором у вас есть доступ не только к обычному набору API браузера но и к различным дополнительным API для доступа к различному функционалу недоступному из браузера.
Особый тип — смешано гибридные, это когда у вас UI реализован в WebView, а логика/работа с данными реализована на каком то языке в полностью переносимой среде.
На представленной схеме полностью переносимый код выделен зеленым.
Мы в компании Tau Technologies занимаемся разработкой решения, Rhomobile, как раз смешанно-гибридного типа и считаем такую архитектуру наиболее перспективной для применения в корпоративной сфере.
Собственно за что справедливо ругают такое самое распространенное решение как Cordova/PhoneGap? За то что у вас все висит в однопоточном WebView. Соответственно как только речь заходит о разработке больших приложений начинаются лаги, тормоза и т.п. Какое решение этой проблемы? Надо вынести код логики/работы с данными вовне WebView. Конечно этот код должен быть переносимым и т.п. Но как это сделать? Можно пойти путем нативных кросс-платформенных решений типа Xamarin, то есть заставить разработчиков учить новые для них API и т.п. Однако можно пойти другим путем — можно предоставить разработчикам какую-либо уже распространенную среду(есс-но и язык тоже). И тут явно напрашивается архитектура клиент-сервер веб приложения — ведь по сути у на сто же самое — WebView в которой клиент и UI и находящийся вовне сервер где код логики и работы с данными. И все что нам надо это перенести сервер прямо на мобильное устройство!
В своем решении Rhomobile мы предлагаем две возможности для написания переносимого кросс-платформенного кода вне WebView (в которой реализуется легковесный UI) — это:


  • язык Ruby и среда Ruby on Rails
  • язык Javascript и среда Node.js
    Все это собирается в итоге в законченное платформенное приложение, причем все работает прямо на мобильном устройстве!
    Какие главные достоинства такого подхода:
  • переносимость кода. В корпоративном решении мобильное приложение это обычно всего лишь часть большой системы, которая обычно включает в себя и веб порталы и десктоп приложения и т.п. В случае применения смешанно-гибридного типа вы можете переносить код не только UI между веб порталом и приложением но и серверный код тоже! Более того код UI переносим не только между порталом и приложением но и между различными решениями гибридного типа!
  • эффективное использование разработчиков. Вам не надо набирать команду мобильных разработчиков и не надо обучать разработчиков новым API и т.п. Вы можете использовать своих разработчиков веб клиент-серверных решений и для разработки мобильных приложений без переучивания!

Эти вопросы я и мой коллега освещали в прошлом году в своем докладе на CEE SECR 2016:
"Настоящее и будущее решений для разработки кросс-платформенных мобильных гибридных приложений в корпоративной сфере"
http://files.tau-technologies.com/Events/2016_10_CEE_SECR/TAU_Technologies_CEE_SECR_2016_RUS.pdf
В этом году у нас тоже будет (в эту субботу 21 октября 2017, в Санкт-петербурге) доклад на CEE SECR 2017 (пока не выложен, но будет выложен в день доклада):
http://2017.secr.ru/program/submitted-presentations/improvement-of-hybrid-solutions-for-the-development-of-cross-platform-mobile-applications
в этом году упор будет именно на смешанно-гибридную архитектуру и демонстрация как это выглядит вживую, когда Ruby on Rails или Node.js работают прямо на мобильном устройстве.


Если кто интересуется как выглядит работа RoR или Node.js прямо на мобильном устройстве — вот пара наших докладов:
"Rhomobile. Разработка кросс-платформенных мобильных гибридных приложений с использованием Ruby" (на RailsClub 2016)
http://files.tau-technologies.com/Events/2016_10_RailsClub/Rhomobile_RailsClub_2016_full_RUS.pdf


"Разработка кросс-платформенных мобильных гибридных приложений на базе Node.js с использованием Rhomobile" (на Node.js SPb Meetup 2017)
http://files.tau-technologies.com/Events/2017_03_31_SPB_Nodejs_meetup/Rhomobile_SPB_Nodejs_meetup_2017_03_31_RUS.pdf

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

На самом деле WebView не такой уж и однопоточный. Композиция и соответствующие анимации, не требующие перерисовки, происходят в отдельном потоке. Тормоза начинаются если анимации делаются на JS и если пытаться рендерить сразу все элементы, в то время как видимыми из них будут хорошо если 5%. Мы пробовали использовать полимер и ионик и всё тупило даже в тривиальных примерах. Поэтому запилили свой фреймворк, который по умолчанию рендерит лишь минимум, а остальное дорендеривает лишь по мере прокрутки. Давайте кооперироваться ;-)

Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
США
Website
www.microsoft.com
Employees
Unknown
Registered

Habr blog