Ага, и лично у меня после ознакомления с этим зоопарком возникло одно простое чувство: "а гори они все!.. В принципе, и setState сам по себе довольно хорош."
Ох, в своё время наелся я этими гибридами так, что даже и близко не хочу подходить, если клиенту требуется полноценное мобильное приложение.
Сам я бэкенд разработчик, но несколько раз в сложных ситуациях приходилось затаскивать мобильную разработку, имея в распоряжении команду, работающую со стеком "для сайтостроя". То есть единственным выходом в моем случае было выбрать технологию, на которой интерфейс можно тупо сверстать, а нативный функционал получить плагинами.
С чем бы я ни работал - чистый PhpneGap, DrupalGap, Ionic (2016 года выпуска) - во всех случаях полученный результат напоминал поделку на коленке, а не полноценное приложение. Несмотря на то, что к разработке со стороны фронтенда привлекалась сильная команда ни с одним крутым проектом за спиной.
И проблемы везде одни и те же:
Всё крутится в браузере. А движки везде разные. Где-то web view одной версии, где-то другой, какие-то мелкие ньюансы они рендерят по-разному. Конечно на демо-приложениях это не видно, но в продакшнне у требовательного корпоративного или гос-клиента......
Плагины. И мало того, что есть они далеко не на все случаи жизни, так ещё и на разных платформах по-разному работают, если вообще от одного автора есть под всё платформы этот плагин. В итоге получаем платформо-зависимый код, хотя нам обещали, что его не будет...
Отклик интерфейса, вообще внешний вид. Он медленный. Прямо вот видно, что это какой-то веб-сайт, даже если клики на ссылках не подсвечиваются визуально (на некоторых устройствах они всегда подсвечиваются, выделяя ссылку, и сразу становится ясно, что это тупо сайт)
В целом набор возможностей. Например, в одном проекте у нас в дизайне были карты и кнопка, чтобы восстановить ориентацию "на север". Позже клиенту предстояло узнать, что на Ionic такого мы никогда не сделаем.
JavaScript и среда выполнения. Всё-таки браузер - не лучшее место для обширной логики, кучи асинхронных операций, включая коммуникацию по REST. Особенно если это браузер на доходом мобильном устройстве с дохленьким процессором и короткой памятью.
По каждому из пунктов можно нырнуть внутрь и "набомбить" ещё с десяток подпунктов и историй об их взаимосвязи, но, наверное,ине в формате комментария.
Итого, мне вообще удивительно, что эти "гибридные" решения всё ещё развиваются в качестве отдельных продуктов, ориентированных на мобайл. Одно дело, когда твой фреймворк позволяет делать адаптивные сайты с возможностью какой-то работы оффлайн, тут требования ниже.
А Ionic и аналоги, по сути, это фреймворки, которые были бы хороши для разработки мобильных сайтов, но вводят нас в заблуждение, обещая, что отлично будут решать поставленные задачи и узконаправленно на мобилках.
В общем, моё мнение - просто не нужно использовать ЭТО для мобильной разработки. Ни вчера, ни сегодня, ни через годы. Лучше оно не станет, ведь все болячки прописаны в их "генетическом коде".
Давеча залез я пет-проект дописывать, и чувствую, что оооочень много скроллю в одном из виджетов, ещё и не понимаю, в каком участке кода нахожусь - просто IDE меня как-то выбрасывает сама, куда нужно, но я уже логически свои перемещения не контролирую. Нездоровая ситуация.
Ладно, думаю, код этого экрана слишком раздут, очевидно, что там недавно писали про ViewModel - дай попробую, вдруг поможет. Почитал про эту прослойку. Потом посмотрел на свой код... ага, так... тут у нас методы, которые представляют собой вообще сервис без состояния... ну и выносим их в сервис без состояния тогда. Так, а вот эта простыня оборачивается в три stateless-виджета. Чудненько. Что в итоге у меня в Stateful-виджете остаётся? Конструктор Scaffold и пару колбэков на кнопки в нём. И вызовы вышеупомянутых сервисов и виджетов.
Можно сказать, что в моём конкретном случае этот паттерн не подошел, и это будет абсолютно верным ответом.
Другой полярный пример, из моего же пет-проекта. Создавал я его из интереса на основе "шаблонного проекта", который разработчики Flutter в какой-то момент сделали в качестве примера "как надо делать". Ну и там для хранения настроек был сделан и экран настроек, контроллер для сохоранения настроек. который дёргает сервис для сохранения настроек... идеологически - правильно, но фактически у меня теперь в этих трёх классах гора копипаста, несчастная переменная гоняется из одного класса в другой и в третий, а потом в обратную сторону, и всё потому что чисто идеологически - это разные слои, абстракция от конкретной реализации и всё такое.... Слделало ли слепое следование методологии мою жизнь счастливее, а мой код - красивее и качественнее? Точно нет)) Только привело к едва одолимому желанию отрефакторить это всё, выбросив лишние слои и завернув всё это в один сервис. Пока терплю, потому что на работе приложения никак не сказывается, а количество настроект и так достигло своего предполагаемого лимита.
Конечно, это всё пет-проекты и "несерьёзно", можно не "засчитывать", но мне кажется, 11я заповедь "не упарывайся" справедлива для любых масштабов.
Я вообще из бэкенда, ещё и динозавр немного, поэтому моё мнение тут ну разве что для статистики.
В целом, глядя на мобильную и фронтенд-разработку, возникает чувство, что как-то перебор там с разными паттернами и подходами... точнее не так. Мучает ощущение, что "паттернов" и "подходов" стало сильно больше, чем собственно, решения конкретной клиентской задачи. Естественно, они не просто так появились, и призваны решать какие-то насущные задачи в конечном итоге, ещё б я этого не понимал. Но в самом деле, когда приходишь в проект или начинаешь новый - всегда ведь хочется, чтобы задачи решались там просто и очевидно, без ритуальных танцев вокруг идеологически правильной архитектуры.
К чему я это? Если классов и слоёв станет меньше без ущерба для поддерживаемости и функциональности приложения, мы же все только выиграем. Так пусть же их и станет меньше!)) Вот.
Какое-то будущее, безусловно есть. Я сам на PHP долгие годы писал, а сейчас ради интереса завел себе пет-проект на Dart, где есть телеграмм-бот и rest-сервер. В целом писать приятно, языком доволен и качеством его работы в продакшене, хотя до бенчмарков дело не дошло. Но вот по наличию типичных для той же пыхи библиотек дарт безнадёжно проигрывает. И, думаю. и будет проигрывать дальше, ведь фокус самих разработчиков языка сейчас направлен на фронтенд и мобилку, для сервера делаются самые минимальные вещи, многие библиотеки пишутся в комьюнити, им же потом и забрасываются в полуфабрикатном состоянии, когда задача автора решена и больше ему ничего не надо.
В целом, думаю, Dart имеет право на жизнь в продакшене на сервере, но в силу медленно развивающейся экосистемы его ниша будет крайне узка, по крайней мере ближайшие годы.
Не советую сильно верить в GPS. Он мне как-то на беговых лыжах выдал скорость под сотку , ещё было несколько случаев "телепортации", причем на разных девайсах. Хотя там и правда скорость была приличная, но система явно не была к ней готова :-)
Вот да, с самокатчиками проблема действительно животрепещущая! На веле хоть скорость ограничена физическими возможностями велосипедиста, чтобы «гонять» — ещё постараться надо, плюс научиться обращаться со скоростями, держать равновесие… На роликах — тоже, скилл и асфальт. На логнборде. На моноколесе даже! Везде хоть какой-то входной порог. А для электросамоката не нужно ни физухи ни мозгов, просто жми на газ и лети с ветерком… К тому же часто они даже не сигналят при обгоне, сделаешь случайно шаг в сторону на своём «законном» тротуаре — и этот снаряд тебя снесёт, мало не покажется.
На сайте указан ИНН 7743304604… Пробиваем его по интернету и видим вообще другие имена учредителей, виды деятельности… Мне кажется, молодой человек явно что-то не договаривает про причины своего успеха :-)
Я не хочу об этом каждый раз думать, тем более что большей части загрузок так и суждено сгинуть во временной папке после разового использования — филиал корзины, в общем))
Эмм… папка загрузок — временная локация, после загрузки надо перенести файл на ПМЖ: музыку в музыку, картинку к картинкам, документы к документам, а документы по работе — к другим документам… Приложения — в папку-песочницу, из которой разрешен запуск приложений и т.п. Или отправить через какой-нибудь месседжнер, или даже перетянуть обратно в браузер, чтобы залить в облако. Кейсов куча, в общем,
<trololo>возможно, вы просто слишком мало пользуетесь интернетом </trololo>
Как раз закончил писать небольшой телеграмм-бот с использованием null-safety, чувства остались смешанные. С одной стороны, я рад, что система подсвечивает мне случаи, которые я, скорее всего, пропустил бы. С другой, такого количества ручных проверок на null в моём коде не было никогда, и это раздражает)) хотя не исключаю, что я как-то не так в целом всё спроектировал…
Наличие большого количества пакетов, не поддерживающих null-safety, также на данном этапе усложняет жизнь. То анализатор заставляет делать проверки там, где они ну точно не нужны, а то предлагает отказаться от "лишней" проверки там, где ну точно может выскочить null. Со временем это, конечно, пройдет, но на данный момент…
А ещё Android Studio пока не умеет запускать тесты в null-safety проектах, приходится вручную через консоль. Ну, мелочь, в целом.
Мне кажется, на данный момент в проектах, не являющихся библиотеками, лучше не использовать null-safety, пока на неё не мигрирует большинство зависимостей. Но я в языке новичок, могу ошибаться, конечно)) А в пет-проектах любые эксперименты хороши.
В целом изменение позитивное, чем больше ошибок обнаружится до запуска, тем лучше!
Может, она и правда проходит, но с геологической скоростью, ведь быть большим, важным и всегда самым-самым умным для многих так привлекательно! Да и просто-напросто полоса вполне честных достижений порой кружит голову даже хорошим, в сущности, людям. Силе темной стороны сложно противостоять))
Что меня в своё время заставило писать код качественно и стуктурированно — это моя дырявая память, когда не помнишь не то что стороннюю либу, но и свой функционал забываешь, если он нелогичен.
А вот с другой стороны, я сейчас читаю статью с мобильника и несказанно рад качеству картинок с читабельным на небольшом экране листингами — без переносов и горизонтальной прокрутки, которые скорее всего вылезут, если делать текстом.
Может-может, кстати, в бытовых и рабочих вопросах регулярно подделывает: когда ты только хотел что-то сказать, но думаешь, что уже сказал, или ждал услышать определённый ответ, а кажется, что уже услышал — и ходите потом, доказываете друг другу с пеной у рта, а потом извиняетесь за получившийся казус:-)
Очень похоже на моём древнем Toshiba, во многом из-за клавы не могу с него слезть, так и работаю. Во-первых, ISO-клавиатуру на ультрабуке теперь фиг найдёшь, во-вторых все так и норовят Home, PgUp, PgDn, End и кнопку вызова меню прирезать…
Ага, и лично у меня после ознакомления с этим зоопарком возникло одно простое чувство: "а гори они все!.. В принципе, и setState сам по себе довольно хорош."
Ох, в своё время наелся я этими гибридами так, что даже и близко не хочу подходить, если клиенту требуется полноценное мобильное приложение.
Сам я бэкенд разработчик, но несколько раз в сложных ситуациях приходилось затаскивать мобильную разработку, имея в распоряжении команду, работающую со стеком "для сайтостроя". То есть единственным выходом в моем случае было выбрать технологию, на которой интерфейс можно тупо сверстать, а нативный функционал получить плагинами.
С чем бы я ни работал - чистый PhpneGap, DrupalGap, Ionic (2016 года выпуска) - во всех случаях полученный результат напоминал поделку на коленке, а не полноценное приложение. Несмотря на то, что к разработке со стороны фронтенда привлекалась сильная команда ни с одним крутым проектом за спиной.
И проблемы везде одни и те же:
Всё крутится в браузере. А движки везде разные. Где-то web view одной версии, где-то другой, какие-то мелкие ньюансы они рендерят по-разному. Конечно на демо-приложениях это не видно, но в продакшнне у требовательного корпоративного или гос-клиента......
Плагины. И мало того, что есть они далеко не на все случаи жизни, так ещё и на разных платформах по-разному работают, если вообще от одного автора есть под всё платформы этот плагин. В итоге получаем платформо-зависимый код, хотя нам обещали, что его не будет...
Отклик интерфейса, вообще внешний вид. Он медленный. Прямо вот видно, что это какой-то веб-сайт, даже если клики на ссылках не подсвечиваются визуально (на некоторых устройствах они всегда подсвечиваются, выделяя ссылку, и сразу становится ясно, что это тупо сайт)
В целом набор возможностей. Например, в одном проекте у нас в дизайне были карты и кнопка, чтобы восстановить ориентацию "на север". Позже клиенту предстояло узнать, что на Ionic такого мы никогда не сделаем.
JavaScript и среда выполнения. Всё-таки браузер - не лучшее место для обширной логики, кучи асинхронных операций, включая коммуникацию по REST. Особенно если это браузер на доходом мобильном устройстве с дохленьким процессором и короткой памятью.
По каждому из пунктов можно нырнуть внутрь и "набомбить" ещё с десяток подпунктов и историй об их взаимосвязи, но, наверное,ине в формате комментария.
Итого, мне вообще удивительно, что эти "гибридные" решения всё ещё развиваются в качестве отдельных продуктов, ориентированных на мобайл. Одно дело, когда твой фреймворк позволяет делать адаптивные сайты с возможностью какой-то работы оффлайн, тут требования ниже.
А Ionic и аналоги, по сути, это фреймворки, которые были бы хороши для разработки мобильных сайтов, но вводят нас в заблуждение, обещая, что отлично будут решать поставленные задачи и узконаправленно на мобилках.
В общем, моё мнение - просто не нужно использовать ЭТО для мобильной разработки. Ни вчера, ни сегодня, ни через годы. Лучше оно не станет, ведь все болячки прописаны в их "генетическом коде".
Ну или вот если вернуться к теме поста...
Давеча залез я пет-проект дописывать, и чувствую, что оооочень много скроллю в одном из виджетов, ещё и не понимаю, в каком участке кода нахожусь - просто IDE меня как-то выбрасывает сама, куда нужно, но я уже логически свои перемещения не контролирую. Нездоровая ситуация.
Ладно, думаю, код этого экрана слишком раздут, очевидно, что там недавно писали про ViewModel - дай попробую, вдруг поможет. Почитал про эту прослойку. Потом посмотрел на свой код... ага, так... тут у нас методы, которые представляют собой вообще сервис без состояния... ну и выносим их в сервис без состояния тогда. Так, а вот эта простыня оборачивается в три stateless-виджета. Чудненько. Что в итоге у меня в Stateful-виджете остаётся? Конструктор Scaffold и пару колбэков на кнопки в нём. И вызовы вышеупомянутых сервисов и виджетов.
Можно сказать, что в моём конкретном случае этот паттерн не подошел, и это будет абсолютно верным ответом.
Другой полярный пример, из моего же пет-проекта. Создавал я его из интереса на основе "шаблонного проекта", который разработчики Flutter в какой-то момент сделали в качестве примера "как надо делать". Ну и там для хранения настроек был сделан и экран настроек, контроллер для сохоранения настроек. который дёргает сервис для сохранения настроек... идеологически - правильно, но фактически у меня теперь в этих трёх классах гора копипаста, несчастная переменная гоняется из одного класса в другой и в третий, а потом в обратную сторону, и всё потому что чисто идеологически - это разные слои, абстракция от конкретной реализации и всё такое.... Слделало ли слепое следование методологии мою жизнь счастливее, а мой код - красивее и качественнее? Точно нет)) Только привело к едва одолимому желанию отрефакторить это всё, выбросив лишние слои и завернув всё это в один сервис. Пока терплю, потому что на работе приложения никак не сказывается, а количество настроект и так достигло своего предполагаемого лимита.
Конечно, это всё пет-проекты и "несерьёзно", можно не "засчитывать", но мне кажется, 11я заповедь "не упарывайся" справедлива для любых масштабов.
Ну да возраста у меня только на мелкого падальщика, до серьёзного ящера ещё не дорос :-)
Я вообще из бэкенда, ещё и динозавр немного, поэтому моё мнение тут ну разве что для статистики.
В целом, глядя на мобильную и фронтенд-разработку, возникает чувство, что как-то перебор там с разными паттернами и подходами... точнее не так. Мучает ощущение, что "паттернов" и "подходов" стало сильно больше, чем собственно, решения конкретной клиентской задачи. Естественно, они не просто так появились, и призваны решать какие-то насущные задачи в конечном итоге, ещё б я этого не понимал. Но в самом деле, когда приходишь в проект или начинаешь новый - всегда ведь хочется, чтобы задачи решались там просто и очевидно, без ритуальных танцев вокруг идеологически правильной архитектуры.
К чему я это? Если классов и слоёв станет меньше без ущерба для поддерживаемости и функциональности приложения, мы же все только выиграем. Так пусть же их и станет меньше!)) Вот.
Сам давно не пишу, но у своих коллег в коде - видел :-)
Какое-то будущее, безусловно есть. Я сам на PHP долгие годы писал, а сейчас ради интереса завел себе пет-проект на Dart, где есть телеграмм-бот и rest-сервер. В целом писать приятно, языком доволен и качеством его работы в продакшене, хотя до бенчмарков дело не дошло. Но вот по наличию типичных для той же пыхи библиотек дарт безнадёжно проигрывает. И, думаю. и будет проигрывать дальше, ведь фокус самих разработчиков языка сейчас направлен на фронтенд и мобилку, для сервера делаются самые минимальные вещи, многие библиотеки пишутся в комьюнити, им же потом и забрасываются в полуфабрикатном состоянии, когда задача автора решена и больше ему ничего не надо.
В целом, думаю, Dart имеет право на жизнь в продакшене на сервере, но в силу медленно развивающейся экосистемы его ниша будет крайне узка, по крайней мере ближайшие годы.
Судя по скриншотам с сайта, там просто клон (форк?) OnlyOffice и Thunderbird. Так что с тем же успехом можете поставить их и потыкать...
Не советую сильно верить в GPS. Он мне как-то на беговых лыжах выдал скорость под сотку , ещё было несколько случаев "телепортации", причем на разных девайсах. Хотя там и правда скорость была приличная, но система явно не была к ней готова :-)
Ну, судя по тем же данным из открытых источников по бухгалтерии, либо случатся инвестиции, либо всё это скоро заглохнет за нехваткой денег.
Хотя, конечно, кто в нашей стране будет верить данным из официальной бухгалтерии))))
Я не хочу об этом каждый раз думать, тем более что большей части загрузок так и суждено сгинуть во временной папке после разового использования — филиал корзины, в общем))
Как раз закончил писать небольшой телеграмм-бот с использованием null-safety, чувства остались смешанные. С одной стороны, я рад, что система подсвечивает мне случаи, которые я, скорее всего, пропустил бы. С другой, такого количества ручных проверок на null в моём коде не было никогда, и это раздражает)) хотя не исключаю, что я как-то не так в целом всё спроектировал…
Наличие большого количества пакетов, не поддерживающих null-safety, также на данном этапе усложняет жизнь. То анализатор заставляет делать проверки там, где они ну точно не нужны, а то предлагает отказаться от "лишней" проверки там, где ну точно может выскочить null. Со временем это, конечно, пройдет, но на данный момент…
А ещё Android Studio пока не умеет запускать тесты в null-safety проектах, приходится вручную через консоль. Ну, мелочь, в целом.
Мне кажется, на данный момент в проектах, не являющихся библиотеками, лучше не использовать null-safety, пока на неё не мигрирует большинство зависимостей. Но я в языке новичок, могу ошибаться, конечно)) А в пет-проектах любые эксперименты хороши.
В целом изменение позитивное, чем больше ошибок обнаружится до запуска, тем лучше!
Может, она и правда проходит, но с геологической скоростью, ведь быть большим, важным и всегда самым-самым умным для многих так привлекательно! Да и просто-напросто полоса вполне честных достижений порой кружит голову даже хорошим, в сущности, людям. Силе темной стороны сложно противостоять))
Что меня в своё время заставило писать код качественно и стуктурированно — это моя дырявая память, когда не помнишь не то что стороннюю либу, но и свой функционал забываешь, если он нелогичен.
А вот с другой стороны, я сейчас читаю статью с мобильника и несказанно рад качеству картинок с читабельным на небольшом экране листингами — без переносов и горизонтальной прокрутки, которые скорее всего вылезут, если делать текстом.
Спасибо за статью!