* chore: upgrade testing project to RN 0.62.x
* add placeholder flow script for CI
* update jet to fix iOS issue
* revert typedoc version (latest version not working)
* add `react-native-port-patcher` back in - port still being ignored by RN so patching manually
* add `react-native-port-patcher` back in - port still being ignored by RN so patching manually
* temporarily use iphone x for detox until CI servers upgraded
* -
* Update package.json
* Update on.e2e.js
* Update orderByValue.e2e.js
* Update on.e2e.js
* Update init.js
* -
* docs: update database usage with switching database URL
I struggled a while with finding out how to switch the database URL for the [DEFAULT] firebase instance during runtime.
With version 5 it was very easy with simply passing the databaseURL to the database module.
The docs did not help unfortunately, so I tried a lot of ways which are documented in this ticket:
https://github.com/invertase/react-native-firebase/issues/3049
This PR shall help other people with the same situation too.
Furthermore, I hope to get valid feedback if the proposed implementation documented in this PR is actually correct.
* refactor: move section above firebase.json
* refactor: change section title
* refactor: remove title, fix typo
* refactor: fix typo
* refactor: feedback from review
First pass at addressing #3253 to allow release in 6.4.0. For v7.0.0 we should make the default value true along with the RN min version set to 0.61.x +
* feat(storage): snapshot prop on Task. put is Task
* removed this._task from StorageReference
* Apply suggestions from code review
not awaiting promise
Co-Authored-By: Mike Diarmid <mike.diarmid@gmail.com>
Co-authored-by: Mike Diarmid <mike.diarmid@gmail.com>
* Don't abort registerForRemoteNotifications
The native call to `registerForRemoteNotifications` shouldn't be aborted even if `isRegisteredForRemoteNotifications` returns `true`. This is because after successful registration on the first boot, on successive boots the app `isRegisteredForRemoteNotifications` will return true, and then `registerForRemoteNotifications` won't be called again and therefore the APNSToken will never be set (because it is only set on the `didRegisterForRemoteNotificationsWithDeviceToken` swizzled by the `FIRMessagingRemoteNotificationsProxy`)
* Set APNSToken on didRegisterForRemoteNotificationsWithDevicetoken
This is what `FIRMessagingRemoteNotificationsProxy` does, and doing it here seems to avoid the race condition caused by `didRegisterForRemoteNotificationsWithDeviceToken` here being executed first and resolving the promise before the token is set (at least on iOS 12). It doesn't do any damage anyway to do it here first anyway.
Co-authored-by: Russell Wheatley <russellwheatley85@gmail.com>
