For a while now, etesync servers return the last entry uid as part of the
general journal querying. We can use this to check if we even need to
update the journals or not, making the overall sync much faster because
we no longer need to fetch journals that haven't changed.
What we do is we mark them as failed and note the error, though we don't
currently have a way to notify the user about these errors. This will
follow in the next commit.
I'm pretty sure this was causing the recent issues with tasks and events
disappearing as described in #97.
Regardless of this, it's not actually needed as SQLite on Android is
already thread-safe. The SQLite locks some users were experiencing were
probably fixed in 26ea8900a2
This reverts commit 9ed172e23c.
This adds support for tasks via OpenTasks.
https://github.com/dmfs/opentasks
Need the OpenTasks client for it to be used.
Currently you can't create new task lists. You can only have the default
one, but that's just a UI thing.
Fixes#7
This change makes clicking on journal items in the list to show in a
separate activity. At the moment it just makes for a slightly nicer
presentation. In the future we would change it to show the data in a
nice formatted way instead of a raw dump of the vObject.
This change only works for calendars at the moment, because we don't have shared
address books anyway.
This is currently only implemented in the client, and only as a read-only attribute,
you can't make a journal read-only yet. This requires server support that is not yet
there, but it's better to be ready for this sooner rather than later.
Having it in raw sql was slowing down development, and was error-prone.
It's much cleaner now, easier to handle, and enables us to develop
faster.
In this change I also fixed the fetching of journals to be by service
and id, not just id, because just id is not guaranteed to be unique.
Before this change, uid was unique on its own, this was wrong, because
due to shared journals, we can have the same journal in two accounts,
and we can thus have both journal and entry UIDs more than once.
This fixes the constraint to be unique for journal, uid, and service,
uid combinations.
This is currently disabled for journals because of a bug in requery.
The server was changed so the owner of the journal, and the encrypted
key (if a shared journal) would be exposed. This change fetches it, and
saves it.
Unfortunately this requery version introduced a regression. When adding
a new account, it takes syncign a few times until it works. It looks
like requery is not loading the recently saved instances.
This reverts commit f0f70ff1c61996d0e45d8f72d24654c739c325f7.
Prior to this version of requery there was an issue that prevented
afterLoad to be called in some cases. This issue forced us to add an
explicit call to afterLoad. It's now fixed, so the workaround is no
longer required.
Reference issue: https://github.com/requery/requery/issues/487
We were storing the ctag separately although the data was already
present in the journal. The last entry's ID is always the CTAG.
This could cause issues if sync is aborted exactly at the right time.
I managed to trigger this issue on rare cases.
It's only used for migrations, and has been considered deprecated for a
while. Mark it as deprecated to make it extra obvious that this should
not be used.
The crypto class now behaves differently depending on the version of the
journal.
The current difference is in the key derivation, and that the new
version of the crypto also hmacs the version automatically whenever it
hmacs anything.
The versioning was added for better future-proofing of the code.
The derivation change was done because before we were creating the same
password for all of the journals, now we do it per-journal. This means
that we can, if needed in the future use this password as the journal
password when sharing journals without compromising the security of the
rest of the journals.
It's really annoying that it doesn't do it automatically as it should,
in the meanwhile, add this workaround.
I reported it to upstream:
https://github.com/requery/requery/issues/487
It's very raw and hacky at the moment, it's just a preview release so
people could see their data is saved, and can look at it in its raw
form until we implement a nicer view.
