On certain locales, F-Droid would crash at startup due to #334.
This isn't a proper fix, but rather a workaround that logs what happened and
links to the issue, instead of making F-Droid crash entirely.
Include support for libaccesspoint to control the WiFiAP of a device.
Selecting wifi networks i snow possible by touching the name of the
wifi network in the "Start Swap" screen (sometimes it will say
"No network yet"). This exhibits the same behaviour as the "Join Wifi"
screen used to (and still does) do.
On emulators (is there other devices too?), Bluetooth is unavailable,
but the "Send F-Droid" is still there. I could remove it, but then
people may get confused as to why it is not there. Instead, there is
now a dialog which explains why it can't be sent (no Bluetooth).
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.
Add timeout for Http request
The timeout of HttpURLConnection is 0, which means the request would never return if either connection or read timeouts, and the code would never catch these exceptions.
This patch set explicit timeout value (10s for connection timeout and 40s for read timeout), so the code would catch and handle timeout exceptions as you would expect.
Best,
See merge request !117
Prompt for beta updates
Ready to get merged. 👍
~~This MR is ready to get merged, the last thing that needs to be fixed is [this](72ed814a73 (note_1726274)).~~
This closes#313.
See merge request !112
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.
