Код Меркури – Telegram
Код Меркури
2.15K subscribers
3.45K photos
487 videos
2 files
3.59K links
Микромедиа об IT для айтишников-релокантов и удаленщиков по всему миру 🪐

Познакомиться поближе: https://mercdev.com
Download Telegram
После такого огромного полотна про RN, про Flutter остаётся написать не то чтобы много. Он просто решает почти все эти проблемы, и делает это хорошо. Без проблем, разумеется, тоже не обошлось, но о них завтра 😅

Flutter позволяет вам нарисовать любую анимацию. Flutter позволяет привязать эту анимацию к жестам. Он также позволяет вам нарисовать что угодно. Без единой библиотеки и без просадок по кадрам. По крайней мере пока вы не рендерите тысячи анимировано-переливающихся звёздочек, летающих по всему экрану. Тут бы и я охренел такое отрисовывать.

Также у Flutter мощнейший на моей памяти инструмент по работе со списками. Sliver’ы – это любовь. Можно запилить практически любой scroll-experience, и, зачастую, сделать это достаточно просто (о некоторых исключениях расскажу завтра).

С Flutter у вас будет на порядок меньше ситуаций, когда код, протестированный на одной платформе, внезапно откажется работать на другой. По большей части, интерфейс и логика пишутся на чистом Dart, а значит, что поведение на обеих платформах будет одинаковым. Dart, конечно, тоже может транслироваться во всякое разное, и я не могу ручаться, что таких проблем не будет, если одно и то же приложение будет исполняется на мобилках и в вебе. (В вебе Dart транслируется в JS). Но у меня ни разу не было такого, чтобы написанный на Dart код отработал по-разному на iOS и Android.

Также очевидно, что если вы задействуете нативный плагин или вьюху, то там таких гарантий нет. Их придётся протестировать на обеих платформах. Разница тут в том, что в случае с RN на обеих платформах нужно тестировать практически весь код, а на Flutter, до тех пор, пока я не добавляю новую нативную библиотеку, я могу тестировать код только на одной платформе, и ни о чем не переживать.

На всякий случай добавлю, что такой код не отправляется сразу в прод. У нас еще есть замечательная команда QA инженеров, которая выловит косяки, если они есть. Но практика показывает, что если код не опирается на нативные плагины, то косяки либо платформонезависимые, либо их вообще нет.

#underhood
5👍4
Самое сладкое в конце - DX. Google любит Flutter разработчиков, и старается сделать так, чтобы им нравилось пользоваться фреймворком. Как только вы начнете разработку на Flutter, вас попросят поставить плагин для IDE. Линтинг, автоформатирование кода, дебаггер в IDE, Hot Reload при сохранении файла, тулзы для редактирования разметки (свапы, вставка виджета в разметку и тд), мощные DevTools для инспекции UI, замеров перфоманса и многое другое. Всё это (ну или почти всё) есть и в RN, не спорю, но по отдельности, и зачастую делается какими-то сторонними решениями. А когда оно всё All inclusive, чисто по-человечески уже как-то приятнее код писать 🙂

Самая сладкая мякотка - это Hot Reload. Он позволяет вам смотреть, как меняется разметка и поведение прямо в запущенном приложении. Забавно, что вскоре после релиза Flutter, у RN появился свой Fast Reload, но когда я его пробовал, работал он не так хорошо, как хотелось бы. Расскажите, его доработали?

#underhood
4👍2
Думаю, пора закругляться)
Я могу рассказать еще много хорошего про Flutter, и не только в сравнении с React, но на сегодня хватит. Думаю, главную мысль я уже донёс: Flutter крутой.

Вернусь к вам завтра, но на этот раз Flutter я буду больше ругать, чем хвалить 😅
А сейчас пора сворачиваться. Спасибо тем кто осилил. Всем удачи, всех обнял!

#underhood
👍13🥰4👎1
Солнца ясного, дня прекрасного, я снова на связи. Сегодня у нас по плану претензии от нативных разработчиков, мои личные проблемы с Flutter, и, внезапно, тестирование. Погнали)

