This is the folder where the git repo should be stored.
By storing it, we can easily change it later. Also it allows us to
reduce of our custom platform code.
We now have a much clearer separation between Git code and this app
specific code. This is awesome, it will allow other people to easily
integrate Git within their apps. Also, eventually it will be trivial to
switch to another implemention of Git (via JGit or a git client written
completely in Dart)
This breaks the iOS version as I haven't moved the code to build the ios
version. Maybe this will be a good excuse for me to setup a proper CI/CD
system for ios builds.
There is also a chance this breaks Crashalytics NDK symbols :(
The Git Api was strange and took a foldeName and it would only allow you
to access git operations in a particular path. This has now been fixed,
and now it can operate in any path.
This was the first step to moving the git api into its own library.
This is our first use case of trying to use 'Provider' for state
management. Right now, we're doing state management quite horribly as
all the widgets are rebuilt whenever the state of the app changes.
With this, we can now start to refactor and only rebuild the widgets
whose data has changed.
There we many many different state management solutions to choose from,
I've settled on Provider, as it seems like the simplest to integrate
into the code base. Bloc/Redux seemed like they would add too much
complexity for me.
This adds a new 'Folders' screen which shows you all your folders and
lets you manage the notes inside them. It currently doesn't allow you to
add or remove Folders, though.
This nearly addresses #18
This way we can adapt the settings in the future to use the most
commonly changed items first.
We're not logging the 'gitAuthor' or 'gitEmail' as that includes
personally identifyable info.
It's time to start using a proper logger so we can control the number of
log messages, also - it helps to have a central configuration point for
the logs, specially since I would like to hook them up to Crashlytics in
the future.
This required refactoring the code. With this we can now write an
integration test to test the main parts of the app, but more importantly
we can automate the process of generating the screenshots.
For now I've mostly tried to follow the same style guide as the flutter
repository, with many options disabled. Eventually, maybe it would make
sense to be far stricter.
This way it properly aligns up with the hamburger menu.
I also discovered this 'debugShowMaterialGrid' option which makes
working with padding issues much much easier.
It's annoying, and does not allow us to easily take screenshots.
Specially since the apps built in release mode cannot be run in an x86
android emulator.
For now just create a local git repo and commit all the changes over
there, we're going to allow the user to first see the app and use it
however they want, and later connect it to a remote git repo.
This commit breaks the app, as the on-boarding screen is no longer
connected so you cannot push to a remote app.
