Перейми досвід найсильніших NLP команд світу: HuggingFace, Stanford, YouScan, Grammarly
×Закрыть

Бум вакансий для Flutter-разработчиков

Всем привет!

Flutter продолжает развиваться. Разработчики Google ведут активную работу по внедрению Flutter Web, который станет одним из основных инструментов для разработки Progressive Web Apps.
Все больше и больше компаний в Украине ищут разработчиков на Flutter для создания новых мобильных приложений и веб-приложений.
На данный момент только на dou.ua опубликовано 19 вакансий и с каждой новой неделей это количество увеличивается.

Google Trends источник не сильно точный, но общую динамику передает: trends.google.com/...​tter,react native,xamarin

Наше сообщество Art Flutter создало Telegram канал — t.me/fluttervacancies, где мы постим самые свежие вакансии для нашей аудитории с различных источников.
Приглашаем всех разработчиков, которым интересен Flutter, присоединиться, а HR — предлагать интересные вакансии.

Давайте вместе развивать украинское Flutter-сообщество!

LinkedIn

Лучшие комментарии пропустить

Ох уж эти кричащие заголовки.
Зашел на indeed.co.uk, поиск по London, Greater London:
«iOS» — 1,317 jobs
«iOS Swift» — 242 jobs
«iOS Objective-C» — 145 jobs
«Android» — 1,370 jobs
«Android Kotlin» — 194 jobs
«Android Java» — 375 jobs
----------------------------------
«Flutter» — 18 jobs, из них 4 в компанию Flutter Group, которая не имеет отношения к IT, а в остальных Flutter обозначен как дополнительная компетенция для таких позиций как Front End Developer, Java Team Lead и, барабанная дробь, Senior Mobile Engineer (react-native).

На самом деле, Flutter, как и React Native, — это отличные технологии, в которые очень даже есть смысл инвестировать 3-5 месяцев своего времени. Написать на них пару-тройку низкоприоритетных модулей и прототипов. Я именно так и поступил — написал на React Native MVP продукта, параллельно неплохо разобравшись в технологии. И теперь RN лежит у меня в загашнике до следующей случая, когда мне нужно будет с уверенностью сказать: «пацаны, я до конца недели могу собрать проект, накидать пару экранов и выкатить вам .ipa и .apk, чтобы вы на выходных поигрались и убедились, что ваша идея — говно».

Делать же Flutter или RN своей основной компетенцией и строить на них карьеру — это тупиковый путь. Ты либо будешь на больших проектах все время пилить прототипы, PoC-шки и временные модули, пока коллеги занимаются разработкой критически важного функционала, либо будешь сидеть на бесконечных 500-долларовых Upwork проектах.

Короче, неправильная подача. Рекламируйте молоток как молоток, а не как кувалду. Многим людям нужны молотки в инструментарии.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Кстати, если у кого с инглишем проблемы, но хочется в Dart и Flutter — на сайте metanit.com появился раздел(ы) по этой теме -> metanit.com/dart/tutorial и metanit.com/dart/flutter .

Ох уж эти кричащие заголовки.
Зашел на indeed.co.uk, поиск по London, Greater London:
«iOS» — 1,317 jobs
«iOS Swift» — 242 jobs
«iOS Objective-C» — 145 jobs
«Android» — 1,370 jobs
«Android Kotlin» — 194 jobs
«Android Java» — 375 jobs
----------------------------------
«Flutter» — 18 jobs, из них 4 в компанию Flutter Group, которая не имеет отношения к IT, а в остальных Flutter обозначен как дополнительная компетенция для таких позиций как Front End Developer, Java Team Lead и, барабанная дробь, Senior Mobile Engineer (react-native).

На самом деле, Flutter, как и React Native, — это отличные технологии, в которые очень даже есть смысл инвестировать 3-5 месяцев своего времени. Написать на них пару-тройку низкоприоритетных модулей и прототипов. Я именно так и поступил — написал на React Native MVP продукта, параллельно неплохо разобравшись в технологии. И теперь RN лежит у меня в загашнике до следующей случая, когда мне нужно будет с уверенностью сказать: «пацаны, я до конца недели могу собрать проект, накидать пару экранов и выкатить вам .ipa и .apk, чтобы вы на выходных поигрались и убедились, что ваша идея — говно».

