Revision Date Author Comments
# 8285c032 13-Aug-2021 Tomasz Sapeta <[email protected]>

Rename unimodules imports to expo-modules-core


# 1037e824 14-Nov-2020 Stanisław Chmiela <[email protected]>

[expo-notifications] Add useLastNotificationResponse hook (#10883)

# Why

Idea inspired by @cruzach sounded! https://github.com/expo/expo/pull/10811#pullrequestreview-518819031

# How

- Since

[expo-notifications] Add useLastNotificationResponse hook (#10883)

# Why

Idea inspired by @cruzach sounded! https://github.com/expo/expo/pull/10811#pullrequestreview-518819031

# How

- Since there will be two hooks now that depend on the notification response listener being registered in the global scope I moved it to a `SharedNotificationResponseListener.fx.ts` file
- Changed `useInitialNotificationResponse` implementation to rely on it
- Added the ability to listen for incoming responses to the shared listener
- Implemented `useLastNotificationResponse` which is like a notification response swiss knife:
- if registered early enough judging by its return values states you can deduce whether there was this special "initial notification response" or not
- always returns the latest notification response received (or something falsy, depending on whether you care about the "initiality" or "initialness" of the response you can ignore the difference between `undefined` or `null` or not)

Frankly speaking I'm not 100% sure how big of a deal is leaving a dangling listener active, but I can't think of any reason why it would be a problem.

# Test Plan

I have verified this hook returns latest notification response if the hook is mounted as (early in the app as possible and after some time from starting the app) ✖️ (the app is started in response to notification tap, notification tap while the app is running)

show more ...


# db1c4130 19-Jun-2020 Stanisław Chmiela <[email protected]>

[expo-notifications] Add preliminary "support" for Web (#8853)

# Why

Even though we don't support Web in `expo-notifications`, we don't want to be a pain to the users and throw errors just becaus

[expo-notifications] Add preliminary "support" for Web (#8853)

# Why

Even though we don't support Web in `expo-notifications`, we don't want to be a pain to the users and throw errors just because of running the code on Web.

# How

Added simple object fallbacks for missing modules on web so that they are queryable by
```ts
if (!Module.methodAsync) {
throw new Unavailability…
}
```

Swapped `.ts` + `.web.ts` for `.native.ts` + `.ts` (or + `.web.ts` + `.ts` where it made sense, eg. if we would need to use `localStorage` inside the `.ts` file I renamed it to `.web.ts` and added an empty fallback in `.ts`).

# Test Plan

- [x] Ran NCL in `bare-expo` on Web, clicked buttons around, noticed the error is readable and makes sense.
- [x] Ran `expo-notifications` test-suite on both iOS and Web. It seems iOS tests are a little bit flaky, unfortunately (the errors could also happen due to erroring Expo API, HTTP error 504 when fetching push token, but I was able to make all of the tests pass just refreshing).

show more ...