If we always refresh on focus then we will
be making many redundant requests, as well as
causing the list to jump around whenever we
navigate back/forward.
The only downside to this is occasionally the
data may be stale, however the user can just
pull down on the list to refresh.
Closes#165
Also prevent flickering of "No sets found"
message on first load.
The infinite scrolling issue was a side-effect
of me messing with our memoization. Some places
didn't specify their deps properly.
When we used navigation params to decide whether
or not to update the SetList, we broke reacting to
settings changes. This is because we used to update settings
whenever the user navigated to the page.
Previously we would always update the created
field by making a new Date object, even if
the user didn't pick a new date. On some
devices this might slightly change the time
of the day, meaning it jumps somewhere else
on the home page.
Closes brandon.presley/Massive#162
We should just keep it simple and get the most recent set instead of
trying to figure out what the best kind of maximum would be.
I find myself opening up a set often to
just read the fields rather than changing
anything.
It makes sense to auto-focus the name for
a brand new set, since it's required and
typically what you first fill out.
Semi-related to brandon.presley/Massive#160
If a user manages to import a database that ultimately
breaks the app elsewhere, deleting the database is a nice
tool to try and fix things.
I don't like having a bunch of backups saying
massive (x).db. Also this masks the issue of permissions,
which is easily fixed by deleting/moving the old massive.db.