[ios] Migrate all remaining native code
[notifications][ios] Scope notification identifiers (#12055)* create method to override request IDs * scope notification request IDs in Expo Go * add method to Presentation header file * r
[notifications][ios] Scope notification identifiers (#12055)* create method to override request IDs * scope notification request IDs in Expo Go * add method to Presentation header file * rename scoping methods to be more general (not just category IDs are scoped) * only scope emitterModule, handlerModule, and presentationModule in Expo Go
show more ...
[expo-notifications] Add yearly notification trigger (#11898)* [expo-notifications] Add yearly notification trigger * Update packages/expo-notifications/README.md Co-authored-by: Charlie Cruz
[expo-notifications] Add yearly notification trigger (#11898)* [expo-notifications] Add yearly notification trigger * Update packages/expo-notifications/README.md Co-authored-by: Charlie Cruzan <[email protected]> * Update packages/expo-notifications/src/scheduleNotificationAsync.ts Co-authored-by: Charlie Cruzan <[email protected]> * Update packages/expo-notifications/src/scheduleNotificationAsync.ts Co-authored-by: Charlie Cruzan <[email protected]> * Update packages/expo-notifications/src/scheduleNotificationAsync.ts Co-authored-by: Charlie Cruzan <[email protected]> * Changes because of PR comments * PR comments 2 Co-authored-by: Charlie Cruzan <[email protected]>
[expo-notifications] Add getNextTriggerDateAsync method for checking if calendar-based triggers are correct (#10455)# Why Could help debug https://github.com/expo/expo/issues/9996, I would even
[expo-notifications] Add getNextTriggerDateAsync method for checking if calendar-based triggers are correct (#10455)# Why Could help debug https://github.com/expo/expo/issues/9996, I would even say it fixes https://github.com/expo/expo/issues/9996. # How Implemented a native method that returns _next trigger date_ for notification trigger, allowing developers to debug their triggers definitions. # Test Plan Added tests to `test-suite` and test buttons to `native-component-list`.
[expo-notifications] Add weekly notification trigger (#9973)# Why In order to trigger a notification once every week on a given day, I added a `WeeklyNotificationTrigger` with this PR. This is not
[expo-notifications] Add weekly notification trigger (#9973)# Why In order to trigger a notification once every week on a given day, I added a `WeeklyNotificationTrigger` with this PR. This is not possible on Android with the current API. This PR is inspired by #8199 and is related to #9584. _Note: I think we should look into supporting the `CalendarNotificationTrigger` on Android. However, implementing and testing such a change is definitely not straightforward. Therefore I've implemented this trigger first because it is less complex and I need it for my client._ # How The `WeeklyNotificationTrigger` is implemented the same way as the `DailyNotificationTrigger` previously added by @thorbenprimke in #8199. # Test Plan I added two E2E tests and one unit test. However the E2E tests only test the first occurrence of the notification.
[expo-notification][ios] Add ScopedSchedulerModule (#8361)* [expo-notification][ios] Add ScopedSchedulerModule * [expo-notifications] Apply requested changes * [expo-notifications] Remove _No
[expo-notification][ios] Add ScopedSchedulerModule (#8361)* [expo-notification][ios] Add ScopedSchedulerModule * [expo-notifications] Apply requested changes * [expo-notifications] Remove _Nonnull attribute * [expo-notifications] Apply requested changes
[expo-notification] Adds DailyTrigger (#8199)# Why In order to trigger a local notification once per day, the `DailyIntervalTriggerInput` is being added with this PR. Previously there was no so
[expo-notification] Adds DailyTrigger (#8199)# Why In order to trigger a local notification once per day, the `DailyIntervalTriggerInput` is being added with this PR. Previously there was no solution that would allow this with the expo-notification library. It was possible on iOS but not Android. # How The daily interval uses the `TimeIntervalTrigger` on Android with a modified subsequent day trigger interval and on iOS it uses UNCalendarNotificationTrigger. # Test Plan Added two integration tests but those tests only verify first day event fire. We may want to remove these are they both take over 1 minute to run. If there are better solutions to verify the notification was scheduled properly, please let me know in the comments.
[expo-notifications] Fix interpretation of `Date` and `number` triggers on iOS (#7942)# Why Fixes https://github.com/expo/expo/issues/7937. # How `+(NSDate *)dateWithTimeIntervalSince1970:
[expo-notifications] Fix interpretation of `Date` and `number` triggers on iOS (#7942)# Why Fixes https://github.com/expo/expo/issues/7937. # How `+(NSDate *)dateWithTimeIntervalSince1970:` expects time interval to be provided in seconds. From JS we receive a `.getTime()` value which corresponds to milliseconds since 1970. Dividing by 1000 transforms milliseconds to seconds. # Test Plan I have added a test case that tests whether a notification scheduled with a `Date` trigger is triggered.
[expo-notifications] Unify types across the API
[expo-notifications] Deprecate `presentNotificationAsync` (#7497)# Why On iOS, calling `presentNotificationAsync` internally does `addNotificationRequest:` with a `nil` trigger, which makes the
[expo-notifications] Deprecate `presentNotificationAsync` (#7497)# Why On iOS, calling `presentNotificationAsync` internally does `addNotificationRequest:` with a `nil` trigger, which makes the notification request go all around and eg. trigger `willPresentNotification:`, etc. Thanks to a flexible architecture we can support presenting the notification, but it feels like allowing the developers not to set a notification handler which is highly encouraged (instead of relying on library defaults). I have talked with Bartek and Tomasz and we've decided that deprecating `presentNotificationAsync` while presenting a smooth path one can take to migrate to the new API may be the best option for now. # How - added `NotificationPresentationModule` as `NotificationCenterDelegate`s listener - `PresentationModule` holds a counted set of notification identifiers, if an identifier of the to-be-presented notification is in that set, the notification will be presented with all the presentation options - deprecated `presentNotificationAsync` by showing a warning message once per application run (when `__DEV__` is `true`). The warning message contains a link redirecting to https://github.com/expo/fyi/pull/2 # Test Plan `presentNotificationAsync` presents the notification even if there is no `setNotificationHandler` set.
[expo-notifications] Scheduling notifications (#7035)# Why Next feature! # How On iOS implementing this feature was fairly simple, all we needed was to expose methods triggering `add/get/r
[expo-notifications] Scheduling notifications (#7035)# Why Next feature! # How On iOS implementing this feature was fairly simple, all we needed was to expose methods triggering `add/get/removeNotificationRequests`, `UserNotificationCenter` took care of everything else for us. On Android however, we needed to implement `UserNotificationCenter` ourselves. The scheduling part of it is located in the new `ExpoNotificationScheduler` job intent service, which handles three types of intents: - `schedule` — extras should contain the notification request, enqueued by any scheduling module — the request is stored in persistent storage and an alarm triggering the notification is scheduled on `AlarmManager` - `remove` — extras should contain the ID of the request to cancel and remove — the request is removed from the storage and alarms are cancelled - `trigger` — extras should contain the ID of the request that is triggered — notification is fetched from the store, handed over to `NotificationsService` and rescheduled - `boot completed` — all known notifications are rescheduled (**note:** we could think about supporting [_Direct Boot mode_](https://developer.android.com/training/articles/direct-boot) if `SoLoader` would support it too. Unfortunately it does not, so there's not hard reason for us to do it.) The architecture looks more or less like this (elements relevant to this PR are left opaque)  An interesting part are triggers, which let us create a simple way to schedule notifications. At the moment there are 2 schedulable notification triggers: `DateNotificationTrigger` and `TimeIntervalTrigger`. The former one will trigger at one specific date and it will never repeat, the second one will trigger at time intervals from the date of creation (optionally repeating). This PR will also allow us to remove the NotificationPresenter module, since (as it is on iOS we can handle this case likewise on Android) presenting is scheduling with `null` trigger. It may look like this PR adds a little bit more of complexity to types with which the native side can communicate with JS, but that is not the case — we reuse the serializers already present on `master`. The one thing left, which I intend to do after all the major PRs land is to refactor the TS side (colocate relevant types, make the folder structure more hierarchical). # Test Plan Added a test suite covering this API, passing on iOS 13, Android 7 and 9 devices.