Делать же Flutter или RN своей основной компетенцией и строить на них карьеру — это тупиковый путь. Ты либо будешь на больших проектах все время пилить прототипы, PoC-шки и временные модули, пока коллеги занимаются разработкой критически важного функционала, либо будешь сидеть на бесконечных 500-долларовых Upwork проектах.

Короче, неправильная подача. Рекламируйте молоток как молоток, а не как кувалду. Многим людям нужны молотки в инструментарии.

Зайшов на dart.dev і там пишуть, що можна на ньому писати серверну частину httpserver та знайшов порівняння з Java Dart vs Java performance

А ще у Dart-а 60 ключових слів, для порівняння у Go 25, Rust 58

Поки відчуття що Dart провальний проект і його пробують реанімувати через Flutter, бо 3+ роки тому вподобав TypeScript ніж Dart

по сравнению с котлин дарт полная лажа, как буд то вернулся обратно в начало 2000ых
почему было не сделать на котлине флатер не понятно

Смотрите комплексно на вопрос выбора языка. hackernoon.com/...​er-uses-dart-dd635a054ebf

да такое можно накатать на любой язык, просто надо найти фаната

Бо Dart повністю підконтрольний компанії, ніж Kotlin

А гуглу есть смысл инвестировать в kotlin-native ?
DartVM уже есть, уже с AOT’ом, и без LLVM ...

Они саму идею kotlin multiplatform ели приняли — поддержки нет, а вброса и PR’a хоть отбавляй.

После Kotlin вообще не хочется ни на чем другом писать... а, сцука, надо... :(

Видите ту кляксу возле самого дна зарплатного графика с подписью Dart (данные с stackoverflow developer survey 2019)?
cdn.sstatic.net/...​uage-1.svg?v=d63c4a852014

А это именно тот язык, на котором пишутся флаттер-приложения.
Тут вообще вопрос, стоит ли уматывать удочки с мобайла, например, в Go писать бэкенд.

Рискну предположить что за Го в 2009ом тоже давали не густо. Сейчас же один из топовых языков по ЗП. А специалистов мало(на нашем проекте не хватает). Не каждый лишь может смотреть в завтрашний день)

про «завтрашний день» гарно згадав) зайшло)

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

+1, довелось недавно подшаманить проект с Laravel 4.2, так вот какой же он куцый даже по сравнению с 5.х версиями. Мне страшно представить, что там было в первых трех версиях.

Ваше право)

Василий, а можете, пожалуйста, дать ссылку на вакансию Го разработчика? Хочу перейти с Джавы на Го.

https://www.openocean.studio/careers/
Засылайте свое ЦВ сюда

Отправил на contact@openocean.studio, так как careers@openocean.studio не работает.
У Вас там чистый Go — только Lead Developer (London), а все остальные Java + Go.
Пул разработчиков, которые знают Java + Go значительно меньше, чем просто Go.
Спасибо!

Підорги роблять черговий GWT.

І ще не раз те зроблять, звісно ж нове і революційне. Бо в інакшому випадку їх звільнять. Гугл давно вже може звільнити левову долю розробників, замінивши їх на патентних тролей. І зможе нічого не робити, окрім поглинання менших проектів як чорна діра — все влітає, нічого не вилітає.

Будем надеяться, что не последний раз. Приятно видеть, что инструменты разработки не стоят на месте.

Приятно видеть, что инструменты разработки не стоят на месте.

це так тільки здається

насправді з 2005 нічого толком не змінилося.

Звичайно) В 2005-му в контексті мобайла була j2me та Symbian, а зараз Android та iOS. Звичайно нічого не змінилось.
Як згадаю wireless toolkit. Про який знають 3.5 мобільних розробника.
Як зробив першу гру на j2me. Яку потім запускав на своєму на Siemens C72 с 10мб пам’яті.

