Issue with Cursor matching with onData()

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Have a ListView backed by a CursorAdapter
2. Have a test case that uses onData() which takes in a Matcher<Cursor>.

What is the expected output?
Espresso should properly run your Matcher<Cursor> on each row of the Adapter 
when building the list of AdaptedData.

What do you see instead?
Espresso will run your Matcher<Cursor> on a Cursor with its position 
permanently set to adapterView.getCount() - 1.

What version of the product are you using?
Espresso 1.1

On what operating system?
Android API 15-19

Please provide any additional information below.

Lets take a look at AdapterDataLoaderAction's perform implementation (I've 
added my own comments in the implementation):

  @SuppressWarnings("unchecked")
  @Override
  public void perform(UiController uiController, View view) {
    AdapterView<? extends Adapter> adapterView = (AdapterView<? extends Adapter>) view;
    List<AdapterViewProtocol.AdaptedData> matchedDataItems = Lists.newArrayList();

    for (AdapterViewProtocol.AdaptedData data : adapterViewProtocol.getDataInAdapterView(
        adapterView)) {

      if (dataToLoadMatcher.matches(data.data)) {
        // For all AdaptedData's in the Iterable, you will get the same Cursor set to
        // the position adapterView.getCount() - 1. Perhaps for Cursors, Espresso can
        // get the Cursor position from data.opaqueToken, call cursor.moveToPosition()
        // and then run the matcher before attempting to add it to matchedDataItems.
        matchedDataItems.add(data);
      }
    }

Original issue reported on code.google.com by mhernan...@gmail.com on 2 May 2014 at 11:12

[GoogleCodeExporter]

Not sure if having a special case for Cursors in AdapterDataLoaderAction's 
perform implementation would be the right fix, but I figured I'd bring it to 
attention. Having a list backed by a CursorAdapter is pretty common in Android 
apps. Writing a Matcher<Cursor>, although a little bit too "whitebox", is 
feasible, but having to write custom AdapterViewProtocol implementations that 
are almost a copy/paste of the private StandardAdapterViewProtocol with a few 
tweaks is a bit tedious in my opinion.

Original comment by mhernan...@gmail.com on 5 May 2014 at 11:01

[GoogleCodeExporter]

Original comment by vale...@google.com on 7 May 2014 at 7:15

• Changed state: Accepted

[GoogleCodeExporter]

I have the same problem.

I have a listview backed by a CursorAdapter and when I try to verify the list 
contains a specific element, the cursor that is returned in matchesSafely() is 
locked to the same position, for all calls.

        onData(allOf(is(instanceOf(MyCursor.class)), withTitle("My String")))
                .check(matches(isDisplayed()));

Original comment by kot...@gmail.com on 2 Aug 2014 at 9:39

[GoogleCodeExporter]

Any chance to get this fixed in Espresso? 
P.S. It seems like this project is not supported at all (no contributions to 
master branch since Jan 8)...

Original comment by vitaliy....@gmail.com on 6 Aug 2014 at 10:58

[GoogleCodeExporter]

Just a quick note to second the importance of this!

+1 on releasing a point release or hotpatch for this issue

Original comment by s...@remind101.com on 10 Sep 2014 at 1:40

[GoogleCodeExporter]

+1 I'm struggling with this now and not a dev...I was really starting to get 
excited about automating with Espresso and making progress on some basics, 
then...Cursor Adapter. :(

Original comment by sdkdo...@gmail.com on 2 Oct 2014 at 9:51

[GoogleCodeExporter]

Fixed in Espresso 2.0

Original comment by vale...@google.com on 20 Dec 2014 at 4:33

• Changed state: Fixed