Collect Device Data

[scannillo]

Changes

• Expose deviceData on BTDropInResult

Motivation

• Android & Web DropIn offer device data collection capabilities.
• In Android, you have to set collectDeviceData to true on your DropInRequest here. If you do, only then will you get back device data on your DropInResult here.
  • For iOS, I decided not to require merchants set the collectDeviceData boolean property on their request, and instead always include deviceData on the DropInResult.
  • I think since this is an additive (non-breaking) change, this is an easier integration pattern for merchants. They don't have to worry about requesting the data. They will always get it and can decide to ignore or use it.

Concerns

I had a concern about performance, but used XCTest's measure function to time this test. I get roughly the same time to initialize the DropInResult with and without the call to PPDataCollector. I think it is OK to add.

Checklist

• Added a changelog entry

Authors

@scannillo

[scannillo]

I think we can do this with OCMock instead (see docs under the 3.2 Stubs and verification section).

This project doesn't use OCMock, so I tried to import it. OCMock has an SPM bug, which I reported on their GitHub. So rather than use a 2nd package manager for the project to fetch OCMock, I went for this approach.

We can always change this testing situation in the future. Let me know what ya'll think.

[sarahkoop]

This approach seems reasonable to me. No need to introduce another package manager for testing.

[sarahkoop]

This looks good to me! Should we mark collectDeviceData on BTDropInRequest as deprecated if it's always going to be requested and exposed now?

[scannillo]

Should we mark collectDeviceData on BTDropInRequest as deprecated if it's always going to be requested and exposed now?

@sarahkoop There is no collectDeviceData on BTDropInRequest, so we should be good!