Comments 6
Зачем вы пишите мобильные приложения с таким подходом? Они же у вас и выглядят 100% как кусок фекалий (поправим какие-то отступы, а ничего, что там инсеты надо обрабатывать уже, predictive back использовать). Вы за год не способны понять и донести что нужно время на обновление? 35 api вышло не вчера как бы.
Я даже боюсь представить какой вы там c/cpp код с такими подходами пишете...
Про зачем, как выглядят и все прочее. Мне кажется вы не уловили основной посыл материала - речь о том, что есть задача, есть требования по срокам. Речь совсем не о том, как мне хочется делать или не хочется, посыл в том, что делать если ситуация сложилась аналогичным образом. Не вижу у себя в тексте нигде о том, что подход рекомендован кем-либо.
Касательно донести - не знаю какие правила в вашей компании, а в нашей считают каждый рубль, потому время от времени и получаем кейс, когда хорошее решение проигрывает - более дешевому, новые фичи в приоритете относительно оптимизаций и рефакторинга, независимо от пожеланий и мнений команды разработки.
По поводу чего вы там боитесь - не бойтесь)
Мой опыт:
— 3 древних проекта, куча модулей, deprecated-код, а заказчик говорит: «Это же просто цифры поменять, да?»
— Android SDK Update Assistant? Смешно. Пришлось вручную ковыряться в граблах, как археолог в руинах.
Какой из этого вывод
Google хочет, чтобы все приложения были современными, но забывает, что половина кода в индустрии — легаси на грани археологии. Бизнес не хочет тратить время на апдейты, пока Google не пригрозит баном. Разработчики сидят с if (SDK_INT > UPSIDE_DOWN_CAKE) и мечтают о переписывании всего с нуля.
а, List.getFirst(), уже классическая подстава от Kotlin. Хорошо, что она описана в официальных гайдах по обновлению, есть в youtrack jetbrains.
Еще есть поддержка страниц 16 кб для гугл плэя. Обновляться еще прикольнее. Когда нужно пересобрать нативные заброшенные под лет так 10 назад библиотеки.
Android обновление API SDK до 35 версии в сжатые сроки, в большом легаси-проекте