Search as the user types
Fixes#323.
This does away with the separate `SearchResult` and instead applies the search to the currently viewed tab on the main screen (Available, Installed, Updates). When filtering the Available list, it filters the currently selected category.
Note however that there are still times when the old style `SearchDialog` will be shown over the top of the action bar rather than the `SearchView` within the action bar. These times include:
* When a user with a hardware keyboard starts typing from the main screen.
* On older devices with a "search" hardware button.
* Probably some other cases (I think when there is not enough screen real estate, but haven't seen that happen).
In cases where this dialog is shown, filtering the lists as you type does not seem to be an option. I tried to figure out how to do that, but failed. If someone else figures it out, that would be great. However, when the search is submitted, it will hide the `SearchDialog` and populate the `SearchView`, focus it, and apply the search appropriately.
There is a script in the `F-Droid/tools/` subdirectory which will consecutively send various intents to F-Droid relating to search. This includes Play, market, Amazon search links. For good measure, I also made it send intents to do with viewing app details. This should probably be made into a proper instrumented test at some point, but I didn't have the time to figure out how to do that. Maybe a project for future @pserwylo.
One unknown is the performance implications. There is no problems on my Nexus 4 with Android 5.0. My Chinese/ebay/$30/Android 2.3.4 device seems good enough too.
See merge request !177
The system's are sometimes wrong, e.g. unexpected names. This also helps
our support across different Android versions without having to worry as
much about the system's language support.
Fixes#503.
In addition, added a @Nullable constraint on the categorySpinner
and a null guard when resuming the fragment to handle possible
null cases (though I don't think there will be any).
The idnexes which are added are for those columns which
are used to calculate information such as latest upstream version.
These queries use subqueries which seemed to be adversely
impacted by the lack of indexes.
In total, reduced update time on test device from just over 100 seconds
to just over 60 seconds.
This requires renaming the old app/apk tables to be deleted and
the temp ones to be renamed. This is done in a transaction to
ensure we always have at least `fdroid_app` and `fdroid_apk`.
Well, two transactions, one for renaming the `fdroid_app` table
and one for `fdroid_apk`.
Fix 324 : Out of memory errors while updating repos.
Fixes#324, but in the process makes the updater take a lot longer. My benchmarks tell me that an update which used to take approx 30 seconds on my Nexus 4 now takes about 50-55 seconds. This is because it first inserts the apps into the database (in a temp table) and then subsequently copies that table to the actual table. This means there is a lot more disk access than before.
I'm open for discussion on whether this tradeoff is worth it - however I'll caution that there is always going to be a tradeoff between faster and more memory vs slower and less memory. This is the case with all software, and perhaps more so with memory constrained devices such as phones. Also, as the repo index grows (until perhaps we are able to extract the app descriptions in the future), this will become more of an issue.
I'd also like this to be CR'ed properly before merging, because it changes some important code around the repo updater. It is important because security, and it is also important because it is the main thing that F-Droid needs to do (get a list of apps to show the user).
See merge request !173
Will also appear as indeterminate if:
* The repo being downloaded from doesn't send a Content-Length header.
* While connecting to the HTTP server to begin downloading.
Right now it says "50%" always, will need to think whether to ditch the
percentage completely, or to have the temp app/apk providers emit progress
events some how too.
Although not used by the temp provider, it seemed strange having some of
the code always using the `DBHelper.TABLE_APP` and other code using
`getTableName()` where all of it could have used `getTableName()`.
Also moved commiting of the temp tables to the real tables into the
`RepoPersiter` instead of in `RepoUpdater`.
The repo xml handler now has a different mechanism for returning
data about the parsed xml file. This is done via a callback, rather
than storing the data in member variables. The tests now deal with
this correctly.
The update/delete operations of the TempAp[pk]Provider's didn't
work, so that has now been fixed.
At the start of a repo update, it will create a copy of the apk table.
Throughout the update, it will query the original apk table for info.
All inserts and updates happen to the temp table. After the repo has been
verified as trusted, the original apk table is emptied, and all apks are
copied from the temp table to the real one.
I realise that the work done to query the apk table for info during the update
could happen against the temp table, but it was not neccesary to move all of
the queries that are required for this task to the temp apk provider.
Refactored repo update to stream apks from network -> jar file reader ->
xml parser -> database. No longer build up large lists of app metadata
to save. Saves memory, but is MUCH slower.
Does sig verification properly, but does it at the END of the process
and DOESN'T ROLL BACK on failure.
Quick and dirty benchmarks show an increase in time from ~25 seconds
to ~30 seconds on my Nexus 4 with Android 5.0. This doesn't seem so
bad to me, for the tradeoff that people on low end devices can actually
update now.
Also, as @eighthave pointed out, if we are able to stream the download
directly from the internet, then that time will drop to essentially
the time it takes to download the index.
