Как стать автором
Обновить
6
Карма
0
Рейтинг
Alexey Che @Klukwist

Android dev

Prosto: убираем бойлерплейт при работе с RecyclerView

Нужно для моих задач. Конкретно в данном простом примере необходимости нет.

Отправка событий из ViewModel в Activity/Fragment в MVVM

Оба вопроса не имеют отношения к навигации, для них нужен свой механизм.

Статья о прокидывании событий, а не о навигации. Навигацией занимается отдельный Навигатор. Поэтому и вопросы такие :)

Вообще, сама навигация происходит (должна) от одного фрагмента/активити к другому фрагменту/активити, то есть от одной View к другой. ViewModel — слой, отвечающий за данные и бизнес-логику и она не должна сама производить навигацию (конечно, разработчики могут делать что угодно и внедрять навигаторы в любое место приложения, это вопрос больше к личному предпочтению разделения отвественности, не будем холиварить на эту тему :).

Мы не производим навигацию между View(Fragment/Activity) из ViewModel, так как у них разные зоны ответственности. Вместо этого, мы отправляем события во View, в котором есть Navigator, который непосредственно управляет навигацией. И далее, если событие навигационное, с помощью Navigator-a открываются другие Fragments/Activities, а если событие локальное, но связанное с фреймворком андроид – показать Alert, Snackbar, запрос на системные пермишены – то такие события обрабатываются самим фрагментом.

Отправка событий из ViewModel в Activity/Fragment в MVVM

Вы прокидываете навигатор во ViewModel и не важно, где и как навигация будет осуществлена.
Есть пара вопросов:
1. Во ViewModel вам нужно показать Snackbar, который привязывается к конкретной View фрагмента. Как это реализовать в вашем случае?
2. Нужно обработать ошибку сети. Данная ошибка одновременно пришла от 5 запросов. Как показать один AlertDialog?

Отправка событий из ViewModel в Activity/Fragment в MVVM

Разные события — разные классы с необходимыми аргументами в данном событии. Иначе, как отличать события и их последующую обработку, если события разные? А если обработка событий одинаковая и аргументы одинаковые, то может и событие одно? :)
Использовать можно хоть sealed class, хоть просто class (но не data class).

Вы пишите, что получился аналог Rx-BehaviorSubject-a, но RxJava хороша своей расширяемостью.

У нас в проекте нет RxJava.

Если речь про взаимодействие Presenter и View не проще использовать Moxy? Там организованы похожие стратегии, которые можно расширять.

Здесь про MVVM, не MPV.

Отправка событий из ViewModel в Activity/Fragment в MVVM

Здесь о фрагментах думал, конечно, т. к. мы с ними. Уточнение верное, спасибо!

Как я ускорил обработку изображений на Android в 15 раз

Да, готовые используются для наложения в других местах.
String также необходим для поиска, хранения в бд, статистики и тд.

Как я ускорил обработку изображений на Android в 15 раз

Супер, видится очень быстрым.
Благодарю!

Как я ускорил обработку изображений на Android в 15 раз

1. Так и есть. В оптимизированном варианте изображение основы включает все кости и мышцы. Накладываются только участвовавшие мышцы.
2. Так и есть. В каждой группе мышц захардкодены ее координаты на основе (общей карте).
3. Так и есть. Отрисовываются только нужные элементы, но методом
resultCanvas.drawBitmap(bitmapDst, x, y, paint); 

О шейдерах ничего не могу сказать, не знаком, посмотрю обязательно, спасибо!

Как я ускорил обработку изображений на Android в 15 раз

Ох, как же я забыл об этом написать, это был первый вариант. Все мышцы хранились в VectorDrawable (тот же SVG, используется в Android). К сожалению, программно заменить цвет заливки нельзя (либо я не нашел таких методов). Но самый большой минус – векторные изображения сначала конвертируются в растр нужного размера, а затем уже их можно полноценно использовать, а это дополнительная память и время.
Поэтому от использования вектора очень быстро отказался, но можно было бы озаглавить пост «Ускорил в 100 раз!», наверное :)
В дополнение, существует LayerDrawable, который позволяет накладывать массив Drawable друг на друга. Удобно, но ресурсоёмко.

Как я ускорил обработку изображений на Android в 15 раз

Удивительно, но это не рационально :)
Во-первых, сейчас заготовок: 31 мышца Х 2 пола = 62 файла. Если сохранять все перекрашенные варианты — это х10 цветов, или 620 файлов. Текущий объем файлов занимает 766КБ (уже кропнутых). По вашему варианту объем отдельных файлов составит более 7МБ – это роскошь для мобайла.
Во-вторых, декодирование ресурсов требует в 3-6 раз больше времени, чем перекрашивание. Специально для вас замерил:
decodeResource> 83 ms
Paint> 18 ms
decodeResource> 85 ms
Paint> 16 ms
decodeResource> 137 ms
Paint> 26 ms

В-третьих, как следствие второго, вы не сможете переиспользовать ресурсы, уже декодированные.

Угроза ИИ – не Skynet, а исчезновение среднего класса

Ударит по привлекательности — потому что, когда у человека есть деньги на еду (хорошее пособие), то мотивация пропадает, ведь и так все не плохо.

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Работает в
Дата рождения
Зарегистрирован
Активность