Return contexts as objects with optional data

[NickAb]

Can GET /session/:sessionid/contexts command be extended to return dictionary of contexts with optional data if present, instead of simple returning list of contexts names?

According to https://github.com/SeleniumHQ/mobile-spec/blob/master/spec-draft.md#webviews-and-other-contexts

GET /session/:sessionid/contexts
returns an array of strings representing available contexts, e.g. 'WEBVIEW', or 'NATIVE'

response data:

["NATIVE", "WEBVIEW_1", "WEBVIEW_2"]

We propose to extend this endpoint so that it would be able to return optional extra data if available:

GET /session/:sessionid/contexts
returns a dictionary where keys are strings representing available contexts, e.g. 'WEBVIEW', or 'NATIVE' and values are objects representing optional data for each context if avaible

response data:

{
    "NATIVE": null,
    "WEBVIEW_1": {
        "title": "page title",
        "url": "https://github.com/SeleniumHQ/mobile-spec/"
    },
    "WEBVIEW_2": {
        "title": "other page title",
        "url": "https://example.com/"
    }
}

Alternately a list of object may be used, instead of dictionary.

Where it can be used?
See appium/appium#4911

This will be useful for hybrid-apps that have more than one webview, as it will make it easier to decide which context should be used by inspecting optional data after calling only one endpoint (instead of iterating over contexts and switching to them to read data).

For example, in our app we have UI where user actions can add new webview to navigation stack. In our tests we have to determine to which webview we should switch (and web context number is not constant, as it depends on previous user actions). As result, we have to iterate over contexts and ask for some attribute (e.g. title or url) to determine which context corresponds to which type of page object. Currently Appium already gets extra information from web contexts on iOS, but this data is not passed along to client. Returning this data to client will reduce number of requests needed in some use-cases, reducing test logic complexity, and slightly reducing test execution time and improving reliability.

[mikenikles]

Hey @NickAb,

We have the exact same situation. Have you been able to find a workaround for this?

Thanks,

Mike

[NickAb]

Hello,

Not actually. I do not follow iOS automation project close lately, but last time I checked we just tried to reduce number of webviews and better structure navigation in tests.