Multi-apps prefactor 2

[d4vidi]

Problem

Support for multi-app testing seems to introduce additional architectural complexity (on top of #2980).

With the management of the list of test-apps, and, more importantly, the current app of which that is considered to be selected in each point in time, state management becomes slightly more extensive*. While the architecture is in fact well suited for holding and mutating that kind of a state model (i.e. under our 2 main top-level business logic entities - device and matchers), it is a bit inflexible when it comes to introducing the API's to do so. With that, I'm effectively referring to device.selectApp(), which is meant to do this kind of toggling between the various apps.

Selecting a test app as the current one requires mutating the state managed internally by both device and matchers, separately. Yet, by coupling the implementation of selectApp() to the device entity itself (as we do today), we can only own the device's internal state -- not any other entity's (matchers in particular).

Solutions

A deeper analysis of why the architecture isn't flexible enough so as to be allow this type of schema to be introduced trivially, puts the finger on the fact that in the matchers realm, the top-level expect(...) API is stateful. Meaning, there's no separation between the external "look&feel" and the internal architecture - and the two are in fact coupled. As a result, to solve this issue, the state has to be extract from the matchers realm's top-level, and put somewhere else.

One solution, which stems naturally from the problem's description, is to push the state downwards. Namely, instead of having the matchers API hold state (i.e. the currently selected app), follow the framework of the device realm, which (starting #2980) delegates the state to the driver:

This would make things like the case of device.selectApp() being implemented more easily, because it would make it very easy to select the app in both the device and matchers:

async selectApp(appAlias) {
  await this._deviceDriver.selectApp(appAlias);
  await this._interactionsDriver.selectApp(appAlias);
};

While we're at it, this change would also make it possible to get rid of the architecture fluke by which device is delegated by matchers, in order to call device.typeText(): Since everything is realistically managed under the drivers layer, the matchers could switch the arrow and call the runtime driver in the lower layer.

Alternative: Apps abstraction

A different approach is to have the app-selection state moved "sideways", such that it would be managed as a 1st class citizen, rather than as a delegation of other stateful entities. Namely, have "apps" added to our objects model (on top of "device" and "detox"), thus having the app-selection state managed in a centralized way. As a result, the device.selectApp() call, will be boiled down to calling something like apps.selectApp(appalias).

Note: We can only do this effortlessly, because there are no side effects to app selection state mutation. In particular, We don't expect any observes over mutations of this state to be registered.

This, in fact, can go alongside the previous solution, rather than instead of it. However it would come as a strictly optional addition.

For further visual explanations of this, check out this slideshow

---

* On Android, for example, selecting an app suggests selecting the right invocation manager to use in calls consequent to device.selectApp()

[d4vidi]

Following our discussion on this and some further thinking on my behalf, the current intent is to try to push forward the app abstraction direction -- namely, have the app "toggle" managed in a place both central and shared.

[d4vidi]

Following a 3rd round of experimentation and some further thought put into things, I've come to realize that if in fact we were to introduce an app entity, it would evidently mean that:

• We would have to do so such that is would represent a test-app in a device in all aspects^*. Namely:
• It would have to also be responsible for things such as the app's dynamic launch args setup, and the associated bundle/package ID.
• It would hence be required to follow the same two-layer pattern we have for the device entity, namely, a logical abstraction over a driver as a lower layer. The logical layer would (arguably) manage the launch args, and the driver layer would be used for handling things such as resolving the app's bundleId (i.e. using aapt on Android and PlistBuddy on iOS).

Therefore, we can in fact conclude that if we were to introduce the apps abstraction as initially planned, we would roughly be providing an elegant delegation of the device entity - but nothing more. It would not allow for having the app-selection toggle managed in a straightforward way, as we aimed for.

With that, I'm basically saying that the best solution I can see from the current view of things, is to have the state be fully pushed down towards the driver layer.

---

* Of course, that is not necessarily a given. However, the alternative of having an abstraction of just the connection management aspect of an "app", would result in having the app-related state managed across various entities, namely, both the app-connection abstraction and the device. The device cannot ignore the selected app because it is essential for fundamental actions such as launchApp() and terminateApp().