Previously, it made it seem like the developer needed to call "prepare." And that was the case but now it's more common to trigger this error by accessing transactions before the synchronizer has been started.
Added a priority to the twig module so that it is easy to exclude chatty logs, which is helpful for third party builds. The default logs are now a lot cleaner and more concise.
This is a fairly frequent crash that occurs when devices return from the background and attempt to reuse a stale channel. In that situation, shutdown the stale channel and rebuild a new one.
Relying on this flag to change was causing new wallets to appear to fail. Although they work on the next launch, it is confusing for users and requires immediate attention.
begin adding a step between the creation of a Synchronizer and starting it, called 'prepare' which is responsible for migrations and other steps to get the data ready for syncing.
Scanning without an account setup is a programming error and prior to this change it wasted a lot of resources and would always crash eventually. Now, this error is caught sooner and surfaced with a clear message.
The project was including a bad version of NotNull and this resulted in errors that were very hard to troubleshoot because the failure happened during annotation processing so Dagger could not even generate the code that the rest of the app relied upon. It was a mess. Fixed by removing the useless NotNulls and being a little more conservative on dependencies.
It is important to be very explicit about the network and not make any assumptions for ease of use because that resulted in numerous bugs while transitioning away from the old two library setup.
squash explicit network
A unified viewing keys serves as a grouping of keys that are all related to the same account but do not have spend authority. This is most important when initializing the database for scanning.
Previously, the wallet had to manage determining the best birthday but that logic has now been pulled down into the SDK. A wallet can safely skip all blocks prior to the first transaction so the birthday starts as an estimate, based on the checkpoint and then moves forward to the height of the first transaction. If a user starts a wallet but does not receive funds for a long while, their wallet will have a better birthday as a result of this change and that is a very common use case.
Calling stop should cleanly exit the synchronizer. Instead, we are seeing lots of errors and crashes. This can be made better but the first step is to add some logs to help troubleshoot the problem.
Kevin Gorham