Спасибо за пост! Приходилось ли решать проблему открытия страниц в авторизованной зоне? Например нужно открыть страницу, для входа на которую требуется access token
Про достижение лимита: в текущем подходе, чтобы его достичь, грубо говоря, major версия должна стать 210000. Если пользоваться semver, то major версия должна повышаться крайне редко (можно посмотреть на номера версий существующих десятилетиями ЯП). Поэтому достижение кажется почти невероятным. Спасибо за информацию про возможность указания кодов прямо в команде gradlew, буду иметь ввиду! На практике не связывался со взаимосвязью версии БД или кэша с версиями приложения. Видел, что подобный функционал делали через хардкод константы-версии прямо внутри модуля. Но согласен, что всякое бывает и имеет право на жизнь.
Раскройте пожалуйста, какие проблемы в будущем вы имеете ввиду?
"монотонно возрастающим при каждой сборке" - что имеется ввиду? Я представил, что есть какая-то настроенная автоматизация, которая при запуске определенных пайплайнов делает commit с инкрементальным повышением versionCode. С ходу кажется, что то возможно добавит трудностей, когда тестировщики будут работать со сборками их master-и релизных веток, придется внезапно удалять приложение, тк versionCode будет зависеть не от фактической версии приложения, а от очередности сборки. Нам на практике достаточно повышать его в "ключевых" точках - при фичафризе и при патчах с исправлениями ошибок. А все промежуточные ежедневные сборки имеют один и тот же versionCode и это не доставляет проблем тестировщикам и разработчикам.
Предложенный подход не про красивую визуализацию, а про избавление от необходимости думать как и когда его повышать, он повышается в "ключевых" точках.
Спасибо за мотивирующий пост! "В следующем релизе общую библиотеку подключили на обеих платформах..." - расскажите пожалуйста в каком виде производится подключение, как библиотека доставляется до iOS команды?
Да. В фича-модуле может быть несколько экранов. Мы делим по принципу бизнес-домена или отдельного сценария. Знаем, что есть подход, когда один модуль - один изолированный экран, но решили так не делать
Понял. Чтобы не было циклических зависимостей (модуль навигации же должен будет знать про модули с экранами, а модули с экранами должны использовать навигацию), придется модуль навигации разбивать на navigation-api и navigation-impl. Где navigation-api будет состоять из множества интерфейсов, а navigation-impl содержать код, который вы привели выше.
То есть этот почти тот-же вариант, что и предложили мы, только теперь все some-feature-api объединены в один navigation-api. Плюс тут действительно в том, что все destinations описаны в одном месте; ну и что модулей станет меньше. Граф переходов мы так же не сможем понять (кстати, а зачем?). Минус - в раздувающемся модуле и необходимости открыть наружу приватные экраны и вью-модели (пример выше можно немного доработать - вью-модели можно инициировать прямо к конструкторе экрана, так что минус снимается). Как я ответил в первом комментарии, такой подход имеет место быть, но мы посчитали что он нам не подойдет из-за указаных минусов.
"Не понимаю, почему один модуль (экран) начнет знать про другие модули (экраны) в моем видении такой навигации?" - я так не писал, видимо произошло недопонимание.
Да, в нашем подходе так же не будет виден граф. Боюсь, так как в compose навигация работает через ссылки, без дополнительных ухищрений граф переходов увидеть не получится. Тут не оговорено, но на compose хорошо ложится MVI-паттерн. Мы его так же применяем, поэтому у нас вызов всех переходов навигации на экране производится в одном месте, в зависимости от action, который пришел от viewmodel-и; то есть внутри экрана вся навигация в одном месте. То есть этот вопрос решается понятной организацией кода внутри фичи.
Если сможете показать пример, было бы интересно посмотреть, что вы понимаете под отдельно-вынесенной навигацией.
Возможно. Надеюсь, Android сообщество со временем придет к общему решению :)
Да, наверное пока нет идеального решения, надеемся оно выработается со временем. Кажется, вынесение api навигации в супермодуль не сильно поможет понимать структуру навигации - просто в одном модуле будет много методов и сверху также не будет понятно, как выглядит граф переходов.
Не понял вторую часть вопроса (если это был вопрос), уточните пожалуйста
Здравствуйте! Как и другие варианты, имеет право на жизнь. Нам кажется, что такой вариант подходит для небольших приложений с малым количеством экранов. При большом количестве экранов такой подход может привести к раздуванию этого модуля; плюс все модули начнут знать про "приватные" экраны других модулей
Откуда информация про «бесплатно»?
Копипаст из мейл.ру:
«В соответствии с Указом президента от 25 марта 2020 г. № 206 “Об объявлении в Российской Федерации нерабочих дней” с 30 марта по 3 апреля 2020 года установлены нерабочие дни с сохранением за работниками заработной платы. Таким образом, наличие в календарном месяце (март, апрель 2020 года) нерабочих дней не является основанием для снижения заработной платы работникам», — сказано в сообщении на сайте Минтруда.
Значит, для тех, кто захочет работать, эти дни все равно будут оплачены как обычно
Здравствуйте! По неизвестной пока причине не у меня одного изображение с камеры не транслируется на экран. Сама камера включается.
В логах получаю:
onSDKReady version 3.6.363
WebRTC supported: true
Mic/Cam access allowed: true
Mic/Cam access allowed: false
Connection established: true
Спасибо за подробный ответ! Выглядит как надежная схема
Спасибо за пост! Приходилось ли решать проблему открытия страниц в авторизованной зоне? Например нужно открыть страницу, для входа на которую требуется access token
Понял вас. Спасибо за ответ!
Про достижение лимита: в текущем подходе, чтобы его достичь, грубо говоря, major версия должна стать 210000. Если пользоваться semver, то major версия должна повышаться крайне редко (можно посмотреть на номера версий существующих десятилетиями ЯП). Поэтому достижение кажется почти невероятным.
Спасибо за информацию про возможность указания кодов прямо в команде gradlew, буду иметь ввиду!
На практике не связывался со взаимосвязью версии БД или кэша с версиями приложения. Видел, что подобный функционал делали через хардкод константы-версии прямо внутри модуля. Но согласен, что всякое бывает и имеет право на жизнь.
Раскройте пожалуйста, какие проблемы в будущем вы имеете ввиду?
"монотонно возрастающим при каждой сборке" - что имеется ввиду? Я представил, что есть какая-то настроенная автоматизация, которая при запуске определенных пайплайнов делает commit с инкрементальным повышением versionCode.
С ходу кажется, что то возможно добавит трудностей, когда тестировщики будут работать со сборками их master-и релизных веток, придется внезапно удалять приложение, тк versionCode будет зависеть не от фактической версии приложения, а от очередности сборки.
Нам на практике достаточно повышать его в "ключевых" точках - при фичафризе и при патчах с исправлениями ошибок. А все промежуточные ежедневные сборки имеют один и тот же versionCode и это не доставляет проблем тестировщикам и разработчикам.
Предложенный подход не про красивую визуализацию, а про избавление от необходимости думать как и когда его повышать, он повышается в "ключевых" точках.
Спасибо за мотивирующий пост!
"В следующем релизе общую библиотеку подключили на обеих платформах..." - расскажите пожалуйста в каком виде производится подключение, как библиотека доставляется до iOS команды?
Думаю, чтобы не создавался новый массив Array<BottomTabs> при каждой рекомпозиции, что в свою очередь приводило бы к ненужной рекомпозиции BottomBar
Да. В фича-модуле может быть несколько экранов. Мы делим по принципу бизнес-домена или отдельного сценария.
Знаем, что есть подход, когда один модуль - один изолированный экран, но решили так не делать
Понял. Чтобы не было циклических зависимостей (модуль навигации же должен будет знать про модули с экранами, а модули с экранами должны использовать навигацию), придется модуль навигации разбивать на navigation-api и navigation-impl. Где navigation-api будет состоять из множества интерфейсов, а navigation-impl содержать код, который вы привели выше.
То есть этот почти тот-же вариант, что и предложили мы, только теперь все some-feature-api объединены в один navigation-api. Плюс тут действительно в том, что все destinations описаны в одном месте; ну и что модулей станет меньше. Граф переходов мы так же не сможем понять (кстати, а зачем?). Минус - в раздувающемся модуле и необходимости открыть наружу приватные экраны и
вью-модели(пример выше можно немного доработать - вью-модели можно инициировать прямо к конструкторе экрана, так что минус снимается).Как я ответил в первом комментарии, такой подход имеет место быть, но мы посчитали что он нам не подойдет из-за указаных минусов.
Напишите если я вас не правильно понял
"Не понимаю, почему один модуль (экран) начнет знать про другие модули (экраны) в моем видении такой навигации?" - я так не писал, видимо произошло недопонимание.
Да, в нашем подходе так же не будет виден граф. Боюсь, так как в compose навигация работает через ссылки, без дополнительных ухищрений граф переходов увидеть не получится.
Тут не оговорено, но на compose хорошо ложится MVI-паттерн. Мы его так же применяем, поэтому у нас вызов всех переходов навигации на экране производится в одном месте, в зависимости от action, который пришел от viewmodel-и; то есть внутри экрана вся навигация в одном месте. То есть этот вопрос решается понятной организацией кода внутри фичи.
Если сможете показать пример, было бы интересно посмотреть, что вы понимаете под отдельно-вынесенной навигацией.
Возможно. Надеюсь, Android сообщество со временем придет к общему решению :)
Да, наверное пока нет идеального решения, надеемся оно выработается со временем. Кажется, вынесение api навигации в супермодуль не сильно поможет понимать структуру навигации - просто в одном модуле будет много методов и сверху также не будет понятно, как выглядит граф переходов.
Не понял вторую часть вопроса (если это был вопрос), уточните пожалуйста
Здравствуйте! Как и другие варианты, имеет право на жизнь. Нам кажется, что такой вариант подходит для небольших приложений с малым количеством экранов. При большом количестве экранов такой подход может привести к раздуванию этого модуля; плюс все модули начнут знать про "приватные" экраны других модулей
Копипаст из мейл.ру:
«В соответствии с Указом президента от 25 марта 2020 г. № 206 “Об объявлении в Российской Федерации нерабочих дней” с 30 марта по 3 апреля 2020 года установлены нерабочие дни с сохранением за работниками заработной платы. Таким образом, наличие в календарном месяце (март, апрель 2020 года) нерабочих дней не является основанием для снижения заработной платы работникам», — сказано в сообщении на сайте Минтруда.
Значит, для тех, кто захочет работать, эти дни все равно будут оплачены как обычно
В логах получаю:
onSDKReady version 3.6.363
WebRTC supported: true
Mic/Cam access allowed: true
Mic/Cam access allowed: false
Connection established: true