-
Peter Serwylo authored
Previously the data was not stored anywhere, and each time we wanted to know about all installed apps, we built a ridiculously long SQL query. The query had essentially one "OR" clause for each installed app. To make matters worse, it also required one parameter for each of these, so we could bind the installed app name to a "?" in the query. SQL has a limit of (usually) 999 parameters which can be provided to a query, which meant it would fall over if the user had more than 1000 apps installed. This change introduces a new table called "fdroid_installedApps". It is initialized on first run, by iterating over the installed apps as given by the PackageManager. It is subsequenty kept up to date by a set of BroadcastReceivers, which listen for apps being uninstalled/installed/upgraded. It also includes tests to verify that queries of installed apps, when there are more than 1000 apps installed, don't break. Finally, tests are also now able to to insert into providers other than the one under test. This is due to the fact that the providers often join onto tables managed by other providers.
4e240507