Самые популярные претензии от нативных разработчиков под iOS и Android, с которыми я сталкивался, выглядят так:

💀 Flutter – это очередной кандидат на кладбище Google, долго ему прожить не суждено, а значит и время в него вкладывать смысла нет.


Первые год-два это имело смысл. Кладбище гугла, действительно, известная штука, и Flutter не был застрахован от попадания туда. Но сейчас он набрал критическую массу, и теперь, мне кажется, Google даже при желании не сможет его убить. Технология получила уже третью мажорную версию, активно развивается, используется самим Google в своих проектах и греется в лучах любви от комьюнити. Ставлю доширак, что Flutter еще всех нас переживёт.

#underhood
👍10
💀 Нужно учить новый язык ради одной технологии.

Да, но это не большая проблема. Дело в том, что если у вас есть опыт использования Си-подобных языков, особенно JavaScript, то вы уже знаете Dart, вам осталось только найти в себе это скрытое знание.

Язык, на мой взгляд, представляет из себя смесь Java и JavaScript, ушедшую несколько вперед от обоих. От Java достались общий стиль и строгость, привычное ООП и человеческая типизация, от JS – ёмкость, функциональные штучки и асинхронный рантайм.

💀 Dart хуже чем Swift/Kotlin

Ну что сказать, каждому своё)
В Dart меньше синтаксического сахара, а из-за отсутствия рефлексии во Flutter, многие вещи приходится делать через кодогенерацию. Зато тут есть настоящая асинхронность, и Dart развивается также быстро, как и Flutter. Яркий пример: еще недавно Kotlin и Swift могли похвастаться нулобезопасностью, а теперь и сам Dart её поддерживает.
А еще он просто классный. Это чувство сложно описать, но его разделяет большая часть комьюнити – на Dart очень приятно писать.

#underhood
👍76
💀 У вас скролл лагает.

Не лагает 😁
Проблемы со скроллом давно устранены. В том числе сейчас поддерживается и ProMotion. Но даже у такой странной претензии есть 2 справедливых момента:

Во-первых, в нативных iOS приложениях, и даже на React Native, тот же ProMotion работал с самого начала и не требовал пересобирать приложение с фиксом.

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

Кстати о скролле: чтобы узнать, написано ли приложение на Flutter, попробуйте поскролить его 2 пальцами. Flutter приложение станет скролить список в 2 быстрее. Это известная “не баг, а фича”, фиксить её, вроде как, пока не собираются.

#underhood
👍13😁2
💀 Нативное приложение всегда будет работать лучше, чем кроссплатформа.

Грех спорить. В плане производительности, потребления памяти и пожирания батареи, даже среднее нативное приложение будет превосходить самое вылизанное приложение на Flutter и React Native. Увы, нельзя брать от жизни всё и сразу, и за экономию на разработке двух нативных приложений заплатит в конечном итоге пользователь. Мы лишь можем сделать так, чтобы он этого не заметил.

На этот счет у меня есть небольшой пример. Когда я проходил курс Hacking with Swift, первым проектом был список картиночек, каждую из которых можно было открыть в отдельном экране. Так вот, этот проект с картиночками в релизной сборке потреблял ~23мб оперативы, в то время как простейший стартовый счётчик на Flutter (текстовый лейбл + кнопка) на том же девайсе кушал уже 60-70мб. Стоит держать в голове, что на больших приложениях эта разница будет не так заметна, но развидеть такое сложно.

Я хотел еще собрать простейший проект на React Native, чтобы посмотреть сколько он жрёт в минималке, но в неравном бою лень одержала победу, поэтому для RN цифр сегодня не будет 🙁

#underhood
👍107
У меня тоже есть некоторые проблемы с Flutter, помимо озвученных выше. После серии вчерашних постов, было бы нечестно о них умолчать. Но сначала краткий ликбез.

