Как мне кажется, Sparkle очень сильно отличается от предыдущих реализаций Ripple. И в этом его главная проблема. Я бы увидев подобное подумал, что с девайсом что-то не так / появились какие-то артефакты.
Даже если Sparkle Ripple сочетается с Material Design 3, он также обязан сочетаться как с приложениями на Material Design 2, так и с приложениями без Material Design вовсе (так как Ripple, в отличие от Material Design, штука системная, а не просто библиотека)
Store без View вне тестирования не имеет смысла. Делать Store наследником ObservableSource, к которому можно подписаться, я не считаю правильным, т.к. не нравится идея работы с подпиской из View (или, что хуже, дополнительной прослойки).
О тестировании в целом. Тестирование того же Reducer все же возможно, но не обособленно. И TestObservable приаттачить можно, но, как и в случае с Reducer, придется приложить дополнительные усилия в виде различных оберток.
Минус существующих решений, на мой взгляд, — один. И он очень субъективен: если нет четкого, полного понимания, что и как работает внутри самого подхода, процесс изучения усложняется при использовании данных решений (по крайней мере, я столкнулся именно с этим).
Что мне не нравилось (и из-за чего возникали сложности с данными решениями):
1) Отход от стандартных терминов (вообще, здесь сложно говорить о каких-то стандартных терминах в MVI), навязывая свои. Не критично, но вызывает своего рода сложности;
2) Раздутость. Некоторые под каждый кусок функционала используют отдельный класс. SRP — это здорово, не спорю. Изначально делал также, но мне не понравилось, как выглядело конечное решение; по итогу — многое заинлайнил.
3) Подписка / .subscribe() / Disposable внутри View.
Основной минус получившегося решения (с чем согласен с linyaKoder) — потеря хорошей тестируемости, предполагаемой подходом. Вырос он из того, что на этапе «сейчас» об этом пункте я попросту не подумал. Постараюсь исправить это в дальнейшем.
изначально так и делал
если не изменяет память, то уперся в то, что были проблемы с переключением фокуса
Как мне кажется, Sparkle очень сильно отличается от предыдущих реализаций Ripple. И в этом его главная проблема. Я бы увидев подобное подумал, что с девайсом что-то не так / появились какие-то артефакты.
Даже если Sparkle Ripple сочетается с Material Design 3, он также обязан сочетаться как с приложениями на Material Design 2, так и с приложениями без Material Design вовсе (так как Ripple, в отличие от Material Design, штука системная, а не просто библиотека)
StoreбезViewвне тестирования не имеет смысла. ДелатьStoreнаследникомObservableSource, к которому можно подписаться, я не считаю правильным, т.к. не нравится идея работы с подпиской изView(или, что хуже, дополнительной прослойки).О тестировании в целом. Тестирование того же
Reducerвсе же возможно, но не обособленно. ИTestObservableприаттачить можно, но, как и в случае сReducer, придется приложить дополнительные усилия в виде различных оберток.Что мне не нравилось (и из-за чего возникали сложности с данными решениями):
1) Отход от стандартных терминов (вообще, здесь сложно говорить о каких-то стандартных терминах в MVI), навязывая свои. Не критично, но вызывает своего рода сложности;
2) Раздутость. Некоторые под каждый кусок функционала используют отдельный класс. SRP — это здорово, не спорю. Изначально делал также, но мне не понравилось, как выглядело конечное решение; по итогу — многое заинлайнил.
3) Подписка / .subscribe() / Disposable внутри View.
Основной минус получившегося решения (с чем согласен с linyaKoder) — потеря хорошей тестируемости, предполагаемой подходом. Вырос он из того, что на этапе «сейчас» об этом пункте я попросту не подумал. Постараюсь исправить это в дальнейшем.