I'm hoping with this if any value in the repo changes it will result in
a rubuild of the entire subtree, so this way I can change the entire
NotesFolderFS easily.
That class is going to lose many of its members, and I don't want to
keep the old ones just for compatibility sake.
Also give each setting the concept on an id - will be used later.
Left over from an experiment. Logs only stay on the device, so this
wasn't a problem, but it stays constant on Android across installs. It
would be nice to use this ID instead the random ID that we generate, but
that could be counted as personally identifyable info. I'm not too sure.
We now infer this by checking if the directory exists, and by reading
the git config. It's a bit slower, but it's a far better method. I can
add a cache later, if it turns out to be too slow.
Some % of the users are badly affected by a bug, which I cannot seem to
reproduce, maybe this debug message will help.
Also, I accidentally shipped it with the bottom bar disabled.
Earlier we had one folder 'journal_local', when the remote would be
setup a new folder called 'journal' would be created, and each all the
files would be copied over. This meant the local history was being
destroyed.
Now, we only have 1 folder 'journal', and on 'cloning', we add the url
as a remote, and do a git fetch + merge.
This simplifies everything drastically, and opens the door for multiple
remotes.
Stop it being a singleton. This means it needs to be passed around a
lot. This sucks, but it's how it should be. I shouldn't be using a
global variable to get around this.
This is needed as Settings will soon become repo specific when we
support multiple repos.
This breaks saving the settings in a file, that feature was toggled off
anyway. It needs to be thought over again.
I'm calling this event gj_app_update as firebase automatically sends an
app_update event. This is being done so that I can easily remove
firebase analytics in the future.
It makes the entire code base far more complicated and the round trip to
get the directory really isn't that much. This is a massive
micro-optimization for very little benefit.
This way all the persistant state of the app is managed from the same
place. It makes everything much easier. Also, it's required for when
GitJournal supports multiple repositories.
I'm testing this with the Foam documentation. This has revealed a number
of bugs in our link resolver - most of which have now been fixed.
The graph layouting is not being done as this is so incredibly slow.
This has been added as an experimental feature.
This way we have the screen names in the debug log and diagnosing issues
becomes easier. Also, this brings me closer to being able to drop
Firebase Analytics.
A note has a parent which is the physical folder it is inside, and a
parent folder which it is being displayed inside. It's useful to have
the latter as that can be used to display the next note - in the case of
the Journal Editor, and open the graph view as well.
Make it a ChageNotifier and try to access it through the Provider
instead of like a global variable. This way, the state is better
managed and it'll be easier to split out Settings into smaller classes.
