Make it possible to dismiss popup from viewBoundCallback

[Tunous]

Use case

I want to be able to dismiss popup when user performs action on a custom item's view.

Current solution

Impossible?

Implemented solution

When building custom item it is now possible to set viewBoundCallback to an instance of ViewBoundCallback class instead of a regular closure, which then allows user to access dismissPopup function.

section {
  item {
    viewBoundCallback = ViewBoundCallback {
      val someView = it.findViewById(R.id.some_view)
      someView.setOnClickListener {
        dismissPopup()
      }
    }
  }
}

Sample

Here sample has been modified to dismiss the popup when only when checkbox gets checked.

[zawadz88]

Thanks for the changes! I'll try to have a look on Monday and get back to you.

[zawadz88]

Hi @Tunous,
I've checked and it is actually possible to achieve the effect you presented with the following lines of code:

        var popupMenu by Delegates.notNull<MaterialPopupMenu>()
        popupMenu = popupMenu {
            dropdownGravity = Gravity.END
            section {
                customItem {
                    layoutResId = R.layout.view_custom_item_checkable
                    viewBoundCallback = { view ->
                        val checkBox: CheckBox = view.findViewById(R.id.customItemCheckbox)
                        checkBox.isChecked = true
                        checkBox.setOnCheckedChangeListener { _, isChecked ->
                            if (isChecked) {
                                popupMenu.dismiss()
                            }
                        }
                    }
                    callback = {
                        Toast.makeText(this@LightActivity, "Disabled!", Toast.LENGTH_SHORT).show()
                    }
                }
            }
        }

        popupMenu.show(this@LightActivity, view)

MaterialPopupMenu has a dismiss() method you can use.

[Tunous]

Hmm, true didn't think of that way. But it feels more like a hack than a real solution because you have to create a variable that is initialized later. With that I can't isolate the code that creates the pop-up from the code which shows it, as I have to somehow send the pop-up to builder code...

[zawadz88]

it feels more like a hack than a real solution because you have to create a variable that is initialized later.

Kinda feels this way although using Delegates.notNull sometimes can be useful if all else fails.

With that I can't isolate the code that creates the pop-up from the code which shows it, as I have to somehow send the pop-up to builder code...

That's a very good point.

[zawadz88]

Looks OK, just have a look at the comment in the test class please.

I'll try to release a new version this week once I complete some other work I'm doing around multi-level menus.

[zawadz88]

This feels like something that deserves a separate test to me since you're making and additional step in the verification section of the test (the one in //then).
A separate test for this with a single item and secondPopupMenuItem.viewBoundCallback.invoke(view) in the //when section would be more appropriate I think as it would indicate more clearly which part is being tested (the code for constructing the popup menu should be in //given section then as it's a part of the test preparation).

[Tunous]

Good idea. I've added one.

[zawadz88]

Ha quite clever to extend a closure here ;)

[Tunous]

Yeah that's a nice feature. I found it by accident :)