Front end changes:
As there is no guarantee that `newblock` event will be dispatched
consequently (e.g. if there was a delay after block#1 the next event
might be dispatched for a block#2000, no guarantee that block#2 will be
the next one), `newTransactions` field was added with a map of accounts
to the number of new transactions received to this block. In result if
there are new transactions we request them all of db instead of fetching
them on for the block specified in `newblock` event, as it was done
previously.
Back end changes:
- In order to avoid handling of the reorganized blocks we use an offset
from the latest known block when start listening to new blocks. Before
this commit the offset was 15 blocks for all networks. This offset is
too big for mainnet and causes noticeable delay of marking a transfer as
confirmed in Status (comparing to etherscan). So it was changed to be 5
blocks on mainnet and is still 15 blocks on other networks.
- Also before this commit all new blocks were handled one by one with
network specific interval (10s for mainnet), which means that in case of
lost internet connection or application suspension (happens on iOS)
receiving of new blocks would be paused and then resumed with the same
"speed" - 1 blocks per 10s. In case if that pause is big enough the
application would never catch up with the latest block in the network,
and this also causes the state of transfers to be delayed in the
application. In this commit in case if there was more than 40s delay
after receiving of the previous block the whole history in range between
the previous received block and ("latest"-reorgeSafetyDepth) block is
checked at once and app catches up with a recent state of the chain.
We should only start receiving messages/processing topics once all the
initializiation is completed, so an endpoint that start the messenger
has been added.
Before we would initialize the topics/receiving messages at the same time,
which resulted in a race condition where a topic was signaled from
status-go and was considered new just because was not loaded yet.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Handle ens-name in qr reader
If user has an username generate link with it
Ensure no infinite recursion happens on qr scan event
Fix test for custom profile ens-name
Fix QR code read for ens-name
Extra check for ens name in QR code
Do not open unknown profile for bad ens name
Signed-off-by: Gheorghe Pinzaru <feross95@gmail.com>
When moving from chat to chat, component-did-mount is not fired as the
component is never unmounted, therefore messages were not loaded.
This changes the behavior to use the component-did-update lifecycle
method.
Signed-off-by: yenda <eric@status.im>
This commit fixes a couple of issues.
The first one is that when we go from offline->cellular-network->wifi
historical requests were not triggered (only when going from
offline->online, but if they are disabled in cellular network they won't
fire).
The second is due to the fact that it is possible that the connection
status gets into a bad state, (this happens for example if get-latency
returns all errors, but we are online, and it won't be retried), and no
connection attempt is made anymore.
I have changed the logic to periodically check the connection state, and
try to connect if too much time has passed since last error (10s),
similarly to what we did before, but in a tick, so we are less reliant
on having the right state in the db.
Signed-off-by: yenda <eric@status.im>
Error with previous update:
Intro-wizard-3 (OLD): Own a Keycard? Store your keys on it; you'll need it for transactions
Intro-wizard-3 (NEW): If you own a Keycard, store your keys there for enhanced security.
Signed-off-by: Churikova Tetiana <churikova.tm@gmail.com>
And we have to trim the one used for Android.
For more details see:
>Warning: The greatest value Google Play allows for versionCode is 2100000000.
https://developer.android.com/studio/publish/versioning
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Fixes#9884 React modal is drawn above the app (maximum z-index) while the bottom sheet and popover are part of the app. https://facebook.github.io/react-native/docs/modal.html documentation also suggest to not use modal in that case cause we lose some control over navigation. Now modal are handled by navigation and we can draw our popover and bottom sheet on bigger z-index and better control what should be on the top.
Signed-off-by: Churikova Tetiana <churikova.tm@gmail.com>
- all messages are not shown right away, in order to paginate history
a user has to press "load more" button
- added link to etherscan before transfers list
- there is a new "fetch more" button at the end of the list
- rest of changes can be found here status-im/status-go#1775
With it we can set last_hope_attempts_backoff to 5 seconds.
This should fix issues with upload wait timing out.
Signed-off-by: Jakub Sokołowski <jakub@status.im>