Adds support for swiping left/right on some types of notifications. Swiping left
(from left to right) shows a blue button allowing the user to mark the
notification as read/unread. Swiping right (from right to left) shows a red
button, allowing the user to delete the notification for good.
Related PR in status-go https://github.com/status-im/status-go/pull/3201.
Fixes https://github.com/status-im/status-mobile/issues/14901
Fixes https://github.com/status-im/status-mobile/issues/14900
Technical notes
===============
How's the performance? It feels near native performance in a production release
in a mid-range smartphone. So I'd say it's pretty good, but let me know if you
find any issue.
- I refrained from trying to eliminate all code duplication in this PR. Some
notifications will behave differently, especially the ones with call to
action, so I ask you to please take that in consideration when reviewing. See
https://github.com/status-im/status-mobile/issues/15118
- React Native Gesture Handler has a component named
[Swipeable](https://docs.swmansion.com/react-native-gesture-handler/docs/api/components/swipeable/).
I used it instead of writing a monstrosity 👹 of code in
Reanimated to achieve the same results.
- RN Gesture Handler touchables are the only ones that work with the Swipeable
component, so I used them and added vars to `react-native.gesture`.
- I had to manually interpolate the translation X of the buttons behind
notifications because notifications are transparent. To make interpolation
work with `Swipeable` it's mandatory to use RN `Animated.View` and not
`Reanimated.View` (see next point).
- `Swipeable` expects us to pass functions that will receive RN
`AnimatedInterpolation` instances and the rendering lifecycle does not work as
usual. Hooks didn't trigger as expected, functional Reagent components didn't
behave as expected, etc. This means `Reanimated.View` and its interpolation
function is out of question. I did try for almost two days, nothing works.
Testing notes
=============
These are some of the manual tests I ran. There are more scenarios to cover
obviously. Assuming no unread notifications before each flow:
Contact request notification
============================
From the perspective of an user A:
1. Receive a contact request from a non-mutual contact B.
2. Verify the unread count is displayed over the bell icon.
3. Verify the unread count is displayed on the `Messages > Contacts` tab, as
well as on the AC `Contact requests` tab.
4. Open the AC and before accepting/declining the contact request, check that
you CAN'T swipe left or right.
5. Accept or decline the contact request.
6. Check the unread indicator disappears in all necessary places.
7. Press on the notification and see if you're redirected to the chat.
8. Go back to the AC and swipe left to mark as `Unread`. Notice that opening the
chat marks the notification as `Read`. Also very important, notice that the
`Messages > Contacts` tab will NOT show the *pending contact requests*
section at the top. This is on purpose, given the notification is unread, but
the user has already accepted/declined the contact request, hence it's not
pending.
9. Swipe left againg to mark as `Read`. Check all unread indicators are updated.
10. Swipe right to delete the notification (it won't be displayed ever again).
Admin notification
==================
1. Generate an admin notification, e.g. a community owner receiving a request
notification to join.
2. Verify the unread count is displayed over the bell icon, as well as the AC
Admin tab.
3. Verify the community unread indicator is correctly displayed.
4. As an admin, open the AC and before accepting/declining the request, check
that you CAN'T swipe left or right.
5. Accept or decline the membership request.
6. Check the unread indicator disappears accordingly.
7. Swipe left to mark as `Read`.
8. Swipe left to mark as `Unread`.
9. Swipe right to delete the notification (it won't be displayed ever again).
Mentions & replies
==================
Similar steps outlined for `Admin` notifications, but there's one important
difference. Mention and reply notifications don't require a call to action from
the user, so the user can swipe left/right **without** first having to do
anything on the notification (such as pressing on it). See issue
https://github.com/status-im/status-mobile/issues/15118
What about other types of notifications?
========================================
Swipe gestures for other notification types will be implemented in a separate
PR.
Otherwise Xcode uses system Node.js version which is different from Nix
version and can result in weird failures like:
```
admin@macm1-01.he-eu-fsn1.ci.devel:~/status-mobile % node --version
v16.19.0
admin@macm1-01.he-eu-fsn1.ci.devel:~/status-mobile % node --openssl-legacy-provider
node: bad option: --openssl-legacy-provider
admin@macm1-01.he-eu-fsn1.ci.devel:~/status-mobile % make shell
Configuring Nix shell for target 'default'...
[nix-shell:~/status-mobile]$ node --version
v16.17.1
[nix-shell:~/status-mobile]$ node --openssl-legacy-provider
Welcome to Node.js v16.17.1.
Type ".help" for more information.
>
```
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Fixes issue with following failure:
```
Failed to construct transformer: Error: error:0308010C:digital envelope routines::unsupported
at new Hash (node:internal/crypto/hash:71:19)
at Object.createHash (node:crypto:130:10)
at stableHash (/Users/jenkins/workspace/status-mobile/platforms/ios/node_modules/metro-cache/src/stableHash.js:19:8)
at JsTransformer.getCacheKey (/Users/jenkins/workspace/status-mobile/platforms/ios/node_modules/metro/src/JSTransformer/worker.js:471:7)
at getTransformCacheKey (/Users/jenkins/workspace/status-mobile/platforms/ios/node_modules/metro/src/DeltaBundler/Transformer/getTransformCacheKey.js:39:29)
at new Transformer (/Users/jenkins/workspace/status-mobile/platforms/ios/node_modules/metro/src/DeltaBundler/Transformer.js:147:28)
at /Users/jenkins/workspace/status-mobile/platforms/ios/node_modules/metro/src/Bundler.js:54:29
at runMicrotasks (<anonymous>)
at processTicksAndRejections (node:internal/process/task_queues:96:5) {
opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
library: 'digital envelope routines',
reason: 'unsupported',
code: 'ERR_OSSL_EVP_UNSUPPORTED'
```
https://roytuts.com/how-to-fix-err_ossl_evp_unsupported-in-react-js-application/
Signed-off-by: Jakub Sokołowski <jakub@status.im>
* nix: upgrade zprint from 1.2.4 to 1.2.5
To address issue described in:
https://github.com/kkinnear/zprint/issues/273
Signed-off-by: Jakub Sokołowski <jakub@status.im>
* chore: use zprint :multi-lhs-hang
* refactor: re-format clojure using zprint 1.2.5
---------
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Co-authored-by: yqrashawn <namy.19@gmail.com>
We were using old ID for the encryption compliance from old Org.
Because of this the iOS release builds failed at TestFlight upload:
```
Error: Asset validation failed Invalid Export Compliance Code.
The export compliance key value [1aa92c4d-6194-4d7d-b70a-16b48256b87e]
in the app's Info.plist doesn’t match the key value of the app’s export
compliance documentation.
To find the correct value, go to My Apps on App Store Connect. (90592)
```
Related:
- https://stackoverflow.com/questions/53326492/
- https://help.apple.com/app-store-connect/#/dev38f592ac9
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Icaro Motta
Churikova Tetiana
Jakub Sokołowski
John Ngei
yqrashawn
Michele Balistreri
Omar Basem
Ajay Sivan
frank
Alexander
Andrea Maria Piana
Mohamed Javid
Ibrahem Khalil
Vitaliy Vlasov
Parvesh Monu
Yevheniia Berdnyk
Jamie Caprani
Siddarth Kumar
Ulises Manuel Cárdenas
Churikova Tetiana
flexsurfer