і шо ви хочете сказати шо тулсет сильно краще став?
зараз хіба що імпорт ліб автоматом робиться бо є плагини для градлу та мейвену.
все інше як біло на рівні тих років так і залишилося

Это как в Майкрософте. Четвёртый десяток лет пилят один Офис, не могут сделать так чтоб в элементарных функциях не глючил.

Про браузер умолчу. Слава яйцам, сдались от написания собственного ишака.

Треба ж якось виправдати змарнований бюджет з 2009го року.
А для любителів GWT вже давно є Vaadin 13+.

Flutter действительно активно развивается и появляются вакансии (по крайней мере в Европе). Думаю за следующий год он догонит, а потом и заменит React Native

реакт говно, так говорят все кто с ним работал
но у флатера одну проблему решили но осталась куча других, например многопоточность

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

есть опыт реакта, не знаю насчет производительности, но на ам было легче на него забить и катать иос и андроид отдельно, так тупо быстрее разрабатывать

да ну, это не серьезно. в описаниее он везде идет как Nice to have или As a plus или в P.S.
Или вот есть вакансии
Senior Back End Engineer (Node.js)
Middle .NET Engineer
Викладачі курсів Magento, Python, Node.js, DevOps, Angular

они каким боком?

Или вот в одной фронтовой вакансии упоминание

Project team:
Development team in Kiev office, 9 team members (middle and senior Python, Angular, Flutter engineers, Senior Java Automation QA), management team in Sweden.

Так что я еще соглашусь на 5-6, но никак не 19

ну такое, ну а как плюс может хотят попробовать да и человека с флатер не найдешь сейчас

Android dev -> flutter нормальний рейт мають — 3-3,5

3-3.5 это маленький рейт, сейчас на андроиде для синьера это минимум 4к

прям таки мінімум?) думаю що далеко не в усіх «сініорів» є 4к там)

с средними скилами есть, ну есть много народу кто себя недооценивает
но в целом рыночек уже таков что готовы давать 4к, в очередь выстраиваются

Я думаю його зараз в основному використовують в «райт ванс, ран еверівеа, шаред кодебейс, економія» проектах невеликого розміру. Там грошей нема(:. От якщо з часом ті проекти раптом отримають розвиток і треба буде їх підтримувати на хорошому рівні, будуть і норм рейти.

От якщо з часом ті проекти раптом отримають розвиток і треба буде їх підтримувати на хорошому рівні, будуть і норм рейти.

Угу, и переписывание на нативный код.
Видали такие проекты в эпохи титаниума, айоника, реакт натива, теперь флаттер.

А какие предпосылки к переписыванию приложения на флаттере?
Для кордовы это webview, для реакт нейтива — js-бридж. Единственный вариант для переписывания — если Google забросит, но пока даже мыслей таких нет.

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

Такая же как и для них всех — собственный канвас флаттера

у React Native не собственный канвас + имхо это решение, а не проблема. например, API андроида не поддерживает нормальные тени, только унылый elevation.

Да, компоненты вроде бы нативные, но не системные

т.е. проблема в том, что экшн бар из коробки может немножко отличаться внешне, если вдруг разработчики андроида решат изменить его внешний вид, а разработчики флаттера не успеют вовремя поправить? серьезная проблема :)

т.е. проблема в том, что экшн бар из коробки может немножко отличаться внешне, если вдруг разработчики андроида решат изменить его внешний вид, а разработчики флаттера не успеют вовремя поправить? серьезная проблема :)

Да, кроме шуток, да.
Кастомер скажет «почему у нас экшн бар из 18-го века?». И будете городить кастом вьюху со всеми её прелестями.
Кстати. А рефлекшн в дарте есть?
Очень нужная штука в работе с андроидными системными барами))

Скорее всего кто-то один кто столкнется с такой проблемой сделает ПР в репо флаттера, а остальные будут пользоваться.
Рефлекшен есть, но это антипаттерн.
А ещё можно использовать флаттер вью в Android activity, так что никаких проблем с барами точно не будет

