Reset to default
Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.
It falls back to sorting by highest score if no posts are trending.
The documentation on Dimensions is quite poor (outstanding issue), so you’ll have to dive into the code to understand what is going on. If you look at the source of Dimensions, you’ll see this comment on line 47:
// Screen and window dimensions are different on android
If you trace back the history using blame, you’ll find this commit on the relevant section of code pointing to this old issue which itself points to this issue about Dimensions reporting different screen heights.
I don’t know enough about Android itself, but from what I can gather, it appears that Android can report back two different numbers:
- width/height with soft menu bar
- width/height without soft menu bar (so the actual entire screen)
A quick test on my Android device printing out these values and I was able to confirm that
window‘s height <
screen‘s height. So in all likelihood, this means:
window: reports width/height without the soft menu bar
screen: reports entire screen’s width/height
I didn’t follow back this product pain about orientation changes on Android, so I don’t know how rotating your screen affects this.
window reflects the section of the total
screen made available for this app. In most cases, width and height for
window will be the same size or smaller than
There are at least 3 cases where
window may be different:
If an Android device has the device navigation bar visible, the
windowheight (or width when landscape) will be lower than
screenheight by the height of the navigator. This is illustrated in this answer by RY Zheng which was linked to in an answer to this question which got deleted.
Example image of an Android system navigation bar from developer.android.com:
If the app is shown in Android’s split screen/multi-window mode, with windows for two apps side by side,
windowwidth or height will be lower than for
screenand will give the width or height allocated for that app’s window. This would have been documented by this PR by ThisIsMissEm, but it was closed by Facebook because no-one from Facebook got around to reviewing it.
Example illustration of Android multi-window mode from developer.android.com:
If an Android device had “screen zoom” or “display size” setting changed in Accessibility settings while the app was open, the
windowwill update to reflect the zoom but the properties for
screenwill not. If the app is restarted, the
scaleproperty will match that of the screen.
If an element with fixed dimensions fails to scale on changing screen zoom without restarting the app, multiplying those dimensions by
Dimensions.get('window').scale / Dimensions.get('screen').scalemay help.
Example image of the Display Size accessibility settings UI from androidpolice.com:
So, width and height for
window are usually the same size, or, sometimes on Android, smaller than
There’s only one exception I’m aware of where
window may give values larger than
screen: if the app was opened with “display size” or “screen zoom” accessibility setting set high, then, this was set lower with the app still open. In this case the height and width will be greater and the
scale will be lower by the same ratio. I suspect this may be a bug in React Native rather than an intended behaviour and may change in a future release.