honour default currency profile setting

bump version preparing for the next release

make use of currency parameters in the new currency dialog

fix migration off options table for current profile

prepare release of v0.18.0 (40)

fix a crash when applying more than one template via QR code

rename a method to better reflect its function

when speculatively updating account amounts, update parent accounts too

view binding for account and transaction list fragments

work around trans. list menu items visible with setOffscreenPageLimit(1)

with that call the transaction list fragment is loaded nicely
off-screen, but also it menu items get in the action bar. of the
fragment is navigated to and away they hide as before, but the initial
load is still a problem

another fix to the layout of template date parameters

stop resetting the date when an old transaction is loaded into the form

drop description history table and support machinery

correct debug message

lookup transactions by description directly in transactions table

description_history is abandoned, transactions.description uses NOCASE
collation and the UPPER trickery is not needed anymore

several fixes when there are no profiles after full room adoption

in particular, the ProfileThemedActivity doesn't call finish() when
there is no current profile, because this is exactly the case when the
app has just been installed and the main activity's introductory
interface needs to be shown

proactively apply the same fix to the new transaction editor

fix profile editor's bottom part getting overlapped by the soft keyboard

drop unnecessary template type

fix binary & used instead of logical &&

small step towards support for currency in transaction templates

rename an event handler using the onXXX style

show comments when invoking a previous transaction

broken in a recent release

fix converting LedgerTransactionAccount to TransactionAccount (room)

the currency can't be null

having null here led to problems when saving the transaction
speculatively and account amounts are updated, because in the database
account_values.currency is declared not null

fix inclusion of exception log in error message

speculatively add new transactions to the database and UI list

this saves a refresh that would be need to view the new transactions and
 ccount balances

fix ordering of transactions when loaded from database

fix displayed transactions count

the count wrongly included the UI elements like date delimiters and the
heading row

restore account ordering by name

it was nice to use the ordering from hledger, but after the migration to
 room this worked only by chance - sqlite returned the rows in the order
 they were inserted. this means that any new accounts will end up at
 the bottom. this is the case when speculative transaction storage is
 active (coming soon) and the transaction has a new account.

 also, the conversion from db account objects to UI list relies on the
 ordering now.

 in a future version, the accounts table may store the hledger ordering
 in a new column, but this doesn't completely solve the problem when
 adding new accounts speculatively

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--