Comments for Planetary Scale LLC

Comment on On the Postage Rejection by Oskar

Oskar — Fri, 11 Dec 2009 03:40:46 +0000

We just got rejected for use of private API “setThoroughfare:”
This is indeed a private API in MKPlaceMark in the MapKit. The thing is that we never call this in our code.

What we do have is an attribute named “thoroughfare” in a Core Data class. setThoroughfare is generated from @dynamic.

Does this imply that all attributes in all core data classes must have names that in no shape or form resembles an attribute found in any of the private API’s?

Comment on On the Postage Rejection by Louis Gerbarg

Louis Gerbarg — Sat, 21 Nov 2009 02:12:19 +0000

Yes, but quite frankly, the view controller hierarchy reeks. Everything to do with collection view controllers is pretty hacky, and it actually is not possible for 3rd parties to implement them because Apple doesn’t expose setParentViewController:. I spent quite a bit of time disassembling them and looking at what was going on before I decided it was impossible to do what I wanted and implemented my own view controllers from scratch rooted off of UIResponder.

Comment on On the Postage Rejection by andrew

andrew — Sat, 21 Nov 2009 00:34:23 +0000

Louis: Hah, fair enough, you got me there. That would still be some pretty smelly design on Apple’s part though.

Comment on On the Postage Rejection by Louis Gerbarg

Louis Gerbarg — Fri, 20 Nov 2009 23:41:39 +0000

There are actually ways this could impact the existing Apple code. For instance, it is entirely possible some of Apple’s code could be doing a [vc respondsToSelector:@selector(previousViewController)].

While that might seem somewhere atypical, the whole notion of how view controllers are related to each other (as opposed to views) is somewhat ad hoc and ill defined, so it would not shock me if the collection VCs (navigation controller, tab bar controller) have some internal protocols for things like next and previous VCs that other parts of UIKit call when present by checking if VCs respond to them.

IOW, just because you are adding a method didn’t exist previously doesn’t mean it won’t cause runtime changes. We live in a very dynamic world

Comment on On the Postage Rejection by andrew

andrew — Fri, 20 Nov 2009 22:53:17 +0000

Hi Kevin:
As I point out, as far as I can tell there isn’t an implementation of -previousViewController in UIViewController. So, there aren’t any implications for this category on Apple code.

Comment on On the Postage Rejection by Kevin Ballard

Kevin Ballard — Fri, 20 Nov 2009 22:50:04 +0000

The one thing I haven’t seen anybody mention yet is the fact that overriding this private method could have implications for the behavior of UIViewController. Unless the overridden implementation of -previousViewController behaves identically to the private one, any Apple code that calls this method may start failing.

Comment on bit.ly + tinyurl.com = FAIL by Robi Ganguly

Robi Ganguly — Wed, 04 Nov 2009 13:40:45 +0000

I suppose it’d be too much to ask for bit.ly statistics to cover stats around being blacklisted or broken. Shame on them.

Comment on iPhone App Sales Heatmap by bit.ly + tinyurl.com = FAIL – Planetary Scale LLC

bit.ly + tinyurl.com = FAIL – Planetary Scale LLC — Wed, 04 Nov 2009 09:39:21 +0000

[...] while writing another blog post, I tried clicking on the bit.ly link to go to my app’s page, and instead saw [...]

Comment on (Soft) Launch Day by Courtney

Courtney — Wed, 15 Apr 2009 04:39:46 +0000

Woohoo! Glad to see things moving along. Great job, guys!