Instead we're going to move back to standard exceptions.
Using a custom Result class has created far far more problems
- The Stacktraces aren't always right
- Sometimes one forgets to check the Result error
- All other exception throwing code needing to be converted to Results
- Non idiomatic Dart code
I think it's better to just go back to exceptions. They have their
problems, but overall, I think it's a better approach.
I'm not planning a macos version, but it's super useful to be able to
run the desktop version for testing, as it doesn't need me to run things
on an emulator or physical device.
Now that dart-code-metrics has been updated, this lint can finally be
used. So far all of these are false positives, in the sense that I don't
care about their return values.
I wish there was an easy way of marking functions whose return value
shouldn't ever be ignored.
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.
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.
* Avoid passing Flutter errors to its Zone handler, this doesn't always
catch the errors
* Catch the current isolate's errors. I haven't been able to test this
out, but lets see.
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.
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.
