Огонь, спасибо за статью! Ещё всеми этими возможностями удобно пользоваться "на автомате" с помощью шорткатов. Писал о том, как начать использовать шорткаты и не возненавидеть мир в этой статье, надеюсь, будет полезно ?
Спасибо, заложил статью. Как раз сейчас в команде натыкаемся на проблемы, что продумывает как делать один человек, а делают другие. Регулярно какая-то часть знаний и требований теряется по ходу работы.
Добрый вечер. Прошу прощения, что у вас возникли проблемы при работе с нашим приложением. Мы постоянно следим за его качеством и стараемся оперативно исправлять ошибки. Проблему с загрузкой фото постараемся решить как можно скорее. Если нашли еще ошибки, не стесняйтесь написать в чат (в разделе Контакты) - операторы обязательно помогут или, если проблему не получится решить, сообщат о ней команде разработки. Спасибо за фидбек!
На мой вкус удобно, но твёрдых аргументов за или против у меня нет. Для меня у макбука (у меня рабочий MacBook Pro 2018) очень удобная клавиатура и трекпад. Тач панель для разработки я использую как F-кнопки, так что от неё пользы особой не получаю, даже скорее наоборот.
Спасибо за комментарий! Возможно, выразился не совсем точно - конечно, никто не стоял надо мной, не порол за плохое знание шорткатов и никто не уволил бы даже если я наотрез отказался даже слышать о шорткатах. В ходе онбординга новых сотрудников знакомят с практиками, которые хорошо себя зарекомендовали в повседневной работе в компании или в определённой команде. Изучение и применение шорткатов - всего лишь одна из таких практик. К слову, эти рекомендации исходят не от менеджеров, а от коллег, которые уже через это прошли и рекомендуют только то, в пользе чего уверены сами.
Keymap Reference немного бесполезен - продуктов jetbrains много, и в каждом много вариантов раскладок, а документ один. В этом смысле Keymap Exporter более актуален - он печатает вашу текущую ракладку. А вот Productivity Guide - отличный инструмент, совсем забыл про него написать. Спасибо!
Всё так, шорткаты ради шорткатов не имеют смысла. Они нужны для оптимизации рутины. Кажется, что некоторые фичи проще вызвать с помощью мыши и не совсем понятно зачем вообще запоминать шорткат, если что-то нужно делать всего раз или два в день. Но если в это вложиться и довести до автоматизма, то производительность довольно сильно растёт. На одном шорткате/одной фиче это может быть незаметно, а в сумме прирост будет приличный
Но, естественно, если что-то я делаю раз в неделю или раз в месяц, учить шорткат для этого скорее всего нет смысла
Сам FragmentContainerView всегда остаётся прозрачным. Чтобы добиться скругления углов и не терять его при анимации, можно покрасить со скруглениями корневой элемент BottomSheetDialogFragment'а и либо не красить корневой элемент дочерних фрагментов, либо установить ему background с такими же скруглёнными краями. Пример можно пощупать на гитхабе
Привет! Здорово, что вы обратили на это внимание. На самом деле, приложение рисуется edge-to-edge, а навбар и статус бар покрашены, но покрашены неудачно. Статус бар уже поправлен (просто скрины делались относительно давно), а навбар пока на очереди.
Спасибо за ваш комментарий, рад, что вам понравилась анимация!
Рад, что идея вам понравилась! Спасибо за обратную связь по статье и за ссылку на интересную статью про inset'ы! Позвольте пару мыслей по тем пунктам, о которых вы упомянули:
Вы абсолютно правы, что использовать insets правильнее, чем получать высоту системных отступов (в нашем случае — статус бара) вручную. Но тут есть один момент — «из коробки» BottomSheetDialog не позволяет обрабатывать inset'ы (об этом на своём митапе рассказывали ребята из Redmadrobot, вот ссылка на комментарий и митап). Это происходит из-за fitsSystemWindows=«true» у CoordinatorLayout'а в BottomSheetDialog. Я посчитал, что решение этой проблемы за рамками данной статьи, поэтому остаётся два простых варианта, как рассчитать доступную высоту — из высоты экрана вычесть либо padding'и CoordinatorLayout'а (padding'и установятся автоматически за счет fitsSystemWindows=«true»), либо высоту status bar'а. Я посчитал, что между этими вариантами разницы нет, но возможно лучше было взять использовать padding'и CoordinatorLayout'а
«В методе getScreenHeight используется только статус бар» — всё верно, так и должно быть. Метод Display.getSize(), который я использовал для получения высоты экрана, внутри себя уже убирает некоторые системные выступы из общей высоты, например, он вычитает высоту navigation бара (проверено на устройствах с navigation баром). Возможно, правильнее было бы использовать Display.getRealSize(), который возвращает полный размер экрана, и вычесть высоту и статус бара, и navigation бара (а еще правильнее, еще раз соглашусь с вами, — использовать inset'ы)
Да, можно так, это проще
Я мог что-то упустить, поэтому буду рад дополнительным комментариям :)
Вы правы (только что посмотрел исходники). Не знал, что в этом случае не будет рефлексии. Спасибо за совет, поправил текст и теперь буду знать про это!
Спасибо! Устройства версии ниже 5.0 поддержать будет довольно трудно, так как transition api доступен только начиная с Lollipop. Для нас это не было проблемой, потому что мы сразу решили такие устройства оставить без данной анимации. Я думаю, если появилась задача поддержать pre-lollipop, то мы использовали бы тот же подход «зафиксировать высоту, потом анимировать», только делать это пришлось бы не с помощью Shared Element Transition, а вручную до и после транзакции фрагментов
Поведение осталось от BottomSheetDialog. По факту, у нас получился честный BottomSheetDialogFragment, просто в него с помощью его childFragmentManager добавляются фрагменты. В теории, даже смена состояний должна работать (но я не пробовал)
Огонь, спасибо за статью! Ещё всеми этими возможностями удобно пользоваться "на автомате" с помощью шорткатов. Писал о том, как начать использовать шорткаты и не возненавидеть мир в этой статье, надеюсь, будет полезно ?
Спасибо, заложил статью. Как раз сейчас в команде натыкаемся на проблемы, что продумывает как делать один человек, а делают другие. Регулярно какая-то часть знаний и требований теряется по ходу работы.
Использование маркетинговых материалов было лицензировано правообладателем, поэтому с этим проблем не возникло
Добрый вечер. Прошу прощения, что у вас возникли проблемы при работе с нашим приложением. Мы постоянно следим за его качеством и стараемся оперативно исправлять ошибки. Проблему с загрузкой фото постараемся решить как можно скорее. Если нашли еще ошибки, не стесняйтесь написать в чат (в разделе Контакты) - операторы обязательно помогут или, если проблему не получится решить, сообщат о ней команде разработки. Спасибо за фидбек!
На мой вкус удобно, но твёрдых аргументов за или против у меня нет. Для меня у макбука (у меня рабочий MacBook Pro 2018) очень удобная клавиатура и трекпад. Тач панель для разработки я использую как F-кнопки, так что от неё пользы особой не получаю, даже скорее наоборот.
External Tools - топ! Присоединяюсь к @deitry, всем рекомендую взять в арсенал
Спасибо за комментарий! Возможно, выразился не совсем точно - конечно, никто не стоял надо мной, не порол за плохое знание шорткатов и никто не уволил бы даже если я наотрез отказался даже слышать о шорткатах. В ходе онбординга новых сотрудников знакомят с практиками, которые хорошо себя зарекомендовали в повседневной работе в компании или в определённой команде. Изучение и применение шорткатов - всего лишь одна из таких практик. К слову, эти рекомендации исходят не от менеджеров, а от коллег, которые уже через это прошли и рекомендуют только то, в пользе чего уверены сами.
Спасибо! Очень много полезных шорткатов. Плюсик за Zen Mode и Vimium
Keymap Reference немного бесполезен - продуктов jetbrains много, и в каждом много вариантов раскладок, а документ один. В этом смысле Keymap Exporter более актуален - он печатает вашу текущую ракладку. А вот Productivity Guide - отличный инструмент, совсем забыл про него написать. Спасибо!
Отлично сказано
Ого, это интересно. А вы не пробовали предложить получившуюся схему разработчикам NX? Она выглядит очень продуманной
Всё так, шорткаты ради шорткатов не имеют смысла. Они нужны для оптимизации рутины. Кажется, что некоторые фичи проще вызвать с помощью мыши и не совсем понятно зачем вообще запоминать шорткат, если что-то нужно делать всего раз или два в день. Но если в это вложиться и довести до автоматизма, то производительность довольно сильно растёт. На одном шорткате/одной фиче это может быть незаметно, а в сумме прирост будет приличный
Но, естественно, если что-то я делаю раз в неделю или раз в месяц, учить шорткат для этого скорее всего нет смысла
Кажется, это обсуждалось тут: https://github.com/microsoft/vscode/issues/26729, но готового расширения для VSCode я не нашел
Спасибо за ваш комментарий, рад, что вам понравилась анимация!
Я мог что-то упустить, поэтому буду рад дополнительным комментариям :)