Wrap the code that mocks the camera with a try-catch clause in the readme

[rocboronat]

It happened to me that the code that performs something with the camera crashes, so the release is never called, so the next test fails because the init has been called twice without releasing it.

Totally open for discussion, of course! But as it's a piece of code that we're aiming people to copy-paste...

[alorma]

Wondering...

Maybe we can create a helper function, that does that?

Wrap code in a try catch and has a lambda to allow any needed interactions

[Sloy]

I think the best / right approach is to do Intents.init() and Intents.release() in the @Before and @After in the test, and let JUnit handle it.

[rocboronat]

What do you think about doing it in the Barista rule, @Sloy?

[Sloy]

Dunno. That's actually what the IntentsTestRule does. Taking a quick look at the code, I don't see anything that could break. I don't know if there's any performance impact though.

But I don't really use the BaristaTestRule myself, so... go go go! 🥳

[Sloy]

PS: We need to talk about BaristaTestRule, the Espresso's ActivityTestRule is now deprecated in favor of ActivityScenario.

[rocboronat]

😱 🙀

[rocboronat]

Hey team! Is that an LGFM? 🤩

[rocboronat]

#402 relates to this.

[rocboronat]

Thanks @alorma 😄