DownloadManager.Request.VISIBILITY_VISIBLE_NOTIFY_COMPLETED is
documented as appearing in 3.0 (api 11) but causes a crash on
a GoogleTV 2 (Honeycomb-based) device.
Skipping it for Honeycomb as we do for Gingerbread; your media
goes into the 'Downloads' directory and can be found there, but
there's no notification on completion.
GitHub: https://github.com/wikimedia/apps-android-commons/pull/24
Change-Id: I4b5b0c0ffc0d9bfa8d1ff524d531022ba8f3f9f8
Initial port of the acceptable use tutorial from iOS app. This version uses static images and is not yet animated. Indicator circles on the pager are done using Apache-licensed https://github.com/JakeWharton/Android-ViewPagerIndicator -- imported via maven. Currently the tutorial launches when we reach the login screen (as when first installing the app or creating a new account from system settings). You can either 'back' out of it or page through and hit the 'yes' button.
GitHub: https://github.com/wikimedia/apps-android-commons/pull/20
Change-Id: Ibc444102e28a55bfa7bbae601ff0c56268a0c7dd
Needs some UI love on both selection & intimation, but works otherwise
People can pick from CC BY-SA, CC BY, or CC0. The commons templates
are set using {[self}}, which I think is good enough.
GitHub: https://github.com/wikimedia/apps-android-commons/pull/14
Change-Id: Iffca6f75c63de6fbe61c4dc41b93dd5f692065a5
We were crashing when trying to take a photo if no camera was
present on the device, since no activity can be found for the
camera intent and an exception is thrown.
Work around this by simply checking if the device has a camera
via the package manager feature checks, and hiding the menu item
if relevant.
GitHub: https://github.com/wikimedia/apps-android-commons/pull/13
Change-Id: I635946ed32cf768917db4a8dff0058061e45e6ec
If we ever download an image's original, we'll save its width and
height. This ensures that we don't try to fetch thumbnails that are
larger than the image itself too often, reducing 500s and improving
performance much.
TODO: Save image's width / height during upload process itself
GitHub: https://github.com/wikimedia/apps-android-commons/pull/8
Change-Id: Ice11cfabab96999b0d07b965d4515b47c1fff428
Add support for using Volley to load remote images instead of UIL
1. Gives us Caching
2. Load images at full resolution, rather than hardcode them. This is done by trying to fetch an image at highest width possible for the particular view. If it 500s, we assume that the image is smaller than the requested width and just request the full size image
3. Created a MediaWikiImageView, to which you can pass a Media object and it will display it. Takes care of sizing, etc. Optionally you can also specify a view to use as the 'loading' view.
TODO:
Loading from content:// URIs still use UIL. Need to write a Volley HTTP Stack that can fake responses for content:// URIs.
GitHub: https://github.com/wikimedia/apps-android-commons/pull/1
Change-Id: Ia21a7b19fefa552d5a0b013085d0f5f1f80dc5ff
We can't use formatted strings directly because it breaks with
our localization tools. Grab an HTML string and turn it into
a formatted string.
Localized versions will have to be updated still, but that should
happen automatically at TWN.
Where we don't specifically need action-bar or fragment-related stuff,
it's cleaner to use regular getActivity(). If/when the action bar shows
up in the general support libraries that'll be easier to update.
Saves original file into the SD card "Downloads" directory via
Android's DownloadManager service.
On Gingerbread the notification vanishes after downloda, but we
force the gallery to reindex the downloads area so you can still
manually bump over to Gallery.
On ICS/JB the notification hangs around and can be used to open
the saved file directly.
Note that on Gingerbread we have to download over HTTP because
DownloadManager didn't support HTTPS.
Included copy of stock 'upload' icon, flipped it for 'download'.
Follows sequence 'Foo.jpeg', 'Foo 2.jpeg', 'Foo 3.jpeg' etc until one is
found that doesn't exist, then we send up the upload. This avoids most
typical conflicts scenarios.
Still can produce a conflict if you start uploads near-simultaneously,
but this is better than none.
