kotlinlang #compose

@Composable
fun TestCardClickable() {
  Card(
    backgroundColor = Color.Red,
    modifier = Modifier.size(100.dp).clickable {
      Timber.e("Click")
    },
    content = {

    }
  )
}

Daniel

06/16/2021, 1:20 AM

Should I name a composable function that "returns" values through out parameters with a uppercase or lowercase name? I have a function like so

fun updatePreconditions(activity: Activity, playServicesPreconditionMetState: MutableState<Boolean?>, settingsPreconditionMetState: MutableState<Boolean?>): Unit

It "returns" by assigning to the states, which I think is cleaner in this case than having generic callbacks. Android Studio tells me I should write it

UpdatePreconditions

, but I'd assume something named like that affected the visible ui

Slackbot

06/16/2021, 3:57 AM

This message was deleted.

:thread-please: 4

aipok

06/16/2021, 5:11 AM

Is it possible to override the

.clickable

ripple effect color on the theme level to avoid

.clickable(
   interactionSource = remember { MutableInteractionSource() },
   indication = rememberRipple(color = MaterialTheme.colors.secondary),
   onClick = onClicked
)

every time I want to apply theme color?

julioromano

06/16/2021, 7:09 AM

When using

ComposeView

is it generally a bad practice to call

setContent

multiple times? My worry is that doing that will not trigger a recomposition (based on the existing content set in the previous

setContent

call) but rather a full composition from scratch.

✅ 1

Akram Bensalem

06/16/2021, 8:29 AM

I have a problem when rotate items and draging them !!! In this exqmple when I rotate the TextField after try yo draging it using one finger I found that it's not go to the right place For example if I try to drag it to the Top it drag to the Top of the Rectangle not the Top of the App !!! What I have to do ?! 😢😢

gitai

06/16/2021, 10:11 AM

How can you view a composable function source code after the compiler plugin edits?

Marcin Mazurek

06/16/2021, 11:03 AM

NavHost(startDestination = "profile/{userId}") {
    ...
    composable("profile/{userId}") {...}
}

Hello how to pass argument to navhost start destination

Alex

06/16/2021, 11:32 AM

Is there a way to change the unfocused border stroke width of an

OutlinedTextField

Alex

06/16/2021, 11:54 AM

Is there a way to change the values of a MaterialTheme TextStyle locally?

gitai

06/16/2021, 4:15 PM

Is there an “internals” type video describing the process of rendering a composition to the screen, like the actual steps taken to produce a single UI frame?

➕ 1

Ravi

06/16/2021, 4:56 PM

Anyone facing issue after upgrading studio to

Android Studio Arctic Fox | 2020.3.1 Beta 4

, I’m using hilt 2.37

* Exception is:
java.lang.NoClassDefFoundError: com/android/build/api/extension/AndroidComponentsExtension$DefaultImpls
	at dagger.hilt.android.plugin.HiltGradlePlugin.configureBytecodeTransformASM(HiltGradlePlugin.kt:258)
	at dagger.hilt.android.plugin.HiltGradlePlugin.configureHilt(HiltGradlePlugin.kt:89)
	at dagger.hilt.android.plugin.HiltGradlePlugin.access$configureHilt(HiltGradlePlugin.kt:59)
	at dagger.hilt.android.plugin.HiltGradlePlugin$apply$1.execute(HiltGradlePlugin.kt:66)

➕ 2

Tash

06/16/2021, 5:43 PM

Came across cases where Composables accept

MutableState<T>

as arguments:

@Composable fun FooButton(fooState: MutableState<Foo>) { /** read/write fooState here **/ }

instead of accepting the raw data (i.e. not

MutableState

) + a lambda for the caller to implement:

@Composable fun FooButton(foo: Foo, onClick: () -> Unit) { /** read foo & call onClick() here **/ }

Given the guidelines around state-hoisting for reads/writes, the former looks like an anti-pattern in the declarative/Compose world. Is that right?

Michal Thomka

06/16/2021, 6:32 PM

Is there a way to prevent

Modifier.verticalScroll()

from taking over/canceling vertical drag events in nested AndroidView (contains 3rd party Java chart component)?

julioromano

06/16/2021, 7:09 PM

Meanwhile…. beta09 😛 (where’s all the fanfare? 🤣)

9️⃣ 1

🎉 21

🥳 1

CLOVIS

06/16/2021, 7:21 PM

Would it be correct to say: •

remember

is used to keep values across recomposition (with a normal variable it would be re-computed everytime) •

State<T>

