bug fixes for 0.71
I fixed the compact layout to make more sense. There seems to be something about the appcompat stuff that is preventing it from being short as it was before. There are some other bug fixes here, and I also included the Guardian Project repo by default, but disabled. @CiaranG proposed doing that a while back, now I finally did it!.
See merge request !25
This should help is there is ever multithreaded access to this variable.
This is an unlikely scenario, but the fix is easy.
findbugs reported this issue like this:
Incorrect lazy initialization and update of static field org.fdroid.fdroid.
FDroidApp.selectedApps in org.fdroid.fdroid.views.fragments.
SelectLocalAppsFragment.onActivityCreated(Bundle)
This method contains an unsynchronized lazy initialization of a static
field. After the field is set, the object stored into that location is
further updated or accessed. The setting of the field is visible to other
threads as soon as it is set. If the futher accesses in the method that set
the field serve to initialize the object, then you have a very serious
multithreading bug, unless something else prevents any other thread from
accessing the stored object until it is fully initialized.
findbugs found this problem and reported it like this:
Nullcheck of org.fdroid.fdroid.data.App.installedApk at line 191 of value
previously dereferenced in org.fdroid.fdroid.localrepo.LocalRepoManager.copyApksToRepo(List)
A value is checked here to see whether it is null, but this value can't be
null because it was previously dereferenced and if it were null a null
pointer exception would have occurred at the earlier dereference.
Essentially, this code and the previous dereference disagree as to whether
this value is allowed to be null. Either the check is redundant or the
previous dereference is erroneous.
This restores the Compact Layout being smaller than the normal layout, and
properly centers the icon in both. This stuff could use some refactoring
to work better with all the appcompat styles.
fixes#61https://gitlab.com/fdroid/fdroidclient/issues/61
default_repo_count is not used at all, and the numbering scheme is just a
vestige of that. This switches all the variables to have clear names of
what they are representing.
On Android 4.x, the category menu is showing up as pure black, and looks
very much like an app list item. I've personally witnessed many new users
struggle to find an app because the category is on "What's New" by default
and the app they are looking for is not new. Some even had troubles
remembering about the category menu after I told them. This small change
makes the category dropdown look the same on all Android versions, and
makes it a lot more apparent on newer Android releases.
This is a temporary usability fix until we can do something much better
than the category dropdown menu.
This merge request is a lot of porting code to use Android Support
appcompat-v7, now that it is in place. There are places where old custom
compat layers are replaced by appcompat, and other places like the local repo
stuff, where appcompat allows for full support on platforms older than 11.
onNewIntent() is called because ManageReposActivity is set to "singleTask"
launchMode, but it is only called if ManageReposActivity is already
running. onResume() is always called, and called after onNewIntent() if it
is called, so use onNewIntent() only to set the current Intent, then parse
the Intent only in onResume().
Here is how to reproduce the original bug:
1. Close F-Droid properly and start it again.
2. Click on https://guardianproject.info/fdroid/repo in a browser (and tell
it to open with F-Droid)
3. Hit cancel on the add repo dialog
4. Leave F-Droid open and switch back to the browser
5. Open that link again.
This should result in two dialogs on top of one another. Happened from both
Firefox, Chrome, and Android browsers.
When someone clicks on a URL that F-Droid can accept, i.e. a repo URL, then
Android puts up a chooser where the user can select which app to VIEW the
URL with. That was showing up with the title "Repositories", which is the
title used for that Activity when viewing it. This keeps the Activity
title the same while changing the title in the chooser.
Instead of just sticking whatever URL is in the clipboard into the "Add
Repo" dialog, this attempts to sanitize the URL in case it has some garbage
or came from a QR Code, and therefore was all uppercase (that makes for
smaller QR Codes). It also checks if there is a fingerprint in the query
string of the URL, and sticks that into the fingerprint box.
fixes#50https://gitlab.com/fdroid/fdroidclient/issues/50
The swap stuff will also need to handle incoming Intents that represent
new repos, so the parsing logic is now its own class NewRepoConfig, which
is something like the Repo class, but using getters instead of properties.
Since the new repo data does not change once FDroid receives it, the only
way to set the values of a NewRepoConfig is via the constructor.
This is based on some incomplete work from @pserwylo:
71cb12ef5c (diff-6)
and
71cb12ef5c (diff-7)
AppListFragmentPageAdapter is a subclass of FragmentPagerAdapter, so it
should include the same spelling to make that clear and easy to trace,
grep for, etc.
Now that the Fragment is embedded in the Activity, and the menu has been
moved to the Activity in ActionBar style, most of the utility functions and
the Dialogs can be based out of the Activity, which is how they are
designed to work. This makes things work a lot easier.
fixes#3https://gitlab.com/fdroid/fdroidclient/issues/3
This allows the main menu to act like a proper ActionBar using appcompat.
It also allows for making the search happen live on the ListView, rather
than having to launch a separate Activity to show the results.
I went through all of the source code replacing anything that is now
possible using appcompat-v7. appcompat-v7 is the official way to handle
backwards compatibility, and it is supported by Google and others. Using it
as much as possible should make the code more maintainable and readable by
others since they'll be used to seeing the appcompat-v7 patterns from other
projects.
fixes#51https://gitlab.com/fdroid/fdroidclient/issues/51fixes#42https://gitlab.com/fdroid/fdroidclient/issues/42
Previously, it was using the native android.widget.SearchView.
Now it uses the widget from appcompat. For good measure, I also
made it so that the search button is always in the action bar,
rather than being hidden behind a menu sometimes.
Do so by:
- Making RepoDetailsFragment/RepoListFragment retain their instances
- Move the management of the update repo dialog to UpdateReceiver
- Let the fragments tell the UpdateReceiver when to show/hide
HTTP Proxy preference for Tor, I2P, etc; add jenkins script
This adds a preference to set the HTTP Proxy so that FDroid can funnel all traffic through Tor, I2P, psiphon, or any other HTTP proxy.
Also, there is a script for jenkins to run before calling `ant clean debug` for the whole setup process. This script sets the `versionCode` to the UNIX time in seconds, and adds the date/time to the `versionName` so that the debug builds are very clearly marked from real builds, and they will automatically update when included in a debug repo:
https://dev.guardianproject.info/issues/2601
Jenkins will then call ant directly after running this script. This then sets
the debug builds made by Jenkins to have a versionCode of the UNIX time in
seconds and adds the data to the versionName. This clearly marks these as
debug builds and also makes it possible to have an fdroid repo of debug builds
that will automatically update after each build.
Taken from the gradle plugin user guide:
With Android KitKat (buildToolsVersion 19) you can use the diamond operator,
multi-catch, strings in switches, try with resources, etc.
Note that you can use minSdkVersion with a value earlier than 19, for all
language features except try with resources. If you want to use try with
resources, you will need to also use a minSdkVersion of 19.
You also need to make sure that Gradle is using version 1.7 or later of the
JDK. (And version 0.6.1 or later of the Android Gradle plugin.)
Appcompat on top of pserwylo
This is a refactor of @pserwylo's !19 to get appcompat building with `ant` and Eclipse. I reviewed @pserwylo's commits and they are ready to go as they are in this merge request.
Both preferencefragment and appcompat-v7 submodules need the
android-support-v4.jar to be included in their respective libs/ dirs in
order for ant to build those projects.
This was a bit more complex than all the other views, because it supports
rotation, and different views for when it is rotated. The end result is
that the way in which the views were constructed needed to be completely
redone.
In the process, I also moved the layout of the app summary to a Relative
Layout. This adds more flexibility, and is also the suggested layout
for complex views (as apposed to nested linear layouts). I believe this
is due to the performance of relative vs linear layotus.
It was aprticularly hard to figure out what was going on
when rotating an Activity which had a list fragment
that had another fragment as a header. I don't think fragments
were designed to work like this, but I believe it is all working
as expected now.
Conflicts:
src/org/fdroid/fdroid/Preferences.java
NOTE: I don't know how android will go with adding a new property
to a string-array resource, but not having it translated everywhere.
Will it struggle because the EN version has three values for "theme",
but other translations only have two?
