[JBoss JIRA] (ARQ-1536) Provide @StartActivity annotation put on test method to automatically start it or use @Location from Graphene to do so
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1536?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic closed ARQ-1536.
----------------------------------
> Provide @StartActivity annotation put on test method to automatically start it or use @Location from Graphene to do so
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: ARQ-1536
> URL: https://issues.jboss.org/browse/ARQ-1536
> Project: Arquillian
> Issue Type: Feature Request
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Fix For: droidium_1.0.0.Alpha6
>
>
> Instead of starting activity every time in test method manually, it would be nice to have this possibility:
> {code}
> @Test
> @InSequence(4)
> @OperateOnDeployment("todo-mobile-app")
> public void loginUserInMobile(@ArquillianResource AndroidDevice device) {
> device.getActivityManagerProvider()
> .getActivityManager()
> .startActivity("org.jboss.aerogear.todo.activities.LoginActivity");
> loginMobileFragment.login("john", "123");
> }
> =========================
> @Test
> @InSequence(4)
> @OperateOnDeployment("todo-mobile-app")
> @StartActivity("org.jboss.aerogear.todo.activities.LoginActivity")
> public void loginUserInMobile() {
> loginMobileFragment.login("john", "123");
> }
> {code}
> However, with the possibility to have Graphene page fragments, it would be teoretically possible to have propper page objects as well which mean that we could abstract activity into @Page and specify its @Location("activityName")
> The problem is, how this translates to Graphene since Droidium starts activities in this manner:
> driver.get("and-activity://" + activityName);
> There is the need to take that "and-activity" string into consideration with @Location annotation.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (ARQ-1613) Allow Android Shell command timeouts
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1613?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic closed ARQ-1613.
----------------------------------
> Allow Android Shell command timeouts
> ------------------------------------
>
> Key: ARQ-1613
> URL: https://issues.jboss.org/browse/ARQ-1613
> Project: Arquillian
> Issue Type: Feature Request
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha3
> Reporter: Karel Piwko
> Assignee: Stefan Miklosovic
> Fix For: droidium_1.0.0.Alpha6
>
>
> It would be handy, if Droidium can setup timeout for DDMS related operations, such as executing a shell commands.
> It looks like it should be possible with:
> {code}
> DdmPreferences.setTimeOut(timeout);
> {code}
> By default, timeout is set to 5 seconds, which might be not enough when running in emulated env.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (ARQ-1557) Align undeployment logic in a proper Arquillian way
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1557?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic closed ARQ-1557.
----------------------------------
> Align undeployment logic in a proper Arquillian way
> ---------------------------------------------------
>
> Key: ARQ-1557
> URL: https://issues.jboss.org/browse/ARQ-1557
> Project: Arquillian
> Issue Type: Feature Request
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Fix For: droidium_1.0.0.Alpha6
>
> Attachments: brainstorming.jpg
>
>
> Right now, undeployment logic for Droidium is bound to observer which observes with precedence -100 on AfterClass event in order to be sure that this observer will be treated as the latest one.
> Right now, we have to be sure that undeployment logic is treated lastly in AfterClass since Arquillian Drone destroys WebDriver instances in AfterClass as well and the destruction of WebDriver instance, in our case, means that Selendroid server will be uninstalled from Android device.
> Since the destruction of WebDriver instance itself is executed randomly in AfterClass regarding of execution time, we can not do undeployment of APKs on UnDeployDeployment event because when doing so, uninstallation of instrumented APK automatically kills Selendroid server process as well so that in turn means that subsequent trying to destroy WebDriver instance fails since Selendroid server is not running anymore and Drone talks to nobody.
> To be sure that all Selendroid servers are uninstalled so we can proceed with the uninstallation of deployments, where it should be done, there has to be a guarantee that all WebDriver instances were already destroyed.
> The solution here seems to be quite simple - we put some positive precedence for DroneDestructor (1) however by doing so, it could cause some backward compatibility issues with Drone extension.
> (1) https://github.com/arquillian/arquillian-extension-drone/blob/master/dron...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (ARQ-1885) Droidium is not buildable with Java 8
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1885?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic updated ARQ-1885:
-----------------------------------
Fix Version/s: droidium_1.0.0.Alpha6
(was: droidium_1.0.0.Beta1)
> Droidium is not buildable with Java 8
> -------------------------------------
>
> Key: ARQ-1885
> URL: https://issues.jboss.org/browse/ARQ-1885
> Project: Arquillian
> Issue Type: Bug
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Beta1
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Fix For: droidium_1.0.0.Alpha6
>
>
> {code}
> ERROR] Failed to execute goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check (signature-check) on project arquillian-droidium-container: Execution signature-check of goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check failed. IllegalArgumentException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check (signature-check) on project arquillian-droidium-container: Execution signature-check of goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check failed.
> ...
> Caused by: java.lang.IllegalArgumentException
> at org.objectweb.asm.ClassReader.<init>(Unknown Source)
> at org.objectweb.asm.ClassReader.<init>(Unknown Source)
> at org.objectweb.asm.ClassReader.<init>(Unknown Source)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (ARQ-1895) Implement video recorder for Droidium
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1895?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic updated ARQ-1895:
-----------------------------------
Fix Version/s: droidium_1.0.0.Alpha6
(was: droidium_1.0.0.Beta1)
> Implement video recorder for Droidium
> -------------------------------------
>
> Key: ARQ-1895
> URL: https://issues.jboss.org/browse/ARQ-1895
> Project: Arquillian
> Issue Type: Feature Request
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha5
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Fix For: droidium_1.0.0.Alpha6
>
>
> Implement recorder for Droidium based on video API of Arquillian Video Recorder.
> The goal of this implementation is to record videos of Android phone itself via screenrecorder API in ddmlib since ddms 24.0.0 - aplicable for Android API 19+.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (ARQ-1658) Wrong isInstance check prevents usage of new/custom container
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1658?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic updated ARQ-1658:
-----------------------------------
Fix Version/s: droidium_1.0.0.Alpha6
(was: droidium_1.0.0.Beta1)
> Wrong isInstance check prevents usage of new/custom container
> --------------------------------------------------------------
>
> Key: ARQ-1658
> URL: https://issues.jboss.org/browse/ARQ-1658
> Project: Arquillian
> Issue Type: Bug
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha4
> Reporter: Thorben Janssen
> Fix For: droidium_1.0.0.Alpha6
>
>
> If the container configuration contains an unknown qualifier, MultipleContainerRegistryCreator tries to the adapterImplClass class and checks if it implements DeploableContainer.
> The current check with isInstance() returns always. The isAssignableFrom() method has to be used instead.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months