Смотрю на твитче блог Leland Richardson, которые в Гугле занимается компиляторным плагином для Compose и параллельно dogfooding. Ну так я бы сказал, что и для сложных сцен на данном этапе всё не просто. Т.е. одинаковые вещи на compose сейчас сделать даже сложнее.
Гибридная схема, на мой взгляд, не совсем работает как надо. Она рассматривает только интересы офисных работников.
Мне как полному удалёнщику она не походит. Я хочу/могу уехать в другой город/страну на 1/3/12 месяцев и "классно собраться в одной комнате" мне не подходит.
Мне кажется, что команда должна согласовывать принцип своей работы на начальном этапе. Либо она полностью офисная(т.е. либо 100% все в офисе либо гибридный подход по решению команды). Либо она полностью удалённая/распределённая и тогда никто ничего не обязан в плане присутствия.
Спасибо за подробные статьи, особенно за наличие всех картинок.
Есть вопрос по передаче результатов от вложенных графов.
Не кажется ли, что в целом передача/получение результатов через бэкстек/навигацию является костылём? Не органичнее ли для этого использовать какие-то общие "бизнес" сущности/компоненты? Например, AuthFlow в результате будет менять наличие юзера в неком UserRepository, информацию из которого и будут получать экраны из других графов навигации.
Вопрос слегка не в тему. Но откуда пошло желание иметь отдельный бекстек для каждой боттом вкладки? Если есть ссылки на хорошие статьи почему это хорошо и улучшает юзабилити/ux/и тд, то был бы рад..
Кто по вашему должен следить за корректностью стейта?
Скажем в UI пришло: loading = true + isCreditDialogShowing = true, что по нашей логике не верно. Кто контролирует это?
И всё таки что-то странное происходит. DI тулза, которая казалось бы должна упрощать собственно работу с зависимостям, становится настолько сложной, что начинают городить абстракции над уже самой тулзой.
Ждём в мобильном сегменте отдельную категорию инженеров — DI developer?)
Т.е. Вы считаете, что идеи можно генерировать только при общении глаз в глаз и по-другому никак они родиться не могут? Или всё таки только Вы так умеете?)
Т.е. если карантин будет вечный — то всем хана и больше идей не будет никогда ни у кого?) Ну ок:)
Тоже бы поучаствовал в разработке приложения. Но пару месяцев назад на форуме писали, что в планах мобильного приложения нет. "but developing a complete mobile app is not in our plans right now."
Так а туговато для кого? Для простых работников, который просто работают?) Или для тех единиц которые что-то хотят придумывать?)
Мне как удалёнщику 6+ лет всё равно на их фантазии. Я просто пишу качественный код и хочу за это денюжку)
На самом деле не нужно бояться "пропустить какой-то там момент") Недавний опыт сеньор+ собеседований показал, что спрашивают всё тоже что и 8 лет назад) Основные компоненты, жизненный цикл, джава, потоки, алгоритмы, Котлин. Из нового только — RxJava могут немного поверхностно спросить + Mvp/Mvvm чутка.
Не соглашусь) Потерять "потенциального" партнёра из-за того, что-то там не закэшировалось может быть значительно хуже сорвавшейся пиццы))
Опять же, статья изначально вышла из того, что приложение стартовало до 15-20 секунд из-за БД. Сколько клиентов/заказов они потеряли при этом за всё время существования проблемы? Судя по графикам из статьи — сопоставимо больше, чем происходят редкие случаи system-kill приложения во время заказа в фоне…
Мой посыл в том, что важнее закрыть критичные для бизнеса вещи, но простыми и безопасными средствами, чем неумело использовать танк сразу для всего:)
Есть и другие примеры. Badoo. Кол-во пользователей многократно больше. Можете поискать инфу, они её тут и писали на Хабре, что почти ничего не кэшируют вообще в приложении.
И вы и мы немного о разном. Мы не спрашиваем о сохранении состояния в целом(что в целом важно). Мы говорим о наличии целой базы данных для этого. В которую как мы видим сохраняется чуть ли не всё вообще)
Как верно заметили ниже — "но зачем?") При этом в одном из предыдущих постов вы указали, что не делает поддержку планшетов "ибо нет необходимости", но зато делаете кучу работы с базой данных и сами решаете проблемы с ней?) Overengineering в Dodo?:)
Смотрю на твитче блог Leland Richardson, которые в Гугле занимается компиляторным плагином для Compose и параллельно dogfooding. Ну так я бы сказал, что и для сложных сцен на данном этапе всё не просто. Т.е. одинаковые вещи на compose сейчас сделать даже сложнее.
Гибридная схема, на мой взгляд, не совсем работает как надо. Она рассматривает только интересы офисных работников.
Мне как полному удалёнщику она не походит. Я хочу/могу уехать в другой город/страну на 1/3/12 месяцев и "классно собраться в одной комнате" мне не подходит.
Мне кажется, что команда должна согласовывать принцип своей работы на начальном этапе. Либо она полностью офисная(т.е. либо 100% все в офисе либо гибридный подход по решению команды). Либо она полностью удалённая/распределённая и тогда никто ничего не обязан в плане присутствия.
"на место". Как псы какие-то?)
Привет. А можете привести некоторые примеры когда и у каких полей приходилось менять маску/форматирования на сервере?
Спасибо за подробные статьи, особенно за наличие всех картинок.
Есть вопрос по передаче результатов от вложенных графов.
Не кажется ли, что в целом передача/получение результатов через бэкстек/навигацию является костылём? Не органичнее ли для этого использовать какие-то общие "бизнес" сущности/компоненты? Например, AuthFlow в результате будет менять наличие юзера в неком UserRepository, информацию из которого и будут получать экраны из других графов навигации.
Если что, то TextInputLayout + TextInputEditText уже это всё имеют на сколько я помню.
Вопрос слегка не в тему. Но откуда пошло желание иметь отдельный бекстек для каждой боттом вкладки? Если есть ссылки на хорошие статьи почему это хорошо и улучшает юзабилити/ux/и тд, то был бы рад..
Кто по вашему должен следить за корректностью стейта?
Скажем в UI пришло: loading = true + isCreditDialogShowing = true, что по нашей логике не верно. Кто контролирует это?
Статью не читал, смотрел картинки… А это реальные фотки или скриншоты с симулятора?!
Или выставить в порядке, как Гугл будет убивать их)
И всё таки что-то странное происходит. DI тулза, которая казалось бы должна упрощать собственно работу с зависимостям, становится настолько сложной, что начинают городить абстракции над уже самой тулзой.
Ждём в мобильном сегменте отдельную категорию инженеров — DI developer?)
Т.е. Вы считаете, что идеи можно генерировать только при общении глаз в глаз и по-другому никак они родиться не могут? Или всё таки только Вы так умеете?)
Т.е. если карантин будет вечный — то всем хана и больше идей не будет никогда ни у кого?) Ну ок:)
Тоже бы поучаствовал в разработке приложения. Но пару месяцев назад на форуме писали, что в планах мобильного приложения нет. "but developing a complete mobile app is not in our plans right now."
Так а туговато для кого? Для простых работников, который просто работают?) Или для тех единиц которые что-то хотят придумывать?)
Мне как удалёнщику 6+ лет всё равно на их фантазии. Я просто пишу качественный код и хочу за это денюжку)
На самом деле не нужно бояться "пропустить какой-то там момент") Недавний опыт сеньор+ собеседований показал, что спрашивают всё тоже что и 8 лет назад) Основные компоненты, жизненный цикл, джава, потоки, алгоритмы, Котлин. Из нового только — RxJava могут немного поверхностно спросить + Mvp/Mvvm чутка.
Было бы интересно узнать у тех кто отвечает "часть останется/часть вернётся" на каких именно сотрудников это распространяется, добровольно ли или нет?
Не соглашусь) Потерять "потенциального" партнёра из-за того, что-то там не закэшировалось может быть значительно хуже сорвавшейся пиццы))
Опять же, статья изначально вышла из того, что приложение стартовало до 15-20 секунд из-за БД. Сколько клиентов/заказов они потеряли при этом за всё время существования проблемы? Судя по графикам из статьи — сопоставимо больше, чем происходят редкие случаи system-kill приложения во время заказа в фоне…
Мой посыл в том, что важнее закрыть критичные для бизнеса вещи, но простыми и безопасными средствами, чем неумело использовать танк сразу для всего:)
Есть и другие примеры. Badoo. Кол-во пользователей многократно больше. Можете поискать инфу, они её тут и писали на Хабре, что почти ничего не кэшируют вообще в приложении.
И вы и мы немного о разном. Мы не спрашиваем о сохранении состояния в целом(что в целом важно). Мы говорим о наличии целой базы данных для этого. В которую как мы видим сохраняется чуть ли не всё вообще)
Как верно заметили ниже — "но зачем?") При этом в одном из предыдущих постов вы указали, что не делает поддержку планшетов "ибо нет необходимости", но зато делаете кучу работы с базой данных и сами решаете проблемы с ней?) Overengineering в Dodo?:)
А зачем вам вообще база? Что вы там храните и для каких сценариев?)
Просто на мой взгляд ваш главный сценарий — зашёл, выбрал, оплатил, закрыл.