Главная фича Flutter — это графический движок Skia под капотом. Фреймворк сам занимается отрисовкой абсолютно всего. Нативные приложения и React Native используют компоненты, предоставляемые системой, а Flutter’у на это пофиг. Если он сказал, что у карточки должна быть огромная розовая тень, то она будет, даже если приложение запущено на пожилом Android, у которого тени управляются одним скромным параметром.

Технически, Flutter — это очень крутой подражатель. Все те виджеты и поведенческие паттерны, которые ощущаются нативно, на самом деле воссозданы с нуля в самом Flutter. С одной стороны, это даёт небывалую свободу, а с другой приводит нас к первому минусу.

Заключается он в том, что Flutter вечно будет догоняющим. Наиболее очевидно это в случае с iOS. Apple явно не предупреждают Google о том, что они собираются выпускать, поэтому, думаю, и дальше будут случаться ситуации как с ProMotion: не поддерживается на старте, но быстро фиксится и попадает к разработчикам. Причем ладно Apple, но кажется даже Google внутри себя договориться не может, ибо Flutter всё еще не поддерживает новое поведение при оверскролле на Android 12 (там всё прикольно вытягивается). UPD: поправили в комментариях, уже поддерживается 😁

#underhood
👍10
Кстати, буквально этой ночью Flutter обновился до версии 3.3.0. Ура, товарищи! 🎉

И это подводит нас к еще одной минорной проблеме — иногда бывают сложности при обновлении. Не подумайте, до опыта React Native тут как до Луны, но глупо не признавать, что косяки случаются.

Уже после того, как коллеги обновили версию и поправили замечания линтера, моё обновление прошло относительно гладко. Сначала у меня перестало собираться приложение, но я быстро выясниснил, в чем дело. В pubspec.lock под шумок решила обновиться транзитивная зависимость, и видимо именно это обновление было несовместимо с новым Flutter. Откатил, зафиксировал версию, и всё снова работает. Даже не пришлось создавать новый проект и переносить туда сорцы 😅

#underhood
👍2
Следующий минус: использование нативных вьюшек во Flutter имеет ощутимый оверхед. Поскольку в отличие от React Native, для Flutter нативные вьюшки чужеродны, разработчикам пришлось использовать весьма хитрые подходы, чтобы это реализовать. Нативные вьюхи рендерятся в текстуру, после чего Flutter встраивает эту текстуру к себе в дерево, попутно разруливая проблемы с передачей жестов, аксесабилити и прочей мишурой.

Если вы иногда, при необходимости, встраиваете такие вьюшки в свой UI - проблем не будет, но злоупотреблять не стоит. Ну и если всё приложение по вашему замыслу состоит из географических карт, вебвьюшки и видео-плеера, то Flutter – такой себе вариант, лучше взять React Native. Особого профита на таком приложении вы не почувствуете, а проблем можете хапнуть.

#underhood
👍1😢1
А еще, иногда виджеты из стандартной библиотеки Flutter - отстой. Бывает такое, что нужно тебе какое-то специфичное поведение, находишь подходящий виджет, начинаешь его подстраивать по себя, и обнаруживаешь, что он абсолютно деревянный. То есть его можно использовать, и будь это личный пет-проект – ты бы забил и оставил как есть, но у тебя есть дизайн, а эта штука явно не пройдет дизайн-ревью.

Заканчивается это тем, что ты стираешь только что написанный код и идёшь писать собственный велик, благо обычно это не сложно. Самый яркий пример такого виджета - DraggableScrollableSheet, или боттом шит, если на рабоче-крестьянском. Его постоянно допиливают и улучшают, но у меня еще ни разу не получилось им воспользоваться. Последняя попытка была буквально на той неделе.

