FeedTimeline, the main feed (Android): the posts, reels, ads and Explore
stories of the home tab. Its one request is the recorded feed/timeline wire
of the @igpapi/mobile brick — POST api/v1/feed/timeline/ with its form
and headers — sent once per page: by enter, by nextPage and by a
swipeToNext that ran out of loaded items.
Visible: one page — items, that page's posts, reels, ads and Explore
stories — and current, the post in focus. Actions:nextPage (the
instance of the next page, the feed's raw pagination; undefined at the
end), swipeToNext (the next item in focus across pages; undefined at the
end); an item's open leads where the item kind opens — a post to the post
screen, a reel to the reels viewer — and a post's like is the feed-surface
like.
The app keeps one post in focus, so this is a swipeable feed: an item enters
when it comes in front and leaves when the next swipe moves it away. No
recording gives the timeline's items an enter or leave of their own yet, so
both send nothing.
The opening is the screen's input: the launch declaration passes
cold_start (an absent opening means the same) and a later tab open passes
tab_open. The cold start is the recorded fetch: reason=cold_start_fetch
with is_pull_to_refresh=0, and the brick adds x-ig-app-start-request,
x-ig-accept-hint and the connection measurements only to that opening; a
later tab open reports a warm start. A page after the opening is
reason=pagination with max_id and carries none of those headers, although
the cursor keeps the opening's reason. The request id is made by the first
answer's request and rides on the answer into the state, so every later
page keeps it; start only names the reason. The first answer goes out
before the screen comes to front. The state is only the cursor of the next
page, continued by next_max_id.
The items' enter and leave send nothing: the app logs Pigeon impression and
view-time events for the post in focus, but no recording decodes them into a
preset yet. The screen emits no telemetry of its own.
FeedTimeline, the main feed (Android): the posts, reels, ads and Explore stories of the home tab. Its one request is the recordedfeed/timelinewire of the@igpapi/mobilebrick —POST api/v1/feed/timeline/with its form and headers — sent once per page: byenter, bynextPageand by aswipeToNextthat ran out of loaded items.Visible: one page —
items, that page's posts, reels, ads and Explore stories — andcurrent, the post in focus. Actions:nextPage(the instance of the next page, the feed's raw pagination;undefinedat the end),swipeToNext(the next item in focus across pages;undefinedat the end); an item'sopenleads where the item kind opens — a post to the post screen, a reel to the reels viewer — and a post'slikeis the feed-surface like.The app keeps one post in focus, so this is a swipeable feed: an item enters when it comes in front and leaves when the next swipe moves it away. No recording gives the timeline's items an enter or leave of their own yet, so both send nothing.
The opening is the screen's input: the launch declaration passes
cold_start(an absent opening means the same) and a later tab open passestab_open. The cold start is the recorded fetch:reason=cold_start_fetchwithis_pull_to_refresh=0, and the brick addsx-ig-app-start-request,x-ig-accept-hintand the connection measurements only to that opening; a later tab open reports a warm start. A page after the opening isreason=paginationwithmax_idand carries none of those headers, although the cursor keeps the opening's reason. The request id is made by the first answer's request and rides on the answer into the state, so every later page keeps it;startonly names the reason. The first answer goes out before the screen comes to front. The state is only the cursor of the next page, continued bynext_max_id.The items' enter and leave send nothing: the app logs Pigeon impression and view-time events for the post in focus, but no recording decodes them into a preset yet. The screen emits no telemetry of its own.