Черным по белому написано - не знаешь как, твои проблемы, не надо пытаться обойти ограничения.
Интернетом пользоваться уже невозможно. Даже Medium заблокирован. Не то что информационный и развлекательный контент. Статьи по разработке, Карл.
Почти всё, что я читал и чем пользовался заблокировали refactoring.guru, medium, soundcloud, медуза, сервера Oculus, статика гугла (картинки то не грузит на ютубе) и т.д.
А ваш Вашингтон, США в профиле - это правда? По ощущениям, вы не знаете масштабы блокировок ну или гоблина наслушались.
Закон не запрещает публикацию информации о способах создания VPN, если конечной целью не является обход ограничений к какому-то целевому ресурсу.
TextField находится в DraggableScrollableSheet, и нужно вызывать unfocus() в onTapOutside, чтобы при взаимодействии с DraggableScrollableSheet клавиатура убиралась.
А когда я использовал StatefullShellRoute, при нажатии на TextField (и всё остальное) на экране 2 сразу происходил unfocus :-)
Добавил debugPrint() в onTapOutside и увидел, что в он вызывается, хотя экран даже не в backstack.
StatefulShellRoute на самом деле кривоватый. Пример:
Есть экран "1" с TextField, на котором висит onTapOutside
Есть экран "2" в другой branch, на котором также находится TextField
Мы переходим с экрана 1 на экран 2 через context.go() (т.е. в backstack экрана 1 нет)
Нажатия по экрану 2 вызывают onTapOutside с экрана 1
Вопрос: А как так? StatefulShellBranch просто держит состояние активным?
Из-за данной проблемы вернулся на обычный ShellRoute.
Идея StatefulShellRoute хорошая, но его допиливать надо. А если я хочу, чтобы не все экраны были в StatefulShellBranch. Иногда хочется что-то вроде StatelessShellBranch.
Вообще, goRouter - очень крутая либа с классными фичами (refreshListanable, redirect и т.д.), всегда с её помощью навигацию строю. Но StatefullShellRoute, вышедший несколько месяцев назад, ещё сырой. Я бы рекомендовал воздержаться от его использования в больших проектах, мало ли что.
Я в школе сделал приложение на андроид, которым некоторые одноклассники пользовались. И 100$ для меня были бы проблемой. Да и в стор его не пустили бы, хотя виртуальный дневник удобно вести было. Хватит защищать эпл уже
А может не надо грейдить команду? Оценить разработчика может только другой более опытный разработчик. И всегда есть тема, которую ты видишь впервые, независимо от уровня. Как выше уже написали, это нужно, чтобы не повышать зп. В итоге мы среднее время работы в компании год и имеем, т.к., вместо повышения, человек в другую компанию уходит
Я не из веба (из флаттера/андроида), но если я правильно понял, то под fsd вы имеете ввиду использования feature-list вместо layer-list структуры топлевел директорий. Мне кажется, разбиение по фичам гораздо удобнее на больших проектах. Ибо имея 3 папки domain, data, presentation очень сложно одну фичу делать. Опять же, случаи, когда какая-то бизнес-логика шэрится между фичами достаточно редки. Фича - это же не экран. Фича это же не экран, а более общая вещь. Типо настройки - а там много экранов со всяким. Я в случае с фичами делаю папку features/ и уже внутри фичи идёт размазывание по presentation, data, domain и т.д. Ну и есть _common для апи, наигации и прочей общей функциональности.
Про MV* не совсем понял. Это же паттерны презентации, а не архитектура. Эта * - это тоже presentation на уровне архитектуры проекта. В архитектуре всякие presenter, bloc, viewmodel, controller и т.д. выполняют роль презентации. А моделью уже что угодно может быть. Поэтому view и её логика должны рядом находиться. Это всего лишь способы организации логики конкретного виджета
Хотя у нас suspend функции в репозиториях эксепшнами кидаются и вполне удобно получается. Либо можно использовать подход Either<L, R> и бизнесовые ошибки вообще в эксепшны не засовывать
да нет. если вы про aab, то он ещё раньше в google play появился. просто для разработчиков он необязательным был. и это хорошо, что gp полностью на этот формат переводят, ибо не надо будет качать ресурсы, которые не предназначены для твоего телефона. а вот кнопка build apk в android studio никуда не исчезнет. можно будет так же собрать апкшку и закинуть её в microsoft store. да и вообще хоть куда.
Чел с картинки купи курс - это битмейкер, который каждое видео просит купить его курс по битмейкингу. В сфере создания музыки кстати почти такая же ситуация. Вместо того, чтобы научить людей нотам хотя бы, показывают, как работать с новомодными плагинами. "Ну... делаем вот так, теперь звучит вот так..."
А зачем? По времени работы и позиции уже понятно, что человек синьор и, вероятно, лид.
Мы hive используем. Это key value хранилище. Он и в вебе работает и дтошки под него писать удобно.
Зато за этим было интересно наблюдать. Можно сказать, самая крутая ARG (хотя не совсем ARG)
Я бы сгорел, если б у меня такие бэкендеры были. Бэкенд - и для апки, и для сайта, и для другой апки. Ну вы поняли.
Может всё-таки общую работу на бэк выносить? Тем более, что производительность клиента гораздо критичнее на пользователя действует.
Ну и логика тоже максимально на сервере должна обрабатываться.
Интернетом пользоваться уже невозможно. Даже Medium заблокирован. Не то что информационный и развлекательный контент. Статьи по разработке, Карл.
Почти всё, что я читал и чем пользовался заблокировали refactoring.guru, medium, soundcloud, медуза, сервера Oculus, статика гугла (картинки то не грузит на ютубе) и т.д.
А ваш Вашингтон, США в профиле - это правда? По ощущениям, вы не знаете масштабы блокировок ну или гоблина наслушались.
Как раз так и наоборот...
"с иностранными языками" можно было и не писать
Ну там различные params deprecated стали. Теперь через Uri. Не так давно вроде было.
TextField находится в DraggableScrollableSheet, и нужно вызывать unfocus() в onTapOutside, чтобы при взаимодействии с DraggableScrollableSheet клавиатура убиралась.
А когда я использовал StatefullShellRoute, при нажатии на TextField (и всё остальное) на экране 2 сразу происходил unfocus :-)
Добавил debugPrint() в onTapOutside и увидел, что в он вызывается, хотя экран даже не в backstack.
Как-то так.
StatefulShellRoute на самом деле кривоватый. Пример:
Есть экран "1" с TextField, на котором висит onTapOutside
Есть экран "2" в другой branch, на котором также находится TextField
Мы переходим с экрана 1 на экран 2 через context.go() (т.е. в backstack экрана 1 нет)
Нажатия по экрану 2 вызывают onTapOutside с экрана 1
Вопрос: А как так? StatefulShellBranch просто держит состояние активным?
Из-за данной проблемы вернулся на обычный ShellRoute.
Идея StatefulShellRoute хорошая, но его допиливать надо. А если я хочу, чтобы не все экраны были в StatefulShellBranch. Иногда хочется что-то вроде StatelessShellBranch.
Вообще, goRouter - очень крутая либа с классными фичами (refreshListanable, redirect и т.д.), всегда с её помощью навигацию строю. Но StatefullShellRoute, вышедший несколько месяцев назад, ещё сырой. Я бы рекомендовал воздержаться от его использования в больших проектах, мало ли что.
Ну RN можно приплести
Ну дзен и пикабу ватные, в отличии от хабра
А насколько большой датасет для одного жанра нужен, чтобы она обучилась нормально?
Я в школе сделал приложение на андроид, которым некоторые одноклассники пользовались. И 100$ для меня были бы проблемой. Да и в стор его не пустили бы, хотя виртуальный дневник удобно вести было. Хватит защищать эпл уже
А может не надо грейдить команду? Оценить разработчика может только другой более опытный разработчик. И всегда есть тема, которую ты видишь впервые, независимо от уровня. Как выше уже написали, это нужно, чтобы не повышать зп. В итоге мы среднее время работы в компании год и имеем, т.к., вместо повышения, человек в другую компанию уходит
Я не из веба (из флаттера/андроида), но если я правильно понял, то под fsd вы имеете ввиду использования feature-list вместо layer-list структуры топлевел директорий. Мне кажется, разбиение по фичам гораздо удобнее на больших проектах. Ибо имея 3 папки domain, data, presentation очень сложно одну фичу делать. Опять же, случаи, когда какая-то бизнес-логика шэрится между фичами достаточно редки. Фича - это же не экран. Фича это же не экран, а более общая вещь. Типо настройки - а там много экранов со всяким. Я в случае с фичами делаю папку features/ и уже внутри фичи идёт размазывание по presentation, data, domain и т.д. Ну и есть _common для апи, наигации и прочей общей функциональности.
Про MV* не совсем понял. Это же паттерны презентации, а не архитектура. Эта * - это тоже presentation на уровне архитектуры проекта. В архитектуре всякие presenter, bloc, viewmodel, controller и т.д. выполняют роль презентации. А моделью уже что угодно может быть. Поэтому view и её логика должны рядом находиться. Это всего лишь способы организации логики конкретного виджета
А ещё лучше при её инициализации
someValue ?: throw SomeException()Хотя у нас suspend функции в репозиториях эксепшнами кидаются и вполне удобно получается. Либо можно использовать подход Either<L, R> и бизнесовые ошибки вообще в эксепшны не засовывать
да нет. если вы про aab, то он ещё раньше в google play появился. просто для разработчиков он необязательным был. и это хорошо, что gp полностью на этот формат переводят, ибо не надо будет качать ресурсы, которые не предназначены для твоего телефона. а вот кнопка build apk в android studio никуда не исчезнет. можно будет так же собрать апкшку и закинуть её в microsoft store. да и вообще хоть куда.
Чел с картинки купи курс - это битмейкер, который каждое видео просит купить его курс по битмейкингу. В сфере создания музыки кстати почти такая же ситуация. Вместо того, чтобы научить людей нотам хотя бы, показывают, как работать с новомодными плагинами. "Ну... делаем вот так, теперь звучит вот так..."