Скорее всего кто-то один кто столкнется с такой проблемой сделает ПР в репо флаттера, а остальные будут пользоваться.

А другие потом будут делать ПРы с фиксами его багов...

Рефлекшен есть, но это антипаттерн

Да это везде антипаттерн. И убивать людей вообще нельзя, но иногда по-другому — никак.

А ещё можно использовать флаттер вью в Android activity

Это как?
Флаттер по идее ни про какие активити ничего не знает. Он даже не должен знать, на Андроиде или Айосе он запущен.

Кстати. А рефлекшн в дарте есть?
Очень нужная штука

Ловите буйного!

Поменяй шрифт текста в BottomNavigationView без рефлекшена)
Та даже просто убери оттуда шифт мод))

Ой ля, сеньор не может написать свою реализацию простейшей вьюхи с кастомными шрифтами (или же тупо ленится).

Зачем писать то, что уже есть в СДК?)

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

А если private поле или метод к которому получаешь доступ через рефлексию разрабы в следующих релизах переименуют или вообще поменяют структуру класса и там этого поля/метода не найдёшь?

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

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

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

Увы, это типичная клиентура украинского аутсорса — пусть говнокод, костыли, но чтобы на пять копеек дешевле :(

клиентура украинского аутсорса — пусть говнокод, костыли

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

не замедлит ничего
Будучи вызванным 5 раз
прибавка 5% ко времени запуска активити

Сам посчитал или прикинул на глаз? Конкретно для рефлекшена класса твоей вьюхи?
Или как попугай повторил то что написал какой-то индус на stackoverflow? Если ты и так добавил выполнение какой-то long running task в main thread, и запуск активити от этого замедлился, то конечно рефлексия замедлит запуск «всего» на 5% от общего времени.
Играть со статистикой все умеют.

или лишние день-два-три на реализацию кастомной вьюхи

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

являющуюся полным дубликатом системной

Она не системная, а является частью сторонней либы.

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

ха-аах-ха.
Давай я тебе дам домашнее задание: используя сорсы ART/Dalvik, посчитай вычислительную сложность рефлекшена приватного поля или метода в зависимости от кол-ва полей/методов в классе и тд. Может тогда мозгов прибавится и будут брать не только в укр галеры.

Сам посчитал или прикинул на глаз? Конкретно для рефлекшена класса твоей вьюхи?

Да. 1 мс занимает снятие шифт мода с одного айтема нижнего меню.
5 айтемов — 5 мс плюс на запуск активити. Это 1/200 секунды. Ты способен отследить глазами такую задержку?

Она не системная, а является частью сторонней support либы.

Считаем её системной, т.к. либа написана разработчиком оси.

используя сорсы ART/Dalvik, посчитай вычислительную сложность рефлекшена приватного поля или метода в зависимости от кол-ва полей/методов в классе.

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

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

И, нет, вовсе не из желания «раскуркулить» клиента на несколько лишних человеко-часов. А банально потому, что «прибивание гвоздями» версии support lib — это не sustainable решение, которое может потом очень больно ударить, когда возникнет необходимость перейти на более новую версию support lib по другим объективным причинам.

А банально потому, что «прибивание гвоздями» версии support lib — это не sustainable решение, которое может потом очень больно ударить, когда возникнет необходимость перейти на более новую версию support lib по другим объективным причинам.

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

Такой подход череват не столько затратами на переименование, сколько тем, что некорректная работа рефлексии при смене версии библиотеки support lib может «стрельнуть» крэшем приложения в самый неподходящий момент просто потому, что в суматохе подготовки очередного релиза про этот «костыль» просто забыли.

Не заметить крэш при старте главного активити?)
Это по идее даже до QA не дойдёт, я это сразу увижу. И фиксится это 20 минут максимум.
Далее. Да, изменение версии саппорт либы — это сильный аргумент, но.
Мы понимаем разницу между «отредактировать рефлексией пару полей системной вьюхи из саппорт либы» и «полностью отказаться от кастомизации вьюх в пользу рефлекшн»?
Мне тут пытаются внушить религиозное верование, что рефлекшн — абсолютное зло, в оракле сидят идиоты, которые его придумали и т.п.
А я напоминаю, что BottomNavigationView — в общем, довольно гибкая и хорошо настраиваемая вьюха, альтернативу которой ещё поискать, а уж писать её самому — это отдельный проект внутри существующего. Т.к. сабкласснуть её не получится, интересуюшие поля там всё равно приватные и сабклассить вы будете в лучшем случае контейнер.
А теперь сравните этот гемор с редко возникающим, легко обнаружимым возможным крашем, который вообще не сложно пофиксить.
Нет, я не призываю всю работу с вьюхами запихнуть на рефлекшн, да, там уже можно попасть и на производительность в случае списков, и получить гемор из обновления сотни функций на рефлекшн, в случае смены версии либы, и вообще девайс-специфик крэши получить.
Но подход должен зависеть от ситуации, а не от религии лида, или архитектора.
Если вьюха мне подходит на 99%, умнее 1% её полей доработать рефлекшном, если это не скажется на производительности, чем создавать в проекте ещё один модуль, потом его саппортить, фиксить, людей для этого нанимать и т.п.
В случае, когда заказчику захотелось ещё и ещё фич, выходящих за возможности системной вьюхи, отут да, пора завязывать с рефлекшеном и писать за его деньги кастомную вьюху.
Нет универсальных подходов, которые хороши для всех без исключения ситуациях.

