Есть SaveStatePresenter в зависимости com.github.adevone.summer:summer-android-save-state. Внутри него в state можно класть только то, что можно положить в Bundle. Это проверяется в compile-time. Так как используется Bundle, это Android-only решение. Сейчас я в процессе разработки чего-то подобного, но мультиплатформенного. На базе kotlinx.serialization, например.
Думаю, это можно решить это с помощью expect/actual. Лично я использую flow для пагинации.
Да, в MVVM примерно такое же количество кода, но нужно городить отдельные классы для того, чтобы прокинуть несколько параметров в один эвент. Не всегда удобно, как по мне.
MVP для мультиплатформы мне нравится тем, что во время компиляции проверяется, все ли методы view реализованы. Когда есть две платформы и одна из них опережает другую, это очень удобно.
На мой взгляд, странно, что основами программирования, с которых нужно начинать свой путь новичкам, называются устаревшие подходы к проектированию кода на PHP. При том, что автор сам называет их неправильными. Если я начинаю программировать в 2019, зачем мне допускать такие же ошибки, как те, кто начинал в 2009?
На мой взгляд, больше похоже на пример применения SRP, если Parcel и UrgentParcel — это разные, с точки зрения бизнеса, сущности и будут меняться по разным причинам.
Тогда тот факт, что в них один и тот же код — случайность и скоро их код может стать совершенно разным.
Если же это UrgentParcel — просто особый вид Pracel, то почему бы не унаследовать его интерфейс от IParcel, применив в реализации делегирование интерфейса, например? Если переиспользование кода через наследование не устраивает по каким-то причинам
Проект, пока что, на стадии разработки и не всё готово. Байт-код для llvm из Kotlin уже генерируется, а поддержка эмулятора заявлена, но, пока не реализована, насколько мне известно.
Сначала генерируются хедеры для кода на Objective-C, который используется Kotlin'ом. Хранятся они в формате ".def". Генерируются с помощью cInterop.
После этого нужно скомпилировать этот используемый код на Objective-C в llvm байт-код (.bc) с помощью компилятора llvm clang.
Затем компилятору Kotlin konanc передаются хедеры Objective-C и файлы исходного кода (.kt). Он тоже сгенерирует llvm байт-код (.bc).
И, наконец, весь байт-код сливается вместе через llvm-lto.
Дальше можно, например, собрать из получившегося ".o" файла статическую библиотеку (.a) и использовать её в своём приложении под iOS, предварительно сгенерировав из Kotlin хода хедеры для Objective-C (я не нашёл способа это сделать сейчас. Возможно, он в разработке).
Переслушаю подкаст. Может, я пропустил что-то, но почему даны столь серьёзные гарантии обратной совместимости для неоднозначной фичи, если можно было сделать аннотацию, а потом, если что, пометить её как deprecated и через несколько версий выпилить без поднятия мажорной версии языка? Может, Java научится сама грамотно инлайнить лямбды и выводить общие типы и тогда эта фича станет абсолютно бесполезной и даже вредной.
View, в любом случае, держит в себе контекст и ссылка на него даже не weak. Поэтому если передать View за пределы Activity, то это Activity неизбежно утечёт.
А по поводу производительности, хороший вопрос, что затратнее: загрузка анонимного класса или обращение к ресурсу, которое является I/O операцией. Я пробенчмаркаю, когда появится минутка.
Нужно или дублировать объявление каждого виджета, или каждый раз проходить по всей иерархии вьюх в поисках нужного. Плюс неудобно когда объявление части вью находится в одном месте, а другая часть — в другом. Имхо, хорошо верстать на языке для вёрстки, если на нём действительно можно описать всю вёрстку.
Смущает использование Flowable, он может упасть из-за размера буфера и имеет больший оверхед, чем Observable. Так же не понимаю, зачем нужен synchoronized в BindableAdapter. Он тоже создаёт оверхед и не имеет смысла. RxJava позволяет писать код без синхронизаций.
Согласен, что Rx не заканчивается на замене streams, но применение этого, скорее, про сервера и Scala. Я пока не видел кейсов под Android, в которых долгоиграющий Observable или Flowable приносит больше пользы, чем проблем из-за сложного жизненного цикла UI-компонентов (потребителей данных), который нужно обслуживать. Буду рад, если вы приведёте пример
В runtime всё равно будет использоваться какая-то одна версия транзитивной зависимости. В случае Gradle — самая новая из указанных (version 2)
com.github.adevone.summer:summer-android-save-state
. Внутри него вstate
можно класть только то, что можно положить в Bundle. Это проверяется в compile-time. Так как используется Bundle, это Android-only решение. Сейчас я в процессе разработки чего-то подобного, но мультиплатформенного. На базе kotlinx.serialization, например.expect/actual
. Лично я используюflow
для пагинации.Да, в MVVM примерно такое же количество кода, но нужно городить отдельные классы для того, чтобы прокинуть несколько параметров в один эвент. Не всегда удобно, как по мне.
MVP для мультиплатформы мне нравится тем, что во время компиляции проверяется, все ли методы view реализованы. Когда есть две платформы и одна из них опережает другую, это очень удобно.
На мой взгляд, больше похоже на пример применения SRP, если Parcel и UrgentParcel — это разные, с точки зрения бизнеса, сущности и будут меняться по разным причинам.
Тогда тот факт, что в них один и тот же код — случайность и скоро их код может стать совершенно разным.
Если же это UrgentParcel — просто особый вид Pracel, то почему бы не унаследовать его интерфейс от IParcel, применив в реализации делегирование интерфейса, например? Если переиспользование кода через наследование не устраивает по каким-то причинам
После этого нужно скомпилировать этот используемый код на Objective-C в llvm байт-код (.bc) с помощью компилятора llvm clang.
Затем компилятору Kotlin konanc передаются хедеры Objective-C и файлы исходного кода (.kt). Он тоже сгенерирует llvm байт-код (.bc).
И, наконец, весь байт-код сливается вместе через llvm-lto.
Дальше можно, например, собрать из получившегося ".o" файла статическую библиотеку (.a) и использовать её в своём приложении под iOS, предварительно сгенерировав из Kotlin хода хедеры для Objective-C (я не нашёл способа это сделать сейчас. Возможно, он в разработке).
В этой статье описан процесс компиляции Kotlin вместе с C++: justmaku.org/2017-06-07-kotlin-on-ios
Нужно или дублировать объявление каждого виджета, или каждый раз проходить по всей иерархии вьюх в поисках нужного. Плюс неудобно когда объявление части вью находится в одном месте, а другая часть — в другом. Имхо, хорошо верстать на языке для вёрстки, если на нём действительно можно описать всю вёрстку.
https://discuss.kotlinlang.org/t/ternary-operator/2116/12
Смущает использование Flowable, он может упасть из-за размера буфера и имеет больший оверхед, чем Observable. Так же не понимаю, зачем нужен synchoronized в BindableAdapter. Он тоже создаёт оверхед и не имеет смысла. RxJava позволяет писать код без синхронизаций.