yet another reason to not use ZuckBook
As if I needed any more than I already have.
Those using Facebook to log into services such as Spotify on their iOS devices are having a bad Friday, as something has gone awry with Zuckerberg's ad-slinging platform. A glance at social media reveals a howl from those affected by the problem which appears to have started early this morning (UK time) and hit iOS devices. …
If the app uses the SDK, then it's possible that calls are made into it even if you don't use Facebook (I'm assuming that the apps where you use Game Centre do have this as an option).
Sounds more like inadequate handling of error conditions within the API.
That's what I'd expect. Anybody that's worked near web development (I wouldn't say I've worked in it) knows what a bunch of third-party scripts can do to a page load.
Having finally caved and decided to buy a pair of hair clippers yesterday, I found a couple of sites selling what I wanted (okay, not what I wanted because everything's sold out, but the closest thing to what I wanted at only three times the fscking price) and couldn't seem to get the "Register" button to work on the site I decided to go with. No message, no response. Tried all the usual stuff — removed the plus section from my email address, simplified the password down to alphanum, ticked one of the boxes saying they could contact me with marketing guff; still nothing. Tried it in another browser, same thing. Eventually I got a message in the status bar telling me it was waiting for something.facebook.com, and then managed to replicate that a couple of times.
Gave up and went with the other site, who despite not being able to guarantee delivery times have sent it so it'll arrive on the same day as the first site had guaranteed. Despite the vast amount of analytics guff companies do, I'm surprised they don't think of giving a smidgeon of credence to their devs who are probably screaming at them about their pages choking on Facebook's big long nasty scripts.
The last time Facebook f***ed up like that, their server changed one reply from a string to a dictionary or vice versa. If the code that processes the reply blindly assumes that the reply is a string and reads the contents of a string, and it is in fact a dictionary, then the app will crash.
Any competent server developers would either use versioning, so all old clients get the old response and new clients get the new response. Or they would very carefully examine the old client code and make sure it can handle the new reply correctly. So it looks like Facebook doesn't have competent server developers.
And any competent client API developers would make sure that their code survives anything that you throw at them from the outside. Clearly that didn't happen, so Facebook doesn't have competent API developers either.
Remember their lord's motto: "Move fast and break things." My code always made use of contracts and validation to ensure compliance even in conditions where all the code was personally written. While it never actually happened, I did not trust myself let alone the rest of the universe. Then again, people would be harmed or killed if I screwed up.
"It may be caused by a problem with the server / service, but error trapping in the client should still be able to detect and handle the problem without crashing."
Absolutely true. In this case, the server code is written by Facebook, and the SDK that crashes is also written by Facebook. And it crashes - no chance for the calling code to catch any error. The app is taken down immediately.