This changes the way the SSH keys are managed, they are no longer
managed by the git_bindings plugin and are instead just passed as
parameters. They are now saved in shared_prefs. This allows us to easily
have multiple ssh keys.
It also allows us to store the ssh keys in a more secure storage
location in the future.
Now with the latest git_bindings we no longer use git_pull which would
do a fetch + merge. It's good that these two actions are separated as
I can then easily replace the git_merge with a smarter version
implemented in git.
Also, that way in the future, the git_bindings plugin will only be used
for git_fetch and git_push for SSH. Everything else can be handled by
dart_git.
The iOS updates keep getting rejected, and I think it's because
RevenueCat is taking too long to respond. Additionally, revenueCat
doesn't really give us anything useful as its receipt validation isn't
perfect, and I've had to roll my own.
Plus from a privacy point of view, this is better as we are no longer
talking to any third party service.
This has so far only been tested on iOS
I'm not 100% sure this will work without the dart code, but I don't want
to replace my working implementation with flutter_sentry's
implementaiton which might not report all the errors.
This reverts commit 763cbf8493c610dec0e7e344bee40ad331e7a272.
This reverts commit ddad699b259bafe6c7ed630e7afc2eb38b7825e6.
This is causing way too many problems -
On Android with GitHub we occasionally get a User Cancelled exception.
On iOS this doesn't work < ios11
I prefer keeping my way till then. Even though it doesn't support
KeepAlive on Android.
This works slightly better on iOS and on Android it has a keep alive,
which will prevent our app from being killed. Additionally, this way
there is less for me to maintain, which is always nicer.
The API for flutter_web_auth is also much simpler.
This also inolves some custom logic for parsing the Query Parameters
from the GitLab callback, as it doesn't seem to be a proper URI. Not
sure what is going on with Gitlab.
Instead lets just use the path_provider. This was being used as for some
reason I wanted the files to reside inside the 'files' folder and not in
the 'app_flutter' directory.
However, that requires maintaining a fork of path_provider, which I no
longer want to do.
Related to #125
This still needs to be integrated into the Flutter Markdown renderer.
But the good news is that this works!
It currently requires network access to download the katex scripts. It
does NOT send the katex string to any server. The rendering is performed
in the app.
