Complete implementation of support for Mac2 engine

In this release, I finally got the support for the Appium Mac2 engine fully implemented. In creating a working "Hello World" example of automated interactions with TextEdit, I discovered a few Mac-specific issues that no one else has reported:

• On MacOS, normal process termination returns exit code 143 instead of the exit code 1 returned on Windows.
• The Mac2 engine doesn't support alerts, which was triggering UnsupportedCommandException in the alert check performed by ContainerMethodInterceptor.
• The command line used to get the process ID of servers managed by Selenium Foundation was slightly malformed.

I also updated the documentation collection copies of several example classes to align them with their actual Java counterparts.

Finish iOS support; upgrade to 4.38.0

In this release, I completed implementation of support for the XCUITest engine of Appium. This largely involved adding a build of the iOS sample application from the Appium project, revising the unit test and page models accordingly.

I also upgraded to the latest Selenium release (version 4.38.0)

Add direct activity navigation for UiAutomator2; fix subtle bugs

The primary objective of this release was to add the ability to open Android activities directly with UiAutomator2. This feature is quite straightforward with Espresso but required the use of Appium's mobile: shell script for UiAutomator2. To facilitate a broader range of options, I added action and category properties to the PageUrl annotation.

In the process of implementing this new feature, I discovered a few subtle bugs that heretofore had gone undetected.

• I had used the Xpath selector /* to select the first element of a page for refresh detection. This worked for web applications, but caused failures on Android applications if RemoteWebDriver was used instead of AndroidDriver. I switch to using //* instead, which works even with RemoteWebDriver.
• A dependency declaration issue had caused the code to fall back to RemoteWebDriver because the java-client artifact was only being included in test scope.

Upgrade to Appium Java client 10.0.0

In this release, I upgraded the Appium Java client to the latest release (version 10.0.0).

Upgrade to Selenium 4.36.0

In this release, I upgraded to the latest Selenium version (4.36.0).

Upgrade to Selenium 4.35.0

In this release, I upgraded to the latest Selenium version (4.35.0). I also upgraded the rest of the direct dependencies.

Add synchronization to container resolver unit test

When I was writing the documentation for the new ContainerResolver feature, I realized that my unit test had a race condition in it. This release adds synchronization to resolve this issue (no pun intended).

I also fixed a couple of esoteric issues with search context unwrapping and added a new convenience method: RobustElementFactory.getOptional()

Add ContainerResolver feature; transition to OSSRH Staging

In this release, I added a feature that enables page model hierarchies to define multiple versions of a component container (page or component) that get selected at runtime based on the current state of the DOM. This enables you to handle pages and components that vary based on browser window dimensions (responsive layout) or UI/UX variations (A/B testing). This feature can also select between old and new versions of site-wide components (e.g. - common navigation) during the transition between versions when some pages have been updated but others haven't.

I also needed to transition my artifact publishing from the now-retired OSSRH to the new Maven Central Portal, using the Portal OSSRH Staging API to avoid having to perform major surgery on my Gradle project.

Add alert modeling; upgrade to Selenium 4.33.0

Is this release, I added modeling of browser alerts. This resolves issue #213, introducing a framework feature that presents a more rational API, where alerts are treated as browser-level entities instead of the pseudo-context. The base class (AlertHandler) is an abstract class, with the methods that accept or dismiss the alert returning landing page objects. As shown in the unit tests, this base class should be implemented as a static class within the parent page model, and access to alert handler functions should be provided through page-class methods. The alert handler itself shouldn't be exposed for direct interaction, because this bypasses the management of page object within the framework.

I also upgraded Selenium 4 to the latest release (version 4.33.0).

Adopt active local grid if found; upgrade to Selenium 4.32.0

In this release, I finally added the ability to adopt an active local Grid instance if it's found at the specified (or implied) address. If the active Grid lacks support for browsers specified by the current configuration, the corresponding nodes are added. Also:

• Upgrade Selenium to the latest release (version 4.32.0)
• Upgrade **HtmlUnit Remote to the latest release (version 4.32.0)
• Remove usage of the Selenium 3 LifecycleServlet
• Backport DefaultNetworkInterfaceProvider and HostIdentifier into the Selenium 3 support branch
• Add a few null argument checks and a bit more debug logging