The StringBufferInputStream is deprecated, because it doesn't know the
encoding of the string it is buffering. This has been changed to use
a ByteArrayInputStream with UTF-8 encoding now.
Also made use of previously unused mimeType parameter to set the
Content-Type header of the response.
Sets a stream handler in FDroidApp which understands bluetooth://
URLs and returns a non-functioning URL handler for such URLs.
The reason it is non-funcitoning is because the openConnection()
function is not being used by the BluetoothDownloader at this point.
In the absense of this, a MalformedURLException is thrown.
The bluetooth stuff is still broken, but it is not broken in
this way any more.
The AppDetails subclass used to be used when you couldn't install apps
directly from the swap workflow. Now we don't send people to app
details, so the activity is unneeded.
The swap progress also now listens for progress broadcasts, rather than
showing an indeterminant progress bar.
Seems to work pretty-alright even when installing multiple apps.
Shows a progress (indeterminent at this stage) bar for each downloading
item, and hides the install button.
InnerView.getToolbarColour() was expecting a @ColorRes, except all views
were returning integers which were the colour value, not a pointer to
the resource as they should have been. Now only one place requires a
call to getResources().getColor() whereas before it was in each view.
Notifications on pre 4.1 devices require a pending intent to work. This
is so that when you touch the intent, it takes you somewhere meaningfull.
Without it, the update process crashes.
Integration branch containing both MR 102 and 107
Given both MR !102 and !107 both stood on eachothers feet to some extent, this branch contains all commits from both in an integration branch. If both @Nutomic and @eighthave are happy that it faithfully kept their changes during the minor merge conflict resolutions, then we can merge this instead of those two branches.
* !102 changed download progress from events + listeners to broadcasts + receivers.
* !107 made use of download progress events + listeners to show a downloading UI that was embedded in the activity, rather than shown as a modal dialog.
The conflicts which arose while I merged these branches together were in `AppDetails`. I made it so that, to the best of my ability, it uses broadcast receivers instead of progress listeners when updating the progress bar. Other than that, the only other conflict was both trying to store a reference to the main button from the UI. The only changes were in naming (mainButton vs btMain) and also in the place where the local variable was assigned (onCreate() vs setupViews() which is called during onCreate() anyway).
After merging, I did some minor cleanups. This is because in the process of checking that my conflict resolution compiled, I thought it best to remove a bunch of warnings from `AppDetails` and others. Turns out that by doing so, I found a bug due to the integration (to do with the `AppDetails` querying the downloader for status in `onResume()` rather than waiting for a broadcast event) so I'm glad I did so.
Let me know what you think, and then after the next stable, we can go ahead and merge this if people are happy.
p.s. I have no idea why GitLab is showing @eighthave's commit at the top of the list of commits, after my integration related commits.
See merge request !114
AppCompat no longer supports progress indicators in the action bar. So
this is not your everyday "Deprecated, but sure, keep using it" job.
Rather, it is "deprecated, and no, we wont even let you use it."
Also removed unused argument and extended AppCompatActivity.
To make things less confusing, this disables the main button on AppDetails
when something is running. During install, it also changes the text of the
button to "Installing..."
This removes lots of boiler plate, makes it much easier to get the info
where it is needed, and puts the code in line with rest of FDroid. The
ProgressListener pattern was forcing a lot of passing the listener
instances around through classes that never used the listener even.
That makes that repo automatically ready for use based on user actions like
adding a new repo, switching an existing repo on, etc.
This also lowers the priority of the "update" menu item since it shouldn't
be needed any more. But leave it for now, just in case.
Having a Context in Downloader means that the communications can be changed
to a LocalBroadcastManager, following the pattern that is in a lot of this
app already.
Since the repo updates are happening in an IntentService, they are already
running in a separate thread. Ironically, the dialog was showing in spite
of that. This removes the dialog entirely and instead puts up a
Notification with the same messages. Ultimately, the "refresh" button
should go away, the repos should be updated whenever someone goes to
install an app, and all APK downloads should also show up in the same
Notification.
This removes UpdateReceiver entirely and replaces it with local broadcasts,
since that is a common pattern in FDroid and Android. It also reduces the
amount of code here.
refs #103https://gitlab.com/fdroid/fdroidclient/issues/103
No need for a reusable Fragment here, its only used in one place. This
changes the structure to be a regular Activity, with all View and Menu
setup in XML files loaded in onCreate().
This also converts the URL to a TextView. Having it editable in this
Activity makes for a confusing user experience. Instead, the "Add Repo"
input should validate the URL and not allow creating repos that don't work.
This also purges the use of UpdateService.UpdateReceiver, it will be going
away in the upcoming commits.
We are not forcing an update, in the sense that we make the update
service run. Rather, we are ensuring that the next update wont return
after doing nothing, with the message "repos already up to date".
In this case, the repo metadata (and hence its etag) is the same,
but we made changes in the client to handle the metadata correctly.
Thus, we don't care that it hasn't changed, we want to update anyhow.
Did this by using the same query which is used to update the icon URLs
after updating the index. To make this same method accessible, without
causing sad database locking, had to expose the method from AppProvider
in a way which would let DBHelper access it. See comments in code for
further explainations.
While there, removed the final lint warning in my Android Studio for
the AppProvider. This was a warning because we could have ended up
iterating over a null object. Although it turns out there was a correct
guard in place which would ensure this didn't happen, it wasn't in such
a way that lint would understand. Thus, I changed the guard condition
around `for( String blah : CommaSeparatedList.make() ) {}` to let lint
relax and not be so pedantic.
Replaced `Switch` with `SwitchCompat`. In the future, should completely remove
F-Droid's `SwitchCompat` class. Fixed paddingLeft/paddingStart, except for some
places where lint complained. Apparantly that is for some Samsung tablets on
Android-16. Will have to create a layout-v17 version in the end for these.
