Devlog #16

At work I've been looking at ways to further organize our codebase. The team had adopted an MVVM approach prior to my joining it but did not take advantage of data binding. Data binding allows one to reference and access their view models from the layout files. I'm still trying to understand some of the development patterns around this. For instance, click events seem to work better if they remain in your Activity or Fragment and not pushed to the view model. Anything that deals with the context, such as showing dialogs or fetching strings from the resources, seem to "fit" in the view more than the view model. But any "business" logic stuff makes sense to be inside of the view model. Sometimes your business logic needs to trigger something within the UI. If that situation arises, we're making use of callbacks. For instance:

fun clickViewButton() {
    viewModel.fetchInfo(this, 
        onSuccess = { info -> this.openDialog(info) },
        onError = { error -> this.openErrorDialog(error) }
    )
}

As far as unit testing goes, I'm still coming to terms with Mockk. It isn't as easy other web frameworks, and I believe it could be. In the web world, you have Jasmine's "spyOn" function that takes an object then a string parameter. That string parameter is the name of the function you want to "take over". With Mockk, you can't exactly do that. Or if you can, I haven't figured out how. Any time I want to "stub" a function it seems to want to call the function itself prior to stubbing it. Example:

mockkStatic(MyHelper)
every { MyHelper.show(any()) } just Runs

In this case, MyHelper.show is executed THEN stubbed by Mockk. This behavior just seems wrong. Depending on how that function is written, it can throw exceptions.

Instead, Mockk should let you do something like this (or similar):

mockkStub(MyHelper, "show")
every { MyHelper.show(any()) } just Runs