This commit adds Emoji Picker in the app for usage in Message Composer and Wallet Account.
---------
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
This commit does the following:
- Moves `get-abbreviated-profile-url` from shell share view into `utils.address` and update its usage.
- Adds `get-shortened-compressed-key` to `utils.address` and update the code using `get-shortened-key` to now use `get-shortened-compressed-key` instead.
- Adds test for newly introduced utils.
This commit refactors the "How to pair" bottom screen (introduced in #15710) on Syncing page, to be reused in "Sign In" and "Sync new device" screens by moving the UI rendering functions to the common place.
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
* remove b&w color as an option
* change system message for minimum display name length to match designs
* update display name validation to match desktop
* onboarding sync devices after scan to sign in
* using subscription to get the status of pairing progress
* update following reviews
* polished code following reviews
* fixed showing unknown devices
* community home screen updates
* removed green border color on status indicator
* added accent color to plus button and jump-to button
* code reviews
* e2e: fix acc id new comm button
* resolved bugs
---------
Co-authored-by: pavloburykh <pavlo@status.im>
This is the introductory work to support the new requirements for unfurling
URLs (while the message is a draft) and displaying link previews (after the
message is sent). Refer to the related status-go PR for a lot more interesting
details https://github.com/status-im/status-go/pull/3471.
Fixes https://github.com/status-im/status-mobile/issues/15469
### Notes
- The old link preview code will be removed separately, both in status-go and
status-mobile.
- I did the bulk of the work in status-go
https://github.com/status-im/status-go/pull/3471. If you want to understand
how this is all implemented, do check out the status-go PR because I heavily
documented the solution, rationale, next steps, etc.
### Performance
Does the feature perform well? Yes, there's very little overhead because
unfurling URLs happen in status-go and the event is debounced. I also payed
special attention to use a simple caching mechanism to avoid doing unnecessary
RPC requests to status-go if the URLs are cached in the client.
I have some ideas on how to improve performance further, but not in this PR
which is already screaming for reviews.
fixes: #13439
Summary
- Update `quo2/qr-code` component to use `fast-image` instead of `rn/image`
- Adds profile tab in share section, wallet tab is marked as WIP
- Shows profile QR code along with link to user's profile and the user's emoji hash.
- profile link is shareable and copyable on tap.
- emoji hash is shareable and copyable on tap.
- fixed weird android issues
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"))
```
Omar Basem
Volodymyr Kozieiev
Lungu Cristian
Siddarth Kumar
Brian Sztamfater
Jinho Jang
codemaster
Mohamed Javid
John Ngei
mmilad75
Mohsen Ghafouri
flexsurfer
erikseppanen
Mohsen Ghafouri
Jamie Caprani
Icaro Motta
Ibrahem Khalil
Ulises Manuel Cárdenas
andrey
yqrashawn
Alexander
Ulises M
Parvesh Monu
Roman Volosovskyi
Ajay Sivan
Andrea Maria Piana
Erik Seppanen