Some were wrapped in BuildConfig.DEBUG, some weren't. Move all of them to
debugLog.
The ones that require building complex strings are left with an explicit
BuildConfig.DEBUG if so that the strings aren't constructed.
Since now we don't have problems with list item height, we can use two
different text labels for unsigned and unverified repositories
indication. Code now only switches visibility for them.
This is technical detail that should not be exposed to users, at least
not before repositories list which are the main data in the activity.
Last update label didn't work properly anyway: it was not updated on
repositories refresh, just on activity creation.
Only enable the light if it's a default. The vibration was causing issues
since we don't have the vibrate permission, and the sound is unnecessary.
Fixes#346.
Found it when trying to add a repo manually:
E/AndroidRuntime(30549): java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String java.lang.String.replaceAll(java.lang.String, java.lang.String)' on a null object reference
E/AndroidRuntime(30549): at org.fdroid.fdroid.views.ManageReposActivity$AddRepo.normalizeUrl(ManageReposActivity.java:547)
E/AndroidRuntime(30549): at org.fdroid.fdroid.views.ManageReposActivity$AddRepo.validateRepoDetails(ManageReposActivity.java:358)
E/AndroidRuntime(30549): at org.fdroid.fdroid.views.ManageReposActivity$AddRepo.access$700(ManageReposActivity.java:218)
E/AndroidRuntime(30549): at org.fdroid.fdroid.views.ManageReposActivity$AddRepo$4.afterTextChanged(ManageReposActivity.java:342)
E/AndroidRuntime(30549): at android.widget.TextView.sendAfterTextChanged(TextView.java:7698)
Analogous to the server commit that removes it on its side. If an index
includes it, we will fail silently since unrecognised tags are ignored.
SQLite doesn't allow deleting columns, so don't do a DB version bump to try to
remove it. It will be gone on new installs, and it doesn't keep current
installs from working. Tested both cases.
This avoids problems in a few corner cases:
* The description is empty (it would probably throw an exception)
* The description doens't end in newlines (as seen in #422)
For the general case that was already working, the result is the same.
The solution is really to get rid of the Fragment and do everything in the
Activity, especially since this nullguard will probably leave things in a
not good state. But that's better than a crash, I think.
W java.lang.NullPointerException
W at org.fdroid.fdroid.views.fragments.AvailableAppsFragment$CategoryObserver.onChange(AvailableAppsFragment.java:88)
W at org.fdroid.fdroid.views.fragments.AvailableAppsFragment$CategoryObserver.onChange(AvailableAppsFragment.java:103)
W at android.database.ContentObserver.dispatchChange(ContentObserver.java:163)
W at android.database.ContentObserver$Transport.onChange(ContentObserver.java:195)
W at android.database.IContentObserver$Stub.onTransact(IContentObserver.java:60)
W at android.os.Binder.execTransact(Binder.java:404)
W at dalvik.system.NativeStart.run(Native Method)
The repo.fingerprint logic is based on null meaning that the fingerprint
has not been set. This ensures that a "" does not sneak in somehow as a
valid fingerprint.
For Strings that are meant to be displayed to humans, using the default
Locale makes sense. But this String is meant to be parsed by code, so it
should force the Locale to make sure the digits are always rendered in the
same format.
As per !140, some languages require different translations for an app being
installed and the tab name for installed apps. Namely, one is plural while the
other isn't. Separate the two.
The Bonjour stuff takes a while to start, and isn't strictly neccesary
in order to swap over WiFi. Rather, it is more of a convenience. Also,
it was causing the UI to appear to lag quite a lot. This way, the WiFi
swap gets setup almost instantly, and is available to swap - therefore
the UI seems much more responsive.
While we're at it, use `Thread`s rather than `AsyncTask`s because
they are more concise. Not 100% sure, but I think `AsyncTask`s
need to wait for the UI event loop to get to them in order kick off.
Trying to pin down why the UI takes one or two seconds to catch up
after performing the "Enable WiFi" toggle. This is best done via
logging rather than using the debugger.
Also changed to Utils.DebugLog instead of Log.d, and removed some
comments and fixed a typo in one comment.
