Можно через Shadow плагин, но нужно руками все прописывать. Условно скинуть свой подграф в один Gradle модуль, применть Shadow с relocate и зависить в дальнейшем от него.
Рецепт прост - после каждого обновления, показываем пользователю на старте ненавязчивый попап с вопросом - оцени нас, брат. И в качестве оценок 5 звёздочек. 4 или 5 - идём в магазин. 1-3 - оставить отзыв во внутренний саппорт.
Так делать нельзя по правилам обоих сторов потому что "rating manipulation".
Спасибо за сравнение, но мне кажется оно не очень корректное в том плане, что код на Котлине изначально не производителен из-за необходимости выделать память в куче на каждой итерации. В то время как вариант на Си работает исключительно на стеке. Даже Android Studio ругается, когда мы в View.onDraw создаем объекты, а тут количество итераций еще больше.
Было бы интересно посмотреть на отличия в следующих случаях:
Использовать пул объектов Complex и переиспользовать их насколько возможно.
Не выделять память в куче на Котлине вообще, использовать value class Complex и упаковывать обе координаты в один long как например у класса Offset в компоузе. Только придется обновить алгоритм, чтобы использовать float.
Сделать из Котлин кода Котлин Нейтив бинарник под андроид androidNativeArm64.
Был, но уже нет. В ходе оптимизации расходов Мозилла выкинула раст в отдельную организацию Раст фоундейшон, который теперь спонсируется разными компаниями.
Из примечательного: Гугл – платиновый спонсор, а Мозилла – всего лишь серебрянный.
Опенсорс опенсорсом, но стоит всегда указывать еще лицензию по которой он распространяется. Особенно для указанных проектов выше, у которых часть компонентов GPL. VLCKit – LGPLv2.1. FFmpegKit – уже нужно быть внимательней, т.к. можно так и GPL v3.0 скачать случайно. Но благо FFMpeg на мобильных устройствах поддерживает использование системных библиотек для h264/h265 вместо GPL licensed x264/x265.
модули позволяют ускорить разработку, уменьшить кол-во merge-конфликтов, снизить кол-во ошибок во всем приложении.
В последнее время многомодульность преподносится в виде решения вообще всех насущных проблем.
Мердж конфликты появляются когда несколько человек трогают одно и то же место, нет никакой разницы, будет это место в одном из сотен модулей или в одном единственном. Если экраны раскидать по пакетам как по модулям, а не городить package by type, то и конфликтов будет ровно столько же.
Как именно многомодульность уменьшает количество ошибок в приложении мне тоже не очень ясно.
И все это идет с огромной пачкой проблем по поддержанию корректности структуры модулей и поддержки Gradle конфигураций.
Этот один человек – Developer Relations Engineer @ Google, working on Android. Я крайне сомневаюсь, что у них там нет единой линии между всеми деврелами, которой они придерживаются.
Чем обоснован переход на flow
Просто попытка не плодить сущности. Вот есть обсервабл дата холдер в виде LiveData. Сторонняя зависимость по сути из одного класса. Которая еще и в тестах требует под себя целую рулу (InstantTaskExecutorRule). И тут внезапно появляется похожая штука, которая по сути часть стандартной библиотеки Kotlin, так еще и с более обширным API.
Тратить время на целенаправленную миграцию кмк смысла нет, но потихоньку выпиливать можно.
Почему используете gradle а не gradle wrapper? Если только для того, чтобы не качать бинарник каждый раз, то как синхронизируете версию Gradle в Docker с версией в Android проекте? Руками каждый раз?
Dynamic Color — интересная вещь. Мне нравится, что с Android 13 все вендоры обязаны будут поддержать эту фичу. Но есть сомнения, что сторонние приложения в ближайшее время начнут поддерживать динамические цвета.
И не безосновательные, я крайне сомневаюсь что бренды тратящие сотни часов на разработку цветовой схемы приложения будут от нее отказываться. Тоже самое с новыми монохромными иконками, которые превращают список приложений в абсолютную монохромную кашу (гуглу здесь не привыкать, у него самого уже давно иконки все сливаются).
У меня был такой же кейс, я его решил намного проще через StorageAccessFramework доступный вроде бы с 4.4 версии. Он даже разрешения на запись не требует и работает как обычный файлпикер в десктопах. Пользователь сам сможет выбрать папку и название файла.
288 картинок с почти нечитаемым текстом на 200 МБ трафика.
Даже просто выложить видео без текста было бы лучшим решением, потому что смотреть ваши скриншоты ровно тоже самое что и смотреть видео.
Для теста запустили приложение использующее exoPlayer для отображения потокового видео – все взлетело без проблем, работает. Так что «сишные» библиотеки не страшны
Но ExoPlayer по-умолчанию не имеет никаких нативных либ, только в экстеншонах, да и те доступны под х86 тоже, так что нужно еще и abi фильтр настроить правильно для эксперимента.
После всех этих действий, у меня перестал запускаться эмулятор и пока с этим не разобрался
Потому что для виртуализации используется Hyper-V, а эмуляторы из студии один из трех вариантов. Покапайте в эту сторону, возможно достаточно будет их пересоздать чтобы SDK вдуплил что теперь нужно использовать Hyper-V. (я не знаю деталей, не использую винду)
А есть примеры? А то пока нахожу только ограничения самой платформы (Android 9+), но не самого GP.
К тому же вендорские приложения, которые обновляются через GP, 100% их используют.
Можно через Shadow плагин, но нужно руками все прописывать. Условно скинуть свой подграф в один Gradle модуль, применть Shadow с relocate и зависить в дальнейшем от него.
https://twitter.com/pietbrauer/status/791883047373246464
Ну тут "прокатило"/"не прокатило", как и с любыми правилами, которые нельзя так сходу проверить модераторам.
Так делать нельзя по правилам обоих сторов потому что "rating manipulation".
Зачем JS? Можно же собрать нативную либу и юзать ее из QT? Или Аврова не съест Linux либу?
Спасибо за сравнение, но мне кажется оно не очень корректное в том плане, что код на Котлине изначально не производителен из-за необходимости выделать память в куче на каждой итерации. В то время как вариант на Си работает исключительно на стеке. Даже Android Studio ругается, когда мы в
View.onDrawсоздаем объекты, а тут количество итераций еще больше.Было бы интересно посмотреть на отличия в следующих случаях:
Использовать пул объектов
Complexи переиспользовать их насколько возможно.Не выделять память в куче на Котлине вообще, использовать
value class Complexи упаковывать обе координаты в одинlongкак например у класса Offset в компоузе. Только придется обновить алгоритм, чтобы использоватьfloat.Сделать из Котлин кода Котлин Нейтив бинарник под андроид
androidNativeArm64.Был, но уже нет. В ходе оптимизации расходов Мозилла выкинула раст в отдельную организацию Раст фоундейшон, который теперь спонсируется разными компаниями.
Из примечательного: Гугл – платиновый спонсор, а Мозилла – всего лишь серебрянный.
https://foundation.rust-lang.org/members/
Опенсорс опенсорсом, но стоит всегда указывать еще лицензию по которой он распространяется. Особенно для указанных проектов выше, у которых часть компонентов GPL.
VLCKit – LGPLv2.1.
FFmpegKit – уже нужно быть внимательней, т.к. можно так и GPL v3.0 скачать случайно. Но благо FFMpeg на мобильных устройствах поддерживает использование системных библиотек для h264/h265 вместо GPL licensed x264/x265.
MVx – это архитектурные паттерны презентационного слоя. Ничто не мешает использовать «чистую архитектуру» с ними, они всего-лишь один из слоев торта.
Есть такое. Только сейчас самый модный вариант сейчас – класть в .toml файлик.
Ну да, так и было. Ссылка на новость, но полный текст исследования только по запросу.
В последнее время многомодульность преподносится в виде решения вообще всех насущных проблем.
Мердж конфликты появляются когда несколько человек трогают одно и то же место, нет никакой разницы, будет это место в одном из сотен модулей или в одном единственном. Если экраны раскидать по пакетам как по модулям, а не городить package by type, то и конфликтов будет ровно столько же.
Как именно многомодульность уменьшает количество ошибок в приложении мне тоже не очень ясно.
И все это идет с огромной пачкой проблем по поддержанию корректности структуры модулей и поддержки Gradle конфигураций.
Этот один человек – Developer Relations Engineer @ Google, working on Android. Я крайне сомневаюсь, что у них там нет единой линии между всеми деврелами, которой они придерживаются.
Просто попытка не плодить сущности. Вот есть обсервабл дата холдер в виде LiveData. Сторонняя зависимость по сути из одного класса. Которая еще и в тестах требует под себя целую рулу (InstantTaskExecutorRule). И тут внезапно появляется похожая штука, которая по сути часть стандартной библиотеки Kotlin, так еще и с более обширным API.
Тратить время на целенаправленную миграцию кмк смысла нет, но потихоньку выпиливать можно.
Уже нет.
LiveData is still our solution for Java developers, beginners, and simple situations. For the rest, a good option is moving to Kotlin Flows.
Почему используете
gradleа неgradle wrapper? Если только для того, чтобы не качать бинарник каждый раз, то как синхронизируете версию Gradle в Docker с версией в Android проекте? Руками каждый раз?И не безосновательные, я крайне сомневаюсь что бренды тратящие сотни часов на разработку цветовой схемы приложения будут от нее отказываться. Тоже самое с новыми монохромными иконками, которые превращают список приложений в абсолютную монохромную кашу (гуглу здесь не привыкать, у него самого уже давно иконки все сливаются).
Отличный способ выстрелить себе в ногу на погрешностях округления. Этот пример считает до 9.900002, в то время как Kotlin версия до 10.0.
Но отсутсвие нормального for-loop в Kotlin конечно убивает.
У меня был такой же кейс, я его решил намного проще через StorageAccessFramework доступный вроде бы с 4.4 версии. Он даже разрешения на запись не требует и работает как обычный файлпикер в десктопах. Пользователь сам сможет выбрать папку и название файла.
https://developer.android.com/training/data-storage/shared/documents-files#create-file
288 картинок с почти нечитаемым текстом на 200 МБ трафика.
Даже просто выложить видео без текста было бы лучшим решением, потому что смотреть ваши скриншоты ровно тоже самое что и смотреть видео.
Но ExoPlayer по-умолчанию не имеет никаких нативных либ, только в экстеншонах, да и те доступны под х86 тоже, так что нужно еще и abi фильтр настроить правильно для эксперимента.
Потому что для виртуализации используется Hyper-V, а эмуляторы из студии один из трех вариантов. Покапайте в эту сторону, возможно достаточно будет их пересоздать чтобы SDK вдуплил что теперь нужно использовать Hyper-V. (я не знаю деталей, не использую винду)
А есть примеры? А то пока нахожу только ограничения самой платформы (Android 9+), но не самого GP.
К тому же вендорские приложения, которые обновляются через GP, 100% их используют.