Migrate to Jetpack Compose

[Iamlooker]

Migrate:

• [x] ConsoleFragment
• [x] Migrate to Flows
• [x] ControlFragment
• [x] SettingsFragment

[Iamlooker]

Hi, I wanted to ask, is this intentional? Because this uses the debug signing key to sign release files

[mathiascode]

Hi, I wanted to ask, is this intentional? Because this uses the debug signing key to sign release files

Looks like I committed it by accident after debugging an issue in the release build. It should be removed.

[Iamlooker]

Looks like I committed it by accident after debugging an issue in the release build. It should be removed.

Done

[Iamlooker]

Btw, why are we passing StringBuilder here

Either way we are converting it to string as soon as we get it here

[Iamlooker]

Manifest merger failed : uses-sdk:minSdkVersion 16 cannot be smaller than version 21 declared in library [androidx.compose.material3:material3-android:1.2.1] C:\Users\LooKeR\.gradle\caches\transforms-4\5a41c055199354d74c6acce2479e2b57\transformed\material3-release\AndroidManifest.xml as the library might be using APIs not available in 16
	Suggestion: use a compatible library with a minSdk of at most 16,
		or increase this project's minSdk version to at least 21,
		or use tools:overrideLibrary="androidx.compose.material3" to force usage (may lead to runtime failures)

What should we do?

[Iamlooker]

Also check the warning on this page They are announcing deprecation for API 21 and below

[mathiascode]

Btw, why are we passing StringBuilder here

Either way we are converting it to string as soon as we get it here

No good reason, we could pass a string instead.

[mathiascode]

Manifest merger failed : uses-sdk:minSdkVersion 16 cannot be smaller than version 21 declared in library [androidx.compose.material3:material3-android:1.2.1] C:\Users\LooKeR\.gradle\caches\transforms-4\5a41c055199354d74c6acce2479e2b57\transformed\material3-release\AndroidManifest.xml as the library might be using APIs not available in 16
	Suggestion: use a compatible library with a minSdk of at most 16,
		or increase this project's minSdk version to at least 21,
		or use tools:overrideLibrary="androidx.compose.material3" to force usage (may lead to runtime failures)

What should we do?

We can bump the minimum version to 21. I believe the oldest Android versions have issues using the built-in Cuberite downloader anyway due to SSL errors.

[mathiascode]

I should also mention that we're stuck on target API version 28, due to 29 no longer allowing executables in the data folder to run. It shouldn't be an issue in this case, but we will probably have to do something about it in a few years.

[Iamlooker]

I should also mention that we're stuck on target API version 28, due to 29 no longer allowing executables in the data folder to run. It shouldn't be an issue in this case, but we will probably have to do something about it in a few years.

Yes, but I did read about some changes in Android 13. I will look into this.

[Iamlooker]

Current State

[Iamlooker]

I suggest migrating LiveData to StateFlow.

This is also the suggest way to create architecture just like Jetpack Compose

[mathiascode]

I suggest migrating LiveData to StateFlow.

This is also the suggest way to create architecture just like Jetpack Compose

If StateFlows are recommended over LiveData when using Compose, we could migrate to them. We mainly need communication between our UI and (threaded) services, which was previously achieved with LocalBroadcastManager (now deprecated).

Could the migration be done in a separate PR?

[Iamlooker]

Could the migration be done in a separate PR?

I will open a new PR after this one

[Iamlooker]

Could the migration be done in a separate PR?

I have been trying migration, but the livedata API seems to be unpredictable, or maybe its just because I am a little inexperienced with it. Should i do the migration is the same PR? or should I do that PR first and do Compose Migration later?

[mathiascode]

or should I do that PR first and do Compose Migration later?

Is it possible to do before the Compose migration? If the Compose migration requires more changes anyway, it would probably be better to just do it in this PR.

[Iamlooker]

Yes, I will migrate to Flows first now :)

[Iamlooker]

Btw what is this tick for?

[Iamlooker]

Can you test this? I have migrated from livedata to flows. Once all is set I will move on to compose migration

[mathiascode]

Seems to be working fine, and the changes look reasonable. Nice work!

[mathiascode]

Btw what is this tick for?

It's a hack for displaying an error when running an invalid executable. Could be replaced with something more appropriate at some point.

[Iamlooker]

This is the current state of control screen:

https://github.com/cuberite/android/assets/60404093/e2a07311-5c83-4f20-bb9e-be57f7914660

[Iamlooker]

Would you also like to migrate to Datastore from SharedPreferences? This is also for reference.

I know this is too much going on in one PR but what are your thoughts?

[mathiascode]

This is the current state of control screen:

sc.mp4

Could we keep UI changes in a separate PR after migration? I like the idea of displaying the IP address in the app itself too, but it would be easier to review and comment on details later.

[Iamlooker]

Cool

[Iamlooker]

I will remove these commits tomorrow

[mathiascode]

Would you also like to migrate to Datastore from SharedPreferences? This is also for reference.

I know this is too much going on in one PR but what are your thoughts?

No strong opinion. If it's the preferred replacement, and migrating existing preferences doesn't require too much work, then we could migrate later.

[Iamlooker]

I will remove the ui commits tomorrow

[Iamlooker]

I think the removing the commits will cause some issues with my local repository. Can we merge this in this state?

[mathiascode]

Are you planning on migrating SettingsFragment in a separate PR? I'll try to review this PR next week, but I can't promise anything.