How many photos in a row may fail before we stop skipping and make the user acknowledge it. Bounds the wholesale-failure case (for example, no server URL): random mode has no end-of-list stop, so an unbounded skip would cycle silently forever.

onDestroy: Full teardown releasing all resources before component removal Called automatically via JRScreen.beforeViewClose when sgRouter permanently closes this view.

isRandom component field has changed

isSlideshow component field has changed

JRScreen hook. Used to ensure tasks are stopped

The router creates this view; its launch data arrives as route.context (set by JRScene.onPhotoLaunchRequested). Apply it on first mount, setting itemIndex LAST so onItemContentChanged fires with itemsNode/itemsArray + slideshow flags already in place. itemIndex defaults to -1, so this runs once (subsequent shows are no-ops).

Render the resolved photo, or handle an unresolvable one. Nothing else draws on this screen (no title, no overhang; see PhotoDetails.xml), so a failed photo shows the user nothing new; the previous frame stays up, or black on the first one. During a slideshow we therefore toast and advance rather than stalling on a frame they never chose, and after MAX_CONSECUTIVE_PHOTO_FAILURES we stop advancing so a wholesale failure can't cycle silently.

A toast rather than a blocking dialog: a modal interrupts a slideshow the user is passively watching, which is the wrong shape for a per-item failure. (An older reason, that the dialog's roFontRegistry can't be created on the render thread, was disproved on device: see docs/architecture/threading.md.) Toast goes through the scene's showToast, which is only field writes.