The main problem I meet. ``` class MyView:View{ private val myChildView:View = findViewById(R.id.m...

# announcements

[w_bianrytree]

The main problem I meet.

class MyView:View{
  private val myChildView:View = findViewById(R.id.my_view_id)
  init{
     View.inflate(R.layout.my_layout,this)
  }
}

There is a chance that myChildView is null because inflation is executed after findViewById.

[Luca Nicoletti]

It shouldn’t be a chance, it should always behave like this

[w_bianrytree]

Or I should say there is a chance that myChildView is not null.

[diesieben07]

You're letting this escape in the init block. that is usually a bad idea.

[diesieben07]

I can't reproduce this behavior with a minimal example though:

fun main() {
    Foo()
}

fun getString() = "hello"

fun doWithString(s: String, foo: Foo) {
    println(s)
    println(foo.x)
}

class Foo {

    val x: String = getString()

    init {
        doWithString(x, this)
    }

}

[diesieben07]

prints "hello" twice correctly

[Luca Nicoletti]

@diesieben07 that’s the expected behaviour

[diesieben07]

Yes, I know.

[diesieben07]

Like I said in the other thread: The code runs in the order it is written in the source code.

[w_bianrytree]

I think it may because the complier reordering happens?

[diesieben07]

The compiler does not reorder things... What order are you seeing?

[diesieben07]

Are you saying in your case findViewById runs after inflate?

[Luca Nicoletti]

It actually can re-order things, in order to optimize them

[diesieben07]

Yes, but only if that doesn't change the observed behavior

[w_bianrytree]

In my case that can happens imo. View inflation is just parsing an xml file. it doesn’t know it will change the findViewById result or not.

[diesieben07]

what do you mean "can happen"... compilation either does one or the other ordering

[diesieben07]

its not ambiguous

[w_bianrytree]

🤔 because I have 2 build on the same phone with the same code. 1 crashes and the other now. That makes me confuse.

[diesieben07]

I am not too familiar with android, but can you decompile to java and check if the output is similar?

[diesieben07]

What crash d you see?

[Alexander Johansson]

Isn’t this less of a case of order of execution, and more of a case of which functions you are using? There can be a case where the View is not actually inflated in the heirarchy, so findViewById will not find the referenced View.

[Luca Nicoletti]

From the code above there should be always a crash

[Luca Nicoletti]

findViewById execute before inflating the view will return null

[diesieben07]

The view ids are different, Luca

[diesieben07]

But I am really out of my water here with Android. So I'll 🤐

[Luca Nicoletti]

The ids are different because one is referencing a layout

[Luca Nicoletti]

Which contain a view with the id findViewById is trying to find

[Luca Nicoletti]

if the layout is not inflated, findViewById will return null

[Luca Nicoletti]

So, that code should always throw a NPE

[w_bianrytree]

But in my case. The crash is not always happening. Interesting enough. I already ship the code in production and the un-crashed user is much higher than crashes. 😂

[Luca Nicoletti]

Can you check the decompiled code?

[Alexander Johansson]

You could just find your child view after the inflation has happened.

private lateinit var myChildView: View

init {
    View.inflate(R.layout.my_layout,this)
    myChildView = findViewById(R.id.my_view_id)
}

Or even lazily using by lazy {}

[Luca Nicoletti]

@Alexander Johansson we're not searching for a solution 😂

[wasyl]

https://medium.com/keepsafe-engineering/an-in-depth-look-at-kotlins-initializers-a0420fcbf546 this article talks about initialization order in Kotlin

[wasyl]

There’s also an example in the docs (https://kotlinlang.org/docs/reference/classes.html): “During an instance initialization, the initializer blocks are executed in the same order as they appear in the class body, interleaved with the property initializers”

So it shouldn’t be possible for your code to not crash 😕

[wasyl]

Unless the base class does something that makes the findViewById not crash

[Luca Nicoletti]

Yep, that post confirmed what we were saying :)

[Luca Nicoletti]

Thanks for sharing though :)

[wasyl]

Yep I just wanted to provide some sources. I expect OP’s snippet doesn’t show entire picture. For one it’s impossible to inflate a view into another View, so the base class must be ViewGroup for example