Gunakan plugin perpustakaan Car UI untuk membuat implementasi lengkap penyesuaian komponen di perpustakaan Car UI alih-alih menggunakan runtime resource overlay (RRO). RRO memungkinkan Anda mengubah hanya sumber daya XML komponen pustaka UI Mobil, yang membatasi sejauh mana Anda dapat menyesuaikannya.
Buat sebuah plugin
Plugin pustaka Car UI adalah APK yang berisi kelas yang mengimplementasikan sekumpulan API Plugin . Plugin API dapat dikompilasi menjadi plugin sebagai perpustakaan statis.
Lihat contoh di Soong dan Gradle:
Segera
Perhatikan contoh Soon ini:
android_app {
name: "my-plugin",
min_sdk_version: "28",
target_sdk_version: "30",
aaptflags: ["--shared-lib"],
sdk_version: "current",
manifest: "src/main/AndroidManifest.xml",
srcs: ["src/main/java/**/*.java"],
resource_dirs: ["src/main/res"],
static_libs: [
"car-ui-lib-oem-apis",
],
// Disable optimization is mandatory to prevent R.java class from being
// stripped out
optimize: {
enabled: false,
},
certificate: ":my-plugin-certificate",
}
Gradle
Lihat file build.gradle
ini:
apply plugin: 'com.android.application'
android {
compileSdkVersion 30
defaultConfig {
minSdkVersion 28
targetSdkVersion 30
}
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
signingConfigs {
debug {
storeFile file('chassis_upload_key.jks')
storePassword 'chassis'
keyAlias 'chassis'
keyPassword 'chassis'
}
}
}
dependencies {
implementation project(':oem-apis')
// Or use the following if you'd like to use the maven artifact
// implementation 'com.android.car.ui:car-ui-lib-plugin-apis:1.0.0'
}
Settings.gradle
:
// You can remove the ':oem-apis' if you're using the maven artifact.
include ':oem-apis'
project(':oem-apis').projectDir = new File('./path/to/oem-apis')
include ':my-plugin'
project(':my-plugin').projectDir = new File('./my-plugin')
Plugin harus memiliki penyedia konten yang dideklarasikan dalam manifesnya yang memiliki atribut berikut:
android:authorities="com.android.car.ui.plugin"
android:enabled="true"
android:exported="true"
android:authorities="com.android.car.ui.plugin"
membuat plugin dapat ditemukan di perpustakaan UI Mobil. Penyedia harus diekspor sehingga dapat ditanyakan pada saat runtime. Selain itu, jika atribut enabled
disetel ke false
, implementasi default akan digunakan sebagai pengganti implementasi plugin. Kelas penyedia konten tidak harus ada. Dalam hal ini, pastikan untuk menambahkan tools:ignore="MissingClass"
ke definisi penyedia. Lihat contoh entri manifes di bawah ini:
<application>
<provider
android:name="com.android.car.ui.plugin.PluginNameProvider"
android:authorities="com.android.car.ui.plugin"
android:enabled="false"
android:exported="true"
tools:ignore="MissingClass"/>
</application>
Terakhir, sebagai tindakan pengamanan, Tandatangani aplikasi Anda .
Plugin sebagai perpustakaan bersama
Berbeda dengan pustaka statis Android yang dikompilasi langsung ke dalam aplikasi, pustaka bersama Android dikompilasi menjadi APK mandiri yang direferensikan oleh aplikasi lain saat runtime.
Plugin yang diimplementasikan sebagai pustaka bersama Android memiliki kelas yang ditambahkan secara otomatis ke pemuat kelas bersama antar aplikasi. Saat aplikasi yang menggunakan pustaka Car UI menentukan ketergantungan waktu proses pada pustaka bersama plugin, pemuat kelasnya dapat mengakses kelas pustaka bersama plugin. Plugin yang diterapkan sebagai aplikasi Android biasa (bukan perpustakaan bersama) dapat berdampak negatif terhadap waktu mulai aplikasi yang tidak aktif.
Menerapkan dan membangun perpustakaan bersama
Pengembangan dengan pustaka bersama Android sama seperti pengembangan aplikasi Android pada umumnya, dengan beberapa perbedaan utama.
- Gunakan tag
library
di bawah tagapplication
dengan nama paket plugin di manifes aplikasi plugin Anda:
<application>
<library android:name="com.chassis.car.ui.plugin" />
...
</application>
- Konfigurasikan aturan pembangunan
android_app
Soong Anda (Android.bp
) dengan tanda AAPTshared-lib
, yang digunakan untuk membangun perpustakaan bersama:
android_app {
...
aaptflags: ["--shared-lib"],
...
}
Ketergantungan pada perpustakaan bersama
Untuk setiap aplikasi di sistem yang menggunakan pustaka Car UI, sertakan tag uses-library
di manifes aplikasi di bawah tag application
dengan nama paket plugin:
<manifest>
<application
android:name=".MyApp"
...>
<uses-library android:name="com.chassis.car.ui.plugin" android:required="false"/>
...
</application>
</manifest>
Instal sebuah plugin
Plugin HARUS diinstal sebelumnya pada partisi sistem dengan menyertakan modul di PRODUCT_PACKAGES
. Paket pra-instal dapat diperbarui sama seperti aplikasi terinstal lainnya.
Jika Anda memperbarui plugin yang ada di sistem, aplikasi apa pun yang menggunakan plugin tersebut akan ditutup secara otomatis. Setelah dibuka kembali oleh pengguna, mereka mendapatkan perubahan yang diperbarui. Jika aplikasi tidak berjalan, saat dijalankan lagi, plugin akan diperbarui.
Saat memasang plugin dengan Android Studio, ada beberapa pertimbangan tambahan yang perlu dipertimbangkan. Pada saat penulisan, terdapat bug dalam proses instalasi aplikasi Android Studio yang menyebabkan pembaruan plugin tidak diterapkan. Hal ini dapat diperbaiki dengan memilih opsi Selalu instal dengan manajer paket (menonaktifkan pengoptimalan penerapan di Android 11 dan yang lebih baru) di konfigurasi build plugin.
Selain itu, saat memasang plugin, Android Studio melaporkan kesalahan karena tidak dapat menemukan aktivitas utama untuk diluncurkan. Hal ini diharapkan, karena plugin tidak memiliki aktivitas apa pun (kecuali maksud kosong yang digunakan untuk menyelesaikan suatu maksud). Untuk menghilangkan kesalahan, ubah opsi Peluncuran ke Tidak Ada di konfigurasi build.
Gambar 1. Konfigurasi plugin Android Studio
Plugin proksi
Penyesuaian aplikasi menggunakan pustaka UI Mobil memerlukan RRO yang menargetkan setiap aplikasi spesifik yang akan dimodifikasi, termasuk ketika penyesuaian dilakukan secara identik di seluruh aplikasi. Ini berarti diperlukan RRO per aplikasi. Lihat aplikasi mana yang menggunakan perpustakaan UI Mobil.
Plugin proksi pustaka UI Mobil adalah contoh pustaka bersama plugin yang mendelegasikan implementasi komponennya ke versi statis pustaka UI Mobil. Plugin ini dapat ditargetkan dengan RRO, yang dapat digunakan sebagai satu titik penyesuaian untuk aplikasi yang menggunakan pustaka Car UI tanpa perlu mengimplementasikan plugin fungsional. Untuk informasi selengkapnya tentang RRO, lihat Mengubah nilai sumber daya aplikasi saat runtime .
Plugin proxy hanyalah sebuah contoh dan titik awal untuk melakukan kustomisasi menggunakan sebuah plugin. Untuk penyesuaian di luar RRO, seseorang dapat mengimplementasikan subset komponen plugin dan menggunakan plugin proxy untuk sisanya, atau mengimplementasikan semua komponen plugin seluruhnya dari awal.
Meskipun plugin proxy menyediakan satu titik penyesuaian RRO untuk aplikasi, aplikasi yang memilih untuk tidak menggunakan plugin akan tetap memerlukan RRO yang secara langsung menargetkan aplikasi itu sendiri.
Implementasikan API plugin
Titik masuk utama ke plugin ini adalah kelas com.android.car.ui.plugin.PluginVersionProviderImpl
. Semua plugin harus menyertakan kelas dengan nama persis dan nama paket ini. Kelas ini harus memiliki konstruktor default dan mengimplementasikan antarmuka PluginVersionProviderOEMV1
.
Plugin CarUi harus berfungsi dengan aplikasi yang lebih lama atau lebih baru dari plugin tersebut. Untuk memfasilitasi hal ini, semua API plugin dibuat versinya dengan V#
di akhir nama kelasnya. Jika versi baru pustaka UI Mobil dirilis dengan fitur baru, fitur tersebut merupakan bagian dari komponen versi V2
. Pustaka Car UI melakukan yang terbaik untuk membuat fitur baru berfungsi dalam cakupan komponen plugin lama. Misalnya dengan mengubah jenis tombol baru di toolbar menjadi MenuItems
.
Namun, aplikasi dengan pustaka UI Mobil versi lama tidak dapat beradaptasi dengan plugin baru yang ditulis dengan API yang lebih baru. Untuk mengatasi masalah ini, kami mengizinkan plugin mengembalikan implementasi berbeda berdasarkan versi API OEM yang didukung oleh aplikasi.
PluginVersionProviderOEMV1
memiliki satu metode di dalamnya:
Object getPluginFactory(int maxVersion, Context context, String packageName);
Metode ini mengembalikan objek yang mengimplementasikan versi tertinggi PluginFactoryOEMV#
yang didukung oleh plugin, namun tetap kurang dari atau sama dengan maxVersion
. Jika sebuah plugin tidak memiliki implementasi PluginFactory
yang lama, plugin tersebut mungkin akan mengembalikan null
, dalam hal ini implementasi komponen CarUi yang tertaut secara statis akan digunakan.
Untuk menjaga kompatibilitas dengan aplikasi yang dikompilasi dengan versi lama pustaka Car Ui statis, disarankan untuk mendukung maxVersion
2, 5, dan yang lebih tinggi dari dalam implementasi plugin Anda pada kelas PluginVersionProvider
. Versi 1, 3, dan 4 tidak didukung. Untuk informasi selengkapnya, lihat PluginVersionProviderImpl
.
PluginFactory
adalah antarmuka yang membuat semua komponen CarUi lainnya. Ini juga menentukan versi antarmuka mana yang harus digunakan. Jika plugin tidak berusaha mengimplementasikan salah satu komponen ini, plugin mungkin mengembalikan null
dalam fungsi pembuatannya (dengan pengecualian toolbar, yang memiliki fungsi customizesBaseLayout()
terpisah).
pluginFactory
membatasi versi komponen CarUi mana yang dapat digunakan secara bersamaan. Misalnya, tidak akan pernah ada pluginFactory
yang dapat membuat Toolbar
versi 100 dan juga RecyclerView
versi 1, karena hanya ada sedikit jaminan bahwa berbagai versi komponen akan bekerja sama. Untuk menggunakan toolbar versi 100, pengembang diharapkan menyediakan implementasi versi pluginFactory
yang membuat toolbar versi 100, yang kemudian membatasi pilihan pada versi komponen lain yang dapat dibuat. Versi komponen lainnya mungkin tidak sama, misalnya pluginFactoryOEMV100
dapat membuat ToolbarControllerOEMV100
dan RecyclerViewOEMV70
.
Bilah Alat
Tata letak dasar
Toolbar dan "tata letak dasar" sangat erat kaitannya, oleh karena itu fungsi yang membuat toolbar disebut installBaseLayoutAround
. Tata letak dasar adalah konsep yang memungkinkan toolbar diposisikan di mana saja di sekitar konten aplikasi, untuk memungkinkan toolbar di bagian atas/bawah aplikasi, secara vertikal di sepanjang sisi, atau bahkan toolbar melingkar yang menutupi keseluruhan aplikasi. Hal ini dilakukan dengan meneruskan tampilan ke installBaseLayoutAround
untuk membungkus toolbar/tata letak dasar.
Plugin harus mengambil tampilan yang disediakan, melepaskannya dari induknya, mengembangkan tata letak plugin itu sendiri dalam indeks induk yang sama dan dengan LayoutParams
yang sama dengan tampilan yang baru saja dilepas, lalu memasang kembali tampilan di suatu tempat di dalam tata letak yang sebelumnya. baru saja meningkat. Tata letak yang diperluas akan berisi toolbar, jika diminta oleh aplikasi.
Aplikasi ini dapat meminta tata letak dasar tanpa toolbar. Jika ya, installBaseLayoutAround
akan mengembalikan nol. Untuk sebagian besar plugin, hanya itu yang perlu dilakukan, namun jika pembuat plugin ingin menerapkan, misalnya, hiasan di sekitar tepi aplikasi, hal itu masih dapat dilakukan dengan tata letak dasar. Dekorasi ini sangat berguna untuk perangkat dengan layar non-persegi panjang, karena dapat mendorong aplikasi ke dalam ruang persegi panjang dan menambahkan transisi yang rapi ke dalam ruang non-persegi panjang.
installBaseLayoutAround
juga diteruskan ke Consumer<InsetsOEMV1>
. Konsumen ini dapat digunakan untuk menyampaikan kepada aplikasi bahwa plugin menutupi sebagian konten aplikasi (dengan toolbar atau lainnya). Aplikasi kemudian akan tahu untuk terus menggambar di ruang ini, tetapi tidak memasukkan komponen penting yang dapat berinteraksi dengan pengguna. Efek ini digunakan dalam desain referensi kami, untuk membuat toolbar semi-transparan, dan membuat daftar bergulir di bawahnya. Jika fitur ini tidak diterapkan, item pertama dalam daftar akan tertahan di bawah toolbar dan tidak dapat diklik. Jika efek ini tidak diperlukan, plugin dapat mengabaikan Konsumen.
Gambar 2. Konten bergulir di bawah toolbar
Dari sudut pandang aplikasi, saat plugin mengirimkan insets baru, plugin akan menerimanya dari aktivitas atau fragmen apa pun yang mengimplementasikan InsetsChangedListener
. Jika aktivitas atau fragmen tidak mengimplementasikan InsetsChangedListener
, pustaka Car Ui akan menangani inset secara default dengan menerapkan inset sebagai padding ke Activity
atau FragmentActivity
yang berisi fragmen tersebut. Pustaka tidak menerapkan insets secara default ke fragmen. Berikut contoh cuplikan implementasi yang menerapkan insets sebagai padding pada RecyclerView
di aplikasi:
public class MainActivity extends Activity implements InsetsChangedListener {
@Override
public void onCarUiInsetsChanged(Insets insets) {
CarUiRecyclerView rv = requireViewById(R.id.recyclerview);
rv.setPadding(insets.getLeft(), insets.getTop(),
insets.getRight(), insets.getBottom());
}
}
Terakhir, plugin diberikan petunjuk fullscreen
, yang digunakan untuk menunjukkan apakah tampilan yang harus dibungkus menempati seluruh aplikasi atau hanya sebagian kecil. Hal ini dapat digunakan untuk menghindari penerapan beberapa dekorasi di sepanjang tepian yang hanya masuk akal jika dekorasi tersebut muncul di sepanjang tepi seluruh layar. Contoh aplikasi yang menggunakan tata letak dasar non-layar penuh adalah Pengaturan, di mana setiap panel tata letak dua panel memiliki toolbar sendiri.
Karena installBaseLayoutAround
diharapkan mengembalikan null ketika toolbarEnabled
bernilai false
, agar plugin menunjukkan bahwa plugin tidak ingin menyesuaikan tata letak dasar, plugin harus mengembalikan false
dari customizesBaseLayout
.
Tata letak dasar harus berisi FocusParkingView
dan FocusArea
untuk sepenuhnya mendukung kontrol putar. Tampilan ini dapat dihilangkan pada perangkat yang tidak mendukung putaran. FocusParkingView/FocusAreas
diimplementasikan di perpustakaan CarUi statis, sehingga setRotaryFactories
digunakan untuk menyediakan pabrik untuk membuat tampilan dari konteks.
Konteks yang digunakan untuk membuat tampilan Fokus harus konteks sumber, bukan konteks plugin. FocusParkingView
harus sedekat mungkin dengan tampilan pertama di pohon, karena ini adalah fokus ketika tidak ada fokus yang terlihat oleh pengguna. FocusArea
harus membungkus toolbar dalam tata letak dasar untuk menunjukkan bahwa itu adalah zona dorongan putar. Jika FocusArea
tidak disediakan, pengguna tidak dapat menavigasi ke tombol apa pun di toolbar dengan pengontrol putar.
Pengontrol bilah alat
ToolbarController
sebenarnya yang dikembalikan seharusnya lebih mudah diterapkan dibandingkan tata letak dasar. Tugasnya adalah mengambil informasi yang diteruskan ke setternya dan menampilkannya di tata letak dasar. Lihat Javadoc untuk informasi tentang sebagian besar metode. Beberapa metode yang lebih kompleks dibahas di bawah ini.
getImeSearchInterface
digunakan untuk menampilkan hasil pencarian di jendela IME (keyboard). Ini berguna untuk menampilkan/menganimasikan hasil pencarian di samping keyboard, misalnya jika keyboard hanya menempati separuh layar. Sebagian besar fungsi diimplementasikan di perpustakaan CarUi statis, antarmuka pencarian di plugin hanya menyediakan metode untuk perpustakaan statis untuk mendapatkan callback TextView
dan onPrivateIMECommand
. Untuk mendukung hal ini, plugin harus menggunakan subkelas TextView
yang menggantikan onPrivateIMECommand
dan meneruskan panggilan ke pendengar yang disediakan sebagai TextView
bilah pencariannya.
setMenuItems
hanya menampilkan MenuItems di layar, tetapi secara mengejutkan akan sering dipanggil. Karena API plugin untuk MenuItems tidak dapat diubah, setiap kali MenuItem diubah, panggilan setMenuItems
baru akan terjadi. Hal ini dapat terjadi karena hal sepele seperti pengguna mengklik tombol MenuItem, dan klik tersebut menyebabkan tombol beralih. Untuk alasan kinerja dan animasi, oleh karena itu disarankan untuk menghitung perbedaan antara daftar MenuItems lama dan baru, dan hanya memperbarui tampilan yang benar-benar berubah. MenuItems menyediakan bidang key
yang dapat membantu dalam hal ini, karena kuncinya harus sama di berbagai panggilan ke setMenuItems
untuk MenuItem yang sama.
Tampilan Bergaya Aplikasi
AppStyledView
adalah wadah untuk tampilan yang tidak dikustomisasi sama sekali. Ini dapat digunakan untuk memberikan batas di sekeliling tampilan yang membuatnya menonjol dari aplikasi lainnya, dan menunjukkan kepada pengguna bahwa ini adalah jenis antarmuka yang berbeda. Tampilan yang dibungkus oleh AppStyledView diberikan dalam setContent
. AppStyledView
juga dapat memiliki tombol kembali atau tutup seperti yang diminta oleh aplikasi.
AppStyledView
tidak segera memasukkan tampilannya ke dalam hierarki tampilan seperti yang dilakukan installBaseLayoutAround
, melainkan hanya mengembalikan tampilannya ke perpustakaan statis melalui getView
, yang kemudian melakukan penyisipan. Posisi dan ukuran AppStyledView
juga dapat dikontrol dengan mengimplementasikan getDialogWindowLayoutParam
.
Konteks
Plugin harus berhati-hati saat menggunakan Konteks, karena ada konteks plugin dan "sumber". Konteks plugin diberikan sebagai argumen ke getPluginFactory
, dan merupakan satu-satunya konteks yang memiliki sumber daya plugin di dalamnya. Artinya, ini satu-satunya konteks yang dapat digunakan untuk mengembangkan tata letak di plugin.
Namun, konteks plugin mungkin tidak memiliki konfigurasi yang benar. Untuk mendapatkan konfigurasi yang benar, kami menyediakan konteks sumber dalam metode yang membuat komponen. Konteks sumber biasanya berupa aktivitas, namun dalam beberapa kasus mungkin juga berupa Layanan atau komponen Android lainnya. Untuk menggunakan konfigurasi dari konteks sumber dengan sumber daya dari konteks plugin, konteks baru harus dibuat menggunakan createConfigurationContext
. Jika konfigurasi yang benar tidak digunakan, akan terjadi pelanggaran mode ketat Android, dan tampilan yang diperbesar mungkin tidak memiliki dimensi yang benar.
Context layoutInflationContext = pluginContext.createConfigurationContext(
sourceContext.getResources().getConfiguration());
Perubahan modus
Beberapa plugin dapat mendukung beberapa mode untuk komponennya, seperti mode olahraga atau mode eco yang terlihat berbeda secara visual. Tidak ada dukungan bawaan untuk fungsi seperti itu di CarUi, namun tidak ada yang menghentikan plugin untuk mengimplementasikannya sepenuhnya secara internal. Plugin dapat memantau kondisi apa pun yang ingin diketahui kapan harus beralih mode, seperti mendengarkan siaran. Plugin tidak dapat memicu perubahan konfigurasi untuk mengubah mode, namun tidak disarankan untuk mengandalkan perubahan konfigurasi, karena memperbarui tampilan setiap komponen secara manual akan lebih lancar bagi pengguna dan juga memungkinkan transisi yang tidak mungkin dilakukan dengan perubahan konfigurasi.
Penulisan Jetpack
Plugin dapat diimplementasikan menggunakan Jetpack Compose, tetapi ini adalah fitur tingkat alfa dan tidak dianggap stabil.
Plugin dapat menggunakan ComposeView
untuk membuat permukaan berkemampuan Compose untuk dirender. ComposeView
ini akan dikembalikan dari ke aplikasi dari metode getView
di komponen.
Salah satu masalah utama dalam penggunaan ComposeView
adalah ia menetapkan tag pada tampilan akar di tata letak untuk menyimpan variabel global yang dibagikan ke berbagai ComposeView dalam hierarki. Karena id sumber daya plugin tidak diberi namespace secara terpisah dari aplikasi, hal ini dapat menyebabkan konflik ketika aplikasi dan plugin menyetel tag pada tampilan yang sama. ComposeViewWithLifecycle
khusus yang memindahkan variabel global ini ke ComposeView
disediakan di bawah. Sekali lagi, hal ini tidak boleh dianggap stabil.
ComposeViewWithLifecycle
:
class ComposeViewWithLifecycle @JvmOverloads constructor(
context: Context,
attrs: AttributeSet? = null,
defStyleAttr: Int = 0
) : FrameLayout(context, attrs, defStyleAttr),
LifecycleOwner, ViewModelStoreOwner, SavedStateRegistryOwner {
private val lifeCycle = LifecycleRegistry(this)
private val modelStore = ViewModelStore()
private val savedStateRegistryController = SavedStateRegistryController.create(this)
private var composeView: ComposeView? = null
private var content = @Composable {}
init {
ViewTreeLifecycleOwner.set(this, this)
ViewTreeViewModelStoreOwner.set(this, this)
ViewTreeSavedStateRegistryOwner.set(this, this)
compositionContext = createCompositionContext()
}
fun setContent(content: @Composable () -> Unit) {
this.content = content
composeView?.setContent(content)
}
override fun getLifecycle(): Lifecycle {
return lifeCycle
}
override fun getViewModelStore(): ViewModelStore {
return modelStore
}
override fun getSavedStateRegistry(): SavedStateRegistry {
return savedStateRegistryController.savedStateRegistry
}
override fun onAttachedToWindow() {
super.onAttachedToWindow()
savedStateRegistryController.performRestore(Bundle())
lifeCycle.currentState = Lifecycle.State.RESUMED
composeView = ComposeView(context)
composeView?.setContent(content)
addView(composeView, LayoutParams(
LayoutParams.MATCH_PARENT, LayoutParams.MATCH_PARENT))
}
override fun onDetachedFromWindow() {
super.onDetachedFromWindow()
lifeCycle.currentState = Lifecycle.State.DESTROYED
modelStore.clear()
removeAllViews()
composeView = null
}
// Exact copy of View.createCompositionContext() in androidx's WindowRecomposer.android.kt
private fun createCompositionContext(): CompositionContext {
val currentThreadContext = AndroidUiDispatcher.CurrentThread
val pausableClock = currentThreadContext[MonotonicFrameClock]?.let {
PausableMonotonicFrameClock(it).apply { pause() }
}
val contextWithClock = currentThreadContext + (pausableClock ?: EmptyCoroutineContext)
val recomposer = Recomposer(contextWithClock)
val runRecomposeScope = CoroutineScope(contextWithClock)
val viewTreeLifecycleOwner = checkNotNull(ViewTreeLifecycleOwner.get(this)) {
"ViewTreeLifecycleOwner not found from $this"
}
viewTreeLifecycleOwner.lifecycle.addObserver(
LifecycleEventObserver { _, event ->
@Suppress("NON_EXHAUSTIVE_WHEN")
when (event) {
Lifecycle.Event.ON_CREATE ->
// Undispatched launch since we've configured this scope
// to be on the UI thread
runRecomposeScope.launch(start = CoroutineStart.UNDISPATCHED) {
recomposer.runRecomposeAndApplyChanges()
}
Lifecycle.Event.ON_START -> pausableClock?.resume()
Lifecycle.Event.ON_STOP -> pausableClock?.pause()
Lifecycle.Event.ON_DESTROY -> {
recomposer.cancel()
}
}
}
)
return recomposer
}
// TODO: ComposeViewWithLifecycle should handle saving state and other lifecycle things
// override fun onSaveInstanceState(): Parcelable? {
// val superState = super.onSaveInstanceState()
// val bundle = Bundle()
// savedStateRegistryController.performSave(bundle)
// }
}