store transaction list in a db transaction

otherwise each insert/update triggers a re-fetch of the while list,
which is devastating for the UI and the battery

put conversion from DB objects to LedgerTransaction in a thread

seems to take a non-trivial amount of time

provide a common routine for running something on the main thread

save profile's order when editing a profile

avoid switching current profile when profiles are rearranged

on rearrange the object instances change so the equality check needs to
be done on IDs, not object instances

fully employ room for loading transactions off DB

debug refinements

do not force transaction list reload upon main activity start

instead, let the account filter observer trigger it (account filter live
data is initialized with a value)

this drops the reloading upon profile change, but profile changes
restart the activity anyway, as do theme changes

also, more precise reaction on account filter changes in the fragment --
no need to reload transactions there now that the main activity does it

MainActivity's logging using a TAG

Data.profile doesn't need to be an inert MutableLiveData

the normal MutableLiveData doesn't fire if not given an initial value

use a constant to indicate profile ID of no real profile

async variant for loading all transactions

TransactionAccumulator needs not keep a reference to the main model

asking UpdateTransactionsTask to load a null profile is fine

it would load an empty transaction list

speculatively update last update date while the transactions are stored

this a white lie, because the displayed list is the new one, retrieved
at the given time

this fixes the previous attempt

Revert "speculatively update last update date before the transactions are stored"

This reverts commit bae2aa9e

the code in question is run every time the transaction list is filtered
or updated. when the transaction list is updated it is OK to lie a bit,
but when the list is just filtered the timestamp of the data does not
change

speculatively update last update date before the transactions are stored

this a white lie, because the displayed list is the new one, retrieved
at the given time

further optimize transaction storage by comparing dataHash field

if the dataHash field of the transaction that needs storage matches one
from the database (retrieved by profile id and ledger id), then simply
update the generation of the transaction in the database (and its
accounts)

since this is the common case (refreshing transaction list -- most of
the transactions are expected to be unchanged) this saves big time

put all the annotated abstract DAO methods in the beginning

inline the storeAccountsAndTransactions method

it is a bit silly to have run() that only calls one method

fix storing transaction accounts (bad typo)

this is the fastest storage approach, next thing to try -- compare
existing records with the new-to-be and avoid the db update alltogether
if they are the same

additional transaction deletion methods

fix copying ensuring currency is not null

rename method to better reflect what it does

fix field/accessor type mismatch

