Repository navigation
Give the activity log room on a short viewport - #92
Merged
Merged
Conversation
The log card was 0dp pinned between the buttons and the bottom of the parent, so it took whatever was left over. On a 1080-tall landscape screen that was 150 units — about one row — with no way to scroll to the rest of the history. Measured, not assumed: the same card was 83 units before the status card shrank. The stack is now inside a NestedScrollView with fillViewport, and the log keeps a 180dp minimum. A tall viewport still fills it, because fillViewport stretches the child and the weighted card takes the remainder; a short one scrolls instead of crushing it. Verified on a device in both orientations. In landscape the log now shows entries where it previously showed one, and in portrait the card fills the remaining height as before.
🤖 Automated Code Review |
rossigee
added a commit
that referenced
this pull request
Oct 6, 2026
- versionCode 8, versionName "2.2.1" - New changelog entry documenting the post-2.2.0 fixes: - Activity log height in constrained viewports (PR #92) - Release checklist no longer leaks Zapstore internals (PR #94) - zapstore-publish prerequisite (v1.0.3 + @v1 update) already shipped so the 30 s timeout and documented fallback are live for this release.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The defect
The log card was
layout_height="0dp"pinned between the buttons and the bottom ofthe parent, so it received whatever vertical space was left over.
Measured on a device in landscape (1080 tall): 150 units — about one row, with no
way to scroll to the rest of the history. Before the 2.2.0 status card replaced three
counters it was 83 units, so the redesign improved it but did not solve it. The
constraint itself was correct; the problem is that a short viewport has nothing left
to give.
The fix
The stack now sits in a
NestedScrollViewwithfillViewport="true", and the logcard keeps a
minHeightof 180dp alongside its weight.fillViewportstretches the child to the viewport, andthe weighted card takes the remainder — the log fills the screen exactly as before.
content exceeds the viewport and the page scrolls instead of squeezing the log to
one row.
Root converted from
ConstraintLayoutto a verticalLinearLayoutinside the scrollview. A
0dp-height child constrained to both top and bottom inside awrap_contentparent is circular, andConstraintLayoutdoes not resolve thatpredictably;
LinearLayoutweights with aminHeightdo.Verified on a device, both orientations
Also verified while I had the device
Two things from the 2.2.0 release that I had only checked in bytecode:
text, and tapping Cancel leaves the cache untouched — verified with a cleared
log: zero
Cache cleared successfullyentries before and after. Clear All doesfire it.
438 messages have no cache entryat12:56:39 and not again on either later launch, which is the repeat-suppression
working.