As far as JSON. I’ve been using it A LOT at work lately and I have to say I love it. Especially in my case where I submit a javascript array to the backend and if rejected, I can easy recreated the array on the client-side and allow correction.

I wasn’t aware of NSScanner, but that’s definitely something I’ll look into for the next update. Right now I do a lot of error checking on the data coming in from the server. I hope it’s enough…

As for JSON, I don’t know what it is, so that’s why I didn’t consider it.

@Doug – I don’t see myself having a huge load on the servers, but even so, the free quotas that Google App Engine provides are pretty impressive. There are full details here:

http://code.google.com/appengine/docs/quotas.html

Needless to say, I don’t think I’ll be exceeding 10,000,000 datastore API calls per day anytime soon.

As for robustness, it’s built on top of their server cloud, so your datastores are stored across multiple servers (if I understand it correctly). Which means, even if one fails, another server should be able to handle the request. The other nice thing about it is that if someone should happen to hack into the system, it’s not the same server as my website.

O.

doug

In addition it’s not quite clear to me why you think you need that loop for clearing your cache. The only thing could be that you might have some cyclic references in your cache. Otherwise I’d be really surprised that this won’t work. What makes you sure that this is indeed a leak?
The second version leaks the username and that should be the reason why you have to loop through the array and release it manually.

In addition ‘componentsSeparatedByString’ is a cool convenient method, but you can get into a whole lot of trouble, when the data you receive is not what you expect (NSScanner does a good job in reliably parsing strings). (Just think about somebody is spamming your online high score list with some data, which probably could easily crash your app).

Why didn’t you consider using JSON, this would have taken the burden away from you having to parse the data yourself?

Btw. it’s more efficient to do
for(NSMutableDictionary* record in mCachedGlobalHighScores) { …

also, i’ve read in several places (mostly forum posts, some from apple employees, iirc) that the retainCount method can’t necessarily be relied upon to tell you what’s really going on leakwise, because of implementation details. it might return what looks like a ‘wrong’ value, but not actually be leaking there.

curiouser and curiouser… it seems like it’d be worth filing as a bug with apple if you can reproduce it in a small test app.

However, it was when I tried to let everything work through the autorelease stuff that I ran into problems with sometimes things not being released (and hence a leak), which is why I put the explicit alloc in there. It’s entirely possible that I’m doing something else dumb with my memory stuff.

This is why I don’t like smart pointers. If I have to manage my own memory, at least it forces me to understand what’s going on all the time.

This should work:
NSArray* recordData = [[records objectAtIndex:i]
componentsSeparatedByString:@”,”];

[dict setObject:[recordData objectAtIndex:0] forKey:@”name”];

No allocs, no retains, no releases.
It’s also important to note that the runtime saves memory whenever possible. So copying a string, if the string is immutable, just results in a new pointer and an incremented retain count. Check the values of your pointers to see if they are pointing at the same object.