Droidium now consists of three groups of artifacts:
1) Android container adapter
2) Native plugin for testing native APKs by Selendroid server
3) Web plugin for testing web apps which are deployed to AS and tested from Android point of view - it is using android-server.apk from Selenium.
Since Droidium depends on Selendroid heavily and Android server apk from Selenium project was officially deprecated (1) and they recommend Selendroid from now on (whoa, thats nice coincidence ) we are trying to drop web plugin altogether and simplify Droidium even more from user point of view.
Changes Selendroid team introduced are as follows:
They coded up very simple, almost dummy like, native android application which gets installed along Selendroid server and it is instrumented after that. To make long story short, from now on, when you want to test web apps deployed to AS, you have to do these things on Android side:
1) Install Selendroid server apk as you are used to for native testing
2) Install "android-driver.apk" from Selendroid as well to Android device
3) instrument android-driver.apk by Selendroid server as ordinary APK as you do when you test native way
4) Start WebKit view on Android (check (2))
And thats it - when you inject @Drone, you have WebDriver by which you are testing web pages on Android.
From Arquillian point of view, it was very simple and the only change needed to be introduced was this (technicalities Aslak and Karel would understand ):
So, when you get AfterDeploy, and that deployment is not being deployed against Android container, you check if it has @Instrumentable on it, and when it does, you fire custom AndroidDeploy event. This is the only change, since from Droidium point of view, whole deployment voodoo logic and instrumentation is the very same as for normal native deployment testing mode but in this case, AndroidDeploy event is not fired by Android container adapter itself from deploy method (because you are deploying wars which does not target Android) so you have to fire it on your own.
1) When you look at test, it looks like this:
You just put @Instrumentable on deployment method as you would in case of native approach but right now, you are "instrumenting" war deployment which is not so intuitive. We are looking for other name of that annotation so it is totally clear that when you put it on deployment method, you know that something is going to be done on Android container side. What should be that annotation name like?
2) When you have test, you have to start activity from android driver apk from Selendroid you deployed automatically when @Instrumentable is put on deployment method, so you have to do this
We are looking for a way how to "hide" it into Drone instantiation logic, because writing this all over again seems to be rather tedious. But the problem is that it is unclear how to connect injected Drone instance with knowing that this particular Drone instance is operating on Android deployment which is there for testing web pages so that switch to webview should be done (+ starting of activity).
When this is done, you get rid of web plugin totally and it will not be released anymore, having one solution with robust lifecycle eventing and logic, deleting any differences between testing of native android applications and web applications, you just inject webdriver and annotated deployments, thats it. Graphene fits into this very conveniently providing quite nice ecosystem which encapsulates it all. Additionally, with the existence of Spacelift extension, you would not need to bring all infrastructure apks with you manually, it would be just somehow resolved so the bootstrap of this is matter of minutes.