UI & UX Discussions

[raresvanca]

So I was watching some videos about the new Material U, so in my boredom, I came up with the idea to implement the design of Material and Material U respectively on Android 12 in this application. What do you guys think?

2026 edit: This discussion was converted into a UI & UX thread to discuss any improvements related to the interface and my current rewrite of the UI using Material 3 Expressive

[slowscript]

My knowledge of Material U only reaches as far as what was covered in that LTT video so I have no idea how much work and code changes it would need or how great is the risk of breaking the UI for existing users. I do like it though. Maybe I'd wait until Android 12 is released and see how other devs use it.

In the meantime, feel free to play with it if you want to. Maybe share us some screenshots 😃

[raresvanca]

Material 3 Expressive re-design update in progress

For those interested in providing feedback or monitoring development progress, here is a status update on the UI rewrite:

1. Manual Connection & QR Optimization

The Manual Connection Dialog has been enhanced with an updated icon, new layout and significant rendering performance improvements:

• Optimization: QR code generation now runs using modern Coroutines.
• Memory Efficiency: We now use Bitmap.Config.ALPHA_8. Since QR codes only contain black/transparent pixels, this minimizes memory footprint. Color tinting is applied via a color Filter during the render pass.
• Visual Quality: By reducing the render size and applying FilterQuality.None, the output is now crisp and pixel-perfect, avoiding the blurriness of bilinear filtering.
• UX: Added "Smart Paste" logic. If the clipboard contains a valid warpinator:// URI, it is automatically validated and added to the list. Added an empty state for when no recent remotes exist.

Screen_recording_20260111_140002.mp4

2. Adaptive Layouts

The home screen now implements the Material 3 List-Detail canonical layout. This ensures optimal functionality on tablets, foldables, and landscape modes.

Screen_Recording_20260111_144250_Warpinator.mp4

And here is the layout on mobile devices featuring the new expandable transfer tiles.

Screen_recording_20260111_142347.mp4

3. Rescan & Settings page

• Refresh Indicator: Added a Material 3 pull-to-refresh indicator to also trigger a rescan of remotes
• Settings Screen: Now using segmented list tiles like the Settings app on Android 16
• Profile Picture Dialog: Redesigned as a full-screen interface with more colors options based on a simplified version of the Material 3 tonal palette algorithm.

Screen_recording_20260111_142427.mp4

4. States

• State Feedback: Worked on clearer visual representations for different service/app states:

Screen_recording_20260111_152930.mp4

[slowscript]

Hi Rares, good to see that you are still around. As you can see, the app design stayed mostly the same as you left it, so a good chunk of the positive feedback the app receives belongs to you. I've probably only made it look worse and less consistent. If you think it could use another redesign, it is definitely welcome (although I might have my nitpicks as usual).

As you suggested, putting it into a separate branch at some point could be fine, maybe merging it part by part later on. I've looked at your repository and noticed that you've reorganized the project quite a bit. If you want, I can split the code in master branch into 'core' and 'views' subfolders to make the final diff smaller and easier to rebase on new changes. Doing more levels however feels a bit excessive to have just a couple of files per folder. Another thing is that the minSDK was increased. I personally would like to continue supporting Android 5 as long as possible, until it becomes seriously impractical to do so. I'm pretty sure Compose should support Android 5, from last time I looked into it.

Visually, most of the changes look great. The list-detail layout is something I was thinking of doing for a while but never got to it. Maybe one thing to consider is the need for a start/restart/stop screen. Ideally these states should take no time (especially stop, I think it currently is instantaneous and definitely doesn't need a screen). I think I like better the current approach where the full UI shows up with text indicating that the service is initializing in the background. For me it's around 2-5 seconds from cold start to fully operational (depending on which phone I use) and having the UI show up in the middle of those 5 seconds makes it feel more snappy than waiting full 5 seconds just looking at a rotating shape.

[raresvanca]

Thanks for the response!

I've looked at your repository and noticed that you've reorganized the project quite a bit.

Yeah, Compose really requires splitting the UI into multiple files, so a feature-based folder structure is much cleaner than dumping everything in one place.

Ignore my repo for now, though, I have a lot of local changes I'm still organizing. I want to make sure the refactor is solid before I push, rather than force-pushing half-baked commits.

I'm pretty sure Compose should support Android 5, from last time I looked into it.

That was the case previously, but Jetpack/AndroidX libraries enforced a minSdk of 23+ starting in June 2025(more info, look a bit above the anchor). We're blocked from Android 5 if we want to use the latest libraries (meaning Material 3 Expressive)

Maybe one thing to consider is the need for a start/restart/stop screen

I agree that perceived performance is crucial. However, the goal of the state screens isn't to hide the UI, but to avoid implicit states.

If the UI appears ready but the server isn't initialized, the app is in a blocking state. Users often interpret a non-responsive "ready" UI as a bug or freeze. The new loading screen is designed to be:

• Transient: Ideally invisible on fast devices.
• Informative: Only visible if startup hangs, letting the user know the system is working rather than broken.

Trust me the screens don't show up if they don't need to. The startup is still almost instant, usually finishing before the first frame renders.

The spinner part is only how the new indeterminate loading indicator looks, with one custom shape that represents the warpinator logo.

As you suggested, putting it into a separate branch at some point could be fine

A separate branch, and a potential Alpha/Beta release would be amazing.

Honestly, the scope grew larger than I expected. I thought I could just write a new UI on top of the old code, but the broadcasting system fought against Compose. I ended up having to move to Hilt and implement modern Kotlin features (coroutines, null safety, flows etc.) to make it work.

Since this is now a full migration, I think it's best if I finish the heavy lifting on my side first. We can discuss merging later once I'm sure I haven't broken anything and if you want after you take a look at how the new code looks.