Driver.deviceInfo() is being called too many times

[bartekpacia]

Problem

Current state

The Driver.deviceInfo() is sometimes being called too many times (too many=more than once) when executing a single Maestro command.

This is caused by lack of clear responsibility separation between Orchestra, Maestro, and Driver when mapping screen size values (width and height) for use by commands.

Expected state

The Driver.deviceInfo() is called at most once for each Maestro command.

Possible solutions

Option 1

Change function of the Driver to accept callbacks that provide the caller with most up-to-date device info (or just screen size) and return Point, e.g. we'd go from:

fun tap(point: Point)

to:

fun tap(callback: (height: Int, width: Int) -> Point)

Then the callers would do:

driver.tap { height, width ->
    // Let's assume we want to in the middle of the screen
    return@tap Point(width / 2, height / 2)
}

Sample implementation in a platform-specific driver:

class IOSDriver : Driver {
    // ...

    override fun tap(callback: (height: Int, width: Int) -> Point) {
        val point = callbackdeviceInfo().heightGrid, deviceInfo().widthGrid)
        runDeviceCall { iosDevice.tap(point.x, point.y) }
    }
}

Pros

• no code duplication across drivers for different platforms

Cons

• more complex and non-obvious function signatures
• changes would likely permeat a large part of the codebase

Option 2

Don't use/depend on device's width/height in Orchestra and Maestro classes. Instead, the Driver interface accomodates for the use cases that currently require calling Driver.deviceInfo() in Orchestra and Maestro. Orchestra and Maestro are not concerned with screen sizes at all.

Pros

• code stays simple

Cons

• code duplication across drivers for different platforms. Right now, for example, the swipe command is implemented both in both Maestro.swipe() and platform-specific Driver.swipe().

Option 3

Be okay with a single command ending up calling the /deviceInfo endpoint multiple times.

This is what we have now (since PR #1974 has been merged).

Pros

• simplest to accomplish, does the job

Cons

• not optimal