[ios] Remove legacy notifications module code (#24325)

[iOS][Expo Go] Remove legacy screen orientation code (#14649)

Revert "[ios] Remove legacy ScreenOrientation code (#11371)" (#12217)

This reverts commit 454e16d504aee225b3bdc8ee3fedbbdc051c7209.

# Why

After #11371, `lockAsync` is broken in iOS Expo Go; it

Revert "[ios] Remove legacy ScreenOrientation code (#11371)" (#12217)

This reverts commit 454e16d504aee225b3bdc8ee3fedbbdc051c7209.

# Why

After #11371, `lockAsync` is broken in iOS Expo Go; it causes the current orientation to change but does **not** persist the lock, which causes various issues. Additionally, the app.json `orientation` setting has no effect either. Essentially, all apps are permanently locked to `DEFAULT` orientation.

# Test Plan

- [x] NCL tests pass
- [x] test-suite tests pass
- [x] app.json `orientation` setting has an effect

show more ...

[ios] Remove legacy ScreenOrientation code (#11371)

[android][ios] add support for development loads in expo-updates AppLoader (#9599)

# Why

Follow up to #9461 and #9523 . The development client's `AppLoader` classes are used to load manifests for

[android][ios] add support for development loads in expo-updates AppLoader (#9599)

# Why

Follow up to #9461 and #9523 . The development client's `AppLoader` classes are used to load manifests for both development and production bundles, but expo-updates is not intended to be used to load projects in development. We need to bypass expo-updates' caching and database layers for development mode loads.

# How

Unfortunately we cannot reliably determine before loading a manifest whether it is for a development or production mode project. Instead, I've added/expanded upon the ability of the calling class to abort a `LoaderTask` upon its cached/remote manifest callback being fired.

Now, the new ExpoUpdatesAppLoader classes will check for development mode at 3 separate stages -- 1) before starting the load, if the URL is clearly indicative of a project in development, 2) when the cached manifest is returned, and 3) when the remote manifest is loaded. If it determines at any of these three stages that it's trying to load a development mode project, it will abort the `LoaderTask` early and delegate to RN to load the development bundle, similar to how the current, non-expo-updates AppLoader classes in both clients work.

# Test Plan

Manual tests of loading a development mode project on both platforms, after enabling the ExpoUpdatesAppLoader class in Kernel.java/EXKernelAppRecord.m. Also ensured that loading production experiences did not break.

show more ...

Remove obsolete kernel service EXGoogleAuthManager (#5660)

[ios][android] Drop SDK 31 and 32 (#5381)

# Why

resolves: https://github.com/expo/expo/issues/5146

# How

Using `et rm-sdk` expotools command.

# Test Plan

Run NCL.

[expo-branch] First 3rd party library unimodule wrapper! (#5165)

We would like to provide a way to users to optionally include `react-native-branch` in their standalone apps. Fixes https://github.co

[expo-branch] First 3rd party library unimodule wrapper! (#5165)

We would like to provide a way to users to optionally include `react-native-branch` in their standalone apps. Fixes https://github.com/expo/expo/issues/5132.

I added support for React Native-specific unimodules to React Native adapter. Right now it works like this:

- unimodule `expo-branch` depends on `react-native`, so it can use its API. It's no longer a uni-platform module, more an optinmodule (I guess the name won't stick)
- we copy `react-native-branch` vendored module directly to the unimodule. It will compile, since we added necessary dependencies to the unimodule
- `BranchPackage < org.unimodules.Package` implements `ReactPackage` interface too, forwarding all the calls to the vendored `RNBranchPackage`.
- when the module registry provider creates a module registry from a list of `Packages`, it can filter out `ReactPackages` — and so it does, putting them into a local internal module (`ReactPackagesProvider`) which only purpose is to carry those to `ModuleRegistryAdapter` which is responsible for creating a list of React Native modules out of a module registry. The adapter grabs the `ReactPackagesProvider` and adds React Native modules to the list.

I have confirmed that adding `BranchPackage` to a list of installed unimodules' packages creates `RNBranchModule` and exports to JS.

show more ...

[expo-branch] First 3rd party library unimodule wrapper! (#5165)

# Why

We would like to provide a way to users to optionally include `react-native-branch` in their standalone apps. Fixes https://

[expo-branch] First 3rd party library unimodule wrapper! (#5165)

# Why

We would like to provide a way to users to optionally include `react-native-branch` in their standalone apps. Fixes https://github.com/expo/expo/issues/5132.

# How

I added support for React Native-specific unimodules to React Native adapter. Right now it works like this:

- unimodule `expo-branch` depends on `react-native`, so it can use its API. It's no longer a uni-platform module, more an optinmodule (I guess the name won't stick)
- we copy `react-native-branch` vendored module directly to the unimodule. It will compile, since we added necessary dependencies to the unimodule
- `BranchPackage < org.unimodules.Package` implements `ReactPackage` interface too, forwarding all the calls to the vendored `RNBranchPackage`.
- when the module registry provider creates a module registry from a list of `Packages`, it can filter out `ReactPackages` — and so it does, putting them into a local internal module (`ReactPackagesProvider`) which only purpose is to carry those to `ModuleRegistryAdapter` which is responsible for creating a list of React Native modules out of a module registry. The adapter grabs the `ReactPackagesProvider` and adds React Native modules to the list.

# Test Plan

I have confirmed that adding `BranchPackage` to a list of installed unimodules' packages creates `RNBranchModule` and exports to JS.

show more ...

[ios] Upgrade notifications framework to User Notifications Framework (#2316)

* Updated notifications

Moved new permissions files to packages

fix

updated yarn.lock

fixes

Requested cha

[ios] Upgrade notifications framework to User Notifications Framework (#2316)

* Updated notifications

Moved new permissions files to packages

fix

updated yarn.lock

fixes

Requested changes

fix after rabase

Made requested changes

Renamed UserNotificationCenterProxy classes

Run `pod install`

* Post-review fixes

* Minor JS fixes

* Do not remember pending notifications in Expo Client (behavior matching previous one)

* Prevent blocking main queue at all times by EXUserNotificationRequester

* Do not scope categories identifiers in ejected applications

* Apply review comments

* Remove obsolete if condition

* Do not store resolver and rejecter in EXUserNotificationRequester

* Update Pods

* Add support for deleting custom notification categories

* Pass notification to a remembered experience when tapped a notification in backgrounded Expo Client

* Update jest-expo mocks

* Ensure permissions consuming happens on permissions queue in EXRemoteNotificationRequester

* Do not scope notification identifiers

* Change cancelScheduledNotification into cancelScheduledNotificationAsync returning native Promise

* Deny scheduleNotificationAsync with both time and repeat set on iOS

* Allow scheduleNotificationAsync with both time and repeat set on iOS using deprecated UILocalNotification

* Add more notification testing buttons to NCL

* Export EXUserNotificationManager service as kernel service

* Add EXNotificationsIdentifiersManager protocol capable of scoping and unscoping identifiers

* Require both RemoteNotificationManager and UserNotificationManager in EXNotifications module

* Scope and unscope action identifiers by EXUserNotificationManager

* Update pods

show more ...

Register singleton modules with a macro (#2914)

* [ios] Register singleton modules with macro

* [ios] Singleton modules fixes:

- move EXPermissionsManager to expo-permissions package,
- remove sha

Register singleton modules with a macro (#2914)

* [ios] Register singleton modules with macro

* [ios] Singleton modules fixes:

- move EXPermissionsManager to expo-permissions package,
- remove sharedInstance from EXSingletonModule
- add name argument to EX_REGISTER_SINGLETON_MODULE
- add singleton modules to EXHomeAppManager

* [ios][expo-core] Remove obsolete variable definition

* [ios] Remove EXSingletonModule references from EXModuleRegistry and EXModuleRegistryProvider

* [ios] Add EX_EXPO_CLIENT macro definition

* [ios] Remove EX_EXPO_CLIENT preprocessor definition in favor of setting SupportsAppMultiplexing in Info.plist

* [ios] Suppress warnings about not being able to call -name on EXSingletonModule classes instances

* [ios] Update pods

fbshipit-source-id: 3cf91c0

show more ...

make modals play well with expo menu (#2379)

fbshipit-source-id: 251bdc0

Permissions per experience (#2161)

* [android] Permissions module - ask for permissions per experience

* [android] Do not check/request permissions on the native side; customize the perm dialog

*

Permissions per experience (#2161)

* [android] Permissions module - ask for permissions per experience

* [android] Do not check/request permissions on the native side; customize the perm dialog

* [expo-sdk] Check permissions before invoking native method

* Revert "[expo-sdk] Check permissions before invoking native method"

This reverts commit f20c90d7622ec00d206a7e116f70f5c63714e1e0.

* [android] DO check permissions on the native side but do not request

* [ios] Scoped permissions - wip

* [ios] Proper perm in dialog; save user defaults correctly

* [ios] Check permissions when required

* [ios] Review updates

* [ios] Multiple kernel services fixes

* [android] Permissions per experience for Android < M

* [android] Change shape of permissions in metadata; further refactor for older Android APIs

* [android] Apply changes to previous SDKs

* [ios] Apply changes to previous SDKs

fbshipit-source-id: 328961f

show more ...

Updates module (#2203)

fbshipit-source-id: 477c902

OTA Updates improvements (#1925)

* [android] fetch updated manifest on launch and allow specified amount of time to do this before populating experienceactivity

* [android] only consume response on

OTA Updates improvements (#1925)

* [android] fetch updated manifest on launch and allow specified amount of time to do this before populating experienceactivity

* [android] only consume response once in onCachedResponse

* [android] removed CountDownTimer in favor of Handler.postDelayed

* [WIP][android] moved all new manifest loading code to new methods with AtomicBundleListener rather than ManifestListener

* [android] moved JS bundle loading to before populating experienceactivity

* [android] refactored most of the new logic into its own AtomicBundleListener class per conversation with Jesse

* [ios][wip] beginning ios changes

* [ios] WIP

* [ios] more wip, have full manifest-fetching logic in AtomicBundleManager

* [ios] reverted changes to bridgeRecord in favor of creating new AppRegistry and AppRecord classes; will eventually refactor everything to use these rather than BridgeRegistry; getManifestAsync now uses AtomicBundleManager for fetching manifest

* [ios] wip, start on bundle loading

* [ios] wip wip wip. not sure how much of the logic to be moving from EXFrameReactAppManager to new class - maybe should keep _jsResource logic in original

* [ios] bundle loading now working from atomic bundle manager

* [ios] renamed new class to AtomicBundleLoader to avoid using word Manager

* [ios] trying to get reloading to work again; there is some weird issue with objc/js communication but going to save it for later

* [ios] wip with adding js bundle loading into timeout - currently just setting a timeout directly on the request

* [ios] bundle loading part of timeout

* [ios] renaming methods to use underscore prefix

* [ios] fully replace EXKernelBridgeRegistry and BridgeRecord with AppRegistry and AppRecord

* [ios] refactor request bundle method to use FrameReactAppManager as delegate

* [ios] renamed AtomicBundleLoader to AppLoader per Ben's suggestion

* [ios] step 1 in resolving reloading issue

* [ios] fix reloading on ios -- now using a UUID to identify record rather than manifestUrl, and we enforce uniqueness after the entire manifest/bundle is loaded to give time for the other record to be removed. Also, changed _appRegistry to an NSMutableDictionary, since NSMapTable was no longer needed and NSMutableDictionary is easier to copy -- safer since we're mixing mutations & enumeration more.

* [ios] a couple more fixes to make sure we're handling possible duplicate AppRecords properly

* [ios] better handling of various cases with possible inconsistencies/network errors

* [ios] add loadedFromCache key to manifest

* [ios] separated resolveWithCachedManifest and resolveWithCachedBundle to avoid situation where resolveWithCachedManifest is called with an error after manifest _finished == YES and therefore bundle never gets fetched

* [android] added loadedFromCache key to manifest, not sure why it's always false...

* [android] loadedFromCache manifest key working now

* [android] prevent onManifestCompleted from being called twice

* [ios] EXKernelAppLoader - control downloading bundle entirely, and don't resolve with manifest until after bundle has been downloaded successfully

* [ios] removed now obsolete EXKernelBundleLoaderDelegate methods

* [home] first step in loading progress fix - move manifest and bundleUrl fetching to a separate flux action, and allow a BrowserScreen to be mounted to show loading progress before manifest is fetched

* [ios][home] bundle loading progress now showing; need to show assets/icon properly, and resolve occasional crash when bundle download reaches 100%

* [home] fixed missing icons and name in project history

* [ios][home] send new manifest optimistically to JS as soon as we receive it so that JS can show the correct icon and background color on loading screen

* [home] moved some logic from BrowserActions to Browser to try and keep actions more pure

* [ios] fix for opening client from a notification - previously an EXKernelAppRecord was never created in this case. Might want to think about only ever creating AppRecords when the manifest is requested

* [home] improve safety/handling of optimisticManifest

* [home] fix for standalone apps where props.task is initially null

* [ios] pass recordId into frame so it can use this to unregister itself safely instead of trying to iterate through all of the records to find a potentially non-unique experienceId. Also, register AppRecords when manifest is requested as there is no reason for them to exist before this

* [ios] add new EXCachedResourceBehavior to never read from the cache but make sure we are always writing to it

* [android] don't send manifest or bundle until we have either downloaded a new bundle or timed out

* [android] only write the manifest that we are actually using to shared preferences

* [android] correct loadedFromCache value (again)

* [android] fix loading icon and progress for dev mode - don't try and download the bundle in exponent code

* [android] send optimistic manifest to ExperienceActivity as soon as we download it so that the activity can display the proper loading screen/icon/task info

* [android] use AtomicBundleListener for detached and shell apps as well

* [android] make sure that AtomicBundleListener is the only thing that is calling loadJSBundle (for non-kernel bundles)

* [android] fix opening detached apps after the first run

* [android] improve handling of failures

* [home] stop accidentally swallowing errors wfrom fetching manifest on iOS

* [ios] clean up stopTimer usage, as anytime we call _resolve we don't want to call it again

* [ios] simplify timeout on JS bundle fetching - since the NSTimer will take care of resolving anyway, we don't need to set the timeout on the JS bundle request based on the timer

* [android] renamed AtomicBundleListener to AppLoader as this is a better description of what it does

* [server] updated unversioned schema with new app.json fields

* [ios][android] make sure to only fetch remote manifest if the shouldCheckForUpdate is true

* [android] if in dev mode, skip the cached manifest + set timer step and just go fetch the remote manifest every time

* [ios][android] stop making bad assumptions -- if a cached manifest exists, it is possible that the corresponding bundle does not exist for some reason, and in this case we should download rather than failing to user

* [ios] resolved first cycle of ben's comments

* [ios][home] resolved some of ben's 2nd round of comments

* [ios] resolved most of ben's 3rd round of comments'

* [ios][server] resolved a few more comments

* [ios] added status enum property to EXKernelAppRecord & so that kernel services can skip over any AppRecords which are partially loaded

* [ios] add todo to get rid of lazy copy workaround

* [android] resolve jesse's comments

* [android] store loading errors in ExponentSharedPreferences, and make sure that we always try to load a new manifest + bundle if this is set to true when loading experience

* [ios] resolved last of Ben's comments, including adding a way for AppRecord to be notified when bridge has successfully loaded JS

* [schema] mark loadJSInBackgroundExperimental as deprecated

* [android] fix loading apps for the first time in dev mode

fbshipit-source-id: 4d763d0

show more ...

Improve assets bundle runtime implementation, support most asset types (#1691)

fbshipit-source-id: d3045f7

Move EXKernelModuleDelegate into separate kernel module service

fbshipit-source-id: 3c5c0112cd

Formalize `EXKernelService` protocol, allow services to listen to bridge lifecycle of all apps

fbshipit-source-id: 20d02633d2