@edvin will you have to use System.exit rather than Platform.exit with the daemon thread?

@carlw No, that shouldn't be an issue with daemon threads.

They will not block the JVM exit process.

@edvin great

Has anyone subscribed to this MEAP? https://www.manning.com/books/grokking-frp?trk_msg=MKU7HKMAPP2K1C0ICRESHSCRU0&trk_contact=P8U3FUV6UPU21VRFH82P82SAP8&trk_sid=DE3PGOTP9B1GH3MQN74EFLJBRC&utm_source=Listrak&utm_medium=Email&utm_term=https%3a%2f%2fwww.manning.com%2fbooks%2fgrokking-frp&utm_campaign=New+name!+Half+off+Grokking+FRP+%2b+other+selected+books

I'm curious about the view layer, which isn't mentioned explicitly in any of the blurbage -- all it says is "Android"

hmmm, I was left with a bad impression of the`grokking` book series after I bought

Grooking FP

.

How do you test JavaFX/TornadoFX apps? (someone is doing that, right?🙂 ) Do you use frameworks like

TestFx

? Or just tests for non-UI stuff? btw if I am following MVVM, is it normal to have async methods like that in ViewModel?

fun loadTokens() {
        tokens.clear() // observable list

        runAsync(status) {
            loadSomeStuff(someData).tokens
        } ui {
            tokens.addAll(it)
        } fail {
            fire(ErrorEvent(it))
        }
    }

I tried to test this VM and found out that I can't do it because of async 🙂 Also I just noticed that I use

someData

(string property) inside async, which I guess is not very thread safe...

@alexp11223 That's where i put the async stuff. My model is synchronous and sends updates via a notifications object. We're looking at Commanding as an alternative

with JavaFX tasks, you should return the stuff you're loading for use in the ui() method rather than operating on it in the call() method (which I think is runAsync)

yeah, that's what I am doing here,

it

is result returned on success, or exception in fail.

someData

is just a property containing query parameter (I guess I should assign the value to local variable before

runAsync

to make it thread safe) and that seemed fine until I tried to unit test VM. I am not sure how to wait for result in tests. I can't even do something like this because FX thread is busy and

ui

cannot fire:

vm.loadTokens()
while (vm.status.running) { }
assert.........

@alexp11223 Maybe you can use a countdown latch?

@alexp11223 Look at the implementation of

runAndWait

in the framework. That might give you some ideas.

@alexp11223 what testing library are you using? Spock has some async capabilities.

JUnit. I'm just starting with JavaFX and before that was testing only some non-UI libraries and web

@alexp11223 http://spockframework.org/spock/docs/1.1/all_in_one.html#_polling_conditions

also http://spockframework.org/spock/javadoc/1.0/spock/util/concurrent/AsyncConditions.html

hm. Looks like using Awaitility library https://github.com/awaitility/awaitility something like this works

val vm = TokensViewModel()

    init {
        FxToolkit.registerPrimaryStage()
    }

    @Test
    fun loadsTokens() {
        vm.loadTokens()

        await().atMost(10000, MILLISECONDS).until { !vm.status.running.value }

        assertNotEquals(0, vm.tokens.size)
    }

but I am not completely sure why and how it works. And looks like it is polling

status

not from UI thread

@alexp11223 Could this be something?

@User uploaded a file: AwaitTest

Output will be:

@User uploaded a file: Untitled

hm, I'm not very familiar with Java concurrency, I thought that countdownlatch simply blocks the thread on await? so if called from UI thread, then events,

ui

etc. will not fire

@alexp11223 This seems to work just fine:

@User uploaded a file: Untitled

But maybe I'm mixing apples and bananas here. It's getting late 🙂

@alexp11223 If you want to know more about java concurrency, here's a video i created on Phaser which is a more flexible CountDownLatch

@alexp11223 I was able to avoid blocking the UI thread and still wait by utilizing

Toolkit.getToolkit().enterNestedEventLoop(this)

. I will commit

awaitUntil

later today. I think it should solve your use case in a good way 🙂

I tested it with this view. If you click the "Wait until 42" button, you'll notice that the UI is still responsive, even though this method will wait until you enter 42 in the text field. You can verify that events are still processed by interacting with the UI and even click the "Look alive" button.

@User uploaded a file: Await on UI thread without blocking