working backup and restore of configuration settings

all profile and template parameters are supported

drop deprecation from profiles.uuid, make not null

will be used when importing profiles from exported JSON configuration

add uuid to templates

will be used to distinguish new templates when restoring configuration
from JSON

add unique index on currencies(name)

this would function as the UUID on profiles and templates

point to local license copies (in addition to web links)

prepare v0.19.2 (43) for release

fix looking up old transactions with non-ASCII names (broken in 0.18.0)

according to the documentation, SQLite's NOCASE collation affects only
ASCII characters. Unicode is explicitly mentioned as not supported.
Strangely Unicode still works on some Android versions/variants, but not
on others.

This change stops relying on NOCASE collation and puts back upper case
variant of transaction description in a new column, which is then used
when looking up previous transactions for auto-completion

prepare v0.19.1 (42) for release

drop a fixme that needs no fixing

fix crash in version checking code with two-component versions (3.14)

maintain amount text independent from the amount

for example, the text may not be a valid amount, i.e. a sole "-"

make decimal separator available globally

updated with locale changes

track more instances where currency may be null (and replace it with "")

bimp gradle, sdk, build tools, jackson; jcentral→mavenCentral

fix loading previous transaction with no preferred account (again)

broken in 0.19.0

use explicit main thread looper

bump version of two test libraries

annotate a data retrieval method with @Transaction as suggested

fix a weird bug when an invalid amount is entered

typo in debug message

new transaction: currency can't be null

prepare release of v0.19.0 (41)

when accumulating running totals, consider sub-accounts too

fix propagation of speculative account ammounts to parent accounts

better text color reference working also in dark theme

visual improvements in template list

add a divider between items, similarly to the account list

fix account list end margin after flow adoption

add small margin between account name and its amount in transaction list

hint account name wrapping after the colon to help long accounts

improve account list with Flow helper widget

makes a difference with very deep account trees and/or long commodities
or big amounts and small screen or big font

fix auto-complete account list amounts alignment

similar improvement can be made to the main account list

show current account balance when choosing account in new transactions

fixed auto-complete pop-up background color for the material layout too

use same font size in template editor / account name

drop unused style attribute

explicit pop-up background color for auto-complete text views in dark

can't find a way to reference the theme-wide color for pop-up menus and
the app drawer

without this, the background is black, which is a problem some times
because the main windows background is also black

use the primary theme colour for transaction list accents

a bit more readable in dark mode

better layout of the transaction list running total

remove duplicate call

simplify logic

whitespace

running totals when filtering transactions by account

this requires traversing the transaction list in the opposite order - from
oldest to newest and corresponding corner cases

fix currency selector without parameters (position/gap)

whitespace

debug loop only in debug builds

add commodity support to template editor

drop a dummy TODO

there are no parameters for creation this fragment, the TODO is a
leftover from the assisted fragment creation

reject TODO about multiple amounts with different currency per posting

the same effect may be achieved with several postings now and this is
how hledger represents such transactions so no need to invent some
convoluted UI for this

update the current profile value when profile list has changed

without this, Data.getProfile() returns a previous value that may not be
current, e.g. the default currency have been changed

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