
Fix crash when returning to swap after cancelling Fixes #409. The problem was that there was some listeners being added for broadcast events when the swap view was shown. These were never removed, and so cancelling swap, then returning to it would spin up a _new_ activity with new views, while the old listeners were still around. When the old listeners received events, they would try to talk to their associated `Activity`. This no longer existed, so a crash ensued. While I was fixing the specific bug associated with #409, I took the opportunity to make more of the event listeners well behaved in the swap process. I don't think any of them were liable to cause crashes, but were likely to cause some weirdness at some point in time if they were not fixed. *Note:* This swap view was an exercise in moving away from `Fragment`s towards an `Activity` with individual `View`s. I'm going to call this a bit of a failure at this point, because there is so much work that needs to be invested in implementing lifecycle stuff in our custom views. `Fragment`s naturally come with lifecycle methods that are familiar to other Android dev's looking to contribute to this project (even if they are a little difficult to understand at times). Implementing our own custom Views instead still results in similar classes of bugs (i.e. talking to an `Activity` when the view no longer is part of that activity). A classic example of this is in my usage of the `onDetachedFromWindow` function in the `View`. I have no idea if this is the best place to unregister listeners or not. In a Fragment, it would be a matter of `onPause` or one of the more well defined lifecycle methods. Empirically, `onDetachedFromWindow` seems to be well behaved. The other alternative would be for the Activity to explicitly invoke a `onRemoved` type method each view when it knows it is transitioning from one state to the next. However at this point, we are then really into reimplementing `Fragment` land. See merge request !232
F-Droid Client
Client for F-Droid, the Free Software repository system for Android.
Building with Gradle
cd F-Droid
../gradlew assembleRelease
Direct download
You can download the application directly from our site or browse it in the repo.
Contributing
See our Contributing doc for information on how to report issues, translate the app into your language or help with development.
IRC
We are on #fdroid
and #fdroid-dev
on Freenode. We hold weekly dev meetings
on #fdroid-dev
on Tuesdays at 20h UTC, which usually last half an hour.
FAQ
- Why does F-Droid require "Unknown Sources" to install apps by default?
Because a regular Android app cannot act as a package manager on its own. To do so, it would require system privileges (see below), similar to what Google Play does.
- Can I avoid enabling "Unknown Sources" by installing F-Droid as a privileged system app?
This used to be the case, but no longer is. Now the Privileged Extension is the one that should be placed in the system. It can be bundled with a ROM or installed via a zip, or alternatively F-Droid can install it as a system app using root.
License
This program is Free Software: You can use, study share and improve it at your will. Specifically you can redistribute and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
Some icons are made by Picol, Icomoon or Dave Gandy from Flaticon or by Google and are licensed by Creative Commons BY 3.0.
Other icons are from the Material Design Icon set released under an Attribution 4.0 International license.