Dart проигрывает Kotlin во всем по синтаксису, пожалуй кроме mixin. Среды как таковой для платформы нет, лишь стремные плагины для AS, VS и т.д. Пишу и на том и на том, и имхо flutter полное дно в сравнении с нативной разработкой. Если бы не мультиплатформенность из коробки, выбросил бы его в окно, но увы деньги для меня важнее радости писать на чистом котлине ;)
Отказался от databinding с самого начала (2018 год). Удивительно, что оно так зашло людям в 2016 году. Библиотека ведь ужасная! Одни костыли - сшили ужа с ежом. Чуть что посложнее пытаешься сделать и никто это уже не поймет - проще заново переписать, чем разбираться в хитросплетенья и форматах. Брррр
Похоже, что injectable и есть та самая библиотека, которой вы пользуетесь - https://pub.dev/packages/injectable. Может быть расскажите о том, какие у нее плюсы, какие минусы? Мб есть какие-то камни преткновения? Иначе, в чем смысл статьи? Если логически рассудить, то я либо знаю об injectable, а тогда я точно знаю о di и нужды в статьи нет; либо я знаю о di и не знаю о injectable, тогда это не к вам; ну и наконец, если же я не знаю ни о di, ни о injectable статья не даст полного понимания, ведь даже ссылки на библиотеку нет. Спасибо вам за материал, но постарайтесь в следующий раз раскрыть тему польностью.
Ну, вы рассказали про теорию абстракции, но где сам пример? Из этих картинок я так и не понял как реализовать di во flutter, какие библиотеки использовать и т.д.
как же меня бесит флаттер после котлина. Где вся та радость, что обещалась? Декларативный подход - ок. Что с состояниями? Где di? ЧТО это за лентачные черви получаются вместе аккуратных классов? Столько разговоров о том, как это круто, а как до дело доходит - беспроглядный мрак. Совершенно не представляю, как это могло стать трендом, да ведь это мертворожденный!
Удивительно... 2.5 года, и уже ни черта не работает)) И ладно бы синтаксис стал лучше, так ведь нет! Просто он немного изменился и сиди гадай в чем дело (у меня конкретно проблема - Classes can only mix in mixins and classes.). Код, который я написал на котлине три года назад все так же работает. Мдаа, ну флаттер и флаттер
У меня был занятный кейс: если сгенерированный модуль Даггер будет больше ~21.4 мб, вы получите ошибку сборки со ссылкой, что один из классов не добавлен)) Т.к. пилите кор на части вовремя!
Да у меня примерно такая же фигня)) прошел две секции, вроде все хорошо, ребята почти хлопают по плечу, говорят скоро увидимся, потом на третьей секции я не решаю полностью задачу (я не обработал крайние участки, хоть и пытался чего-то изобразить), как итог про меня забывают на две недели, потом сбривают. Но ребята, я и не такие алгоритмы могу решить и куда качественнее, но не в 6:30 вечера и не за пол часа)) я всё-таки андроид разработчик. На мой взгляд лучше в шахматы поиграть (показать умение логически мыслить) или по деревьям полазить (показать упорство), чем проходить это)) Яндекс лишь сбривать хороших девелоперов,и оставляет тех кому повезло. В заклад бьюсь, что проверь вы своих андроид разработчиков как меня 30% из них задачку не решит в аналогичных. условиях, а в спокойной обстановке за чашкой чая ее решат все
Ну, вот, я прочитал пример в вики с буквами, пример тут с фигурами, и так и не понял что это такое? Выглядит как ограниченный набор кубиков, из которых собирается все остальное, но так ли это?
Как мобильный разработчик пишу простенький алгоритм 1-2 раза в год, но почти любое собеседование содержить задачку на алгоритм. В результате я трачу свое время на подготовку в мертвой для меня области, и все потому что кто-то в компании считает, что ум == уменее решать задачки на бумаге. Это не так)))
Похоже, что я нашел ответы на свой вопросы. Перворначально я хотел сделать абсолютно гибкую навигацию, так чтобы каждый модуль мог переходить в любой другой. Именно поэтому первая версия библиотеке подходила - достаточно было указать ключ фрагмента и вуаля! Переход! Слабостью казалось только расшаривание этих ключей (не писать же их в каждом модуль отдельно?), но потом мне вспомнилось, что все модули будут иметь свои зависимости, а значит при переходе их нужно будет предоставить, что убило идею на корню. Тогда я вернулся к версии 7.1 и стал предоставлять Screen из апи даггер компонента дочернего модуля (сложно, но вчитайтесь). Сами переходы стали более жесткими - каждый модуль просит на вход в виде зависимости только нужные ему переходы в виде интерфейса с методами отдающими Screen. Зависимости формируются в апп модуле. В итоге: о всех фрагментах и всех переходах знает только апп модуль. Дочерние модули полностью инкапсулированы. Переходы (Screen) предоставляют дочерние модули, app только их сшивает в нужные интерфейсы через их же апи и передает следующим дочерним модулям. Я так же смотрел в сторону андроид навигации, но переделывать пришлось бы слишком много. Плюс у нас проект горизонтальной ориентации, а в навигации все экраны показывают вертикально и никак это не изменить. В общем как-то так. Спасибо за либу, буду делывать
Попробовал вашу замечательную библиотеку в многомодульном приложении - пока вот разбираюсь) С версией 1.0 понятно как работать - строки есть во всех модулях, а оформив переходы в общем файле константами можно вызывать переход откуда угодно и куда угодно - вся навигация пройдет через app-модуль. А вот как работать с версией 7.1? Она в отличии от первой просить screen, а в примерах он еще и с фабрикой идет. Т.е. вынести их в тот же gradle.prorepties уже не получится. Мб я чего-то не понимаю и ларчик просто открывается?
@txdrive спасибо вам за статью - в свое время очень мне помогла. У меня такой вопрос: есть ли способ использовать multibinding в отдельных компонентах? У нас идет миграция на многомодульности, а общая фабрика viewModel-ей работает через map:
private val creators: @JvmSuppressWildcards Map<Class<out ViewModel>, Provider<ViewModel>>
я так понимаю, мапы доступны только в основном app компоненте, там где подключено
AndroidSupportInjectionModule
Будь у нас подкомпоненты, путь был бы ясен, но как быть с отдельными компонентами? Пока у меня одна идея - это убрать мапу и собирать ее на месте, подключая к фабрике провайдеры вью-моделей. В общем, что думаете?)
В остальном конечно автор молодец, так держать)
Dart проигрывает Kotlin во всем по синтаксису, пожалуй кроме mixin. Среды как таковой для платформы нет, лишь стремные плагины для AS, VS и т.д. Пишу и на том и на том, и имхо flutter полное дно в сравнении с нативной разработкой. Если бы не мультиплатформенность из коробки, выбросил бы его в окно, но увы деньги для меня важнее радости писать на чистом котлине ;)
Отказался от databinding с самого начала (2018 год). Удивительно, что оно так зашло людям в 2016 году. Библиотека ведь ужасная! Одни костыли - сшили ужа с ежом. Чуть что посложнее пытаешься сделать и никто это уже не поймет - проще заново переписать, чем разбираться в хитросплетенья и форматах. Брррр
Так что такое inset?) Нативные методы по работе с системными тулбарами? Что-то вы с места в карьер начали
Похоже, что injectable и есть та самая библиотека, которой вы пользуетесь - https://pub.dev/packages/injectable. Может быть расскажите о том, какие у нее плюсы, какие минусы? Мб есть какие-то камни преткновения? Иначе, в чем смысл статьи? Если логически рассудить, то я либо знаю об injectable, а тогда я точно знаю о di и нужды в статьи нет; либо я знаю о di и не знаю о injectable, тогда это не к вам; ну и наконец, если же я не знаю ни о di, ни о injectable статья не даст полного понимания, ведь даже ссылки на библиотеку нет. Спасибо вам за материал, но постарайтесь в следующий раз раскрыть тему польностью.
Ну, вы рассказали про теорию абстракции, но где сам пример? Из этих картинок я так и не понял как реализовать di во flutter, какие библиотеки использовать и т.д.
как же меня бесит флаттер после котлина. Где вся та радость, что обещалась? Декларативный подход - ок. Что с состояниями? Где di? ЧТО это за лентачные черви получаются вместе аккуратных классов? Столько разговоров о том, как это круто, а как до дело доходит - беспроглядный мрак. Совершенно не представляю, как это могло стать трендом, да ведь это мертворожденный!
Удивительно... 2.5 года, и уже ни черта не работает)) И ладно бы синтаксис стал лучше, так ведь нет! Просто он немного изменился и сиди гадай в чем дело (у меня конкретно проблема - Classes can only mix in mixins and classes.). Код, который я написал на котлине три года назад все так же работает. Мдаа, ну флаттер и флаттер
Спасибо большое, все ещё актуально. Третий день работаю с flutter, архитектура - наше все!
В точку. Все это будет расти со скоростью бамбука, 5 лет максимум наш рынок продержится в прежнем виде. Впереди супер волны сокращений
У меня был занятный кейс: если сгенерированный модуль Даггер будет больше ~21.4 мб, вы получите ошибку сборки со ссылкой, что один из классов не добавлен)) Т.к. пилите кор на части вовремя!
Мне понравились костыли в их коде. Это говорит о том, что их секция с алгоритмами не работает, ведь люди написавшие этот код ее прошли)))
Да у меня примерно такая же фигня)) прошел две секции, вроде все хорошо, ребята почти хлопают по плечу, говорят скоро увидимся, потом на третьей секции я не решаю полностью задачу (я не обработал крайние участки, хоть и пытался чего-то изобразить), как итог про меня забывают на две недели, потом сбривают. Но ребята, я и не такие алгоритмы могу решить и куда качественнее, но не в 6:30 вечера и не за пол часа)) я всё-таки андроид разработчик. На мой взгляд лучше в шахматы поиграть (показать умение логически мыслить) или по деревьям полазить (показать упорство), чем проходить это)) Яндекс лишь сбривать хороших девелоперов,и оставляет тех кому повезло. В заклад бьюсь, что проверь вы своих андроид разработчиков как меня 30% из них задачку не решит в аналогичных. условиях, а в спокойной обстановке за чашкой чая ее решат все
Тесты это прекрасно!
Поставил плюсик, проверил - работает)
Ну, вот, я прочитал пример в вики с буквами, пример тут с фигурами, и так и не понял что это такое? Выглядит как ограниченный набор кубиков, из которых собирается все остальное, но так ли это?
Как мобильный разработчик пишу простенький алгоритм 1-2 раза в год, но почти любое собеседование содержить задачку на алгоритм. В результате я трачу свое время на подготовку в мертвой для меня области, и все потому что кто-то в компании считает, что ум == уменее решать задачки на бумаге. Это не так)))
Похоже, что я нашел ответы на свой вопросы. Перворначально я хотел сделать абсолютно гибкую навигацию, так чтобы каждый модуль мог переходить в любой другой. Именно поэтому первая версия библиотеке подходила - достаточно было указать ключ фрагмента и вуаля! Переход! Слабостью казалось только расшаривание этих ключей (не писать же их в каждом модуль отдельно?), но потом мне вспомнилось, что все модули будут иметь свои зависимости, а значит при переходе их нужно будет предоставить, что убило идею на корню. Тогда я вернулся к версии 7.1 и стал предоставлять Screen из апи даггер компонента дочернего модуля (сложно, но вчитайтесь). Сами переходы стали более жесткими - каждый модуль просит на вход в виде зависимости только нужные ему переходы в виде интерфейса с методами отдающими Screen. Зависимости формируются в апп модуле. В итоге: о всех фрагментах и всех переходах знает только апп модуль. Дочерние модули полностью инкапсулированы. Переходы (Screen) предоставляют дочерние модули, app только их сшивает в нужные интерфейсы через их же апи и передает следующим дочерним модулям. Я так же смотрел в сторону андроид навигации, но переделывать пришлось бы слишком много. Плюс у нас проект горизонтальной ориентации, а в навигации все экраны показывают вертикально и никак это не изменить. В общем как-то так. Спасибо за либу, буду делывать
Попробовал вашу замечательную библиотеку в многомодульном приложении - пока вот разбираюсь) С версией 1.0 понятно как работать - строки есть во всех модулях, а оформив переходы в общем файле константами можно вызывать переход откуда угодно и куда угодно - вся навигация пройдет через app-модуль. А вот как работать с версией 7.1? Она в отличии от первой просить screen, а в примерах он еще и с фабрикой идет. Т.е. вынести их в тот же gradle.prorepties уже не получится. Мб я чего-то не понимаю и ларчик просто открывается?
@txdrive спасибо вам за статью - в свое время очень мне помогла. У меня такой вопрос: есть ли способ использовать multibinding в отдельных компонентах? У нас идет миграция на многомодульности, а общая фабрика viewModel-ей работает через map:
я так понимаю, мапы доступны только в основном app компоненте, там где подключено
Будь у нас подкомпоненты, путь был бы ясен, но как быть с отдельными компонентами? Пока у меня одна идея - это убрать мапу и собирать ее на месте, подключая к фабрике провайдеры вью-моделей. В общем, что думаете?)