is used to represent something that can change overtime (or not) The thing I don't understand is how Compose knows which state force a recompose, and which don't. I thought

remember

was used to tell Compose that the current

Composable

needed to ‘subscribe/observe' that state; however after reading other comments in this channel I'm confused whether I completely misunderstood something.

Hachemi Hamadi

06/17/2021, 9:17 AM

Is there a way to display SVG in Canvas and changing the SVG properties ?

ste

06/17/2021, 10:13 AM

Hi all! I noticed `enum class`es are getting converted into `inline class`es (e.g. here). I was wondering what are the benefits of this?

taponidhi

06/17/2021, 11:16 AM

Can we use

remember{mutableStateOf(<data>)}

for every type of data?

dimsuz

06/17/2021, 12:37 PM

I have a BottomSheetScaffold and I want to control its state externally. I do

confirmStateChange = { notifyStateChangeRequest(it); false }

where

notifyStateChangeRequest()

will decide what state to switch to and cause

LaunchedEffect(newSheetState) { scaffoldState.bottomSheetState.animateTo(newSheetState) }

. The problem is that

confirmStateChange { false }

causes

Swipeable

to start its own "rollback to previous state" animation which conflicts with mine and produces a visible jitter. Is there a way around this?

julioromano

06/17/2021, 1:30 PM

Why is there

mutableStateListOf

and

mutableStateMapOf

but no

mutableStateSetOf

✅ 1

rajesh

06/17/2021, 2:22 PM

I'm building 2 different section on screen. both section load data from network (Like instagram profile page). What's wrong with below code? Expectation: ProfileView should be on upper part and PostView should be below it Reality: ProfileView Replace PostView and Postview is not showing up once data is loaded

Michał Diner

06/17/2021, 2:26 PM

Hi everyone, did anyone came up with proper way of combining bottomSheet with bottomNavBar? My current scenario requires opening BottomSheet in several places with different content, so the solution has to be somewhat generic. Implementation I did looks like this:

BottomSheet(navController) {
    BottomNavigationBar(
        navController,
        navHost)
}

