The viewer's own profile (SelfFragment:self_profile, Android 451), the
account's profile tab. It shows the viewer themself — the avatar, name and
counters, the story ring, the media grid — and it takes no input: the target
is MobileSession.dsUserId, so no caller can show another user under the
self_profile module or the self follow status. The handle keeps the
viewer and the typed failures of the enter's background requests; how the
answers are rendered is unverified (the recording's screenshot shows a grid
that no request of the run loads), so the screen invents no surface.
It is reached from the feed's tab bar (FeedTimelineScreen.openMyProfileTab,
source main_profile), and its openFeedTab is the tab bar's way back. The
tab's first entry starts its chain (SelfFragment:self_profile:2:main_profile)
and the enter's burst opens the media tab with it
(ProfileMediaTabFragment:self_profile:3:button). Opening the tab again from
the feed is a resume: the recording's second visit sends no burst and adds no
chain entry, only the resumed media tab's last-shown stamp.
The visit's telemetry is the app's own: an impression_add_banner and an
action: exit, written together when the profile stops being in front
(leave), both carrying the visit's chain — never on enter or resume.
Every event of the recording names the viewer, the process's tray session as
story_ranking_token, and the visit's id as profile_session_id (the
Android 451 recording: two visits of one process, two pairs; see
screens.profile.telemetry.ts).
Its recorded actions are named, not modelled: tap_grid_post ×3,
tap_followers ×2, swipe, impression ×3, impression_username,
impression_settings and tap appear in the recording, but no screen of this
package renders their targets yet, so they stay unmodelled here rather than
being attached to a surface that does not exist.
Unverified, and kept out on purpose:
the media grid's content: the recording's screenshot shows a grid but no
request of the run loads it, so no request is invented for it;
the viewer's Facebook id: the school badge asks with the empty id, because
the session does not hold it (the recording's request names the viewer's
Facebook id). A recording whose window reaches the launch answer the app
learns it from is what closes this;
the text_feed/ig_text_post_app_new_activity_feed_count/ requests: two on
the first tap and one on the second, each reporting the screen in front,
and another recording sends the same request from the contextual feed, the
followers list and the clips viewer. It is the app's activity counter on a
transition, not this screen's request, and what it is keyed to is not
observed, so none is modelled here;
the media tab's second onboarding-checklist request: it repeats the first
0.75 s later with the same endpoint and chain, and the recording carries no
responses, so whether it is a retry or a second trigger is not observed; the
screen sends the two the recording sends, one after the other;
how the answers of the burst are rendered: the ayml suggestions, the
onboarding checklist, the creators trial and the monetization checks are
sent, and their failures kept, but the screen's data keeps only the viewer
and the failures.
No screenshot ships with this screen: the only recorded frame is the
account's own profile, whose data is not published.
The viewer's own profile (
SelfFragment:self_profile, Android 451), the account's profile tab. It shows the viewer themself — the avatar, name and counters, the story ring, the media grid — and it takes no input: the target isMobileSession.dsUserId, so no caller can show another user under theself_profilemodule or theselffollow status. The handle keeps the viewer and the typed failures of the enter's background requests; how the answers are rendered is unverified (the recording's screenshot shows a grid that no request of the run loads), so the screen invents no surface.It is reached from the feed's tab bar (
FeedTimelineScreen.openMyProfileTab, sourcemain_profile), and itsopenFeedTabis the tab bar's way back. The tab's first entry starts its chain (SelfFragment:self_profile:2:main_profile) and the enter's burst opens the media tab with it (ProfileMediaTabFragment:self_profile:3:button). Opening the tab again from the feed is a resume: the recording's second visit sends no burst and adds no chain entry, only the resumed media tab's last-shown stamp.The visit's telemetry is the app's own: an
impression_add_bannerand anaction: exit, written together when the profile stops being in front (leave), both carrying the visit's chain — never onenterorresume. Every event of the recording names the viewer, the process's tray session asstory_ranking_token, and the visit's id asprofile_session_id(the Android 451 recording: two visits of one process, two pairs; seescreens.profile.telemetry.ts).Its recorded actions are named, not modelled:
tap_grid_post×3,tap_followers×2,swipe,impression×3,impression_username,impression_settingsandtapappear in the recording, but no screen of this package renders their targets yet, so they stay unmodelled here rather than being attached to a surface that does not exist.Unverified, and kept out on purpose:
text_feed/ig_text_post_app_new_activity_feed_count/requests: two on the first tap and one on the second, each reporting the screen in front, and another recording sends the same request from the contextual feed, the followers list and the clips viewer. It is the app's activity counter on a transition, not this screen's request, and what it is keyed to is not observed, so none is modelled here;No screenshot ships with this screen: the only recorded frame is the account's own profile, whose data is not published.