is `ContextAmbient` always activity? I need to get at the activity to silently get a `ViewModel` beh...

# compose

[Ian Warwick]

is ContextAmbient always activity? I need to get at the activity to silently get a ViewModel behind the scenes using ViewModelProvider

fun getModel(): MyViewModel {
        val context = ambient(ContextAmbient) as AppCompatActivity
        return ViewModelProvider(context).get(MyViewModel::class.java)
    }

[Klaas Kabini]

If I still recall well, I think of the framework engineers at Google highlighted that is not a full activity context. It is only a lightweight context to allow accessing application resources such as strings, drawables, etc.

[Ian Warwick]

cool thanks @Klaas Kabini it is the activity right now but since its Context it could change to anything

[Manuel Wrage]

You could just create your own ViewModelStoreAmbient.

[Ian Warwick]

Its a good idea but at the moment for my little Router API I don't require the user to provide anything to do with view models or the activity and wanted to sneakily grab it behind the scenes 😄 the function I call startComposing() is a @Composable function and there I do that activity cast from ContextAmbient
Its not such a crime to require the user to provide the activity really though just prefer one less arg and + 1 more magic. Is a ActivityAmbient something we want to avoid? It could be useful in some scenarios but I understand it could also be misused 🤔

Untitled

[Ian Warwick]

Some more info on the router class https://github.com/fluxtah/memset#app-navigation-in-memset

[Adam Powell]

just prefer one less arg and + 1 more magic

often you want the reverse of this for scalability, understandability, composability, probably lots of other -abilities 🙃 it helps when each component declares its dependencies explicitly and callers know what's in play and can influence things

[Ian Warwick]

I guess so... though I think API developers break those rules quite often also as a trade off for convenience, Something like val service = ambient(ServiceAmbient) is already quite magical! 🙂 even so I do agree with your point completely since its just an extra argument for an object the caller has access to anyway

[Adam Powell]

Every one of those we add is a debate 🙂

[Ian Warwick]

ah! 🙂 I guess its just critical stuff? is ambient at risk of being removed?

[Adam Powell]

the ambient() function has already been removed, but it was replaced with a val extension on the ambient types, .current I think? It's sticking around as a concept.

[Adam Powell]

it's an abstraction that is highly useful but it's very easy to overuse and make a mess with since it has that, "magic" property

[Adam Powell]

If you're looking for some reading on the pros and cons of the pattern, take a look around the web for material on React's Context - many of the same ideas apply to Compose's Ambient

[Ian Warwick]

yeh defo a trade-off, most things like that as long as they don't make testing things difficult its ok to add magic providing its not to obscure

[Adam Powell]

it's double-edged, and there was definitely a surge in posts and conference talks for a while in the spirit of, "we finally removed all of our Contexts from our app!" in that community after folks got bitten by the pitfalls

[Ian Warwick]

ah nice thanks 👍 will check that out I never used those frameworks so this style is totally new to me 🙂

[Adam Powell]

it should be telling that react's official page on context starts with a big, "before you use this, try all of these other things first" section 🙂 https://reactjs.org/docs/context.html

[Ian Warwick]

nice was just reading that

[Adam Powell]

in particular, Compose leans very heavily on lexical scoping for things like this. You can remember {} something in a val in a composable but use it several layers down the UI tree without those layers in between having to understand it or pass it as parameters

[Adam Powell]

You only need to think about things like ambients when that sort of structure isn't an option and you need to cross-cut a bit differently

[Ian Warwick]

Here is something I am doing in my screen

val router = ambient(AmbientRouterContext)

    val cardActions = CardActions(
        editCard = { card ->
            router.goto(MemsetDestination.CardDesigner(card.uuid))
        })

    HomeScreenContent(state, cardActions)

Using this router basically sets a model property above this composable HomeScreen causing it to show another XyzScreen

[Adam Powell]

Right. So can your screens accept a Router? Can they accept an onEditCard: (Uuid) -> Unit event callback, so that the caller that does have a reference to the router can pass a lambda that makes the actual router.goto call?

[Adam Powell]

in particular, designing things like the latter suggestion and publishing higher-level event callbacks can make testability a breeze

[Adam Powell]

since you don't have to assert that your router did the right thing, you just assert that the composable published an instruction to navigate to the expected place

[Adam Powell]

and if you jumped straight to ambients as the solution you'd miss out on all of those benefits of designing the abstraction a little bit differently

[Ian Warwick]

yeh actually its a bit more complicated like that I had to come up with two themes, I can do this

Button("Click Me", onClick = goto(MemsetDestination.HomeScreen))

and that goto function looks like this:

@Composable
fun goto(destination: Destination, context: GotoContext.() -> Unit = { go() }) = goto(destination.uri, context)

@Composable
fun goto(uri: String, context: GotoContext.() -> Unit = { go() }): () -> Unit {
    val model = ambient(AmbientRouterContext)
    return {
        context(GotoContext(model, uri))
    }
}

I am going a bit nuts with it but its fun 😆 seriously cool stuff

[Ian Warwick]

and then the whole selecting a new screen is

AmbientRouterContext.Provider(value = model) {
            state.currentUri.let {
                findMapping(it).invoke(it)
            }
        }

they are across a few classes

[Ian Warwick]

but I think this is quite cool as and end user

Button("Click Me", onClick = goto(MemsetDestination.HomeScreen))

[Ian Warwick]

Another thing I guess from where I am looking at this is my top level is a composable function

fun HomeScreen(repository: MemoryCardRepository = get()) {

(get() is just some poor mans DI) and I chose that to be the point that gets changed from one screen to the next the only thing retained above this is "what was the last screen the user was on" and when that state.currentUri changes it constructs a new screen.

[Ian Warwick]

got some 🤔 to do you make a good point if I did pass this Router into the compose function tree then it would be way easy to test 🤔

[Adam Powell]

and even easier if you passed lambdas that receive info that can be used to construct a destination

[Ian Warwick]

by pulling up navigation to top compose? I have been favouring passing down lambdas such as that

val cardActions = CardActions(
        editCard = { card ->
            router.goto(MemsetDestination.CardDesigner(card.uuid))
        }

 HomeScreenContent(state, cardActions)

is that what you mean?

[Adam Powell]

sure, that's one way. If you have an object full of those it starts looking like an interface real quick 😄

[Ian Warwick]

defo seems a good idea to make composable functions not rely on to many things and have callbacks into complex parts of the UI tree, I was passing down my model all the way before I decided to pass lambdas down instead 🙂

[Ian Warwick]

aha true man though the card editor does have a few functions 🙂 I will keep an eye on it

[Adam Powell]

yeah, lambdas and interfaces make good black boxes for carrying logic down

[Ian Warwick]

do you prefer individual lambdas passed to a function or an interface full of lambdas? its hard to say specially with default args make it not so much of an issue with Kotlin... I did think about wether CardActions was a good idea over just individual lambda per action (only got two actions so far, edit and delete)

[Adam Powell]

depends on how many required callbacks you need. If several semantically-related lambdas keep appearing in the same place and are never separated, that sounds like an interface.