Fixes#9433 : this was due to the fact that `.-response-to` was
returning nil, because of the dash in the name, instead in this cases
`(aget .. "response-to")` should be used.
Fixes#9431 : This was a left-over from the move from message-groups to
message-list, and the code was not updated.
Fixes#9430#9429 Both of these were due to the same issue, cofx were
wrongly passed to the function resulting in the db being updated but the
fxs being discarded.
There's still a separate issue that might result in messages not being
saved on logout, because of a race condition (if you logout while is
fetching messages, some of the message might not be saved). I will
address that separately as we might be able to just save messages as
they come in status-go, rather then having to pass them to status-react
and back to status-go for saving.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
find account by key-uid
show pairing slots info on pairing
fix pin reset flow
pass retry-counter
fix sign with keycard button in wallet
Signed-off-by: Dmitry Novotochinov <dmitry.novot@gmail.com>
- add option in profile on Android to enable local notifications
- use foreground service to keep the app alive when running in the background
- implement enable and disbable notification function in status module
When enabling notifications, a foreground service is started that displays
a sticky notification to make the user aware that the app is running in the
background.
Notifications are updated whenever a new.message signal is handled on java side.
Currently only one to one chats are generating notifications but that can be
easily extended to other types of messages, including mentions and keywords.
The ens name of the user as well as keywords to follow should then be passed
to the native side when calling the enable function.
Signed-off-by: yenda <eric@status.im>
This commit enables parsing of messages in status-go.
Currently only a few messages are supported in status-protocol-go.
For now we only enable Message types.
Status-react will conditionally use the parsed version if present.
Eventually this can be moved to a separate signal/different structure,
but for the time being is best to validate with the minimum amount of
changes.
The next step would be handle validation and processing of the field in
status-go, so we can skip saving the message from status-react.
This commit should improve performance of receiving messages from a
chat, although haven't had time to validate that.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
* Update fr.json
Validated JSON file (last line contained an extra comma)
* Update i18n_resources.cljs
Defined the languages and translations
Signed-off-by: Andrey Shovkoplyas <motor4ik@gmail.com>
The from parameter was left out, tests did not pick it up as they were
not running, probably I have wrongly rebased the code and did not
include the new namespace in runner.cljs
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
There are some instances on the keycard screens that read `Recover key` rather than `Access key`, this is dated language so I've changed it. There are a few other instances of the word 'recover' in relation to keycard that may also need to be changed, but I'm not sure what context they are in.
Signed-off-by: Andrey Shovkoplyas <motor4ik@gmail.com>
This commit does a few things:
==== Ordering of messages ====
Change the ordering of messages from a mixture of timestamp/clock-value to use
only clock-value.
Datemarks are now not used for sorting anymore, which means that the
order of messages is always causally related (not the case before, as we
were breaking this property by sorting by datemark), but datemark
calculation is unreliable (a reply to a message might have a timestamp <
then the message that is replied to).
So for timestamp calculation we
naively group them ignoring "out-of-order timestamp" messages, although
there's much to improve.
It fixes an issue whereby the user would change their time and the
message will be displayed in the past, although it is still possible to
craft a message with a lower clock value and order it in the past
(there's no way we can prevent this to some extent, but there are ways
to mitigate, but outside the scope of this PR).
==== Performance of receiving messages ====
The app would freeze on pulling messages from a mailserver (100 or so).
This is due to the JS Thread being hogged by CPU calculation, coupled
with the fact that we always tried to process messages all in one go.
This strategy can't scale, and given x is big enough (200,300,1000) the
UI will freeze.
Instead, each message is now processed separately, and we leave a gap
between processing each message for the UI to respond to user input
(otherwise the app freezes again).
Pulling messages will be longer overall, but the app will be usuable
while this happen (albeit it might slow down).
Other strategies are possible (calculate off-db and do a big swap,
avoiding many re-renders etc), but this is the reccommended strategy by
re-frame author (Solving the CPU Hog problem), so sounds like a safe
base point.
The underlying data structure for holding messages was also changed, we
used an immutable Red and Black Tree, same as a sorted map for clojure, but we use
a js library as is twice as performing then clojure sorted map.
We also don't sort messages again each time we receive them O(nlogn), but we
insert them in order O(logn).
Other data structures considered but discarded:
1) Plain vector, but performance prepending/insertion in the middle
(both O(n)) were not great, as not really suited for these operations.
2) Linked list, appealing as append/prepend is O(1), while insertion is
O(n). This is probably acceptable as messages tend to come in order
(from the db, so adding N messages is O(n)), or the network (most of
them prepends, or close to the head), while mailserver would not follow this path.
An implementation of a linked list was built, which performed roughtly the
same as a clojure sorted-map (although faster append/prepend), but not
worth the complexity of having our own implementation.
3) Clojure sorted-map, probably the most versatile, performance were
acceptable, but nowhere near the javascript implementation we decided on
4) Priority map, much slower than a sorted map (twice as slow)
5) Mutable sorted map, js implementation, (bintrees), not explored this very much, but from
just a quick benchmark, performance were much worse that clojure
immutable sorted map
Given that each message is now processed separately, saving the chat /
messages is also debounced to avoid spamming status-go with network
requests. This is a temporary measure for now until that's done directly
in status-go, without having to ping-pong with status-react.
Next steps performance wise is to move stuff to status-go, parsing of
transit, validation, which is heavy, at which point we can re-consider
performance and how to handle messages.
Fixes also an issue with the last message in the chat, we were using the
last message in the chat list, which might not necessarely be the last
message the chat has seen, in case messages were not loaded and a more
recent message is the database (say you fetch historical messages for
1-to-1 A, you don't have any messages in 1-to-1 chat B loaded, you receive an
historical message for chat B, it sets it as last message).
Also use clj beans instead of js->clj for type conversion
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Roman Volosovskyi
Pedro Pombeiro
Churikova Tetiana
Andrea Maria Piana
Dmitry Novotochinov
Andrey Shovkoplyas
yenda
Jakub Sokołowski
AlphaSerpentis
Rachel Hamlin
William Mruzek
Serhy
acolytec3
dependabot-preview[bot]
tbenr