* chore: add english translation for "Beta"
* tweak: add beta tags to communities and chat home screen titles
* fix: use smaller size for beta tags on chat and communities home screens
* chore(wallet): feature flag adding watch only accounts
* e2e: disabled test for watch-only accounts
---------
Co-authored-by: Yevheniia Berdnyk <ie.berdnyk@gmail.com>
This change will now allow for customizing the port number when running the metro server. The environment variable `RCT_METRO_PORT` can now be set when executing commands like `make run-ios`, `make run ios-device`, and `make run-android`. Though, it should be noted that `make clean` may need to be ran before attempting to set or change `RCT_METRO_PORT` since the react-native app will have statically built code that references the value of RCT_METRO_PORT from compile time and not runtime.
* 📈 Capture onboarding funnel
* ⏩ Faster lookup
* ✅ Capture how many people enabled metrics
- It technically captures disabled too
- But we'll never know if someone disabled
- Because that info won't be transmitted
* ✏️ Fix tests
* 🧯 Fix lint
Creating this PR for regression testing the comparability of feature sync
between different versions(mainly current PR build vs v2.29) after adding
backend fallback pairing support. Because frontend haven't added the invocations
relate to fallback pairing API yet, so fallback pairing won't support with
current build.
relate status-go PR https://github.com/status-im/status-go/pull/5614
Testing notes expected: sync should work as before between different versions
like following: v2.29 <-> PR build PR build <-> recent desktop build
NOTE: It breaks with v1 of pairing, but that's ancient (last year I believe), so
safe to break.
This commit uses "usd" currency as default for the fiat price calculation for the tokens.
Every currency has a different format - decimal which we need to rely on a separate RPC to fetch currency format and do the calculation. So, this PR will change to use usd as the default for v2.30.
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
* fix(wallet): fix bridge transactions
Signed-off-by: Brian Sztamfater <brian@status.im>
* add support for approve transactions
Signed-off-by: Brian Sztamfater <brian@status.im>
---------
Signed-off-by: Brian Sztamfater <brian@status.im>
* feat: removed wallet connect feature flag
* fix: show pending requests when logging out and in
* fix: don't show requests across (test/main)nets
* format: added env newlines
* fix: network state reset on network type change
* fix: reject typed-data if wrong chain-id
* chore: added logs for future debugging
* fix: create password for small screen
* feat: use floating button page
Signed-off-by: yqrashawn <namy.19@gmail.com>
* fix: use keyboard will show for ios
Signed-off-by: yqrashawn <namy.19@gmail.com>
* fix: safe area bottom on devices without physical home button
Signed-off-by: yqrashawn <namy.19@gmail.com>
* feat(create-password): tips and checkbox stick with confirm button
* fix: floating button blur after rebase
* fix(floating-button): absolute content avoid keyboard view
---------
Signed-off-by: yqrashawn <namy.19@gmail.com>
In this commit:
- we set `ANDROID_ABI_SPLIT` to `true`
- we set `ANDROID_ABI_INCLUDE` to `arm64-v8a` for debug & PR android builds
- release builds would still contain `armeabi-v7a;arm64-v8a` and there is no change for E2E android builds
- we point to relevant changes in `status-jenkins-lib` which also introduces a size check for this `apk`.
The agreed threshold is 100 MB.
* 🥅 Filter connected dapps based on testnet mode
- Fixes#20794
* 🥅 Remove map, just filter
* 💿 Rebase
* ❌ Remove greedy fetch
* 🙅♀️ Properly reject proposals and requests
* 🎗️ Remove newline and move `set`
- `set` was applied at the wrong place here
* ✏️ Address review comments
* 👀 Read proposal to reject from state
* ◀️ Bring back network filtering
* 🧹 Cleanup
* ✏️ Move comment around
* 🎣 Use filter operable accounts helper
* ➕ Add back events deleted during rebase
* 🧰 Fix Issue 2, Testnet sessions not visible
* 🖊️ Fix lint
* 🔗 Make testnet filtering more explicit
* 🥢 Use union instead of two subsets call
* ✏️ Fix lint
* 🔇 Undo changes that creeped in an unrelated ns
* add v2 method
* rename v2 to get-suggested-route
* remove timestamp check on success
* handle async signal for suggestion
* fix stop get suggested routes
* address feedback
* rename get-suggest-route
* prefer lazy seq
* fix formatting
* update suggested routes success
* refactor get-in calls in start-get-suggested-routes
* move transformations to data store
* clean suggested routes immediately
* fix lint
* pass precision as ar
* change test name
* fix big number division error (issues 1,2)
* only trigger router fetch when there address (to/from)
* check response data for error response when routes received via signal
* update status-go
* fix: test failure
* update status go
* handle error message for generic errors
We do a few things to reduce the initial load and make the app more responsive
after login. The scenario we are covering is a user who joined communities with
a large number of members and/or which contain token-gated channels with many
members.
- Related to https://github.com/status-im/status-mobile/issues/20283
- Related to https://github.com/status-im/status-mobile/issues/20285
- Optimize how we convert a community from JS to CLJS. Community members and
chat members are no longer transformed to CLJS, they are kept as JS. Read more
details below.
- Delay processing lower-priority events by creating a third login phase. The
goal is to not put on the same queue we process communities less important
events, like fetching the count of unread notifications. Around 15 events
could be delayed without causing trouble (and this further prevent a big chain
of more events to be dispatched right after login).
- Tried to use re-frame's flush-dom metadata, but removed due to uncertainty,
check out the discussion:
https://github.com/status-im/status-mobile/pull/20729#discussion_r1683047969
Use re-frame’s support for the flush-dom metadata whenever a signal arrives.
According to the official documentation, this should tell re-frame to only
process the event after the UI has been updated. It’s hard to say if this
makes any difference, but the theory is sound.
- Reduce the amount of data returned to the subscription that renders a list of
communities. We were returning too much, like all members, chats, token
permissions, etc.
Other things I fixed or improved along the way:
- Because members are now stored as JS, I took the opportunity to fix how
members are sorted when they are listed.
- Removed a few unused subs.
- Configured oops to not throw during development (in production the behavior is
to never throw). This means oops is now safe to be used instead of interop
that can mysteriously fail in advanced compilation.
- Show compressed key instead of public key in member list for the account
currently logged in.
Technical details
The number one reason affecting the freeze after login was coming from
converting thousands of members inside communities and also because we were
doing it in an inefficient way using clojure.walk/stringify-keys. We shouldn't
also transform that much data on the client as the parent issue created by
flexsurfer correctly recommends. Ever since PR
https://github.com/status-im/status-mobile/pull/20414 was merged, status-go
doesn't return members in open channels, which greatly helps, for example, to
load the Status community. The problem still exists for communities with
token-gated channels with many members.
The current code in develop does something quite inefficient: it fetches the
communities, then transforms them recursively with js->clj and keywordizes keys,
then transforms again all the potentially thousands of member IDs back to
strings. This PR changes this. We now shallowly convert a community and ignore
members because they can grow too fast. From artificial benchmarks simulating
many members in token-gated channels, or communities with thousands of members,
the improvement is noticeable.
You will only really notice improvements if you have spectated or joined a
community with 1000+ members and/or a community with many token-gated channels,
each containing perhaps hundreds of members.
What's the ideal solution?
We should consider removing community members and channel members from the
community entity returned by status-go entirely. The members should be a
separate resource and paginated so that the client doesn't need to worry
about the number of members, for the most part.
frank
Andrea Maria Piana
Sean Hagstrom
Jamie Caprani
Mohsen
Parvesh Monu
Yevheniia Berdnyk
Ulises Manuel
flexsurfer
Shivek Khurana
Lungu Cristian
Brian Sztamfater
Mohamed Javid
mmilad75
yqrashawn
Icaro Motta
John Ngei
Siddarth Kumar
BalogunofAfrica