Is getting references to views in an Activity like...

# android

[gsala]

Is getting references to views in an Activity like this considered a bad practice ?

val button : Button by lazy {
    findViewById(R.id.button)
}

[ribesg]

Well if you put that code inside an Activity directly, then yes, it’s very bad.

[sindrenm]

I've had issues with this in the past with navigating back to fragments, at least. Remember that the fragment/activity might be destroyed while the actual object might still exist.

[gsala]

@ribesg why do you think so?
@sindrenm what do you mean with "the actual object?" the fragment/activity? or the view? or the lazy?

[ribesg]

Well inside a Fragment it’s wrong, but inside an Activity it may be ok

[gsala]

@ribesg what's the reason

[ribesg]

Look at the Fragment lifecycle

[ribesg]

https://developer.android.com/images/fragment_lifecycle.png▾

[ribesg]

See how the view can be destroyed then re-created in the same Fragment instance. You then have (in your case) a reference to a Button that is no longer attached to anything, and which is NOT the Button displayed on screen.

[ghosalmartin]

maybe just easier to use synthetics and not bother with onCreateView or only use onCreateView to inflate your fragment and use synthetics in onViewCreated

[sindrenm]

I use synthetic imports myself and haven't had problems with them. Although I tend to also keep references to them in the activity/fragment as well, but through “virtual” properties with a getter:

private val button: Button
  get() = the_button_in_the_layout // synthetically imported

[gsala]

@ribesg Makes sense, thanks 👍

[gsala]

What if I was to keep a reference to the whole View like so

private val rootView : View by lazy { inflateView() }

override fun onCreateView(): View{
    return rootView
}

Would this be bad practice ?

[ribesg]

Or just don’t use XML views 😛

[ribesg]

@gsala don’t start to work around the android lifecycle, it’s a very dark path. Just deal with it

[gsala]

I'm not doing any of these things. But I needed to understand the reason behind why it's not a good idea

[ribesg]

You can safely do that

val button : Button
    get() = findViewById(R.id.button)

But in this case you may end up calling button multiple times in the same function like it’s nothing. Well, it’s not huge, but it’s better to have a local var and call findViewById only once if you can

[gsala]

KotterKnife (https://github.com/JakeWharton/kotterknife/blob/master/src/main/kotlin/kotterknife/ButterKnife.kt) appears to be implemented like the first case though

[ribesg]

That’s not what I’m understanding from the link you give

[gsala]

🤔 How do you understand the implementation then?

[sindrenm]

@ribesg: Note that I was using a getter together with synthetic imports, which does in fact cache the views for you. Just so there's no misunderstanding. simple smile

[ribesg]

@sindrenm Yes, it would be best but if you have synthetic imports you just use them directly usually

[ribesg]

@gsala I don’t know, I don’t see anything returning a lazy val. Wait I’m not sure I read this code correctly

[sindrenm]

Yeah, but some people use snake_case in IDs and some people use prefixes (e.g. signInEmailAddressEditText), so I prefer to keep track of them in property getters. simple smile

[ribesg]

@gsala oh, I see. Nothing tells you to bind your views as property though. The given example is inside a ViewGroup

[gsala]

True.

I'm now reading through the conversation that spawned this reply : https://kotlinlang.slack.com/archives/C0B8M7BUY/p1532693549000239

[ribesg]

In ButterKnife, you should call ButterKnife.bind(this); after the view has been created to replace the instances by the ones for the newly created view, which dereferences old views in the process

[sindrenm]

Indeed, but that thread is so 2018. 😏

[ribesg]

For me the best way is not to have XML anyway

[ribesg]

Just have your views with direct references to what you need. Anko was great for that, now you should use Splitties View DSL instead

[ribesg]

Also read this https://github.com/LouisCAD/Splitties/blob/master/modules/views-dsl/Kotlin-UIs-vs-xml-layouts.md

[sindrenm]

Yeah, Anko was great for that and Splitties probably is, but I'm just so incredibly used to the preview thingymabob that I've grown quite dependent on it. Although I don't seem to need it when writing Flutter apps (a whole discussion all in its own, I guess), but then again that has proper hot reloading. 😛

[ribesg]

Both Anko and Splitties support preview in IDE

[ribesg]

I don’t use it much, as when you write Kotlin code you just know what it will look like, but it works. You can’t build your view graphically, which is a good thing because usually the graphical editor writes things you don’t want/need

[sindrenm]

Yah, they do support it, but you'll have to build the code first, which is not the case for XML layouts. And while I usually know what I want, it's a whole lot easier to be able to preview my constraint layouts while writing it.

And no, I don't build my layouts graphically, I prefer having full control over the resulting XML. Although, to be fair, the WYSIWYG editor does usually build decent XML.

[ribesg]

It’s not like writing views with code is long, compared to XML

[ribesg]

You start with something like

class MainView(override val ctx: Context) : Ui {

    override val root = constraintLayout ()

}

[sindrenm]

Oh, I know it's not long. I really like the idea behind it. And I did use Anko UI for a while. But complex views are a bit … complex.

[sindrenm]

But I feel like we digress from the original question. Let's leave it at that. 😛

[ribesg]

class MainView(override val ctx: Context) : Ui {

    val myTextView =
        textView {
            textResource = R.string.my_string
        }

    override val root = constraintLayout {

        add(myTextView, lParams {
            centerInParent()
        })

    }

}

Splitties is better than Anko, it works differently and fixes some general issues.

And for complex views, you can very easily split them in multiple files.

It’s also a lot better to just have your views there, like myTextView in my example. It’s just there. In my Activity/Fragment I just have view.myTextView.

Also parsing XML is something not-trivial in terms of resources 😛

[sindrenm]

As I said, I really like the concept, no need to convince me. Like, I love having stuff like centerInParent(), for instance. But the preview is not as good as it is with XML layouts.

Also, the XML files aren't shipped as XML, it's binary. simple smile

[ribesg]

Was talking about the preview 😛

[sindrenm]

Oh, right. Yeah, that's definitely not for free. 😛

[zhuinden]

If you can, you should most likely disable thread safety over this, it's not like you need double-check lock synchronization to get a view from your view's... views. Lately it is easier to just use Kotlin synthetics

[Lou Morda]

I'm also a big fan of Kotlin synthetics

[rkeazor]

Bigger fan of databinding 😔

[Lou Morda]

Came back to this 3 months later, looks like kotlin synthetics are not very performance friendly! Need to learn databinding asap. Also just found kotterknife, wondering how that will be

[rkeazor]

Better off learning databinding