fluidinfo / objc-client Goto Github PK

as gridaphobe pointed out...

This is pretty important, since it's both an illustration and a test of how the library is intended to be used, when appropriate to use it in an object-oriented fashion.

The fix I did some time ago that made lots of method calls convenient (by actually executing them instead of just preparing them) broke concurrency. It turns out that the synchronous networking call function demands to run in the main thread. I found this out as I attempted to make my iPad app concurrent, yesterday. So, there has got to be some middle ground. I think writing two versions of doRequest, one of which is asynchronous and uses a Session-specific NSOperationsQueue, would be all right, BUT, some developers will want to make some operations in another queue (and possibly another kind of queue!) depend on the results of these requests, and it would be nicer for them if they were permitted to handle the request-execution.

Maybe the right solution is to (and this is the advantage of having almost no users) undo the changes that we made for gridaphobe (sorry, dude!), and wrap up a new function called handleRequest, which will be just another convenience function for interpreting and wrapping up the server's response, intended to be passed as part of an upon-completion block with an NSOperation or similar mechanism. Additionally, I could make appropriately-named aliases for the convenient but synchronous functions (i.e., synchronouslyPut: ...) that we are now using. This would be nice because it would let people try out Fluidinfo via Obj-C without putting too much thought or care into low-level details. However, it would encourage lazy Lion devs to write non-concurrent code, which might indirectly make Fluidinfo look bad.

Opinions?

Most of the tests are outdated beyond belief. Rewriting them following a grand simplification of the test suite (which eliminated the unnecessary complexity of FakeServer) is still incomplete. Finish this so we can have a stable repo with no more incomplete repairs in it (except for the Sample class, which isn't done at all).

With the simplification, we now need to test the following

• request semantics
• response handling
  with everything between.

This could be more detailed, but it's good enough for now.

...just to see if there are any major slow-down points that we can focus on optimizing.
if we hit one method that's working too slowly, the repair will likely apply to many.

gridaphobe can set it up to compile for Lion at home, but, it would be nice if everyone who wants to use it on Lion doesn't have to do that.

Right now it naively just saves each tag-value separately. :(

these methods (i.e., saveWithCoder:) are used for longer-term state saving and recovery. Can't believe I missed that. Now I need them.

the title says it all. When I wrote these methods for Objects, implicit tag- and namespace-creation was just an idea---an idea that I didn't like. Now that it's a done deal, the obj-c lib ought to take advantage of it to make many fewer API calls.

Actually, this update, although it concerns objects from one perspective, is really about the code related to saving tags and namespaces. To fix that, we need to know whether implicit tag- and namespace- creation is recursive. If it isn't, writing the right code in the client could be very messy, indeed.

it just surrounds the string in quotes, which does not produce valid json.

related: put to values, with just a string value, isn't working whe there are newlines in the text. this could be mostly a clipboard problem, but, here it's noted until more is known.

Cocoa already defines a class named Object, so importing the Object class from Fluidinfo causes the following warning when running a Mac app:

objc[14834]: Class Object is implemented in both /usr/lib/libobjc.A.dylib and
/Users/eric/Library/Developer/Xcode/DerivedData/Clipboard-czfncwzxhpegfgafhuratxztgkon/Build/Products/Debug/Clipboard.app/Contents/MacOS/Clipboard.
One of the two will be used. Which one is undefined.

• (void) dataCheck:(NSMutableURLRequest *)request forValue:(id)val
  in the tests...
  This test has uncovered a problem in the JSON library, which is that it decodes floats as decimals, rounding as necessary. We have to override how JSONSerialization is doing this, or possibly report the issue to Apple. Meanwhile, this test might as well just check to see if the decimal is reasonably close to its original value. For now, it's doing nothing.