TouchDB-iOS KVO are getting disrupted

[Pulkit Singhal]

I recently noticed that using 3rd party components like:
a) PayPal Mobile Payments Library, or
b) ZooZ SDK
ends up nuking any KVO relationships that live queries use for notifying the CouchUITableSource to repaint the view.

I don't exactly know or understand how this "nuking" happens but I have observed it happen first-hand (views stopped painting themselves) and it took me quite some time to narrow down the fault to the "use" (not presence) of these libraries.

Now for such libraries, the generic warning is that the payment workflow screens presented by them usually:

"display itself on top of the application’s Window object"

And its strongly recommended that the developer:

"take care not to take control of the Window"

until after the payment workflow is finished.

Does anyone have any suggestion on where to start placing breakpoints in TouchDB-iOS code to figure out how & where the disruption of the KVO takes place?

- Pulkit

[Jens Alfke]

On May 16, 2013, at 6:39 PM, Pulkit Singhal <pulkit...@gmail.com> wrote:

I recently noticed that using 3rd party components like:
a) PayPal Mobile Payments Library, or
b) ZooZ SDK
ends up nuking any KVO relationships that live queries use for notifying the CouchUITableSource to repaint the view.

I don't exactly know or understand how this "nuking" happens but I have observed it happen first-hand (views stopped painting themselves) and it took me quite some time to narrow down the fault to the "use" (not presence) of these libraries.

That’s strange. Key-value notifications are sent directly from the observed object to the observer, so there isn’t really any way for another object to block them.

My guess is that the issue may involve the runloop, since it sounds like these libraries are running some kind of modal session. They might be running a nested runloop. When you invoke such a library, is it a synchronous or asynchronous call? That is, do you call “RunPaypalWorkflow” and when that call returns the workflow is done? Or do you call “StartPaypalWorkflow”, which returns immediately, and then later some kind of delegate callback tells you when it’s done? In the former case, there’s definitely a nested runloop going on.

There can be weird issues with nested runloops vs. code that uses perform-after-delay or perform-on-thread or NSTimers, all of which are scheduled on runloops. I’m not sure that’s what’s happening here, but I’ve had this happen in the past and this kind of smells like it.

Have you turned on CouchCocoa logging? If so, look for messages of the form

CouchLiveQuery: Starting…

and

CouchLiveQuery: ...Rows changed! (now %lu)

which are logged when notified that the database has changed, and then after the query object has loaded new rows, right before it triggers the KVO notification of its ‘rows’ property.

—Jens

[Pulkit Singhal]

Have you turned on CouchCocoa logging?

I'm familiar with TouchDB logging:
https://github.com/couchbaselabs/TouchDB-iOS/wiki/Logging
Is this what you're referring to?

[Pulkit Singhal]

When you invoke such a library, is it a synchronous or asynchronous call? That is, do you call “RunPaypalWorkflow” and when that call returns the workflow is done? Or do you call “StartPaypalWorkflow”, which returns immediately, and then later some kind of delegate callback tells you when it’s done? In the former case, there’s definitely a nested runloop going on.

Its an asynchronous call. The payment system presents its bunch of screens and then I get notified in a delegate method when its done and I'm free to take control.

[Pulkit Singhal]

That’s strange. Key-value notifications are sent directly from the observed object to the observer, so there isn’t really any way for another object to block them.

I feel like this is what is really getting interrupted:
            [[NSNotificationCenter defaultCenter] addObserver: self
                                                     selector: @selector(databaseChanged)
                                                         name: kCouchDatabaseChangeNotification
                                                       object: self.database];
The query no longer gets informed of DB changes.

[Jens Alfke]

No; CouchCocoa has its own logging. Set gCouchLogLevel to 1 (it’s defined in RESTOperation.h, I think.)

—Jens

[Jens Alfke]

On May 17, 2013, at 1:47 PM, Pulkit Singhal <pulkit...@gmail.com> wrote:

I feel like this is what is really getting interrupted:
            [[NSNotificationCenter defaultCenter] addObserver: self 
                                                     selector: @selector(databaseChanged)
                                                         name: kCouchDatabaseChangeNotification 
                                                       object: self.database]; 
The query no longer gets informed of DB changes.

That notification is posted from -[CouchDatabase changeTrackerReceivedChange:]. You can set a breakpoint there, or rather at its last line, the `[queue enqueueNotification…]` call, to see if that’s still being reached.

—Jens