react-native: Dimensions.get('window') is not returning the current values on Android

Description

The width and height returned by Dimensions.get(‘window’) are not updating. The first time it’s called, it returns the correct values. But if I change the device screen orientation and call it again, it returns the same values as before. This only happens on Android, and only started happening after I upgraded from RN 0.62.2 to 0.63.0

React Native version:

0.63.0 Android only

Steps To Reproduce

Provide a detailed list of steps that reproduce the issue.

  1. Add an onLayout like this to a View in your app: onLayout={() => { console.log(Dimensions.get('window')); }
  2. Rotate the device and notice that the width and height printed to the console stay the same after each rotation

Expected Results

The width and height should update to reflect the new screen layout

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 23
  • Comments: 23 (4 by maintainers)

Commits related to this issue

Most upvoted comments

How is this issue still going on? How can such a popular framework not have a working Dimensions module?!

I can confirm. On Android the event listener won’t trigger on orientation change. It makes no difference if we use Dimensions.addEventListener('change', setWindowSize); or useWindowDimensions(). On iOS it still works

The fix for this is checked into the master branch (thank you @ajpaulingalls and @ejanzer) and will naturally make its way into the first react-native@0.64 release candidates. If you want it to be included in the future react-native@0.63.4 patch release, please upvote the comment linked below.

https://github.com/react-native-community/releases/issues/212#issuecomment-725612630

weirdly, when using useDimensions in this package the device orientation changes get detected…

@react-native-bot This is the really critical issue which breaks all Android orientation related styling in apps. When this can be reviewed by maintainers? Thanks…

This one is pretty mild, it has only been open for 3 months. There are outstanding bugs going on 4 years without solutions. There’s a lot of undocumented, inconsistent-across-platforms, or (especially on Android) broken stuff in RN. FB has developed somewhat of a reputation for subpar community management with this project. Many issues get closed without resolution or explanation. PRs linger for months or years. Long standing bugs never get fixed/merged because FB has closed internal workarounds. etc, etc.

I’m not complaining however, it’s free software, we can fork and fix it ourselves if the quirks bother us. It’s just a shame to see an innovative and otherwise great project like RN marred and slowed by seemingly indifferent maintainers.

As for a fix, I’ve found that many measurement problems on Android are corrected by doing two things:

  1. Add collapsible={false} to your views you plan to measure. Even if you have a ref on a view Android/RN will still “optimize” (remove) it leading to unexpected behavior
  2. Use a ref and the .measure function to get the measurement at the time you need it instead of relying on onLayout. Frequently onLayout doesn’t get called when expected or doesn’t return the values you expect because of animations or mounting behavior. Just be aware that .measure returns different values than onLayout. IIRC measure will give you the absolute pixel size on screen where onLayout gives you the untransformed original size (ex: if transform: [{scale: 2}] is on a view or any of it’s parents onLayout will give width: 50 and .measure will give width: 100)

I can confirm it is not working on android, but on iOS is it still ok. Using RN 0.63.2. Probably also happening on 0.63.3, I will try to update later.

This has broken my orientation-dependent rendering, I had to check the ‘screen’ dimensions to get the correct orientation change but I see a lag in the orientation layout change after device rotation of about 2-3 seconds (only on android).

Updated to 0.63.4 from 0.63.3, and confirmed fixed on Android.

@ws333 just tested, 0.64.2 still got #30371 though, going to bump it once again at 0.65 😩