da8e41249b
Yay! As expected, a lot of the stuff in DB class is due to UpdateService requiring it to process the downloaded indexes and insert data into the database. Thus, this change is about removing that stuff from the DB class and migrating to ContentProviders. This required a bit of a change to the way that UpdateService decides what to do with the data from indexes, but I hope it will make understanding and changing UpdateService easier in the long term. For example, it used to read the app details from database, then if a repo wasn't updated (due to unchanged index) then it would take the app details for that repo from the list of apps, and re-update the database (or something like that). Now, it has been refactored into the following methods: * updateOrInsertApps(appsToUpdate); * updateOrInsertApks(apksToUpdate); * removeApksFromRepos(disabledRepos); * removeApksNoLongerInRepo(appsToUpdate, updatedRepos); * removeAppsWithoutApks(); * and probably some others... Which hopefully are self-explanitory. The recent change to implement single repo updates was re-implemented with in light of the methods above. The interface to UpdateService for scheduling a single repo update is the same as it was before, but the implementation is completely different. Still works though. Using batch content provider operations for repo updates, but they suffer from the problem of not all being under the same transaction, so if an insert/update stuffs up half way through, we are left with only half of the update being complete. In the future, if there is some way to implement notifications from the content provider's applyBatch method, then we can do it all in the one transaction, and still have notifications. Currently we break it into several calls to applyBatch (and hence several transactions) to inform the user of the progress. Also adding the beginnings of some tests for AppProvider. In the future, I'll work on adding better coverage, including instrumentation to test UI features. ========================== Below is a list of many of the minor changes that also happened along the way ========================== Make "Can update" tab stay up to date using content observer, rather than manually deciding when to refresh the tab label as before. The installed app list is now cached in Utils, because it is invoked quite a few times, especially when rendering the app lists. The cache is invalidated when PackageReceiver is notified of new apps. The content providers don't notify changes if we are in batch mode. I've left the notification at the end of the batch updates as the responsibility of the UpdateService. However, it would be nice if this was somehow handled by the content, as they are really the ones who should worry about it. Made curVersion, curVercode and curApk work with providers. This was done by removing curApk (otherwise we'd need to query the db each time we fetched one app to get a reference to that apk (resulting in hundreds of queries). Instead, UpdateService now calculates curVercode and curVersion and saves them to the database. We then use these where possible. If we really need curApk (because we want info other than its version and code) we still have the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered putting this inside the app value object, e.g. in getCurApk() but thought better of it as it will likely result in people invoking it all the time, without realising it causes a DB query. incompatibleReasons required a minor UI tweak, removing the "min sdk" ui element from the Apk list. It is replaced by the "Requires: %s" view (which only appears when the app is incompatible). In the process, and in response to some feedback from mvdan, I left the min sdk in there, but only made it show when in "expert mode", just like the architecture. In order to make the "installed apps" query work under test conditions, needed to change the way the InstalledApkCache be replaceable with a mock object. Pause UIL loading on fast scroll of list, as the list was very choppy for some reason. Re-added "Last repo scan" info to the Manage Repo list view. Fixed up some misc TODO's, removed some unused/empty functions.
93 lines
3.8 KiB
XML
93 lines
3.8 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<project name="test" default="help">
|
|
|
|
<!-- The local.properties file is created and updated by the 'android' tool.
|
|
It contains the path to the SDK. It should *NOT* be checked into
|
|
Version Control Systems. -->
|
|
<property file="local.properties"/>
|
|
|
|
<!-- The ant.properties file can be created by you. It is only edited by the
|
|
'android' tool to add properties to it.
|
|
This is the place to change some Ant specific build properties.
|
|
Here are some properties you may want to change/update:
|
|
|
|
source.dir
|
|
The name of the source directory. Default is 'src'.
|
|
out.dir
|
|
The name of the output directory. Default is 'bin'.
|
|
|
|
For other overridable properties, look at the beginning of the rules
|
|
files in the SDK, at tools/ant/build.xml
|
|
|
|
Properties related to the SDK location or the project target should
|
|
be updated using the 'android' tool with the 'update' action.
|
|
|
|
This file is an integral part of the build system for your
|
|
application and should be checked into Version Control Systems.
|
|
|
|
-->
|
|
<property file="ant.properties"/>
|
|
|
|
<!-- if sdk.dir was not set from one of the property file, then
|
|
get it from the ANDROID_HOME env var.
|
|
This must be done before we load project.properties since
|
|
the proguard config can use sdk.dir -->
|
|
<property environment="env"/>
|
|
<condition property="sdk.dir" value="${env.ANDROID_HOME}">
|
|
<isset property="env.ANDROID_HOME"/>
|
|
</condition>
|
|
|
|
<!-- The project.properties file is created and updated by the 'android'
|
|
tool, as well as ADT.
|
|
|
|
This contains project specific properties such as project target, and library
|
|
dependencies. Lower level build properties are stored in ant.properties
|
|
(or in .classpath for Eclipse projects).
|
|
|
|
This file is an integral part of the build system for your
|
|
application and should be checked into Version Control Systems. -->
|
|
<loadproperties srcFile="project.properties"/>
|
|
|
|
<!-- quick check on sdk.dir -->
|
|
<fail
|
|
message="sdk.dir is missing. Make sure to generate local.properties using 'android update project' or to inject it through the ANDROID_HOME environment variable."
|
|
unless="sdk.dir"
|
|
/>
|
|
|
|
<!--
|
|
Import per project custom build rules if present at the root of the project.
|
|
This is the place to put custom intermediary targets such as:
|
|
-pre-build
|
|
-pre-compile
|
|
-post-compile (This is typically used for code obfuscation.
|
|
Compiled code location: ${out.classes.absolute.dir}
|
|
If this is not done in place, override ${out.dex.input.absolute.dir})
|
|
-post-package
|
|
-post-build
|
|
-pre-clean
|
|
-->
|
|
<import file="custom_rules.xml" optional="true"/>
|
|
|
|
<!-- Import the actual build file.
|
|
|
|
To customize existing targets, there are two options:
|
|
- Customize only one target:
|
|
- copy/paste the target into this file, *before* the
|
|
<import> task.
|
|
- customize it to your needs.
|
|
- Customize the whole content of build.xml
|
|
- copy/paste the content of the rules files (minus the top node)
|
|
into this file, replacing the <import> task.
|
|
- customize to your needs.
|
|
|
|
***********************
|
|
****** IMPORTANT ******
|
|
***********************
|
|
In all cases you must update the value of version-tag below to read 'custom' instead of an integer,
|
|
in order to avoid having your file be overridden by tools such as "android update project"
|
|
-->
|
|
<!-- version-tag: 1 -->
|
|
<import file="${sdk.dir}/tools/ant/build.xml"/>
|
|
|
|
</project>
|