chore: [SDK-4364] prepare .NET MAUI demo for Appium E2E tests

[fadi-george]

Description

One Line Summary

Wires the .NET MAUI demo app up so the shared Appium E2E suite can drive it on iOS and Android, plus the supporting demo refactors and one small SDK fix.

dotnet-and.mov

dotnet-ios-720.mov

Details

Motivation

Linear: SDK-4364. The shared Appium harness in sdk-shared/appium already runs the same spec set against the Flutter, React Native, and Cordova demos. This branch brings the .NET MAUI demo up to the same bar so it can be exercised by the same harness, and pulls in a handful of demo cleanups + one SDK-side null-safety fix that fell out of that work.

Scope

Demo app (most of the diff). The demo's UI was reworked so every interactive element has a stable AutomationId, dialog inputs use plain keyboards with autocorrect / spell-check / InputAccessoryView disabled (Appium can't reliably tap through the iOS predictive bar), and the section list is reorganised to match the spec ordering. A few pieces were rewritten more substantially:

• OneSignalRepository was deleted and its callers go directly through the SDK; the repo layer was only there to insulate against an older API and was making things harder to read.
• LoadingOverlay -> inline LoadingState per section so spinners don't block taps on unrelated controls.
• LogView removed in favour of Debug.WriteLine; the in-app log was never used and added a lot of XAML noise.
• Custom JSON event sending now goes through a typed Dictionary<string, object?> path instead of stringly-typed args, and the underlying ToNativeConversion helper was taught to forward null values to native dictionaries (previously they were silently dropped).

iOS-only demo glue.

• Platforms/iOS/PopupKeyboardAvoider.cs shifts CommunityToolkit.Maui popups out from under the keyboard via AdditionalSafeAreaInsets, so confirm buttons in tall modals stay tappable for Appium.
• MauiProgram.cs registers global EntryHandler / EditorHandler mappings that null out InputAccessoryView and installs the popup avoider on iOS.
• NotificationServiceExtension.csproj and demo.csproj only apply CodesignTeamId / CodesignProvision for device builds so iOS simulator builds work without a provisioning profile.
• OneSignalWidget/ now ships an XcodeGen project.yml (+ generated xcodeproj and .gitignore) that produces the Live Activity widget extension, replacing a hand-checked-in debug .appex that depended on a missing *.debug.dylib and failed to load at runtime. The new build links (but doesn't embed) the OneSignal xcframeworks already shipped under OneSignalSDK.DotNet.iOS.Binding/; the widget resolves them via the host app's Frameworks/ at runtime.

SDK change. OneSignalSDK.DotNet.iOS/Utilities/ToNativeConversion.cs now lets null values through into NSDictionary (as NSNull) instead of throwing. This keeps parity with the Android binding and is what unblocks the typed-event work above.

What is not changing

• No public SDK API changes.
• No changes to Android or iOS binding source beyond the one null-handling fix above.
• The Appium spec files themselves live in sdk-shared and are not in this PR.

Testing

Manual testing

Ran the full shared Appium suite locally against the iOS simulator (iPhone 17, iOS 26.2) and Android emulator using sdk-shared/appium/scripts/run-local.sh --platform=ios --sdk=dotnet and --platform=android --sdk=dotnet. All specs pass, including 12_activity.spec.ts which exercises the rebuilt Live Activity widget.

Also exercised the demo by hand on the simulator to confirm the UI changes (loading states, custom-event dialogs, multi-pair alias dialog, popup keyboard avoidance) behave the same or better than before.

Unit testing

No new unit tests. The behaviour this branch cares about is covered by the shared Appium specs.

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

(No SDK-public surface affected; the one SDK file touched is an internal native-conversion helper. Everything else is the demo app.)

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing - all changes are in service of getting the .NET demo runnable under the shared Appium suite
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
• I have reviewed this PR myself, ensuring it meets each checklist item

Made with Cursor

[fadi-george]

@claude rereview