orgzly
Add support for Google Drive synchronization
Is there somebody struggling for this feature? I am investigating Google Drive apis and this repository and would like to share ideas if somebody is working for this.
I would be interested in working on it as well! I don't think there is currently a timeline on it and I would very much like the feature!
I'm interested in work on this, any help about where to start looking? I mean some classes or packages that can be candidates to modify
Service-side - new class is needed implementing Repo interface UI-side - new fragment is needed to display directory/auth view
Those are tied together in ReposActivity and RepoFactory.
Checking existing DropboxRepo and DirectoryRepo is probably a good start.
(There's a lot of room to DRY things up, as this is all very similar. But I wouldn't worry about that right now if you're just starting - copying what DropboxRepo does and how is used is fine.)
Note that com.google.android.gms:play-services-drive is proprietary software. If it becomes a mandatory dependency, Orgzly won't be updated on F-Droid.
I will keep it in mind @relan and try to find a way to solve this problem.
Also I like to try to add nextcloud/ownclud integration appart from google drive. What do you think?
@relan: isn't the dropbox integration proprietary as well ? Why is integration with drive separate ?
If the issue is that this uses a specific android API not available on F-droid, could the app not use the regular web API (https://developers.google.com/drive/v2/reference/) ? I haven't written any Android apps, so perhaps this is a naïve question, and the app would have to use the android API But my understanding is that the user would just have to go through a separate OAuth flow to connect via the web API.
isn't the dropbox integration proprietary as well ?
Dropbox SDK is free software (MIT license), see https://github.com/dropbox/dropbox-sdk-java
Why is integration with drive separate ?
Well, because Google decided to make com.google.android.gms:play-services-drive library non-free.
Can't answer your other questions, I never reasearched Google's APIs.
Orgzly could use the Storage Access Framework (since Android 4.4) client API. Any SAF provider - such as Google Drive, Dropbox, OwnCloud #28, SD Card etc. - would then be available through one common interface.
Please add support for the Storage Access Framework so that we can sync to Nextcloud. Nextcloud now has an end-to-end encryption as an App so we get client side encrypted sync for free. At the moment I cannot sync to Nextcloud at all.
Orgzly could use the Storage Access Framework (since Android 4.4) client API. Any SAF provider - such as Google Drive, Dropbox, OwnCloud #28, SD Card etc. - would then be available through one common interface.
It already does - Orgzly uses ACTION_OPEN_DOCUMENT_TREE for "Directory" repo type. It's what opens the system browser.
However, support for that intent doesn't seem to be too popular with the providers. See for example https://github.com/nextcloud/android/issues/303. Google Drive and Dropbox don't support it either.
It doesn't look like Orgzly accepts donations, but if I could I would donate to have this feature added. It's one of the last remaining obstacles to me switching to org-mode completely. Alas, I don't currently have time to work on it.
I think something that Orgzly could add would be repositories limited to a single file? This way it could use the same intent as the one for “Import Org file”, which does work with all providers.
Actually, it'd also match better my personal use case of org-mode files, where I'd like orgzly to show me only some of the notebooks in a directory, but that's an unrelated question :)
As for donating money, I think BountySource (even though I don't like the idea of giving 10% of the donation to a for-profit intermediary myself) could handle this with a proof of the actual will to donate, better than someone just sending here a message saying one would donate :)
Seeing that this issue was updated back in 2018 I am wondering if it should not be pushed to a later milestone.The inclusion of WebDav (#38) will make a lot of people, including me, very happy.
Seeing that this issue was updated back in 2018 I am wondering if it should not be pushed to a later milestone.
It makes sense. I planned to implement it in a separate module (moving Dropbox sync to the one as well), but that will take some time to figure out.
With Dropbox's new approach of "only three devices can be linked" for the basic account, this is becoming more important for me. In the meanwhile, I'm exploring what it would mean to set up a webDAV server somewhere for myself instead...
I have been using webdav in 1.8.2 for quite some time already, it works like a charm.
I'm exploring what it would mean to set up a webDAV server somewhere for myself instead...
There are a plenty of WebDAV providers, you don't necessarily have to run your own server.
I have some spare time and am a developer, is anyone working on this? If not I'm going to start. If yes let me know how I can help.
I'm working on this now so if you wanna know sup hit the email on my profile
@komali2 I'd suggest you start using this issue to drop your resources and questions!
Ironically, I've now set up a nextcloud server for myself, but I'm still interested, and I'd be happy to help / provide insight / be a sounding board / etc.
I also don't know what I'm doing but I've never let that stop me before :p
I had been looking into this a little bit, but it seems that the standard google auth libraries might not work unless 3rd party cookies are enabled. E.g. org-web also does not seem to work with google for the same reason. I won't use any solutions personally that require me to use 3rd party cookies, so I lost interest for now. Maybe I misread how this works, and I heard Google is working on a solution for 3rd party cookies, so I keep looking out for this issue and might be able to help in the future.
In the meantime, good luck!
On Fri, Aug 7, 2020 at 12:35 PM Caleb Rogers [email protected] wrote:
fyi i have no fucking idea what i'm doing so nobody get your hopes up
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/orgzly/orgzly-android/issues/25#issuecomment-670679202, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGMK7CPQ27G76RVTSQHHGU3R7RJOPANCNFSM4DB3XCIQ .
I think one option might require some painfully manual setup, such as this setup for calfw: https://github.com/myuhe/org-gcal.el
Basically you would create your own project on GCP to which you can give restricted permissions (only read/write gdrive?) and get a token you can use for authentication through that project
Orgzly could use the Storage Access Framework (since Android 4.4) client API. Any SAF provider - such as Google Drive, Dropbox, OwnCloud #28, SD Card etc. - would then be available through one common interface.
It already does - Orgzly uses
ACTION_OPEN_DOCUMENT_TREEfor "Directory" repo type. It's what opens the system browser.However, support for that intent doesn't seem to be too popular with the providers. See for example nextcloud/android#303. Google Drive and Dropbox don't support it either.
But why then does the Storage Access Framework docs say this?:
The SAF includes the following: Document provider—A content provider that allows a storage service (such as Google Drive) to reveal the files it manages
https://developer.android.com/guide/topics/providers/document-provider
Genuinely curious. This app is literally the first APK I've run on an android emulator on any machine ever so like, I'm totally out of my league here.