Оба вопроса не имеют отношения к навигации, для них нужен свой механизм.
Статья о прокидывании событий, а не о навигации. Навигацией занимается отдельный Навигатор. Поэтому и вопросы такие :)
Вообще, сама навигация происходит (должна) от одного фрагмента/активити к другому фрагменту/активити, то есть от одной View к другой. ViewModel — слой, отвечающий за данные и бизнес-логику и она не должна сама производить навигацию (конечно, разработчики могут делать что угодно и внедрять навигаторы в любое место приложения, это вопрос больше к личному предпочтению разделения отвественности, не будем холиварить на эту тему :).
Мы не производим навигацию между View(Fragment/Activity) из ViewModel, так как у них разные зоны ответственности. Вместо этого, мы отправляем события во View, в котором есть Navigator, который непосредственно управляет навигацией. И далее, если событие навигационное, с помощью Navigator-a открываются другие Fragments/Activities, а если событие локальное, но связанное с фреймворком андроид – показать Alert, Snackbar, запрос на системные пермишены – то такие события обрабатываются самим фрагментом.
Вы прокидываете навигатор во ViewModel и не важно, где и как навигация будет осуществлена.
Есть пара вопросов:
1. Во ViewModel вам нужно показать Snackbar, который привязывается к конкретной View фрагмента. Как это реализовать в вашем случае?
2. Нужно обработать ошибку сети. Данная ошибка одновременно пришла от 5 запросов. Как показать один AlertDialog?
Разные события — разные классы с необходимыми аргументами в данном событии. Иначе, как отличать события и их последующую обработку, если события разные? А если обработка событий одинаковая и аргументы одинаковые, то может и событие одно? :)
Использовать можно хоть sealed class, хоть просто class (но не data class).
Вы пишите, что получился аналог Rx-BehaviorSubject-a, но RxJava хороша своей расширяемостью.
У нас в проекте нет RxJava.
Если речь про взаимодействие Presenter и View не проще использовать Moxy? Там организованы похожие стратегии, которые можно расширять.
1. Так и есть. В оптимизированном варианте изображение основы включает все кости и мышцы. Накладываются только участвовавшие мышцы.
2. Так и есть. В каждой группе мышц захардкодены ее координаты на основе (общей карте).
3. Так и есть. Отрисовываются только нужные элементы, но методом
resultCanvas.drawBitmap(bitmapDst, x, y, paint);
О шейдерах ничего не могу сказать, не знаком, посмотрю обязательно, спасибо!
Ох, как же я забыл об этом написать, это был первый вариант. Все мышцы хранились в VectorDrawable (тот же SVG, используется в Android). К сожалению, программно заменить цвет заливки нельзя (либо я не нашел таких методов). Но самый большой минус – векторные изображения сначала конвертируются в растр нужного размера, а затем уже их можно полноценно использовать, а это дополнительная память и время.
Поэтому от использования вектора очень быстро отказался, но можно было бы озаглавить пост «Ускорил в 100 раз!», наверное :)
В дополнение, существует LayerDrawable, который позволяет накладывать массив Drawable друг на друга. Удобно, но ресурсоёмко.
Удивительно, но это не рационально :)
Во-первых, сейчас заготовок: 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
В-третьих, как следствие второго, вы не сможете переиспользовать ресурсы, уже декодированные.
Статья о прокидывании событий, а не о навигации. Навигацией занимается отдельный Навигатор. Поэтому и вопросы такие :)
Вообще, сама навигация происходит (должна) от одного фрагмента/активити к другому фрагменту/активити, то есть от одной View к другой. ViewModel — слой, отвечающий за данные и бизнес-логику и она не должна сама производить навигацию (конечно, разработчики могут делать что угодно и внедрять навигаторы в любое место приложения, это вопрос больше к личному предпочтению разделения отвественности, не будем холиварить на эту тему :).
Мы не производим навигацию между View(Fragment/Activity) из ViewModel, так как у них разные зоны ответственности. Вместо этого, мы отправляем события во View, в котором есть Navigator, который непосредственно управляет навигацией. И далее, если событие навигационное, с помощью Navigator-a открываются другие Fragments/Activities, а если событие локальное, но связанное с фреймворком андроид – показать Alert, Snackbar, запрос на системные пермишены – то такие события обрабатываются самим фрагментом.
Есть пара вопросов:
1. Во ViewModel вам нужно показать Snackbar, который привязывается к конкретной View фрагмента. Как это реализовать в вашем случае?
2. Нужно обработать ошибку сети. Данная ошибка одновременно пришла от 5 запросов. Как показать один AlertDialog?
Использовать можно хоть sealed class, хоть просто class (но не data class).
У нас в проекте нет RxJava.
Здесь про MVVM, не MPV.
Здесь о фрагментах думал, конечно, т. к. мы с ними. Уточнение верное, спасибо!
Да, готовые используются для наложения в других местах.
String также необходим для поиска, хранения в бд, статистики и тд.
Благодарю!
2. Так и есть. В каждой группе мышц захардкодены ее координаты на основе (общей карте).
3. Так и есть. Отрисовываются только нужные элементы, но методом
О шейдерах ничего не могу сказать, не знаком, посмотрю обязательно, спасибо!
Поэтому от использования вектора очень быстро отказался, но можно было бы озаглавить пост «Ускорил в 100 раз!», наверное :)
В дополнение, существует LayerDrawable, который позволяет накладывать массив Drawable друг на друга. Удобно, но ресурсоёмко.
Во-первых, сейчас заготовок: 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
В-третьих, как следствие второго, вы не сможете переиспользовать ресурсы, уже декодированные.
Ударит по привлекательности — потому что, когда у человека есть деньги на еду (хорошее пособие), то мотивация пропадает, ведь и так все не плохо.