I wanna make my compose app more user friendly on android tv, is there a way to get my UI to layout ...

# compose

[zt]

I wanna make my compose app more user friendly on android tv, is there a way to get my UI to layout slightly different, and be able to check in code if it's running on TV so I can show stuff thats not needed on mobile?

[andrew]

You'd be better off making a new target for your TV app instead of sharing your mobile app target

[andrew]

And you'd probably want a third target for shared code, like presenters, view models, shared ui elements, networking, etc

[andrew]

Of which could probably be split up more

[Colton Idle]

I'm not being too helpful here besides letting you know that TV support is officially alpha as of Monday I think?

https://developer.android.com/jetpack/androidx/releases/tv

[andrew]

You could technically also use flavors but that's a REALLY messy route.

[zt]

im using compose

[zt]

forgot to mention that for the 3 not kotlin reactions

[andrew]

It’s still more of an architectural question anyway, it could apply to the view system, java, etc

[andrew]

You should structure your project so your mobile and tv apps are separate

[andrew]

You’ll be saving yourself a huge headache checking if your platform is for TV or phone within your shared mobile codebase

[zt]

well theres some composables I dont really need to change at all, I tested and they look fine on both devices

[andrew]

And those can go into a separate shared library

[andrew]

your mobile and tv targets would use it to pull shared logic, shared ui elements, etc

[andrew]

but anything platform specific gets implemented separately

[Colton Idle]

I don't disagree with Andrew about separate targets but I used to have an app I worked on that worked with a single apk across phone, tabs and tvs and it worked really well. The experience overall was always a big screen first experience (tablets) and so it moved to TV easily.

Basically just saying that, its' not the worst thing if it makes sense in your scenario for it to be all in one app

[Colton Idle]

@Alex Vanyo do you know if any of the multi screen stuff has support for detecting if it's a TV? I know there were those window class sizes and I'm wondering if it is meant to work with TVs too

[andrew]

The issue arises if you want to use a set of leanback components conditionally, you’re much more equipped when using multiple targets

[andrew]

There are ways to detect if the display is a TV though

[andrew]

https://developer.android.com/training/tv/start/hardware.html

[Colton Idle]

Yeah. I never used the lean back library.

[andrew]

Leanback or leanback-esque components would be crucial to blending in, but as you mentioned isn’t necessarily required. UX might be a little weird though but that is on a per app basis.

[Ilan Sasportas]

Working in TV company, we do both mobile and TV, we mostly share all the code as many things are common. Also we are backend driven so lots of things are done on the backend side, and presented easily to the ui (example a grid on TV and a carousel on mobile). So for us it’s easy to not end up in complex flavors or packaging.

[zt]

@andrew would I be able to use expect and actual declarations?

[andrew]

Not across multiple targets that aren't multiplatform as it's all JVM/Android

[zt]

I'm not sure how I would make a different implementation for TV, do you have some example I could look at

[andrew]

Well for starters, you can abstract away a lot of your common implementation details like networking, any models, database/data retention away from your current app

[andrew]

This would be some kind of core module, and you could probably split this up further

[andrew]

So at that point you might have :app:mobile and :core under your project’s root

[andrew]

And :app:mobile would include :core

[andrew]

You could also split up any shared primitive custom UI components you might have as well

[zt]

I see

[zt]

I've already got my networking split into a separate module

[andrew]

At that point you could start a separate app target for TV, using the same package id, etc. This project would also include any core/shared modules that are critical to both

[andrew]

So both :app:mobile and :app:tv would depend on :core and maybe a :core:ui package for example

[andrew]

Then you could build more “leanback” styled layouts with the guarantee that no mobile only code will ever run, and this target will only run on tv since you’re requiring the hardware for it 🙂

[andrew]

You’re also able to exclude any tv only dependencies like compose for TV from your mobile app

[zt]

What exactly is leanback?

[andrew]

message has been deleted

[andrew]

Best example I can find

[andrew]

Looks older, but should convey it still

[andrew]

Just layouts optimized for a TV UX

[zt]

In my gradle config how would I make it build the TV and mobile APK seperate?

[andrew]

you need two separate app targets

[andrew]

After everything is separated, you could probably just make a copy of your mobile target and name it tv

[andrew]

Then you need to include it in your settings.gradle file

[andrew]

Afterwards, remove everything, strip it down

[andrew]

At least then any conventions you have in your gradle config, boilerplate, etc still remain

[andrew]

As you can see here, we have mobile and wear

[andrew]

message has been deleted

[andrew]

And each module has been included