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.
Partially implements https://github.com/status-im/status-mobile/issues/14712Fixes#14744
### Summary
This PR implements the first, among what will probably be many different kinds of membership notifications. For this PR, I started with implementing a particular flow for private group chats because it's already supported by `status-go` (albeit I had to make some changes, see [PR in status-go](https://github.com/status-im/status-go/pull/3088).
1. `A` and `B` are mutual contacts.
2. `A` creates a private group chat with `B` as member.
3. `B` sees the group chat in the app, but doesn't interact with it.
4. `B` reinstalls the app (remember to back up the seed phrase).
5. `A` mentions `B` in the group chat.
6. `B` should see a group chat notification, which can be accepted/declined.
- [x] Also fixes#14744
### Demo
In the video I'm simulating the steps outlined in the *Summary*, but using the approach described in *Steps to test*, because it's way easier to iterate during development.
[demo.webm](https://user-images.githubusercontent.com/46027/212470798-c135d229-948d-4ba5-98db-ee73cc5495cd.webm)
### Review Notes
Some changes had to be made in `status-go` ([PR](https://github.com/status-im/status-go/pull/3088)), namely:
- According to [Figma](https://www.figma.com/file/eDfxTa9IoaCMUy5cLTp0ys/Shell-for-Mobile?node-id=3806%3A586901&t=xLTAjLXjG1UtorpI-0), users should be able to see `accepted` group chat notifications. Until now, `status-go` hardcoded that `accepted` notifications would *not* be returned in query results, and so it would be impossible to show them to users. This was changed and now the RPC endpoint accepts an additional filter. The implementation on the backend is backwards compatible so as to not break Status desktop.
- The `Membership` tab needs to display various types of notifications (group chat, community, etc), but the membership type doesn't exist on the backend. To overcome this constraint, this PR makes the membership type a logical/virtual type, i.e. a Clojure set of types. `status-go` was changed to support querying for multiple notification types (also backwards compatible).
#### Platforms
- Android
- iOS
### Steps to test
Please, follow the steps described in the Summary and you should be able to test.
But during development, I followed these steps (recommended by @cammellos). I documented them here for reference.
1. Checkout `feature/e2e` in status-go. Apply the diff below.
2. `cd cmd/e2e && ./e2e`
3. This will create a temporary account automatically, let's call it `A`.
4. On another device, create account `B`.
5. Follow the steps documented in bdc406ea2e/cmd/e2e/README.md (L2) in order for user `A` to create a group chat with `B` as member. Don't make `A` and `B` mutual contacts.
6. On `B`'s device, a notification should appear, and `B` should be able to accept or decline the "invitation" (actually *invitation* is another concept and related to another feature).
```diff
modified cmd/e2e/main.go
@@ -283,6 +283,11 @@ func defaultNodeConfig(installationID string) (*params.NodeConfig, error) {
nodeConfig.NetworkID = 1
nodeConfig.LogLevel = "ERROR"
nodeConfig.DataDir = "/ethereum/mainnet_rpc"
+ nodeConfig.HTTPEnabled = true
+ nodeConfig.HTTPPort = 8545
+ nodeConfig.HTTPHost = "localhost"
+ nodeConfig.HTTPVirtualHosts = []string{"localhost"}
+
nodeConfig.APIModules = "wakuext,ext,waku"
nodeConfig.UpstreamConfig = params.UpstreamRPCConfig{
modified protocol/messenger_group_chat.go
@@ -26,17 +26,17 @@ func (m *Messenger) validateAddedGroupMembers(members []string) error {
}
contact, _ := m.allContacts.Load(contactID)
- if contact == nil || !(contact.Added && contact.HasAddedUs) {
- return ErrGroupChatAddedContacts
- }
+ if contact == nil {
+ contact, err = buildContactFromPkString(contactID)
+ if err != nil {
+ return err
+ }
+ }
}
return nil
}
func (m *Messenger) CreateGroupChatWithMembers(ctx context.Context, name string, members []string) (*MessengerResponse, error) {
- if err := m.validateAddedGroupMembers(members); err != nil {
- return nil, err
- }
var response MessengerResponse
logger := m.logger.With(zap.String("site", "CreateGroupChatWithMembers"))
```
* we are now able to navigate to desktop communities
b4bdfd3d...d2e95eee
In this commit we add support for various status-go methods in mobile :
- `multiformatSerializePublicKey`
- `multiformatDeserializePublicKey`
- `compressPublicKey`
- `decompressPublicKey`
- and my personal favourite `deserializeAndCompressKey`
When someone pastes a community joining share url into chat and taps on it, we check whether the community was generated on a desktop or mobile.
We need to do this because currently both the clients have different urls for joining a community.
Once we have identified that the url is generated via desktop we then convert that url to something that the mobile client is used to.
This enables the mobile client to view this community and interact with it.
However more work needs to be done in the future to ensure that mobile implements these compressed keys end to end, we need to get this feature in so that
by the time RC1 is released mobile client is able to join communities created by Desktop.
The dependency on `make shell` is confusing and unnecessary since
`update-status-go.sh` script only requires availability of the
`nix-prefetch-url` utility to check SHA256 of the `status-go` verison.
Use of `make shell` with this script can also cause issues when running
`make run-android` if already in the shell, which prevents spawning a
new one and effectively stops changes to `status-go-verison.json` file
taking effect.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Baic skeleton 🦴
NFT Details page. The API is not returning properties
Add traits, add opensea link, fetch nfts when new account is added
Toggle privacy options
Hide NFT behind FF
Update sgv
Fix lint and rename opensea to collectibles
Signed-off-by: Shivek Khurana <shivek@status.im>
⛳️ Add flag to hide message in UI, there are some bugs in rebuild list process
Don't rebuild, just update the UI state
Update delete to soft delete. Some traces of delete already exist in the app
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Do not need account-info for password reset
Update status go version
Java API
PR Fixes and hide behind a feature flag
Reset status go version to HEAD
Disable reset password in DEV
Enable reset password in DEV
Signed-off-by: Shivek Khurana <shivek@status.im>
Fixes: #2061
This commit adds an unread mentions count in 3 places:
1) Public chats
2) Communities in home
3) Communities chats
The logic is that if you have unread mentions, it will show you the
count of messages with unread mentions, while if you have only unread
messages, you will see a blue dot.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
This commit moves most of the mailserver logic to status-go.
- Filters are now removed and not passed to the client anymore
- Ranges have been removed
- Gaps are now messages with a different content type
- Upsert/Save chat has been removed and instead we have more specific
endpoints such as CreatePublicChat/CreateOneToOneChat/CreateProfileChat
- Creation of timeline/profile chat has been moved to status-go
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
[Fixes: #11806]
[Fixes: #11877]
Features added
An admin should receive a notification on android if a community request is made
Clicking on the push notification will take you to the list of requests
Changes to push notifications
Push notification for messages are grouped by chat, similarly to discord. Only the first notification in a chat will alert, the next will be "silent" notification. Meaning you will see the message but it will not alert. This is consistent with discord/whatsapp.
Clicking on a transaction notification will take you to wallet (not sure it was doing that before, but it might have)
Changed the behavior of the notification toggle, before Notifications and wallet transactions were separate, meaning you could have wallet transaction and Notifications disabled and you'd still receive transactions notifications. Now you need to have Notifications enabled to receive wallet transactions. Eventually we will have an option to toggle message notifications.
Technical details
Removes headless tasks, they were not used
Message notifications are passed unchanged to java, we still check if the chat is in the foreground, but no modifications are made to the notification object. This should get us closer to avoid clojure completely.
Merged the two notifications implementation (NewMessageSignalHandler and PushNotificationHelper). We should split maybe off in more meaningful classes, but there's less code duplication now, and it can be re-used for non-chat (communities) notifications.
Parsing of text for message notifications is done in status-go
Signal is not passed to status-react if notifications are not enabled
Next step
To completely remove notification code from status-react the following are required:
Java needs to be alerted of which chat is in the foreground and whether the app is in the foreground
Transaction notification body message need to be created in status-go
Notification signal needs to be stopped in Java
Limitations
If the name of a contact changes, the notification will not change, once is displayed, it won't be modified
* Removed region from on-ramping we don't want it
* Updated status-go version
* revert change make ios made to keycard version
* Updated status-go version
* Updated status-go version
* Updated status-go version
This commit adds bannning of users in communities for on-request and
invitation only communities.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
In some instances when fetching messages for a timeline the app would
crash as a map was accessed concurrently without locking.
This fixes the issue.
Signed-off-by: andrey <motor4ik@gmail.com>
There were a few issues with topic management:
- Topics/ranges were saved one-by-one, which cause an out of memory
error on some devices
- Topics that were not listened to were saved, and therefore requested
from the mailserver, which caused long syncing time
It also removes tribute to talk and add export/import methods
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
frank
flexsurfer
Icaro Motta
Alexander
Vitaliy Vlasov
Andrea Maria Piana
Roman Volosovskyi
Omar Basem
yqrashawn
Parvesh Monu
Siddarth Kumar
Richard Ramos
Ibrahem Khalil
Jakub Sokołowski
audriu
Churikova Tetiana
Brian Sztamfater
andrey
Vitaliy Vlasov
Samuel Hawksby-Robinson
John M. Ngei
Michele Balistreri
Shivek Khurana
Volodymyr Kozieiev
Gheorghe Pinzaru