Как стать автором
Обновить
11
3
Данил Абдрафиков @Holofox

Мобильный разработчик в TAGES

Отправить сообщение

Надеюсь, что сообщество найдет способы восстановить доверие и открытость, чтобы Open Source остался тем пространством, которое объединяет, а не разделяет.

Вам спасибо! Очень долго не мог выбрать подходящие хабы, исправил

Команда Dart не объясняет, почему этого следует избегать в пакетах. Вопрос тянется ещё с 2015 года, однако этому есть разумное объяснение для одного из вариантов неправильного использования.

Интересный вид! В суровой реальности при форматировании кода используют dartfmt, к сожалению, он раскладывает лесенкой:

var res = cond1
    ? exp1
    : cond2
        ? exp2
        : cond3
            ? exp3
            : cond4
                ? exp4
                : elseExp;

Очень здорово! Да, практики полезные, особенно с обновлением виджетов.

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

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

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

С выходом Swift UI единственная проблема была в установке минимальной версии iOS 13, которая на тот момент являлась актуальной. Это сдерживало разработчиков какое-то время оставаться на UIKit.

Считаю, что сейчас прекрасное время, чтобы использовать Swift UI, ведь это охватывает большинство устройств на рынке. Как по мне, если у человека уже был опыт с Flutter или Jetpack Compose, то освоиться будет куда проще!

К слову, на данный момент, часть фичей из статьи реализованы в better_player, правда всё равно можно столкнуться с теми же проблемами, так как пакет перестал активно поддерживаться и под капотом это работает почти также. В потенциале есть пакет media_kit, который недавно начал разрабатываться, поживём-увидим.

Но если рассматривать жесткие требования со стороны бизнеса, никакие пакеты уже не спасут.

В оф доках все это есть https://dart.dev/resources/faq#q-is-dart-single-threaded

Спасибо за ссылку, очень полезно

Все кто работал с KAPT знают, что основная его проблема - это скорость, он работает очень медленно

В сравнении с build_runner, это небо и земля. Не было цели сравнивать только kapt и KSP между собой. Посыл был в том, что если это работало хотя бы на уровне kapt, то проблема не казалась бы существенной.

Спасибо, это была небольшая опечатка, которая уже исправлена

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

Это не так, см Isolate или вот

Каждому изоляту выделяется отдельный Event Loop и своя память, а взаимодействие между изолятами возможно только посредством сообщений, что ведёт к тому, что в Dart нет параллелизма с общим состоянием. Вообще язык очень хитрый в этом плане, я бы назвал это псевдо многопоточностью? :)

все строго наоборот: сначала был kapt (как реализация стандартного аннотейшн процессора в джаве для котлина, которые работает достаточно медленно), а потом уже появился KSP.

Спасибо за наводку, действительно перепутал местами.

это все зависит от сценария использованения, для главной страницы магазина - врядли такое подойдет, но для внутренней админки бекенда - вполне, учитывая скорость разработки + функциональность.

Конечно это не останавливает разработчиков писать приложения на Flutter Web, но порой сталкиваешься с такими проблемами, которые и вовсе быть не должны. Скорость разработки может упасть, как только разработчик столкнется с проблемой движка, отсюда появляются обходные решения, костыли и креатив разработчика тут уже задействуется на полную. Иногда вот думаешь, а зачем я этими проблеми занимаюсь?

Да, несомненно нужно потратить своё время чтобы разобраться в языке, но на деле начать писать на Dart не так сложно. В Flutter бывает начинаешь писать на Dart, потом переключаешься на Kotlin или Swift, чтобы реализовать конкретную нативную часть, и происходит это без страшных последствий. Наверное, с опытом уже неважно на чём писать :)

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

Информация

В рейтинге
1 150-й
Дата рождения
Зарегистрирован
Активность

Специализация

Mobile Application Developer
Senior
Flutter
Dart
Kotlin
SWIFT
iOS development
Android development
Development of mobile applications