Asked for twice on Zapstore by two different users: more than the next 5
events, and future events rather than only today's. Four independent caps
had to move, since lifting any one alone changed nothing.
Cache: readUpcomingEvents was fixed at 3, so only 3 future events ever
reached either platform no matter how much room the widget had. Now 10,
and each widget takes the prefix that fits.
Android: the layout carried 5 static row slots and ROW_COUNT matched. Now
10 slots, and how many are usable is decided by HEIGHT rather than a fixed
count. RemoteViews clips silently rather than reporting an overflow, so a
flat count would either clip the last row (when rows carry a location and
render two lines) or waste space (when they don't). The fill accumulates
each row's estimated height instead. The height comes from the portrait
figure the host reports (OPTION_APPWIDGET_MAX_HEIGHT; MIN_HEIGHT is the
shorter landscape one, and budgeting off it showed a single row on a real
device). onAppWidgetOptionsChanged redraws on resize. maxResizeHeight went
from 220dp to 400dp, which is what makes the extra slots reachable; the
default 3x2 placement size is unchanged.
iOS: added .systemLarge, which reuses MediumView with a rowBudget of 10
rather than forking the view. Small and medium keep 3 and 4.
Not addressed, deliberately: the reporter asked to scroll the widget. On
Android that needs a collection widget, a rewrite of the receiver. iOS
widgets cannot scroll at all, so .systemLarge with more rows is the whole
of what that platform can offer.
Verified on a TCL (real hardware): default 3x2 shows a clean 5 rows plus
"+ 1 more" with no clipping, and a resized-taller instance shows the full
10 (6 today events plus 4 upcoming across future days). iOS widget target
builds on the Mac Mini simulator SDK.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017LpNS8m7XcRcmAKvv9ed3c
Your NameandClaude Opus 4.8
28fbf51371