[fadi-george]

Description

One Line Summary

Add a sticky, logcat-style Log View to the MAUI demo app.

Details

Motivation

Matches the shared demo spec (sdk-shared/demo/build.md Prompts 1.5, 2.0, 6.2 and styles.md Log View) so the shared Appium suite can assert SDK listener events (e.g. spec 13 notification click) on .NET, same as the Capacitor and React Native demos.

Scope

• New LogService (Info console only, Show/Error console + view). In memory only, max 100 entries, so every launch starts empty.
• New LogView control pinned under the app bar, above main_scroll_view. AutomationIds: log_view, log_entry_{index}, log_clear_button, log_toggle_button.
• SDK listeners log the spec's exact messages: notification id added to click/foregroundWillDisplay, push subscription change uses →/…, null for missing ids, lowercase bools.
• Remaining Debug.WriteLine calls moved to LogService.Info.
• Demo app only. No SDK changes.

Testing

Manual testing

Ran the shared Appium suite (run-all.sh --sdks=dotnet) against this branch:

• Android 17 (emulator): full suite, 34 passing.
• iOS (iPhone 17 simulator, iOS 26.5): specs 01, 02, 13 passing. A full-suite run stopped at a flaky "Notifications not ready" in spec 02 that passed on rerun.
• Confirmed spec 13's Notification click log assertions actually run (not skipped) on both platforms, including cold start, by temporarily making the missing-log-view branch throw.
• Manually toggled collapse/expand and clear on the iOS simulator.

Affected code checklist

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

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
• 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

🤖 Generated with Claude Code

[cursor]

Multi-model review

Reviewed with Claude Opus 5.5, GPT 5.6 Sol, and Grok 4.7. Demo-only sticky log view; no SDK changes.

Act on: none blocking.

Consider

• LogView subscribes to static LogService.Entries.CollectionChanged and never unsubscribes (3/3). MainPage is transient and CreateWindow builds a new one, so an Android activity recreate can keep the old visual tree alive and re-render into detached views. Subscribe/unsubscribe on Loaded/Unloaded.
• Info is console-only; only Show/Error populate the panel (3/3). Login/tag/send-notification and live-activity failure lines therefore never appear in log_entry_*. Fine if this matches the sibling demos — testers debugging those failures without a debugger will still need logcat.

Noted

• Full rebuild on every collection change; at the 100-entry cap each new line rebuilds twice (Opus+Grok).
• ScrollToEnd is async inside Dispatcher.Dispatch (async void) and only runs from SizeChanged, so a same-height rebuild at the cap may not scroll (Grok).
• Debug.WriteLine → Console.WriteLine ships emails/SMS/external IDs in Release (Opus).
• log_entry_{i} is 0-based oldest; the 100px viewport hides older rows from Appium unless it scrolls (same as the iOS/Android demos).

Dismissed

• Logging ActionId/Url on click events — not a regression; the old console lines omitted them too.
• Off-thread mutation of public Entries — LogService writers already marshal to the main thread.

  

_{Sent by Cursor Automation: PR Reviews}