Including coredata branch in Mac app causes it to beachball

[mauricerkelly]

In an attempt to avoid duplicated effort I've been trying to use the coredata branch of StackKit.

I'm using Xcode 4.2.1 and have created a workspace containing two projects - a test Mac app (TestApp), and the StackKit project for Mac.

When I run TestApp without StackKit, it starts reliably every time.

If I import StackKit as a Framework for the TestApp target, TestApp will randomly beachball on startup. Sometimes it displays it's UI, sometimes nothing appears and I get a beachball. Doing a bit of debugging I can see that the "constructor" for StackKit is being called and it is connecting out in order to fetch the list of sites. However despite the fact that this stuff is supposed to be running in separate threads, it still seems to be causing problems with the main run loop. The fact that it doesn't happen all the time suggests it may be a race condition.

[davedelong]

The core data branch is unstable and shouldn't be used. The 2.0 API is currently in testing, and I'm trying to figure out if I want to put the time in to updating the framework to support it.

[mauricerkelly]

Dave, I realise you've closed this issue as you feel the coredata branch is unstable, but I've been using it based on information posted elsewhere (e.g. on the StackApps entry for StackKit you wrote: 'technically the "coredata" branch is experimental. Once I get it to a point where I'm mostly satisfied with it, I'll merge it in to "master". However, it should be stable.').

While I respect that this is your project, I would request that you re-open and leave this issue open, as surely it's a potential issue whether it's in an experimental branch or not. It's also a potential issue if you're going to be using the coredata branch as the basis for the 2.0 API.

If you are unable to replicate what I'm seeing then fair enough close the issue then.

I'm also happy to help in any way I can.

Cheers,

Maurice

[davedelong]

Fair enough. I would not be using the coredata branch as the basis for the 2.0 api. There are enough design flaws inherent in the v1.x implementation that a full rewrite would be necessary.

[mauricerkelly]

Want to share the "design flaws" with me so I can keep an eye out for them? :-)

I'm working on a project that needs to communicate with the Stack API, and I did a fair bit of hunting around for suitable frameworks/libraries and StackKit seemed like the best. My choice came down to using StackKit or doing it all myself and I'd rather work on my app than reinvent the wheel. However, if I can contribute back to StackKit during my own development process, I'm eager to do so.

[davedelong]

The main issue it has revolves around the usage of NSPredicate. By its nature, a predicate is extremely flexible in terms of what structure it allows (infinite width and depth of compound statements). However, the SE API is very limited in what it accepts, so there's a mismatch between what a developer can express versus what the framework can accept. Trying to find a reasonable way to express those limitations turned out to be extremely difficult. (Check out the NSPredicate category for an idea of some of the contortions that go on) Similarly, the layer for translating a predicate into the appropriate HTTP request turned out to be not as flexible as I'd originally hoped.

In retrospect, I should've designed an API that made these limitations explicit in the API, instead of implicit in the documentation.