selects from joined tables need explicit column list :(

speed up transaction storage a bit

by updating existing records in-place. sqlite's insert or replace
statement tries insert, and when that fails because of unique/primary
key violation *removes* the existing record together with any child
records and then retries the insert. it is almost like deleting all the
transactions and inserting them again, but with a failed insert before
that

(commented) facility for debugging Room's SQL queries

available in room 2.3.0

implement stable IDs for the transaction list

fix ordering of filtered transaction items

ledger_id matches the order at which the transactions are stored in
the ledger

fix comparison of transaction date delimiter contents

it is possible that a delimiter that showed the month name no longer
does and vice versa

add some profiling on acount/transaction list storage

BaseDAO: async operation variants without callbacks

use plain 'long' for Currency.id

also make it mutable, like in the rest of the entity classes

drop MobileLedgerDatabase, move initComplete to DB

splash: show forced delay before starting the main activity in debug

we may want to do something useful with this time - preload profile
data?

convert DatabaseInitTask to a lightweight thread

looks much cleaner

drop remnants of gradual transaction data loading, and last non-Room SQL

preload transaction list page, making transition smoother

fix updates of last transaction update text

rework transaction list with proper view holders and no background load

all the data is already available in the transaction list loaded from
the database (asynchronously)

also, fix a glitch where a visible item's matching account row is not
coloured when the list is filtered by account name (because the
underlying item is the same)

fix finding the earliest transaction by date

rewrite update of transaction list from DB with Room

drop unused async db queue classes

drop now unused MLDB class along with its async db routines

wipe retrieval progress when transaction retrieval is stopped

fixes a glitch when a retrieval error suggests changing profile
configuration, and from there the profile is deleted and activity
restarted because of the change of the active profile. the new activity
instance observes the retrieval result and gets the error and reports it
erroneously

interpret only json-parsing exceptions as API mismatch

all others, like no Internet, bad host name etc should be reported as
usual

when deleting the currently active profile, switch to the first profile

fix exception handling while trying different API versions

fix profile deletion / data wipe

do not keep a reference to the profile being edited, instead query it
by the ID now stored in the model

one thing doesn't work yet - reaction to deletion of the current profile

fix passing profile ID to ProfileDetailActivity

add a pre-release build variant

to be used as debug aid when initial install needs to be tested, but
keeping the data in the debug-variant ap

make use of getBindingAdapter and save a field

bump library dependencies

RecycleView 1.2.0 deprecated getAdapterPosition, replace with
getBindingAdapterPosition -- no concat adapters are used

fix creation of a new profile after Room-y of Profile adoption

fix template editor layout

due to a glitch in the view chains on some devices the layout was
broken

noise: renaming of IDs

constant TAG

debug--

Room-based profile management

MobileLedgerProfile is gone, Room spreads gradually

equality check for Profile

Room-based profile wipe

used only in debug builds as before

dummy migration method

it appeared useful at a point, but later the fix was another

still, it may be handy in the future

Default template name given at save time

gets in the way when put in the details

asynchronous profile initialisation

the problem here was that the startup profile is read from the DB,
synchronously, and all DB operations need to happen via Room off the
main thread

since at activity startup only the theme is needed, that, and the startup
profile ID can be stored in the android preferences. actual loading of
profile and further data can be done after the theme is setup, in the
background, via Room

more Room adoption - accounts@100%, some profiles/transactions

implement incremental changes in account list adapter

avoids unnecessary viewHolder replacement

expansion/collapse are much nicer now

adopt Room for displaying account lists

generation is long

account_id → accountId

specialized sub-classes of AccountListItem

debug--

fix SQL when cleaning obsolete transaction/accounts

minor optimization in getting next generation

fix SQL when filtering transaction list by account name

fix transaction account storage SQL

whitespace

fix db migration to surrogate IDs (final step)

the cleanest approach is to create all new tables, move the data, and
then drop/rename them, followed by index creation

fixes a problem with transaction_accounts being empty because the
profiles table was dropped

requires foreign_keys pragma (set outside transaction control) so that
the declare foreign keys to the new tables get renamed with the tables

more fall-outs after transition to surrogate IDs

fix migration of transaction_accounts (attempt #N)

another step towards surrogate ID db objects

profile → profile_id in more places
transactions.id is globally unique; ledger-supplied ID
(profile-specific) is in transactions.ledger_id

another step towards surrogate ID db objects

rename profile's uuid column to catch (and remove) all its usages
use default theme id for the initial theme id

migrate to surrogate IDs for all database objects

along with foreign keys etc

drop unused create_db.sql

replace custom autocompletion adapter hooking with specialised adapters

... which use Room

prepare release of v0.17.1 (39)

fix db migration from v0.16.0 (profile data)

update features in full description

prepare v0.17.0 (38) for release

minimize flicker when applying templated transaction too

smooth items replacement when old transaction is loaded and upon reset

make transaction header row always have Id of 0

there's onle one header, and having a stable Id avoids visual flicker
when the list is updated

fix flicker introduced with unique item Id

when items get unique id every time, resetting the model causes new
IDs to be assigned, making the adapter consider old items gone and new
items added. this sounds OK, but the visual effect is that everything
disappears and then reappears, causing flicker.

split new transaction item holder in two

one for the header row, another for the account rows

clean up unused resources

Транзакция → Движение навсякъде

template details delete icon needs to be white

it is shown in the action bar

minor optimization: avoid constructing empty string object

replace TextUtils.equals() usage with Misc.equalStrings()

equalStrings() considers null to be equal to the empty string

improvements in debug messages

note focused item changed when item is moved