This requires a minor dink to some of the test code itself, to work around a compatibility glitch. (The underlying problem is robolectric/robolectric#372 but it's so easy for me to work around that there's no point messing around with patched versions while the fix makes its way through their release pipeline.)
See GitHub issue #8.
It may no longer function as a top-level scope in all cases, but there are other uses for it (e.g., to get the discriminant of a variant record type, which was already in use for the Contacts sample app).
Patching this one in manually, since it wasn't cleanly isolated in his git history.
…ctly. This requires minor changes to the TestRunner-cloned glue, in order to set up a DatabaseMap. Right now, you're stuck with the default behavior on that; good enough for me, for now, but support for UsingDatabaseMap annotations, or the equivalent, wouldn't be hard...
This is happening now because Robolectric's SQLite cursors can't handle qualified column names, and require aliasing to disambiguate. It's not clear that the platform's real cursors have the same restriction, but aliasing has other uses anyway, so we might as well support it.
The intended use case (as shown in the API sample) is when you've got an association (say, TodoLists to TodoItems), you've got a query for objects on one side of the association (say, lists whose names contain the string 'blue'), and you'd like to query for the other (say, identifying all the items in such a list).
The Activity mixin that did the dispatch was declaring "PendingResponse" as a nested class --- which means it gets a reference to the parent object. The parent object is the Activity itself, which ... doesn't serialize well. Not sure how this ever worked...
Left out of the initial commit for the app. (oops) I try to avoid Java stubs in sample apps, but in this case, we need to define one to follow platform conventions. (It's a bag of "vals" and functions defining conventions for accessing our app's ContentProvider.)
APIs still need polishing, but it runs and doesn't blow up...
See design note on DataStreams for discussion here.
The intended usage here is for a ContentProvider which lets you fetch records of a particular type through multiple URIs.
The idea had been to have DependentRecordManagers (next commit) special-case ID handling --- in particular, to have extra state associated with the IDs they manage. But the values to use for that state are not available in all cases (in particular, not when the ID is being fetched out of a column in a query on some other table from the same content provider), so we punt.
Generally friendlier than catching them later, when it's often not obvious where they came from or how they got screwed up.
…a Future. Name could change, but this actually covers an intended use case: a DataStream that does an orm query (returning a future) when new values arrive...
…tream. If 'initialFuture' is a val, things initialized from it turn up null. If it's a 'def', they don't.
Make the 'baseQuery' parameter to the constructors by-name and deferred so we don't actually try to construct the ContentQuery objects until the provider is fully open (and onCreate, etc., have been invoked).
Unlike the last try, this version lets you define special-case handlers for CRUD operations matching specific patterns in a reasonably convenient way, and also easily massage the ContentValues of the data going in on an insert or update. May still want to do some tweaking around the edges. I've mocked out a child/parent record case, in which a delete on parent records should also clobber the children. It works, but it isn't exactly pretty. And there's still rather more monkey business invovled in plugging in parent record IDs into contentValues than would ideally be required...
... to test harmonization with platform conventions.
…mgrs". In most cases, the same object serves for both, but we want to support situations where the two are distinct. (E.g., a ContentProvider that allows the same record type to be accessed through multiple URIs.)
…nager. For future classes with multiple managers, the manager is the heavyweight object that should not be duplicated. Although... manager here is getting *awfully* thin and indistinct from Scope, which suggests a little renaming might be in order...