Workflow for updating apps

In the current design, apps are updated manually on an individual basis.

@grote would it be possible to allow the user to drag and drop (for example) 5 new .apk files into the repo view (for apps they have previously added), and have them auto-update? So, when you open the app detail view, the latest version would be listed.

@crwinfrey

would it be possible to allow the user to drag and drop (for example) 5 new .apk files into the repo view (for apps they have previously added), and have them auto-update?

From what I can see, this is a big improvement for manually updating apps and is indeed possible to do.

Awesome. Thank you Nico, for the feedback. I will include a place within the design for users to manually upload an .apk to the app detail view, as well. But, for making multiple updates, this feature would be super!

@NicoAlt do we need some sort of target area where the files can be dragged to or can they just be dragged to any place on the page?

@grote While the first is easier to implement, the second is also possible and provides a better user experience in my opinion: http://stackoverflow.com/questions/28226021/entire-page-as-a-dropzone-for-drag-and-drop

Note that drag and drop is only possible with JavaScript enabled. Therefore we need to provide a backup solution in case it's not available.

Yes, if you prefer using the entire page as a dropzone, then there should be a button to upload files shown only if JavaScript is disabled.

Something to consider for the proposed work-flow: What should we do if one of the dragged files is

• not actually an APK?
• an APK, but not an update for the current app?
• an update for the current app, but has a different signature?

changed milestone to %1.0

added bazaar label

mentioned in issue #101 (closed)

mentioned in issue #107 (closed)

@crwinfrey may I propose something?

So when the user uploads multiple files, we add all to the app that are proper updates and refuse all the rest. These can be:

• files that have a different file type than the existing files (e.g. user uploads an image, but the existing files are APKs)
• APKs that does not belong to the current app
• APKs that belong to the current app, but have a different signature

When we encounter any of those, we should provide the user with the filename that she tried to upload and with a reason why it was rejected.

@grote I think your design is great and correct me if I'm wrong but this issue is about the repo view. Your design works perfectly for the app view because it needs to know which apps the files belong to.

I understand this issue that a user drag and drop files in the repo view like he does currently with "browse to upload". The new thing is that we now think about handling updates i.e. files that match to an app already added to a repo.

Right! I was thinking about dragging files into the version section of an app.

When dragging files into the app section of the repo, similar considerations apply though. There we would need to reject:

• possibly forbidden file types (.php, .py)
• APKs that would be an update for an existing app, but already exist or have a wrong signature

So when the user uploads multiple files, we add all to the app that are proper updates and refuse all the rest. These can be:

• files that have a different file type than the existing files (e.g. user uploads an image, but the existing files are APKs)
• APKs that does not belong to the current app
• APKs that belong to the current app, but have a different signature When we encounter any of those, we should provide the user with the filename that she tried to upload and with a reason why it was rejected.

I agree that this makes sense for the app detail view as @NicoAlt mentioned.

When dragging files into the app section of the repo, similar considerations apply though. There we would need to reject:

• possibly forbidden file types (.php, .py)
• APKs that would be an update for an existing app, but already exist or have a wrong signature

This makes sense for adding to the repo index. For .apks that are added here, they would NOT be rejected if

• the key matches an app that is already in the repo AND is a new version
• it's a new app that isn't already in the repo

@grote Can we apply this workflow to other file types (documents, audio, video, etc.)? Do they also have a signature?

added Doing and removed ~2112488 labels

Can we apply this workflow to other file types (documents, audio, video, etc.)? Do they also have a signature?

They don't have a signature unfortunately. We can apply a similar logic when they are uploaded en masse. However, things get even more complicated when one non-apk file should be considered an update of another one.

We can not automatically detect if one file is supposed to be an update for another one. So updates for those need to be uploaded directly in the app edit mode. Then, we could reject certain files when they have a different type than the existing versions. For example, if the first version was a video and then an ebook is uploaded as an update, we would probably need to reject that.

But we can't do much when a ZIP file is uploaded (type OTHER) and then a DMG file is uploaded as an update for the zip file.

@crwinfrey If there's no more UI or worflow to be designed here, we can close this ticket, I think.

The implementation ticket is #107 (closed).

Agreed.

closed

removed Doing label