Менее приятная ситуация возникает, когда речь идёт о виджете, который просто так не напишешь. Топ-1 моего личного анти-рейтинга – NestedScrollView (https://api.flutter.dev/flutter/widgets/NestedScrollView-class.html). Абсолютно поломанная штука, которую сложно использовать за пределами стандартных кейсов, описанных в документации.

Когда я пытался использовать его в проекте, это закончилось тем, что мне пришлось копипастить его сорцы, чтобы накатывать заплатки. Какие-то фиксы можно было скопипасть из баг-репортов на GitHub, а что-то пришлось фиксить самому. Некоторые фиксы были абсолютно отмороженные, до сих пор ими горжусь.

Но даже после всего этого, мы всё еще не смогли включить NestedScrollView в релиз, а у меня в бэклоге валяются баги, от которых кровь стынет в жилах. Боюсь того дня, когда про эту фичу вспомнят и достанут тикеты из бэклога.

#underhood
👍4😱2
Последняя тема на сегодня — тесты. Мне в данном вопросе больше интересно узнать ваше мнение, но свой опыт тоже опишу. А ниже будет пара-тройка вопросов, очень прошу потыкать кнопочки)

У меня отношение с тестами примерно как с пробежками по утрам. Глобально понимаешь, что это круто и полезно, надо бегать. Если однажды почувствовал себя особо заряженным — побежал, и может быть даже еще несколько недель после этого стабильно бегал. А потом что-то пошло не так, и ты пропустил день. На следующий еще думаешь: «черт, надо наверстать», но еще через день такая ересь даже не посещает твою голову. Ситуация в тестами у меня 1 в 1.

#underhood
👍14
Объясню, почему тут появилась тема тестирования. Как вы уже поняли, я не пишу в TDD стиле (за редкими исключениями), да и постфактум тестами покрываю далеко не весь код. Но это не мешает мне грезить об утопии, которую описывает в своих желтых книжечках Роберт Мартин. Там, если что, огромные системы разрабатываются в TDD, все пишут только чистый код и регулярно программируют в паре, а система периодически подвергается рефакторингу и вообще очень легко поддерживаются.

Сам я такой идеальной картинки еще ни разу не видел, но мне кажется, тесты — неотъемлимая часть этой картины. Однажды я хотел бы своими глазами это увидеть, но пока что есть 2 препятствия.

Во-первых, когда я среди знакомых завожу тему тестирования и рассказываю про прелести TDD — на меня сморят как на местного сумасшедшего. Люди, кажется, не очень в это верят :)

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

#underhood
👍12
Для себя я обозначенную проблему решаю, потихоньку изучая умные книжки и пытаясь вклинивать тесты в свой процесс. По теме, помимо полного собрания сочинений Роберта Мартина, могу посоветовать 2 книги: Кент Бэк «Разработка через тестирование» и Владимир Хориков «Принципы Unit-тестирования». Вторая особенно запала мне душу. Я её только дочитываю, но уже могу рекомендовать. Это первый источник на моей памяти, который наглядно объяснил, почему тесты, которые я писал раньше — отстой, почему некоторые из них вообще не надо было писать, и как стоило написать остальные, чтобы они помогали, а не путались под ногами.

Надеюсь, впитанные знания помогут мне однажды достичь уровня, когда написание теста будет чем-то настолько естественным, что вопрос о том, писать его или нет, даже не будет стоять. А покрытие тестами будет ускорять процесс разработки. Тогда я стану бородатым тим-лидом, заставлю всех писать тесты, регулярно рефакторить систему и парно программировать. И пусть бизнесовые тикеты подождут 😄

#underhood
🔥14👍31🤔1
На этом я буду закругляться. Большое спасибо всем дочитавшим, и особенно тем, кто принял участие в последних опросах!

Приятно видеть, что большинство считает, что тесты важны, и что они положительно влияют на скорость разработки. А даже если влияют отрицательно, то всё равно важны 😄

На сегодня всё, по традиции, всех обнял

#underhood
13👍3👏2
Всем привет! Настал последний день, и уже скоро наш SMM Лёша выпустит меня из подвала, чтобы я снова мог писать код, а не посты в Телеграмм 😄

Сегодня я расскажу вам про мобильный митап Merk/PRO, который пройдёт уже в эту субботу в Ереване. И начать я хотел бы с того что… его не будет.

#underhood
😁21