Espresso Idling when using Box<T>.put(T::class.java)

[RafaRuiz]

Issue Basics

• ObjectBox version (are using the latest version?): ANY (tried 1.2.1 and 1.4.4)
• Reproducibility: ALWAYS

Reproducing the bug

Description

*Espresso is finding an idling when using Box<T>.put(T). I'm using a BoxStore as a Singleton and calling a box as: val box = RafaBoxStore.getInstance().getBoxFor(MyItem::class.java) then using box.put(T).

When running instrumented tests, the app won't change the idle and Espresso will be waiting at least 45 seconds.*

    fun saveOrUpdateMyItem(product: ProductItem) {
        val box = RafaBoxStore.getInstance().getBoxFor(MyItem::class.java)
        if (isItemSavedInBox(product)) {
            addQuantityToProduct(product)
        } else {
            val myItem = MyItem()
            myItem.setProduct(product)
            box.put(myItem) /** THIS IS THE CASE **/
        }
    }

Logs & stackstraces

java.lang.RuntimeException: Could not launch intent Intent { flg=0x14000000 cmp=my.app.debug/my.app.debug.activities.ItemsActivity } within 45 seconds. Perhaps the main thread has not gone idle within a reasonable amount of time? There could be an animation or something constantly repainting the screen. Or the activity is doing network calls on creation? See the threaddump logs. For your reference the last time the event queue was idle before your activity launch request was 1522851145816 and now the last time the queue went idle was: 1522851145816. If these numbers are the same your activity might be hogging the event queue.

[greenrobot]

Weird. We'll plan to look into that next week.

[greenrobot-team]

The error message says that "If these numbers are the same your activity might be hogging the event queue". The numbers are the same. Are you calling saveOrUpdateMyItem on the main thread? Is there an unintentional loop which causes the UI to constantly update (e.g. a list view is listening for changes, so after your put it may cause another call to saveOrUpdateMyItem)?
-ut

[RafaRuiz]

• saveOrUpdateMyItem is called in the main thread, yes.
• There's no loop. Indeed it happens only when any .put is involved.

[greenrobot]

Are you having additional strict mode restrictions (e.g. file access on main thread)? What happens if you call the put in another thread?

[greenrobot-team]

I tried to reproduce this using our objectbox-example project. I added a simple EspressoTest entering a few notes (which causes the Note objects to be put). Not seeing any issues. The modifed project:
objectbox-examples-espresso-test.zip

You should really check that there is nothing still updating the screen (progress indicator, animation, camera view, ...).
-ut

[RafaRuiz]

Sorry @greenrobot @greenrobot-team due to a release, I had to change the entire ObjectBox library for Room Persistence otherwise we couldn't make it.

I'm sure it was happening with put as removing the unique line causing Box<T>.put(T::class.java) was succeeding in the test.

Is it useful if I provide a Thread dump when Box<T>.put(T::class.java) is called?

[greenrobot]

Is it useful if I provide a Thread dump when Box.put(T::class.java) is called?

Maybe a worth to try. Thanks.

Info on this might also be helpful if you find the time now or later:

Are you having additional strict mode restrictions (e.g. file access on main thread)? What happens if you call the put in another thread?

[RafaRuiz]

Sorry I'm needed of time, but I could bring this:

I was using the Box<T>.put(T::class.java) in a SetUp for a EspressoTest. This is the way I was using:

    fun setItems(itemsNumber: Int): SetUp {
        for (i in 0 until itemsNumber) {
            // This is where Box<T>.put(T::class.java) is involved
            ItemHelper
                    .saveOrUpdateItem(ProductModel.getRandomProductForTests())
        }
        
        return this
    }

I tried to put the same setUp call in an AsyncTask, and now I don't get the results expected, but Espresso is not waiting for idle:

    fun setItems(itemsNumber: Int): SetUp {
        object: AsyncTask<Any, Any, Any>() {
            override fun doInBackground(vararg p0: Any?): Any {
                for (i in 0 until itemsNumber) {
                    // This is where Box<T>.put(T::class.java) is involved
                    ItemHelper
                            .saveOrUpdateItem(ProductModel.getRandomProductForTests())
                }

                return 0
            }
        }
        return this
    }

is this useful for you?

[greenrobot]

I still don't see any obvious reason why this should block. Because it does not block in a separate thread, the Thread dump might be interesting after all.

[RafaRuiz]

Hello @greenrobot, after a deep investigation, I checked that this doesn't regard ObjectBox, I'm sorry for the waste of time 🙁.

[greenrobot]

Great that you found the cause! Is there anything you could share to help others running into that issue?

[RafaRuiz]

I changed all my TextViews for custom text views that, somehow, they were trying fetch some value to draw. Still an issue on my code, if I can get more useful information, I'll post it in this issue.