Closed GoogleCodeExporter closed 9 years ago
Thanks for reporting this. Would it be possible for you to send me your app
and test project?
Original comment by renasr...@gmail.com
on 25 Oct 2011 at 2:51
created a new project which illustrates the issue at hand.
Original comment by tomi.ura...@gmail.com
on 25 Oct 2011 at 4:49
Attachments:
Thanks.
Original comment by renasr...@gmail.com
on 26 Oct 2011 at 6:14
[deleted comment]
1. Do you have an approximate ETA for when this will be fixed?
2. In the meantime is there a workaround that would enable me to full test the
application?
Original comment by tomi.ura...@gmail.com
on 26 Oct 2011 at 7:41
Please use the constructor solo = new Solo(getInstrumentation) and then in the
beginning of your test case call getActivity() and it will work.
Original comment by renasr...@gmail.com
on 3 Nov 2011 at 6:58
thx.
Original comment by tomi.ura...@gmail.com
on 4 Nov 2011 at 5:51
I noticed that the status of this is now invalid and the issue is now moved to
closed. Is the workaround listed above:
"Please use the constructor solo = new Solo(getInstrumentation) and then in the
beginning of your test case call getActivity() and it will work."
the only fix for this or will a better solution be rolled into a future release?
Thanks!
Original comment by david.a....@gmail.com
on 6 Dec 2011 at 1:12
that's the working workaround
Original comment by tomi.ura...@gmail.com
on 6 Dec 2011 at 3:05
I would not call it a work around. If there is one Activity which is started
immediately by the start activity, before the solo object is created then it
will not be ready to register the new activity. By using this constructor
instead, getActivity() will be called after the solo object is fully created
thus making it ready to register a new activity that is started immediately by
the start activity.
Original comment by renasr...@gmail.com
on 6 Dec 2011 at 4:00
agreed
Original comment by tomi.ura...@gmail.com
on 6 Dec 2011 at 5:45
I don't want to whine, or get hung up on semantics, but it does sound a bit
like a workaround. When I call solo.getCurrentActivity() , as an end user I
expect to retrieve the current activity that I am on independent of setup. I
expect this because the constructors that Robotium provides for the Solo object
don't provide the information listed within this issue.
That being said, instead of complaining I'll go ahead and take a gander at the
source and see if I can help ;)
Thanks!
++dave;
Original comment by david.a....@gmail.com
on 7 Dec 2011 at 8:34
[deleted comment]
Has this been fixed?
I think I encountered the same problem.
Hoping for some input.
Michael
Original comment by M.Schwar...@gmail.com
on 16 Dec 2014 at 9:17
We have updated how this works in 5.2.1 and so far no one has reported it not
working. What problem do you get?
Original comment by renasr...@gmail.com
on 16 Dec 2014 at 4:35
I'm using calabash-android <https://github.com/calabash/calabash-android/>,
which is using robotium version 4.3.1. It has this bug, where the launch
activity starts a 2nd activity, and intermittently the test server is unable to
recognize that the launch activity has since started a new activity.
I tried the fix mentioned in #c6:
but it is still only showing the launch activity, even though a 2nd activity
has been started and is showing on the screen. The code that calabash uses for
obtaining the current activity is:
Activity currentActivity = InstrumentationBackend.solo.getCurrentActivity();
Result result = new Result(true, currentActivity.getClass().getSimpleName());
I can try integrating robotium 5.2.1, but if it's not a simple update of the
jar, then I am not going to have the time to do this work.
Is there any other suggestion that would work in 4.3.1?
Original comment by jhans...@meetme.com
on 12 Mar 2015 at 6:15
I was able to update calabash to use robotium 5.3.1 with some package renaming
and a couple method signature changes, and that appears to have resolved the
issue.
Original comment by jhans...@meetme.com
on 12 Mar 2015 at 7:04
Good to hear that its working well for you!
Original comment by renasr...@gmail.com
on 12 Mar 2015 at 8:38
I may have spoken too soon... I wasn't able to get it to happen on a device.
But once I started testing on the emulator again, it's back -- happened 4 out
of 8 times in my emulator test.
I'm new to Ruby, so I may just be doing something dumb.. I'm gonna try a manual
version bump to make sure that I'm actually using the gem that I built.
If this still doesn't work, I'm going to have to get rid of the Robotium-driven
activity check, and use `adb shell dumpsys` to get the focused activity
instead. 50% failure rate is unacceptable. :/
Original comment by jhans...@meetme.com
on 12 Mar 2015 at 9:32
I've confirmed that I'm using the new version of the calabash test server apk,
which includes robotium 5.3.1, and I am still seeing the issue. The calabash
test starts with something along the lines of:
wait_for_not_activity("LaunchActivity")
That is a method I created which waits for the calabash "get_activity_name"
result to be anything else other than LaunchActivity (that is the activity
specified as the default activity in my AndroidManifest, and the one that
calabash launches to begin the tests). The "get_activity_name" action does as
described above: InstrumentationBackend.solo.getCurrentActivity(), returning
the class's simple name.
But it is still not detecting that the current activity is changed.
Original comment by jhans...@meetme.com
on 12 Mar 2015 at 9:55
Would it be possible for you to share the APK you use to reproduce this issue?
Original comment by renasr...@gmail.com
on 12 Mar 2015 at 9:57
Not by attaching here, but I can send it to you privately -- but your email is
truncated to "renasr..." here.
If I have time I'll see if I can put together a sample project that does the
same thing. I have a feeling it isn't specific to my app.
Original comment by jhans...@meetme.com
on 12 Mar 2015 at 11:32
That would be great. You can send it to support@robotium.com.
Original comment by renasr...@gmail.com
on 12 Mar 2015 at 11:36
@renasr... I was able to reproduce the bug (running within Calabash) using this
project: https://github.com/MeetMe/robotium-179
After building the apk:
$ cd app
$ bundle install
... if you don't have bundle, install it with: gem install bundler
... or just install calabash manually: gem install calabash-android -v 0.5.8
Resign the APK:
$ calabash-android resign build/output/apk/app-debug.apk
Then try running the calabash test:
$ calabash-android run build/output/apk/app-debug.apk -v
On a *device*, this was working more often for me. But on an emulator, it
fails most of the time. The key is the built-in calabash step:
Then I wait for the "SecondActivity" screen to appear
LaunchActivity starts SecondActivity from onResume(). But calabash (which uses
Robotium to keep track of which activity is active) never sees SecondActivity
launch, so it still thinks that LaunchActivity is the focused activity. That
causes the calabash step to fail, because it times out waiting for
SecondActivity.
Original comment by jhans...@meetme.com
on 12 Mar 2015 at 11:53
Original issue reported on code.google.com by
tomi.ura...@gmail.com
on 24 Oct 2011 at 1:02