ModalBottomSheetLayout(
    sheetState = bottomSheetScaffoldState,
    sheetContent = {...}
    content = {
        bottomNavigationBar()

Unaccaptable alternatives: 1. BottomSheet opened up by navigation -> replaces current screen and is above the BottomNavBar 2. BottomSheet initialised on currently displayed screen -> shows up above the BottomNavBar. Any ideas how to improve this or is this it?

Andrey Nikanorov

06/17/2021, 3:11 PM

Do we have any compose component to create expandable Card?

Chris Fillmore

06/17/2021, 5:07 PM

Hi folks. Can anyone offer advice on best practice for constructing nested navigation in a use case like this? I have an activity which provides behaviour based on some user-selected plugins. So the user can navigate to a “plugin screen”, at which point the UI content is provided by a plugin. I would like to define some nested navigation within the plugin, and I’m trying to figure out the best way to do this. My idea so far is to do something roughly like this:

@Composable
fun MainNavHost(
  navController: NavHostController,
  plugin: Plugin,
) {
  NavHost(...) {
    // Define regular navigation within the activity
    composable(...) {
      ...
    }
    // Call this here to define nested navigation for plugin(s)
    plugin.navGraph(navController)
  }
}

interface Plugin {
  fun NavGraphBuilder.navGraph(navController: NavHostController)
  ...
}

This seems fine to me, though I don’t like passing

navController

down to the plugin. But it isn’t obvious to me how to avoid this, since there will be navigation to do within the plugin. But… does this seem sensible? Any risks stand out to you that I may not have considered? Any feedback is appreciated, thanks!

David Albers

06/17/2021, 6:10 PM

Is there a way to have multiple

LazyColumn

s within a scrolling `Column`/other container? 🧵

06/17/2021, 6:36 PM

Is it okay to use mutable states in the View Model rather than exposing other observable types like stateflows or livedata?

:yes: 4

🇳🇴 1

mario

06/17/2021, 10:38 PM

Hi everyone, All my screens have viewmodel and it gives me an error when showing the preview, how do you solve this problem?

Travis Griggs

06/17/2021, 10:48 PM

I'm just starting to look at compose... I want to understand (at 10000) how it works. I see a bunch of functions that look like object/struct things because they start with UpperCaseUIElementNames rather than the way functionsNormallyExist(), they don't return anything (apparently), but they're annotated with @Composable. So... how does it work? Do these "functions" actually return anything, or are they used more like "draw this" commands on an implicit canvas/tree behind the scenes? What does the @Composable annotation actually provide? Composable.kt doesn't give much hints. Any links/videos that answer these kinds of questions? I get the basic approach from experience with Flutter/SwiftUI, but I want to understand the actual Kotlin architecture here

frankelot

06/17/2021, 11:22 PM

Maybe this belongs in #android-architecture but… I’m always conflicted between these two architectural approaches. Should I be striving to have relatively dumb Composables, where the state is passed down from its parent and events are propagated up using callbacks, Or should I instead try to make composables as reusable and independant as possible. Which means giving them a VM, and having communication happen through layers above the VM (repositories, services, etc) Both work (I’ve tried them) I can’t find any pro/cons to justify my decision Maybe mix and matching is the right approach (depending the Composable complexity), what’s your take on this

Title

frankelot

06/17/2021, 11:22 PM

In the scenario on the left the repository would be reactive, VMs don’t talk to each-other directly

I’m thinking of having dumb Composables (right), until one becomes complex enough that it deserves its own VM (but it’s not always easy to know where to draw the line between simple/complex)

Ian Lake

06/17/2021, 11:32 PM

The latest video has specific guidance around this:

https://www.youtube.com/watch?v=0z_dwBGQQWQ▾

- use ViewModels at the screen level, pass state down and events up for subcomponents of a screen

👍🏽 1

👍 3

frankelot

06/17/2021, 11:35 PM

Thank you Ian! Im giving this a watch now

Very clear, looks like this is the way to go 👌 thanks again @Ian Lake!

Ian Lake

06/18/2021, 12:04 AM

Of course, that doesn't mean that your state can't be split up into smaller pieces; it doesn't need to be monolithic, nor are you constrained to only using one ViewModel even at that higher level

frankelot

06/18/2021, 12:10 AM

Let me see if I got that… you can have multiple VMs… as long as you don’t nest them. This wouldn’t be ok.

@Composable
fun MainScreen() {
     val vm = viewModel()
     ....
     Foo()
     ...
}

@Composable
fun Foo() {
    val anotherVm = viewModel()
    ....
}

Also, wont this restriction make it hard for really deep views hierarchies 🤔they would need to bubble up the events though multiple layers of composables

tad

06/18/2021, 2:04 AM

I've found that it's not really a big deal, and it means you can be really flexible when moving components around

frankelot

06/18/2021, 8:19 AM

Right, I haven’t actually tried it, maybe it;’s not an issue

it doesn’t need to be monolithic

Would love to learn more about this though, how can I avoid a god VM in very complex screens 🤔 … should I just use 2 or more VMs at the top level

Cicero

06/20/2021, 10:41 AM

This is a very good topic I’ve been struggling to find a good compromise. I recently wrote a todo app to test out how would a data driven UI would work because I was getting stuck having an internal state (for like a checkbox being checked or not) and storing in Realm that this object was checked. In the end instead of having a the state being passed down I’m passing down data. Of course this does work well because checkbox has already a state built in. Bottom line, I’m using state inside of the composable when it’s directly connected to the UI behavior and changing it using data from a repository to avoid inconsistencies. I was thinking about the need of a view model maybe, for the composable. But it worked in a very interesting way when I only had a VM for the view, composables that had a state for their UI presentation and that the changes came from local data. https://github.com/cicerohellmann/to-beetle-do

And about the amount of VMs, best way to be sure about the bulkiness and understanding, invite a fellow dev that it’s a stranger to the project and you may get your answer. I’m in a privileged situation where very few people at my company know compose so I can try and show them my implementations and get a very honest answer about how understandable it is. Also a very good architectural view of it because as they don’t understand it they rely more in architectural knowledge to criticize the code.

frankelot

07/06/2021, 7:28 AM

Thanks Cicerohellmann! I also went with only one ViewModel at the top and passing state down - events up

It seems to work, but I’d like to explore using completely independent Composables with their own VMs in the future and see how it goes. (left approach in the picture above)

darkmoon_uk

09/27/2021, 11:43 PM

I'm creating Forms in Compose including specialised

TextField

and Drop-Down List components constructed from

TextField

and

DropDownMenu

. Each component has its own sub-VM to manage loading of data/valid states; validation of input both in real-time and at final submission etc. These are clearly reusable units of business logic that mirror the View layer in structure. Hard to imagine having it any other way... copying and pasting this functionality in a single VM would be 🤢. Structuring presentation logic alongside the View feels natural to me and also encourages keeping the View layer (Compose declarations) as thin as possible, meaning easier portability to other systems/flavours of View layer (e.g. Compose for Web). At the end of the day it's whatever works for you - here's a counter-point 🙂

View count: 6