Согласен. Но часть этого времени уходит на передачу APK по ADB. Этап Installing apk длится достаточно долго если девайс общается с ПК по USB 2.0. Для отладки желательно иметь USB 3.0-3.1 type A или type C на ПК и девайс с type C с той же реализацией. Есть еще девайсы с USB 3.0 и type B, но из таких помню только SGS 5.
В общем, такая конфигурация дает большую вероятность того, что установка пройдет мгновенно т.к. медленные ПЗУ с контроллером 3.0 ставят редко. На руках Nokia 6.1. Время билда до полного запуска (проекта, который в статье) около 3х секунд.
В Вашем случае- да, она не основная. Но в других бизнесах Android-приложение является основным продающим в силу распостраненности.
Но я fluter попробовал и мне понравилось…
Так это же хорошо. Мне на самом деле идеи flutter тоже нравятся. Просто не хватает инструментов для широкомасштабного продакшена.
Я пишу всё это не потому, чтобы «окунуть flutter», а чтобы показать последствия выбора для девелопера и компаний. Если конкретно Вам он подходит (судя по описанной Вами ситуации- да, вполне, закрытое использование)- это прекрасно! Делайте в своё удовольствие.
Просто конкретно я побоялся бы использовать flutter для серьезного коммерческого приложения. По крайней мере сейчас.
BTW. Посмотрите на Kotlin. На нем мы всей компанией пишем.
LinearLayoutManager.setReverseLayout(true);//меняем направление
LinearLayoutManager.setStackFromEnd(true);//меняем начало компоновки (если надо точь в точь)
Да, две строчки, но и возможность менять край компоновки полезна. А можно и не менять и будет как начало переписки в старом вайбере. В любом случае- так же легко.
На Android под MD тоже складывается такое ощущение. Что поделать- свой рендер.
Но на самом деле это не критично. Посмотрите на huawei, meizu, xiaomi- их оболочки делают всё, чтобы пользователь не понимал чем пользуется. И прокатывает. Если большинству пользователей айфона дать huawei или meizu, предварительно заклеив задник- то те свято будут уверены что это- другая модель айфона. Большинство не видит разницы в упор.
Это не очень дорогая цена кроссплатформенности и скорости разработки.
Я уже объяснял выше, почему там (по крайней мере сейчас) не может быть той скорости разработки, что у двух команд нативщиков.
В чем ужас — если не секрет?
Ужас в том, что крайне много востребованных модулей, не дошедших до версии 1.0. А так же большинство не предоставляют нужного функционала. Например, в модулях, которые работают с местоположением, все поголовно забывают о settings dialog (который крайне необходим для качественной работы местоположения). Тут можно долго продолжать, но соль в том, что модули либо не доработаны либо их возможностей не хватает для коммерческого применения.
Несомненно, в каждом приложении должны быть карты гугла.
Очень часто требуется. И сейчас, просто ради кластеризации, придется писать собственный модуль.
А это что? И это?
Напомню, что указанное Вами решение не релизное и нестабильно. И, насколько я понял, не совместимо с Flutter (посмотрите dartson). Вот что написано в доках:
Is there a GSON/Jackson/Moshi equivalent in Flutter?
The simple answer is no.
Such a library would require using runtime reflection, which is disabled in Flutter.
Конечно же для дарта нет http-клиентов, ога.
Не путайте http-клиенты и REST api-клиенты. Chopper, конечно, уже похож на retrofit, но сериализация и десериализация там предполагается ручная.
Куча приложений гугла (да и не только) для айфона в материал-дизайне говорят об обратном. Да и вообще флаттер не диктует делать именно material-design.
Да, но MD предлагается из коробки. Выходит, что писать только под MD или cocoa вредит UX, писать два варианта лейаутов- время и нет смысла, писать свой дизайн- разрабатывать UX и гайды\схемы что долго и дорого. То, что google на iOS с MD- так google сервисный гигант и может позволить себе консистентность. Сервисам по-меньше это вредит.
Зато на Java быстро, плюс на java одни приложения-не-витрины, да и говнокодеров нет, ага.
Относительно быстрее. Вас тормозит синтаксис- берите kotlin. Большинство известных коммерческих приложений- нативные. Копрокодеров везде хватает, но в Dart с его потокобезопасностью выстрелить себе в ногу проще.
В следующий раз, прежде чем вбрасывать
Простите, но скорее Вы не знаете инструмент, с которым работаете.
По поводу 7mb ответил выше. Даже в сравнении 2gis на qt цифра внушительная.
По поводу модулей- да, они появятся. Но речь шла о том, что можно разрабатывать под flutter быстро сегодня. Но нет достаточного количества дошедших до первой версии модулей для этого. И потом- многих инструментов просто не будет из-за текущих ограничений Dart и механизма сборки flutter. В общем бонусы по скорости сомнительны.
Официальный google maps в стадии Developers Preview версии 0.0.3. В здравом уме в продакшен такое не возьмут.
Да, можно разработать два лейаута для android и iOS, а из-за разных UX-парадигм еще и разную presentation и business-логику. Тогда на кой нужен flutter если 70 и больше процентов кода будут платформозависимы? Две команды нативщиков справятся с этим качественнее и быстрее
И это я не упомянул про то, что в Dart, в плане потокобезопасности (да и не только), гораздо проще выстрелить себе в ногу, чем в kotlin\java, что ведет к дополнительным отладкам и спящим багам. В нативе с этим куда проще
В случае iOS вы, возможно, правы. Но я говорил об Android:
Сhrome Beta: 53mb
Adobe Photoshop Express: 61mb
Это из тяжелого. А если смотреть оптимизированные:
Клиент хабра: 12mb
Твиттер: 19mb
WhatsApp: 20mb
Telegram: 15mb
Даже 2gis на увесистом QT- 36mb
Потому 7mb, внезапно, становятся половиной\третью\четвертью от хорошего коммерческого приложения и такая цифра может быть критична. А с развитием flutter эта цифра будет только расти
Это всё, конечно, хорошо. Но давайте смотреть реально на вещи.
Сразу скажу что я- Android-нативщик и мне тоже пришлось изучать Flutter. 7 mb для hello world release, на мой взгляд, многовато. Модули для flutter сейчас- тихий ужас. Для сколь либо вменяемого функционала придется писать свои, что требует знаний iOS и Android в идеале двумя разными людьми, поскольку «универсальщик» не способен выдать качественного решения. Полноценная работа с гуглокартами- забудьте. В готовых модулях нет ничего похожего. ORM, OODB- забудьте. в Dart нет рефлексии, полноценных кодогенераторов тоже. json-маппинг- забудьте. причина выше. REST? пиши руками! нет аналогов ретрофиту.
В конце концов, у пользователей обеих платформ разный UX и ходить на iOS с material design нехорошо.
В итоге- утверждение, что сейчас можно делать на flutter быстро и дешево применимо, разве что, к штампованным приложениям-витринам. Для сколь либо серьезных проектов это утверждение смехотворно. Да, красиво. Но жирно, долго и неправильно.
Может быть когда нибудь (например с приходом фуксии) flutter обзаведется приличными инструментами, но сейчас этого нет.
Пользовался BlueStacks когда-то. Хорошая штука. Во многих моментах эмуляция качественнее и быстрее аналогов. Большое спасибо разрабам.
Раздражали, разве что три, момента
1. Долгий старт (даже с SSD)
2. Нельзя выставить некоторые разрешения (типа HD Ready 1366x768), при этом скалирование на windows не работает
3. Реализация некоторых api сильно изменена (видимо ради производительности). В итоге отлаживать на нем приложения, которые много используют системные api и Play Services, становится проблемно- результаты непредсказуемы.
Кстати, возможно, кому-то подойдет просто низкопрофильная мышь? У меня раньше была какая-то a4tech классическая (с хватом ладонью). Да, запястье устает и ноет. Но тогда особого внимания этому не уделял. Потом купил MS Desinger Mouse. Просто потому, что понравилась) Она низкопрофильная и ложится не в ладонь а под пальцы, от того кисть имеет более прямое положение (тут, правда еще зависит от высоты стола\кресла). И да, уже два года пользуюсь, запястью хорошо) Если не нравится MS- есть аналоги от, например, HP и других фирм
На самом деле давно уже не писал на Java- проекты довольно необычные, часто приходится переключаться на C, а в основе уже везде Kotlin.
И я написал это потому, что дожился до написания собственных интерпретаторов и виртуальных машин (не для JS. проприетарщина). И примерно с этого момента начинаешь понимать, что реализации слабой типизации без ЖЦ, или, например stateless- они все имеют ряд именно концептуальных проблем.
Да, разные реализации софта на JS будут показывать разную производительность. И на машине с i5 и выше, Вы, скорее всего, не заметите разницы в работе одной и той же простой логики на JS и Java и нативе. Но, чем логика жирнее, и чем машина слабее- тем больше будет проявляться разница.
Факт в том, что так или иначе- чтобы JS вращался нужно больше ресурсов. Ведь JS-примитив содержит больше информации, чем, например, C-примитив. Плюс нужно больше компонент, чтобы этот примитив обслуживать, адресовать. И это всё добро, призванное облегчить жизнь разрабу, надо где-то хранить. Конечно же, в оперативе пользователя.
Так что нет- одна и та же логика не может работать одинаково быстро на JS\Java\C чисто математически.
Со Slack другая проблема- ни Electron ни JS сам по себе не могут корректно работать с ЖЦ Win\Mac\etc… И не смогут- JS разработан дня веба, для него предназначен, и в нем должен оставаться. Попытки запихнуть JS в приложение- это как ехать на санках по асфальту летом- это реально, но не эффективно. Но дешево, если под рукой только санки. Так что, люди в Slack не криворукие, просто (слишком) экономные
Это, конечно, всё очень далеко от реальности…
Не поймите не верно- я сам android-разраб и пишу исключительно натив, и у меня JS-приложения тоже вызывают негодование.
Но IT правит бизнес. И только бизнес. И он двигает индустрию, разработчики к этому не причастны.
И вот когда начинаешь считать деньги- выясняется, что JS-приложения очень дешево обходятся. В том числе и с косяками. А еще выясняется, что время разработчика стоит дороже вычислительных ресурсов пользователя. Точнее эти ресурсы для бизнеса бесплатны почти совсем. И этими ресурсами бизнес расплачивается за скорость и дешевизну JS-фреймворков.
И тут два выхода:
1. Заставить бизнес платить за ресурсы пользователя. Не знаю чем и как, но это бы сделало фактор реально важным. Минус- много игроков уйдут с рынка
2. Стандартизировать API или вообще заставить всех поддерживать JS. Но тут минусов еще больше:
Все перейдут на что-то типа Chrome OS и конкурировать останется мало чем.
Внезапно выяснится, что подход с реализацией интерпретируемого языка с нестрогой типизацией сам по себе затратен. Ведь для системы уже нет разницы между Boolean и String. Экономить просто не на чем. Плюс в JS придется вводить много жизненного цикла сущностей, к чему он просто не готов. На выходе получаем неповоротливую тупую монстро-ось, но зато да- в JS локально можно будет из коробки, да. И бизнесу обойдется в копейки.
Вывод прост- в мире пишется много хороших, быстрых и экономных софтин. Но если общество привыкло есть фекалии кактус- то и вам придется. Иначе вы окажетесь отрезаны от благ общества частично или полностью.
Всё верно, там приведен пример отдельного запуска activity и дальнейшего переиспользования кода. А когда таких активити будет много? А когда там будет работа с различными payload? А если другую (уже имеющуюся) активити проще вызвать сразу, а не городить новый стек? А если захочется еще и в recents сохранять?
Какой же это тогда single activity?
Поймите правильно, подавляющее большинство задач можно реализовать обоими путями, но не надо позиционировать свой подход как «истинно верный»…
На мой взгляд, надо брать то, что дает меньше сопротивления в каждом конкретном случае
В общем, такая конфигурация дает большую вероятность того, что установка пройдет мгновенно т.к. медленные ПЗУ с контроллером 3.0 ставят редко. На руках Nokia 6.1. Время билда до полного запуска (проекта, который в статье) около 3х секунд.
Так это же хорошо. Мне на самом деле идеи flutter тоже нравятся. Просто не хватает инструментов для широкомасштабного продакшена.
Я пишу всё это не потому, чтобы «окунуть flutter», а чтобы показать последствия выбора для девелопера и компаний. Если конкретно Вам он подходит (судя по описанной Вами ситуации- да, вполне, закрытое использование)- это прекрасно! Делайте в своё удовольствие.
Просто конкретно я побоялся бы использовать flutter для серьезного коммерческого приложения. По крайней мере сейчас.
BTW. Посмотрите на Kotlin. На нем мы всей компанией пишем.
Да, две строчки, но и возможность менять край компоновки полезна. А можно и не менять и будет как начало переписки в старом вайбере. В любом случае- так же легко.
Но на самом деле это не критично. Посмотрите на huawei, meizu, xiaomi- их оболочки делают всё, чтобы пользователь не понимал чем пользуется. И прокатывает. Если большинству пользователей айфона дать huawei или meizu, предварительно заклеив задник- то те свято будут уверены что это- другая модель айфона. Большинство не видит разницы в упор.
Ужас в том, что крайне много востребованных модулей, не дошедших до версии 1.0. А так же большинство не предоставляют нужного функционала. Например, в модулях, которые работают с местоположением, все поголовно забывают о settings dialog (который крайне необходим для качественной работы местоположения). Тут можно долго продолжать, но соль в том, что модули либо не доработаны либо их возможностей не хватает для коммерческого применения.
Очень часто требуется. И сейчас, просто ради кластеризации, придется писать собственный модуль.
Напомню, что указанное Вами решение не релизное и нестабильно. И, насколько я понял, не совместимо с Flutter (посмотрите dartson). Вот что написано в доках:
Не путайте http-клиенты и REST api-клиенты. Chopper, конечно, уже похож на retrofit, но сериализация и десериализация там предполагается ручная.
Да, но MD предлагается из коробки. Выходит, что писать только под MD или cocoa вредит UX, писать два варианта лейаутов- время и нет смысла, писать свой дизайн- разрабатывать UX и гайды\схемы что долго и дорого. То, что google на iOS с MD- так google сервисный гигант и может позволить себе консистентность. Сервисам по-меньше это вредит.
Относительно быстрее. Вас тормозит синтаксис- берите kotlin. Большинство известных коммерческих приложений- нативные. Копрокодеров везде хватает, но в Dart с его потокобезопасностью выстрелить себе в ногу проще.
Простите, но скорее Вы не знаете инструмент, с которым работаете.
По поводу модулей- да, они появятся. Но речь шла о том, что можно разрабатывать под flutter быстро сегодня. Но нет достаточного количества дошедших до первой версии модулей для этого. И потом- многих инструментов просто не будет из-за текущих ограничений Dart и механизма сборки flutter. В общем бонусы по скорости сомнительны.
Официальный google maps в стадии Developers Preview версии 0.0.3. В здравом уме в продакшен такое не возьмут.
Да, можно разработать два лейаута для android и iOS, а из-за разных UX-парадигм еще и разную presentation и business-логику. Тогда на кой нужен flutter если 70 и больше процентов кода будут платформозависимы? Две команды нативщиков справятся с этим качественнее и быстрее
И это я не упомянул про то, что в Dart, в плане потокобезопасности (да и не только), гораздо проще выстрелить себе в ногу, чем в kotlin\java, что ведет к дополнительным отладкам и спящим багам. В нативе с этим куда проще
Сhrome Beta: 53mb
Adobe Photoshop Express: 61mb
Это из тяжелого. А если смотреть оптимизированные:
Клиент хабра: 12mb
Твиттер: 19mb
WhatsApp: 20mb
Telegram: 15mb
Даже 2gis на увесистом QT- 36mb
Потому 7mb, внезапно, становятся половиной\третью\четвертью от хорошего коммерческого приложения и такая цифра может быть критична. А с развитием flutter эта цифра будет только расти
Сразу скажу что я- Android-нативщик и мне тоже пришлось изучать Flutter.
7 mb для hello world release, на мой взгляд, многовато.
Модули для flutter сейчас- тихий ужас. Для сколь либо вменяемого функционала придется писать свои, что требует знаний iOS и Android в идеале двумя разными людьми, поскольку «универсальщик» не способен выдать качественного решения.
Полноценная работа с гуглокартами- забудьте. В готовых модулях нет ничего похожего.
ORM, OODB- забудьте. в Dart нет рефлексии, полноценных кодогенераторов тоже.
json-маппинг- забудьте. причина выше.
REST? пиши руками! нет аналогов ретрофиту.
В конце концов, у пользователей обеих платформ разный UX и ходить на iOS с material design нехорошо.
В итоге- утверждение, что сейчас можно делать на flutter быстро и дешево применимо, разве что, к штампованным приложениям-витринам. Для сколь либо серьезных проектов это утверждение смехотворно. Да, красиво. Но жирно, долго и неправильно.
Может быть когда нибудь (например с приходом фуксии) flutter обзаведется приличными инструментами, но сейчас этого нет.
Раздражали, разве что три, момента
1. Долгий старт (даже с SSD)
2. Нельзя выставить некоторые разрешения (типа HD Ready 1366x768), при этом скалирование на windows не работает
3. Реализация некоторых api сильно изменена (видимо ради производительности). В итоге отлаживать на нем приложения, которые много используют системные api и Play Services, становится проблемно- результаты непредсказуемы.
В 4 версии есть с этим прогресс?
И я написал это потому, что дожился до написания собственных интерпретаторов и виртуальных машин (не для JS. проприетарщина). И примерно с этого момента начинаешь понимать, что реализации слабой типизации без ЖЦ, или, например stateless- они все имеют ряд именно концептуальных проблем.
Да, разные реализации софта на JS будут показывать разную производительность. И на машине с i5 и выше, Вы, скорее всего, не заметите разницы в работе одной и той же простой логики на JS и Java и нативе. Но, чем логика жирнее, и чем машина слабее- тем больше будет проявляться разница.
Факт в том, что так или иначе- чтобы JS вращался нужно больше ресурсов. Ведь JS-примитив содержит больше информации, чем, например, C-примитив. Плюс нужно больше компонент, чтобы этот примитив обслуживать, адресовать. И это всё добро, призванное облегчить жизнь разрабу, надо где-то хранить. Конечно же, в оперативе пользователя.
Так что нет- одна и та же логика не может работать одинаково быстро на JS\Java\C чисто математически.
Со Slack другая проблема- ни Electron ни JS сам по себе не могут корректно работать с ЖЦ Win\Mac\etc… И не смогут- JS разработан дня веба, для него предназначен, и в нем должен оставаться. Попытки запихнуть JS в приложение- это как ехать на санках по асфальту летом- это реально, но не эффективно. Но дешево, если под рукой только санки. Так что, люди в Slack не криворукие, просто (слишком) экономные
Не поймите не верно- я сам android-разраб и пишу исключительно натив, и у меня JS-приложения тоже вызывают негодование.
Но IT правит бизнес. И только бизнес. И он двигает индустрию, разработчики к этому не причастны.
И вот когда начинаешь считать деньги- выясняется, что JS-приложения очень дешево обходятся. В том числе и с косяками. А еще выясняется, что время разработчика стоит дороже вычислительных ресурсов пользователя. Точнее эти ресурсы для бизнеса бесплатны почти совсем. И этими ресурсами бизнес расплачивается за скорость и дешевизну JS-фреймворков.
И тут два выхода:
1. Заставить бизнес платить за ресурсы пользователя. Не знаю чем и как, но это бы сделало фактор реально важным. Минус- много игроков уйдут с рынка
2. Стандартизировать API или вообще заставить всех поддерживать JS. Но тут минусов еще больше:
Все перейдут на что-то типа Chrome OS и конкурировать останется мало чем.
Внезапно выяснится, что подход с реализацией интерпретируемого языка с нестрогой типизацией сам по себе затратен. Ведь для системы уже нет разницы между Boolean и String. Экономить просто не на чем. Плюс в JS придется вводить много жизненного цикла сущностей, к чему он просто не готов. На выходе получаем неповоротливую тупую монстро-ось, но зато да- в JS локально можно будет из коробки, да. И бизнесу обойдется в копейки.
Вывод прост- в мире пишется много хороших, быстрых и экономных софтин. Но если общество привыкло есть
фекалиикактус- то и вам придется. Иначе вы окажетесь отрезаны от благ общества частично или полностью.Когда будет отдельный проект- то тогда и будет отдельное полноценное приложение. До тех пор у Вас есть логика, которую можно переиспользовать
Какой же это тогда single activity?
Поймите правильно, подавляющее большинство задач можно реализовать обоими путями, но не надо позиционировать свой подход как «истинно верный»…
На мой взгляд, надо брать то, что дает меньше сопротивления в каждом конкретном случае