Не заметить крэш при старте главного активити

Если главного, тогда проще — первый же смоук тест выявит проблему. И, в таком случае, риск использовать рефлекшен может быть оправдан (хотя я бы все равно потребовал в gradle файле написать комментарий большими «красными» буквами там, где подключается конкретная версия support lib).

Если же это используется где-то внутри приложения, куда не каждый раз доходят смоуком или выборочной регрессией — тогда стрёмно. И тогда ещё неизвестно, что дороже — сделать кастомный bottom navigation view строго под нужды проекта, или оверхед на постоянную перепроверку этой активити.

P.S. Про impact-based regression, конечно же, в курсе, но в реалиях украинского аутсорса в способности разработчиков en masse делать тщательный impact analysis не очень верю.

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

А такой необходимости практически не возникает. Я же говорю, речь в контексте боттом навигейшн. Он всегда на основном экране.

Костыли и говнокод — это создавать кастомную вьюху, являющуюся полным дубликатом системной

флаттер это отдельный от андроида SDK, который для удобства из коробки предоставляет набор виджетов в material дизайне и к «системным вьюхам» андроида никакого отношения не имеет

это как утверждать, что какая-нибудь вьюха из material библиотеки для веба, это тоже костыль, потому что где-то там в андроиде есть её дубликат

Ой, можно подумать во флаттере странных вьюх, по которыми иногда нужно слегка пройтись рефлекшеном нет/не будет.

да потому что флатер хорош для небольших апок, как только у тебя большая апа и куча многопоточности, все пиши пропало, будешь с бубном вокруг флатера ходить
я уже получал фидбек от флатер разрабов на собесах, даже для среднего проекта это тупик

Учитывая, как далеко шагнула многопоточность в Котлине по сравнению с джавой и как там теперь всё легко, просто, понятно, нетребовательно к уровню разработчика и расширяемо, вообще не вижу смысла в ближайшие годы с него куда-то переходить.
Вот если Гугл таки разродится своей Фуксией, вытеснит ей Андроид с рынка с его миллионом версий с убогой обратной совместимостью, тогда да, посмотрим и потрогаем. И то, не факт, что они дарт там основным языком разработки сделают.
Но пока что Гуглу предстоит решить проблему с портингом без изменений всего миллиарда приложений вместе с длинной лабудой гугл плей сервисов на новую платформу, что мягко говоря, не выглядит тривиальной задачей.
Сколько уже «убийц Андроида» упокоились в истории... Бада, Бада 2, Тайзен, теперь вот Фуксия к ним готовится рядом прилечь))

