Sometimes development bugs seem to never end. Sometimes more come to light, immediately after fixing those we can already see. Bugs can come from one’s own mistakes, but this time it’s all Facebook’s fault.
Today, Facebook’s changes tripped me up. I am so grateful that this happened before the app launched in the very near future, because this was an instant-kill type crash, and could have ruined a perfectly good user experience, for 100% of Facebook users, on Day 1 of release.
http://developers.facebook.com/roadmap/
This page briefly discusses the update to the way the picture is accessed, for user profile images. Before today (October 3, 2012) there was only a web address to the picture, but now it is an object that contains extra information.
Further, there is no actual discussion in the document about this new object, because there is an undocumented intermediate object between the desired info and the top level of the info hierarchy.
The following is copy-pasted from
http://developers.facebook.com/docs/reference/api/user/
picture |
The URL of the user’s profile pic (only returned if you explicitly specify a ‘fields=picture’ param) | access_token required for pages with whitelisting/targeting restrictions, otherwise noaccess_token required |
string; If the “October 2012 Breaking Changes” migration setting is enabled for your app, this field will be an object with the url andis_silhouettefields;is_silhouette istrue if the user has not uploaded a profile picture |
so in the explicit JSON code, this would be:
{ picture=”http://picture.facebook.com/john_doe_profilepic.jpg”; }
but now, the documentation suggests somethign like:{
{
picture={
url="http://picture.facebook.com/john_doe_profilepic.jpg",
is_silhouette=1
}
}
But in reality, information about the picture comes back like this:
{
picture={
data={
url="http://picture.facebook.com/john_doe_profilepic.jpg",
is_silhouette=1
}
}
}
anyway, I wouldn’t have discovered this flaw in Facebook documentation if it hadn’t been for the migration. (I say flaw with emphasis because I’ve found other faults in the Facebook documentation before leading to crashes, that was fixed after I contributed to the awareness of the flaw.) And they will change it again, no doubt. So the important thing to do is write code to adapt to either of these situations.
