Migrate to Jetpack Compose (master)

[westnordost]

This is the master ticket for migrating from the Android view system (layout XMLs etc.) to Jetpack Compose as UI framework.

The primary reason for this is #5421: To make possible an iOS version of this app that has a shared codebase for the UI through the use of Compose Multiplatform. The first step however is to migrate to Jetpack Compose and only later switch to Compose Multiplatform.

The first foray into Jetpack Compose has been made in PR #5447, I am also new to this but I tried to follow guidelines closely how things should be done, so feel free to look into that PR to learn how the UI code typically looks like before and after.

Contributing

As this is a larger undertaking which can be implemented step by step - this ticket shall serve as a master ticket. Whenever you would like to contribute, post on which screen or view you would like to work on now here and later post a PR when you are done.

Migration is generally done bottom-up, i.e. start with single views first and then work your way up to the screen-level, see Migration Strategy. For converting a whole screen, it is very advisable to do this only after the Fragment or Activity in question has been refactored to use ViewModels, see #5530.

[westnordost]

Current blockers and issues with Compose:

• Appear-animation missing for achievements and links screen. Lazy item animations not supported by Jetpack Compose yet.

• Fancy animate-from-icon animation is missing for achievement dialog. Not supported by Jetpack Compose yet

• (Material2) DatePicker and TimePicker (dialogs) are not available in Jetpack Compose (yet). Necessary for: Logs screen, any quest where a time needs to be set (opening hours, collection times, ...)

• scroll bars are not supported by Jetpack Compose yet. (They would be handy at least in the Logs screen)

[westnordost]

Re-do of About and Settings screen done, in review. Details here: https://github.com/streetcomplete/StreetComplete/pull/5719/files

[westnordost]

User screens are also done, except for the quest statistics / country statistics screen. See #5595

[westnordost]

I'll look into the two tutorial screens (start tutorial, overlay tutorial) coming week.

[westnordost]

tutorial screens are done

[westnordost]

Next up would be the buttons and controls on the main screen plus the menus and dialogs there.

So, this is an opportunity to redesign the main menu dialog, which I designed the way it is now chiefly because it was the easiest to do. In the future it could e.g. also be a popup menu, or a sheet that slides in (from the top, from the right?) like the undo menu does... I am open to suggestions. What's popular in other apps?

[mnalis]

Other approaches I see:

• slide from the left - e.g. Osmand (which has menu icon on lower left) and OpenStop, K-9, Libretorrent, Nextcloud, AntennaPo, NewPipe, Fedilab (which have menu icon on upper left corner)
• slide from the bottom - e.g. Commons App, Vespucci, Organic Maps (which have menu icon on lower right)
• popup fullscreen - e.g. EveryDoor (which has menu icon on upper left), F-droid (lower right)

I actually quite like current StreetComplete "pop up in middle of the screen" menu, but other approaches are probably fine too, provided they happen fast (i.e. noticeably faster than half a second).

[westnordost]

Thanks for the input! I ended up mirroring the current appearance now.

I am now working on migrating the UI of the main screen to compose, i.e.

• (button) controls and star counter, (dropdown on long-press)
• main menu
• team mode menu (I plan to redesign it to be a wizard, i.e. similar appearance as the tutorial screens and will commission an artist for some nice illustration)
• overlay selection dropdown
• the various messages-dialogs (new-osm-message, "too much to do"-message, achievement unlocked, changelog)
• upload/download-related dialogs probably
• location pointer pin: However, I have no idea how to implement that with compose! Maybe this feature has to go! :-( The problem is that the layout of the location pointer pin depends on the layout of the other elements, i.e. it has to be layout after the bounds of the other buttons are known - but in Compose, it is not really possible to inspect that! Help appreciated!

Maybe now, maybe immediately afterwards:

• edit history sidebar and dialog

[rugk]

slide from the bottom

…generally has the advantage as they can be used with one finger. And IMHO such a panel optionally including a gesture even (moving up from bottom) would be good too in SC, I don't quite like that you e.g. need to press (/go to) the top right icon for opening the menu.

[westnordost]

the complete user screen is now based on compose (including the statistics screen)

[westnordost]

The main screen, i.e. the buttons, the menus, the dialogs, the team mode, the dropdowns, the edit history sidebar, error handling and handling start parameters is also all based on compose. See #5799 (currently in alpha)

[westnordost]

Next step would be

• the map, but this depends on a library that does not exist yet.
• and migrate all those widgets used in quest forms to compose: the street side select widget, the "select one of these icons+text" widget, the opening hours editing, the names editing etc.. These are many small(er) tasks, so are well eligible for individual contributions for PRs. Write here if you are interested.

[GaeaKat]

I have a bit of a silly question. With the original being of course, is

this a suitable match, or would you prefer more exact match?

[westnordost]

Oh cool, you are contributing!

It doesn't need to exactly look the same. It's more important to rather use mostly the normal (material) components than to endlessly customize the whole thing. (I.e. better to have less and maybe reusable code than to have a perfect match with how it looks like currently)

[GaeaKat]

@westnordost Do you prefer smaller PR's with single items, like, a PR for the button, then PR for another widget, or to let them build into a bigger PR?

[westnordost]

I prefer small PRs which however form a logical unit.

E.g. a PR for just one of those buttons when they are not used anywhere yet would be a bit too small. The apply-last-answers-button-row plus building+roof level input form would be ideal as a PR. The apply-last-answers-button-row could maybe be generalized to be easily reusable in other forms with such an UI element, but work on other widgets and this kind of generalization stuff should ideally go into a follow-up PR and done when opportune.
Since anyway this is your first PR, better keep it small and manageable as depending on your experience level (in Compose, in OSM, in StreetComplete) I may have comments about this or that.

[GaeaKat]

I have rapidly found that what I thought I knew about compose was not enough to do much more then make the button, and wire it into the existing form currently. I am going to be spending a week or two learning / playing with less complicated projects so I can continue attempting to contribute to this project. in the mean time, will submit a draft PR so not just dead in water