[Android Software/Hacking General [Developers Only]] FFU5y:
It is great to see you here!

It would be great to have more details about the network location fix when you're ready. I haven't looked at it yet.

I did give it some hammering, but didn't specifically look at the heap as a result.

The reason for using an LRUCache (rather than another form of cache) is that the main target was packages using things like the camera or compass, which cause a constant hammering of requests to PDroid service. That is also the reason the cache is, at this stage, very small (only 10 items). The goal was to keep settings for the two or three packages making heavy use of the service in a cache to reduce database hits for these items. However, I will very likely expand that cache (but I'll do some math on heap size and object size first, to work out how big to make it).

The other reason I used LRUCache is that it is Google's recommended way to have a recent-use cache. It is thread-safe, and discussio suggests that it is reasonably efficient (but I haven't read the code in detail myself).

I considered soft-reference based caching, but apparently Android tends to destroy soft-referenced objects immediately, not just in low-memory situations.

The choice of cache approach really depends on the goal. If the goal is to absolutely minimise database hits and memory is not a concern, then a hashlist-based cache with cache deletion only when the settings for an app are changed is optimal - loosely, it is like offloading the database into memory. Since there is absolute certainly about when settings change, having a time-based cache makes no sense: you then need to check the time on the cached objects, which isn't actually even relevant, so LRU makes more sense than a time-based cache. In terms of leaving things for garbage collection, a bigger LRU would be better than the current small LRU because less objects would need to be instantiated. However, that means holding onto more memory, so that's a trade-off too.

So in brief, I could have created an extended synchronised hashmap, but then I would have had to decide when to clear stuff from memory myself, so an LRU that I can keep small actually fills the need at the moment. And as I said, it is what Google recommends.

I'm open to alternatives, though.

I'm happy to look at problems, but I'm afraid without a bit more detail I can't really pin down what you mean.

I know that if the connection to the database fails (i.e. getReadableDatabase fails) then 'null' is returned. I agree this isn't ideal: it is inherited behaviour from the original PDroid. That result is never cached, which means it will be tried again next time, but it still isn't ideal.

Edit: there was indeed a cache problem, relating to detecting whether the cached PrivacySettings were a 'stub' - i.e. represented a lack of settings (since LRUCache cannot take nulls) or real PrivacySettings. I'm testing a fix for that now. Well spotted.

Re-reading the code, there was a problem where a database exception could lead to an incorrect result being cached, and I'm building a test fix for that now to make sure it works on my device.

In terms of cache freshness: You'll need to be more specific, because the cache for an item is deleted whenever its settings change (via saveSettings) or are deleted (via deleteSettings). That means that if the settings change, the cache for those settings is cleared and a new set will be retrieved from the database on next request.

That's something we're working on arranging.

Generally, with github the way in which changes occur is that you 'fork' a repository - which then appears in your account. You then make changes in your own repository, and others can see and access those changes. Once you're happy with them, you can create a 'pull request', which basically notifies the holder of the original repository that there are changed to be merged, and the original repository holder can then merge them in, provide feedback, etc.

In terms of making your PDroid 2.0 available on github, there are a couple of ways to do that - which is one of the challenges we've had with OpenPDroid. You can create forks of complete repositories (e.g. platform_frameworks_base, platform_build, etc), which I've done. You can also create a repository for your patch files, which Mateor has done. We will actually do both in the immediate term; the repository of patches having the latest 'stable' releases, and actual development taking place in the openpdroid-devel branches (ideall the jb-mr1-release-openpdroid-devel branch). The latest 'stable' code will also be in the repositories as the '-openpdroid' branches (without the -devel).

Mateor and I have been discussing this a bit, and will be continuing to do so. I'm not sure what the best approach is, but having users willing to volunteer for testing duties is the first step =)