react-native-device-info: Required dispatch_sync to load constants for RNDeviceInfo. This may lead to deadlocks

Still an issue on RN v0.56.0

@compojoom move the libRNDeviceInfo.a to the bottom of linked frameworks and libraries

I think I found how to resolve this issue: the issue is caused by the fact that the module requires the main queue (https://github.com/rebeccahughes/react-native-device-info/blob/master/ios/RNDeviceInfo/RNDeviceInfo.m#L31) while the app’s loading, it seems to be wrong for some reason so we need the requiresMainQueueSetup to return NO.

Unfortunately doing so would cause a crash since when the lib loads it needs to be in the UI Thread because it silently instantiate a UIWebView to get the device User Agent.

IMHO we should defer this task and transform the userAgent field into a getUserAgent method (like isPinOrFingerprintSet and getBatteryLevel), it would allow us to achieve lazy loading for this property, solving this issue.

@machour do you think it would be ok if I submit such a PR? NB: it would be a breaking change since the new iOS method would return a promise, according to you, what is preferable between the two scenarios:

• I do this in iOS only and replace the current getUserAgent() returned value with something like “please use getIOSUserAgent()” so it avoids a breaking change in current API?
• I do the same thing in Android to keep the two implementations in sync and it replaces the current getUserAgent() behaviour for both platforms, switching the returned type from string to Promise<string>?

Warning still there. React Native 0.57.4

Warning still there. React Native 0.57.3

Updating the library or moving the libRNDeviceInfo.a to the bottom of linked frameworks and libraries did not help in my case

Thanks, @haystome - your note lead me to update the library to the latest, 0.15.3 (updated from 0.14.0), and it worked!

Not sure what version or commit fixed the problem, but for me it’s working on 0.15.3 after updating and then un-linking and re-linking the library. Output:

$ react-native unlink react-native-device-info
Scanning folders for symlinks in <path>/node_modules (214ms)
rnpm-install info Unlinking react-native-device-info android dependency 
rnpm-install info Android module react-native-device-info has been successfully unlinked 
rnpm-install info Unlinking react-native-device-info ios dependency 
rnpm-install info iOS module react-native-device-info has been successfully unlinked 

$ react-native link react-native-device-info
Scanning folders for symlinks in <path>/node_modules (26ms)
rnpm-install info Linking react-native-device-info android dependency 
rnpm-install info Android module react-native-device-info has been successfully linked 
rnpm-install info Linking react-native-device-info ios dependency 
rnpm-install info iOS module react-native-device-info has been successfully linked 

This warning only appears when we call a function from the RNDeviceInfo module in our initial render stage.

I’m guessing this has something to do with the synchronous nature of the call (in our case: ‘getUniqueID’), resulting in the whole app locking up until the function returns.

Warning still there. React Native 0.57.3

Same here 😦

Module RNDeviceInfo requires main queue setup since it overrides `constantsToExport` 
but doesn't implement `requiresMainQueueSetup. In a future release React Native will default 
to initializing all native modules on a background thread unless explicitly opted-out of.

RN: 0.57 react-native-device-info: 0.22.5

Issue is still present in 0.21.4.

Same here. React Native 0.57.7

For me the YellowBox is now showing this warning since I upgraded from RN 0.55.4 to 0.56.

@machour PR #442 is ready to be tested, I didn’t modify the changelog since I don’t know what you want to do with the semver (I guess the changelog will have to be modified in the process). I integrated the new way of getting user agent @maxkomarychev suggested

+1

RN 0.48.4

There is also this warning in console:

Module RNDeviceInfo requires main queue setup since it overrides `constantsToExport` 
but doesn't implement `requiresMainQueueSetup. In a future release React Native will default 
to initializing all native modules on a background thread unless explicitly opted-out of.

@psegalen can we bring back requiresMainQueueSetup to return YES?

I see no problem with module being initialized on main thread in general.

The bigger problem is to have dispatch_sync called with main thread from main thread. Which I’m assuming what was wrong with webview operation - which we solved.

looks like we have a solution in #442, great job @psegalen !

Also the current way of getting user agent is now deprecated. New version is async: https://developer.apple.com/documentation/uikit/uiwebview/1617963-stringbyevaluatingjavascriptfrom?language=objc

Hi @psegalen, by all means yes. This will be a bc breaking release though, we’ll need to semver that properly

@antoinerousseau did you tried to ullink and link the pakges? see this and this