Сколько уже «убийц Андроида» упокоились в истории... Бада, Бада 2, Тайзен, теперь вот Фуксия к ним готовится рядом прилечь))

Так вроде Tizen вполне себе жива (вон на офф. сайте пишут что в мае вышла версия 5.5). Правда до гордого статуса «убийца Андроида» ей конечно же далековато.
А насчет фуксии: когда она зарелизится, посмотрим что за фрукт. Вангую, что она просто будет существовать параллельно с андроидом. Например, андроид в основном на смартфонах, а фуксия в основном на чем-то другом.

насчет фуксии: когда она зарелизится, посмотрим что за фрукт. Вангую, что она просто будет существовать параллельно с андроидом. Например, андроид в основном на смартфонах, а фуксия в основном на чем-то другом.

Собственно, Гугл и сами говорили, что не планируют Фуксию как убийцу Андроида. Скорее, они её видят как ОС для разнообразных smart устройств.

Tizen, извините, на сегодня я видел только на смарт часах. И реально не понимаю, в чём там преимущество перед Андроидом. Т.к. под андроидные часы я могу живо наваять аппликуху, оформив её как модуль к телефонному/планшетному проекту и подправив лишь юай, переиспользовать всю или почти всю бизнес логику.
А на тайзене, емнип html5. Вы ещё поищите мобайл девелопера, который его знает и может на нём что-то написать. Я уж молчу про портинг бизнес-логики из мобильного приложения.

Tizen, извините, на сегодня я видел только на смарт часах. И реально не понимаю, в чём там преимущество перед Андроидом.

Думаю Тайзен не про преимущества над андроидом, а об альтернативности. Но в силу того, что почти весь рынок мобильных устройств захватилы гуглофоны и яблокофоны — все блэкджеки с девками выходят именно под них, а под тайзен видимо почти ничего нет, кроме официальных гайдов/доков/туториалов, Tizen Studio и Visual Studio Tools for Tizen ( developer.tizen.org/...​visual-studio-tools-tizen ).

А на тайзене, емнип html5.

Там вроде еще на С# / Xamarin можно.
developer.tizen.org/...​training/.net-application
docs.microsoft.com/...​orms/platform/other/tizen
Ну и на плюсах, естесно.

Вы ещё поищите мобайл девелопера, который его знает и может на нём что-то написать.

Ну вот тут хз, кто реально под тайзен пишет, кроме китайцев/корейцев)

Там вроде еще на С# / Xamarin можно.
developer.tizen.org/...​training/.net-application
docs.microsoft.com/...​orms/platform/other/tizen
Ну и на плюсах, естесно.

Кроссплатформа — не в счёт, это понятно, на ней под все можно.
Си — это вообще отдельная тема, на них пишутся модули для сложных вычислений, а не приложения. И это естественно, что ось позволяет подключать в приложение сишные либы. Со всеми их прелестями в виде привязки к архитектуре железа.
Хтмл5 там вроде основной язык разработки.
Кроме фронтендщиков его никто не знает. А их с JSа ещё стянуть надо и заставить тайзеном заниматься))

Ну тут все ж є свій рендер, яка для багатьох аплікух може бути і плюсом. Тому не обов’язково все будуть переписувати. Ніша є, і може виявитись немаленькою. Он скільки всяких вікторин та інтерактивних проектів (не ігор) на юніті роблять.

Много проектов, о которых я слышал, либо переписывают с реакта/кордовы, либо интегрируют Flutter в нативный проект для отрисовки интерфейса. Рейты соотвественно сохраняются. Если единственная мотивация перехода на флаттер — экономия денег тут и сейчас, то скорее всего рейты будут на соответствующем уровне без привязки к технологии.

ну вот хз, много ты сэкономишь на разметке? как долго ее делать? но зато интеграция с флатером сьест весь профит

Подписаться на комментарии