Refactor account storage and camera upload #444

forouher · 2015-11-15T16:42:32Z

This PR refactors camera upload and the account storage. To be more precise, it does two things:

It refactors the account storage. Instead of storing accounts in an SQL table, they are now stored in an Android-provided storage API. This is only done to allow us to do thing number 2.
refactor camera upload. this changes most of the internal structure of the camera upload procedure. I tried to keep the UI as unchanged as possible, though.

The patches have more detailed explanations in their individual commit messages.

They should hopefully address the following issues:

issue #277 (Camera upload function dumps all subdir files into single dir)
issue #301 (Inconsistency in camera upload sync)
issue #311 (second suggestion: target repo sub directories)
issue #336 (file duplication when doing a full resync)
issue #375 (Picture upload not acting as service?)
issue #423 (Pictures never upload) [maybe. not sure what's going on there]

Some further notes:

This patch set includes the patches from PR Remember browse position when re-entering Seadroid via Launcher icon #422 as the same files are touched and thus to avoid merge conflicts.
Originally I also wanted to refactor the TransferService into a SyncAdapter. However this patchset took much longer than expected so I postponed the TransferService refactoring for a later time.
The Java 7 patch is not necessary, just a convenience. I can remove it, if you want to stay compatible with Java 6.
Due to the large number of changes, there might well be bugs remaining. ;) I've tested this patchset for some days in the emulator and on an Android 5.1 phone and will amend commits if I find more issues.
Please be especially aware of Shibboleth accounts and SeafilePro features. I had to touch code for both, but was not able to test the changes.
To the best of my (and AndroidStudio's) knowledge this should all be compatible with API level 8. However I didn't do any tests on an API 8 device.

While this PR adds a feature or two, the main reason for its existence is to bring more stability to camera upload mechanism. So, to avoid replacing 5 old bugs with 10 new ones, this PR will need some thorough testing. Especially on

phones with Android 4.x or 2.x
non-standard camera apps

[EDIT: I realized maybe I should write a couple of lines on the user-visible changes of this PR. Here it goes:]

Accounts

Accounts can now be created/removed via Android Settings -> Account. It uses the same activities and should behave pretty much the same.
The "Pick type of Seafile server" dialog had to be refactored into an Activity with a list. Actually I'm not quite happy with that and I think the old Dialog looked slightly better (building Android UIs is still new to me). Unfortunately I couldn't figure out a way to get the old Dialog working reliably, as I had to move it out of AccountsManager into the SeafileAuthenticatorActivity.
Accounts are now stored seperately from all other SQL tables. This means that they will survive the cleaning of all app data (which is probably more useful to developers than anyone else ;)

Camera upload

In Android Settings -> Account -> Seafile one can now see the timestamp of the last successfull camera upload sync. Also the user can manually trigger a sync there.
The directory chooser for picking local directories to upload is gone. It has been replaced with a list of media albums (basically the same list the Android gallery shows). If people had previously configured manually a list directories, after this patch the settings will revert back to the "Auto sync" setting.
The sync will now skip files that are already on the server and have the same file name and size.
The sync will now place image properly in subfolders on the server. The folders are named after the gallery albums (internally called "buckets").
As a target, subdirectories of repositories are now also possible.
Monitoring of the media store will now start at phone boot and after an APK upgrade.
Resyncs will happen regularily (about every 24h, scheduled by the Android OS)
In case of network errors, Android does an automatic retry with exponential backoff
Hard errors during sync (remote repo gone, auth error) are now made visible to the user as a notification.

Migration

Accounts are migrated.
Default account is not migrated (due to settings refactoring). So the user has to select her preferred account once after upgrade.
Camera settings are migrated, except the "custom local folder" setting. That one will revert back to "auto select folders".
Camera sync will resync everything after upgrade. As the target folders are now different (in most cases "Camera" instead of "Camera Uploads") this will cause a full reupload of all local images.

I'll be happy to address any upcoming bugs, issues and questions.

Logan676 · 2015-11-21T08:45:54Z

@forouher I have to say it is an elegant way to implement the camera uploads by CameraSyncService&SyncAdapter. The gallery albums feature is awesome, the implementation of subdirectories-of-repositories targets users requirements, the code style is neat and clean, our customized utility methods were accurately used and even avoid several potential bugs, but there are some issues to talk with you.

better to exclude the modifications of Accounts module, as this patch mainly focus on camera uploads
better to keep the transfer list working, e.g. displaying uploading progress (list) in transfer list
better to keep the "Choose a Seafile Server" dialog unchanged
have to use database to manage the media uploading infos because it stores more detailed infos and works more stable and robust
have to create folder(s) under My Photos, right, dumps all subdirectories into a single directory, instead of under the root directory

This patch set includes the patches from PR #422 as the same files are touched and thus to avoid merge conflicts.

better to remove that

It refactors the account storage. Instead of storing accounts in an SQL table, they are now stored in an Android-provided storage API.

why not create a separate patch? Please notice that the Account migration patch is at a low priority according to our agenda, anyway I still being excited to welcome your PRs.

refactor camera upload. this changes most of the internal structure of the camera upload procedure. I tried to keep the UI as unchanged as possible, though.

Although the UI keeps the same, the transfer list doesn`t show any uploading (or downloading) progress any more. Always show "No upload tasks yet"

[EDIT: I realized maybe I should write a couple of lines on the user-visible changes of this PR. Here it goes:]

That`s the way to make people understand your code even faster, 👍

The "Pick type of Seafile server" dialog had to be refactored into an Activity with a list. Actually I'm not quite happy with that and I think the old Dialog looked slightly better (building Android UIs is still new to me). Unfortunately I couldn't figure out a way to get the old Dialog working reliably, as I had to move it out of AccountsManager into the SeafileAuthenticatorActivity.

I will get this done for you after it was merged, just go ahead to other implementations.

Originally I also wanted to refactor the TransferService into a SyncAdapter. However this patchset took much longer than expected so I postponed the TransferService refactoring for a later time.

Big welcome! 😸

forouher · 2015-11-22T17:53:05Z

@Logan676 thanks for your feedback!

better to exclude the modifications of Accounts module, as this patch mainly focus on camera uploads
why not create a separate patch? Please notice that the Account migration patch is at a low priority according to our agenda, anyway I still being excited to welcome your PRs.

Separating these two patches would require a lot of work. SyncProvider /depends/ on having an Android Authenticator. I could separate them, however the code would probably look quite ugly. In the end it would be a different patch entirely.

I agree that the Account Authenticator change is not an important patch, as it neither fixes a bug nor adds a user-visible feature. However from a code perspective, I'd strongly suggest to do this refactoring:

It makes the implementation of the camera SyncProvider more saner and readable.
It also cleans up other parts of the account handling (e.g. by giving each account a unique account name).

So, unless there is a fundamental problem with Account Authenticator refactoring (and I'm happy to address any other issues that come up), I'd argue for merging these two patches at the same time.

If you consider this PR as too big and are worried about potential complications, an alternative would be to merge ec94702 first. And then fdc36f6 at a later date.

better to keep the transfer list working, e.g. displaying uploading progress (list) in transfer list

Good point, I didn't notice that. Hm... To add entries to the transfer list, I'd have to use the TransferManager. I wanted to avoid that as it would be one more point of failure (creating the service, what to do if it dies,...).

But yeah, having entries in the transfer list would be a good thing. I'll look into it.

have to use database to manage the media uploading infos because it stores more detailed infos and works more stable and robust

In what situations would my approach (filter images by "date_added") fail?

I like this approach because it is simple (less code) and because it avoids the issue presented in #301.

have to create folder(s) under My Photos, right, dumps all subdirectories into a single directory, instead of under the root directory

So, if the user selects "Server S" / "Repo R" / "Folder A".
Then the fotos should be uploaded into

Server S / Repo R / Folder A
- "My Photos"
  - "Camera"
    - "photo1.jpg"
    - "photo2.jpg"
  - "Album X"
    - "photo1.jpg"
    - "photo2.jpg"
  - "Album Y"
    - "photo1.jpg"
    - "photo2.jpg"

Correct? No problem, I'll amend a patch.

Logan676 · 2015-11-23T02:52:13Z

I wanted to avoid that as it would be one more point of failure (creating the service, what to do if it dies,...).

Before I started the service by calling public final void startForeground (int id, Notification notification) to make this service run in the foreground in case that it dies.

So, if the user selects "Server S" / "Repo R" / "Folder A".
Then the fotos should be uploaded into

Right, the uploaded photo structure is correct.

Logan676 · 2015-11-24T02:21:04Z

In what situations would my approach (filter images by "date_added") fail?

Camera sync will resync everything after upgrade. As the target folders are now different (in most cases "Camera" instead of "Camera Uploads") this will cause a full reupload of all local images.

At least it fails to recognize those already uploaded photos. From users perspective, its bad if they find that all uploaded (back-up) photos have to upload again after upgraded the App. Also users have no idea about how to distinct "Camera Uploads" with "My Photos" except the App explicitly shows a guiding page or some hint infos to show the differences.

I think its better to add a small feature each time (when creating a PR) because its easier for testing, easier to ensure the quality and faster to release a new version.

forouher · 2015-11-26T18:34:35Z

@Logan676 Okay. I'm mostly convinced to have found the issue in #423 and will soon start on implementing the changes discussed above. Coding and testing might take a couple of weeks, I'll notify you when its ready.

Logan676 · 2015-11-28T04:35:41Z

@forouher Although I have applied gradle build structure to master branch, please just ignore this changes with you pull request because it compares with develop branch, and I will keep develop branch unchanged until this pull request was resolved.

forouher · 2015-12-07T16:29:55Z

These patches should address the issues discussed above, especially:

use TransferService
use CameraDbHelper (you were right, reverting that back was a good idea).
Put media into a subdirectory "My Photos"

Also I've fixed some issues that came up during testing in issue #423 and the one mentioned in issue #451.

If there is anything else, please let me know!

Logan676 · 2015-12-15T02:06:36Z

src/com/seafile/seadroid2/account/Account.java

+    /**
+     * Type of the account (currently there is only one type)
+     */
+    public final static String ACCOUNT_TYPE = "com.seafile.seadroid2";


I think it`s better to append more strings, e.g. "com.seafile.seadroid2.account.type"

Logan676 · 2015-12-24T02:31:14Z

@forouher I tested this patch via seacloud.cc, and there are seveal issues listed as below.

Settings --> Turn on Camera Upload --> Configuration Helper --> Select Remote Library --> click a repo. Expected behavior is the checked mark was shown, but now it nav into the repo. That will lead up to an incorrect behavior, and user can created the "My Photos" and its subfolders recursively.
- Server S / Repo R / Folder A
- "My Photos"
  - "Camera"
    - "photo1.jpg"
    - "photo2.jpg"
  - "Album X"
    - "photo1.jpg"
    - "photo2.jpg"
  - "Album Y"
    - "photo1.jpg"
    - "photo2.jpg"
  - "My Photos"
    - "Camera"
      - "photo1.jpg"
      - "photo2.jpg"
    - "Album X"
      - "photo1.jpg"
      - "photo2.jpg"
    - "Album Y"
      - "photo1.jpg"
      - "photo2.jpg"
LIBRARIES tab --> the repo you chose to back up photos --> MyPhotos (the folder icon is incorrect) --> nav into the foder --> the folder icons of its sub folders are incorrect as well. see screenshot below.
Upload Failed (no photo was uploaded)

12-23 11:55:01.639 10183 10603 I CameraSyncAdapter: sync aborted because of IO or server-side error.
12-23 11:55:01.639 10183 10603 I CameraSyncAdapter: SeafException{code=520, msg=UNKNOWN STATUS CODE}
12-23 11:55:01.639 10183 10603 I CameraSyncAdapter:     at com.seafile.seadroid2.SeafConnection.checkRequestResponseStatus(SeafConnection.java:1109)
12-23 11:55:01.639 10183 10603 I CameraSyncAdapter:     at com.seafile.seadroid2.SeafConnection.getUploadLink(SeafConnection.java:521)
12-23 11:55:01.639 10183 10603 I CameraSyncAdapter:     at com.seafile.seadroid2.SeafConnection.uploadFile(SeafConnection.java:567)
12-23 11:55:01.639 10183 10603 I CameraSyncAdapter:     at com.seafile.seadroid2.data.DataManager.uploadFileCommon(DataManager.java:558)
12-23 11:55:01.639 10183 10603 I CameraSyncAdapter:     at com.seafile.seadroid2.data.DataManager.uploadFile(DataManager.java:543)
12-23 11:55:01.639 10183 10603 I CameraSyncAdapter:     at com.seafile.seadroid2.transfer.UploadTask.doInBackground(UploadTask.java:86)
12-23 11:55:01.639 10183 10603 I CameraSyncAdapter:     at com.seafile.seadroid2.transfer.UploadTask.doInBackground(UploadTask.java:1)
12-23 11:55:01.639 10183 10603 I CameraSyncAdapter:     at android.os.AsyncTask$2.call(AsyncTask.java:295)
12-23 11:55:01.639 10183 10603 I CameraSyncAdapter:     at java.util.concurrent.FutureTask.run(FutureTask.java:237)
12-23 11:55:01.639 10183 10603 I CameraSyncAdapter:     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
12-23 11:55:01.639 10183 10603 I CameraSyncAdapter:     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
12-23 11:55:01.639 10183 10603 I CameraSyncAdapter:     at java.lang.Thread.run(Thread.java:818)
12-23 11:55:01.640 10183 10603 D CameraSyncAdapter: Cancelling remaining pending tasks (if any)
12-23 11:55:01.642 10183 10603 D CameraSyncAdapter: disconnecting from TransferService

But it succeed when I switched to another server, and it works as expected.

It handles signing out the account correctly, but what about switching account? I noticed the configuration stay the same after changed to another account. Better stop the uploading and clear up the data.

Logan676 · 2015-12-24T02:37:35Z

src/com/seafile/seadroid2/cameraupload/CameraSyncAdapter.java

+                    // there is already a file. move it away.
+                    dataManager.rename(targetRepoId,
+                            Utils.pathJoin(serverPath, dir.name),
+                            dir.name + " (renamed by Seadroid)",


better to use renamed by Seafile and move it to strings.xml for the sake of i18n

Logan676 · 2015-12-24T09:54:38Z

if you take a new photo by camera, it always fail to upload.

forouher · 2015-12-24T13:15:05Z

I'll create an account on seacloud.cc and try to reproduce the issues you observed.

Regarding your comment:

Settings --> Turn on Camera Upload --> Configuration Helper --> Select Remote Library --> click a repo. Expected behavior is the checked mark was shown, but now it nav into the repo. That will lead up to an incorrect behavior, and user can created the "My Photos" and its subfolders recursively.

That was by design, so users can place photos into subdirectories (as suggested in #311). Most of the code to allow selecting subdirectories was already there, I just fixed it up. In case you don't like that functionality, I could easily disable it again.

Regarding your comment:

It handles signing out the account correctly, but what about switching account? I noticed the configuration stay the same after changed to another account. Better stop the uploading and clear up the data.'

So, camera upload should disable itself if the user switches to another account via the AccountsActivity? I don't like that. I use 2+ Seafile servers and sometimes switch between them in Seadroid. If camera upload disabled itself every time I switched the account, that would be a real nuisance.

Logan676 · 2015-12-25T08:29:41Z

That was by design, so users can place photos into subdirectories (as suggested in #311). Most of the code to allow selecting subdirectories was already there, I just fixed it up. In case you don't like that functionality, I could easily disable it again.

Please disable that, we don`t plan to support that feature. Since we created "My Photos" under the root of a repo, the #311 will not be fixed.

forouher · 2015-12-25T08:38:06Z

Please disable that, we don`t plan to support that feature. Since we created "My Photos" under the root of a repo, the #311 will not be fixed.

Alright, will do.

Btw, I could not reproduce the issue you reported regarding seacloud.cc. I tested it yesterday and today. Upload and file viewing work fine. Maybe it was just a network error?

Logan676 · 2015-12-25T08:54:47Z

So, camera upload should disable itself if the user switches to another account via the AccountsActivity? I don't like that. I use 2+ Seafile servers and sometimes switch between them in Seadroid. If camera upload disabled itself every time I switched the account, that would be a real nuisance

agree and we will keep that.

About the issue

if you take a new photo by camera, it always fail to upload.

I can upload successfully now.

Btw, I could not reproduce the issue you reported regarding seacloud.cc. I tested it yesterday and today. Upload and file viewing work fine. Maybe it was just a network error?

I will look into it.

forouher · 2015-12-25T09:59:35Z

These patches should address all the issues you've noticed up to now.

Please be aware that merging commit bc5a2df will remove your existing accounts on your development phone as that patch renames the account type.

forouher · 2015-12-26T09:01:04Z

src/com/seafile/seadroid2/cameraupload/CameraUploadManager.java

-    }
+    public void performFullSync() {
+        Bundle b = new Bundle();
+        b.putBoolean(ContentResolver.SYNC_EXTRAS_INITIALIZE, true);


Good question. See here:

https://github.com/forouher/seadroid/blob/refactor/account_and_camera_upload/src/com/seafile/seadroid2/cameraupload/CameraSyncAdapter.java#L233

Logan676 · 2015-12-26T09:34:02Z

Please be aware that merging commit bc5a2df will remove your existing accounts on your development phone as that patch renames the account type.

If changing the account type will remove existing accounts, that`s not what I meant to. Because users will feel really bad after upgrade to the new version. Another worry is users have to start a refresh upload since we have rewritten the camera upload module and created a completely different remote folder "My Photos", I wonder if they have enough patience and kindness to accept that. To decrease the effects as much as possible, we would better to revert the modifications on account type part and sorry for the comment.

forouher · 2015-12-26T11:21:21Z

No, sorry, you missunderstood. Its just YOU (as you've allready using this PR) will loose the accounts. :)

Am 26. Dezember 2015 10:34:02 MEZ, schrieb Logan Guo notifications@github.com:

Please be aware that merging commit bc5a2df will remove your existing
accounts on your development phone as that patch renames the account
type.

If changing the account type will remove existing accounts, that`s not
what I meant to. Because users will feel really bad after upgrade to
the new version. Another worry is users have to start a refresh upload
since we have rewritten the camera upload module and created a
completely different remote folder "My Photos", I wonder if they have
enough patience and kindness to accept that. To decrease the effects as
much as possible, we would better to revert the modifications on
account type part and sorry for the comment.

Reply to this email directly or view it on GitHub:
#444 (comment)

forouher · 2015-12-26T11:35:16Z

Regarding the "My Photos" change, I could add some backwards compability. Currently its Christmas here, I'll write up a patch in a couple of days.

Dariush

Am 26. Dezember 2015 10:34:02 MEZ, schrieb Logan Guo notifications@github.com:

Please be aware that merging commit bc5a2df will remove your existing
accounts on your development phone as that patch renames the account
type.

If changing the account type will remove existing accounts, that`s not
what I meant to. Because users will feel really bad after upgrade to
the new version. Another worry is users have to start a refresh upload
since we have rewritten the camera upload module and created a
completely different remote folder "My Photos", I wonder if they have
enough patience and kindness to accept that. To decrease the effects as
much as possible, we would better to revert the modifications on
account type part and sorry for the comment.

Reply to this email directly or view it on GitHub:
#444 (comment)

Logan676 · 2015-12-27T03:38:31Z

src/com/seafile/seadroid2/cameraupload/CameraSyncService.java

+    public void onCreate() {
+        synchronized (sSyncAdapterLock) {
+            if (sSyncAdapter == null) {
+                sSyncAdapter = new CameraSyncAdapter(getApplicationContext(), false);


Why not passing true to initialize the sync adapter?

Good question. We need to do initialization manually (clearing the photo database). I'll add a comment to explain this.

…pload targets this again simplifies the code a bit

as suggested by Logan676

…tible Make the structure to be: - Server S / Repo R - "Camera Uploads" - Media from bucket "Camera" (backwards compatibility) - "Album X" - Media from bucket "Album X" - "Album Y" - Media from bucket "Album Y" this way, existing photos uploaded by previous versions of Seadroid won't be uploaded again as they will be placed in the same directory as before.

forouher · 2016-01-05T20:59:59Z

Okay, I've implemented your suggestions and did the rebase.

I've added a patch (a21f844) that changes the directory structure on the server to the following:

Server S / Repo R
- "Camera Uploads"
  - Media from bucket "Camera" (backwards compatibility)
- "Album X"
  - Media from bucket "Album X"
- "Album Y"
  - Media from bucket "Album Y"

You were worried that changing the directory layout on the server might give discomfort to existing users. This directory layout might make the upgrade more transparent for users.

The idea is to automatically rename the bucket "Camera" to "Camera Uploads". This should preserve backwards compatibility for existing users of the Camera Upload feature.

In case you prefer the previously implemented approach I could easily revert it.

schwabe · 2016-01-08T10:03:02Z

I tried looking into this PR, but I have trouble building it. It does not contain a build.gradle and the ant build freaks out on my system. It seems that this PR is based on develop instead of master.

forouher · 2016-01-08T11:27:50Z

@schwabe Ah yes, the build system in this PR is still based on mvn. Hang on, I'll build and upload an apk for you to test.

forouher · 2016-01-08T12:20:05Z

@schwabe https://github.com/forouher/seadroid/releases/download/account_and_camera_upload_tag/seadroid_a21f844.apk

schwabe · 2016-01-08T12:42:22Z

@forouher Thanks! I resigned and installed that file on my phone.
Upgrade/Downgrad process worked without hassle.

My Pictures are getting reuploaded in a different folder (100Android) but that could by design since with the stock seadroid version (with my crude hack) the pictures are not uploaded at all.

forouher · 2016-01-08T13:40:05Z

@schwabe Thats good to hear! Ah, that folder name was not intended. Thanks for pointing that out, will amend a fix.

the previous commit tried to put all camera-related media into the folder "Camera Uploads". However it missed that there are actually three possible bucket names for camera-related media. This patch addresses that.

forouher · 2016-01-08T13:51:51Z

@schwabe What is the name of the folder on the server? Is it exactly "100Android" ?

schwabe · 2016-01-08T14:51:40Z

@forouher No it is 100ANDRO to be precise. Same as on the Android device. (/storage/sdcard1/DCIM/100ANDRO)

forouher · 2016-01-08T15:48:48Z

@schwabe Ah, good. That bucket name will be covered by the heuristics (Android has some beautiful APIs. Media storage isn't one of them ;)

Logan676 · 2016-01-09T06:09:12Z

In case you prefer the previously implemented approach I could easily revert it.

We have discussed it, and we prefer the previous one because it is kind of mess to put so many folders under the root directory of the repo, so please revert it.

Refactor account storage and camera upload

Logan676 · 2016-01-13T08:30:01Z

@forouher Is it possible to trigger "instant sync" in order that user can see the uploading progress in Transfer list? Users may not realized that they can go to Settings -> Account -> Seafile -> Sync to trigger instant sync and we want to make that more obvious after the sync service was started. Now it works fine if user browsing under the target repo and dir, folders can be created and photo can be uploaded instantly. But if you go to Transfer list, mostly you need to wait for a while till the progressing list shows up. Same thing happens when taking new photos. Any ideas?

To implement the feature as discussed above, can we simply change the flag to be

SYNC_EXTRAS_EXPEDITED

Forces the sync to start immediately. If you don't set this, the system may wait several seconds before running the sync request, because it tries to optimize battery use by scheduling many requests in a short period of time.

in performFullSync of CameraUploadManager.java and onPerformSync of CameraSyncAdapter.java.

forouher · 2016-01-13T12:31:09Z

You want to add a button that allows the user to force an immediate manual camera sync?

I've never tried SYNC_EXTRAS_EXPEDITED. From the documentation, yes, it should schedule an immediate sync.

But we should not add that flag to all the existing onPerformSync() calls. Android adds a delay precisely to save battery (e.g. it tries to group pending syncs from multiple apps, wait for good 3G signal, whatever).

For such a "Sync Now" button, we could add a new method to CameraUploadManager:

    public void performManualImmediateSync() {
        Bundle b = new Bundle();
        b.putBoolean(ContentResolver.SYNC_EXTRAS_EXPEDITED, true);

        Account cameraAccount = getCameraAccount();
        if (cameraAccount != null)
            ContentResolver.requestSync(cameraAccount.getAndroidAccount(), AUTHORITY, b);
    }

That method could be called by the main thread.

forouher · 2016-01-13T12:33:55Z

Another important point to be aware is that calling CameraUploadManager.perform*Sync() will currently not overwrite the data plan restrictions.

forouher · 2016-01-13T12:38:44Z

[I'm not going to have much time over the next days, so I'm only writing up ideas here.]

Also it might be possible to query the timestamp of the latest succesful sync from the SyncAdapter. Displaying that timestamp in Settings (or the Transfer list) might give the user a better understanding of how the camera upload works.

Logan676 · 2016-01-14T08:57:11Z

we will drop that then.

forouher mentioned this pull request Nov 20, 2015

Pictures never upload #423

Closed

Logan676 added this to the 2.0 milestone Nov 21, 2015

forouher mentioned this pull request Nov 30, 2015

If one file fails to upload, all subsequent ones are not even tried #451

Closed

Logan676 reviewed Dec 15, 2015
View reviewed changes

Logan676 reviewed Dec 24, 2015
View reviewed changes

forouher reviewed Dec 26, 2015
View reviewed changes

Logan676 reviewed Dec 27, 2015
View reviewed changes

forouher added 5 commits January 5, 2016 20:50

CameraUpload: remove the ability to select subdirectories as camera u…

8a48d73

…pload targets this again simplifies the code a bit

CameraUpload: fix directory creation

7dff24f

add callback for newer frameworks

cb90c59

as suggested by Logan676

CameraSyncAdapter: add comment to explain autoInitialize

165f6c9

Rename camera upload authority

7f58e8d

forouher force-pushed the refactor/account_and_camera_upload branch from 0844ab7 to ffb92e2 Compare January 5, 2016 20:19

fix compile error introduced by rebase

6c9f6e9

forouher force-pushed the refactor/account_and_camera_upload branch from ffb92e2 to 6c9f6e9 Compare January 5, 2016 20:21

forouher mentioned this pull request Jan 7, 2016

Fix not uploading from external scared on SONY Z5 compact #464

Closed

Camera Upload: fix previous commit regarding target folder

720296c

the previous commit tried to put all camera-related media into the folder "Camera Uploads". However it missed that there are actually three possible bucket names for camera-related media. This patch addresses that.

Logan676 added a commit that referenced this pull request Jan 9, 2016

Merge pull request #444 from forouher/refactor/account_and_camera_upload

c26341b

Refactor account storage and camera upload

Logan676 merged commit c26341b into haiwen:develop Jan 9, 2016

forouher deleted the refactor/account_and_camera_upload branch January 11, 2016 09:08

werkkrew mentioned this pull request May 2, 2016

Android and iOS Apps Inconsistent #515

Closed

Refactor account storage and camera upload #444

Refactor account storage and camera upload #444

Conversation

forouher commented Nov 15, 2015

Logan676 commented Nov 21, 2015

forouher commented Nov 22, 2015

Logan676 commented Nov 23, 2015

Logan676 commented Nov 24, 2015

forouher commented Nov 26, 2015

Logan676 commented Nov 28, 2015

forouher commented Dec 7, 2015

Logan676 Dec 15, 2015

Choose a reason for hiding this comment

Logan676 commented Dec 24, 2015

Logan676 Dec 24, 2015

Choose a reason for hiding this comment

Logan676 commented Dec 24, 2015

forouher commented Dec 24, 2015

Logan676 commented Dec 25, 2015

forouher commented Dec 25, 2015

Logan676 commented Dec 25, 2015

forouher commented Dec 25, 2015

forouher Dec 26, 2015

Choose a reason for hiding this comment

Logan676 commented Dec 26, 2015

forouher commented Dec 26, 2015

forouher commented Dec 26, 2015

Logan676 Dec 27, 2015

Choose a reason for hiding this comment

forouher Jan 5, 2016

Choose a reason for hiding this comment

forouher commented Jan 5, 2016

schwabe commented Jan 8, 2016

forouher commented Jan 8, 2016

forouher commented Jan 8, 2016

schwabe commented Jan 8, 2016

forouher commented Jan 8, 2016

forouher commented Jan 8, 2016

schwabe commented Jan 8, 2016

forouher commented Jan 8, 2016

Logan676 commented Jan 9, 2016

Logan676 commented Jan 13, 2016

forouher commented Jan 13, 2016

forouher commented Jan 13, 2016

forouher commented Jan 13, 2016

Logan676 commented Jan 14, 2016