Extended Permissions support in Bamboo (a Facebook Graph API iPhone SDK)

May 31, 2010 at 3:31 pm (Bamboo, Facebook development, iPhone development, Software Engineering) (, , , , , , , , , , )

Today I successfully added support to Bamboo for Facebook’s nefarious new permissions model. This means that, for the very first time, iPhone application developers have real SDK support for Facebook’s new Graph API, without writing very low-level networking code and handling extremely confusing authorization and permissions.

Facebook has been threatening to shut down data access for all apps that do not migrate over to using the new model for some time now. The most recent deadline was June 1, and it has just moved back to June 30.

If your iPhone app publishes to the user’s stream, as is the case for 98% of iPhone apps, your app will break. You need to do something about it NOW, so that you are ready by June 30. And I am here to help you with that.

Enter Bamboo, a Facebook Graph API iPhone SDK.

First, some Facebook permissions details

Facebook’s fundamental permission concept has changed from a simple yes/no, either your app had permission to do everything or nothing, to a much more granular set of very specific abilities. There are currently 5 “publishing” (write) permission types, and a whopping 45 “data” permission types, broken down into personal data (25 types), and friends data (20 types). You can see the full list here.

For iPhone app developers who interface with Facebook, this means that if you do anything besides read the most basic of public data from a user’s profile, you must update your app with support for the new extended permissions.

So, how can Bamboo help me?

In one succinct line: Bamboo aims to meet all your Facebook needs as an iPhone application developer.

Bamboo is an objective-c implementation of the Facebook Graph API, including support for both the new oAuth authorization, and the new extended permissions model. For integration instructions and more technical details, please see the Bamboo github page.

For your convenience, here is a simple example of client code using Bamboo:

	[[FacebookProxy instance] loginAndAuthorizeWithTarget:self 
                                  callback:@selector(finishedAuthorizing)];
	GraphAPI* graph = [[FacebookProxy instance] newGraph];

	GraphObject* me = [graph getObject:@"me"];
	NSString* myName = me.name;
	
	UIImage* myProfileImage = [me largePicture];

	NSArray* thingsILike = [graph getConnections:@"likes" 
                                                       forObject:me.objectID];
	
	// hello world post - update status message to my feed/wall
	NSDictionary* args = [NSDictionary dictionaryWithObjectsAndKeys:
                            @"Hello World, from bamboo!", @"message", nil];
	[self._graph putToObject:me.objectID connectionType:@"feed" args:args];

	// comment on a post
	NSDictionary* args = [NSDictionary dictionaryWithObjectsAndKeys:
                                   @"Bamboo comment test", @"message", nil];
	GraphObject* post_result = [self._graph putToObject:@"post_id" 
                                        connectionType:@"comments" args:args];

	// add a like connection from me to you
	[self._graph likeObject:@"your_id"]

Bamboo is designed to make the transition from using Facebook Connect to using Bamboo as simple, straightforward, and easy as possible. I have reused the login mechanism of Facebook Connect, and reused the same UI look and feel for the new extended permissions dialog, so your users will feel right at home with the new flow. They may not even notice that anything has changed.

The underlying systems are extremely complex, so it’s not possible to hide all of it, but I constantly strive to make the SDK interface as easy to use as possible, and I actively support the library…so if you need something, I’m here to take care of you.

While Bamboo is far from being finished, I hope that you will consider it to service your iPhone Facebook needs. One day, someone like Apple or Facebook may publish an official SDK that makes this project obsolete…but given Facebook’s negligent track record with FBConnect, I’m not holding my breath. And until that day comes, right now, Bamboo is your best option.

Honestly, it’s pretty much your only option.

Thanks
R.

Permalink 1 Comment

Mother’s Day Greetings, iPad app style

May 8, 2010 at 3:24 pm (iPhone development, Uncategorized) (, , , , , , , , )

This year, I have re-energized my long standing partnership with Steve Bjorkman, my fabulous illustrator, who’s greeting cards have been a successful staple in retail stores since the early 80s. His softly hand-drawn, humorous style is very popular to a very wide audience, which we have taken advantage of, and harnessed to create iPhone applications for kids and adults alike.

This past week, we published our first iPad app, a Mother’s Day greeting card-style app very similar in concept to the Create a Valentine app we did last year. If you have an iPad, please go take a look at the app, download it, and use it to tell your mom just how much you appreciate her. Your mom will be impressed by the unique, warm style and subtle beauty, and your neighborhood developer will be grateful of your support.

Additionally, I also created a universal app which will run on both the iPhone and the iPad, but unfortunately it just missed being approved in time. It will hit the store on Monday, so if you forgot Mother’s Day (tsk tsk) and have an iPhone, give it a shot! And next year, it’ll still be there.

About the Greeting Card business in the 2010s…

Over the last 10 years or so, digital media has become a prominent form of greeting-sending that traditionally were always paper based. One of the side-effects of this, for a variety of reasons, is that the general quality of such greetings tend to be relatively poor, the receiver often feels as if the sender did not care quite enough to “send a real card.” You have all experienced it at one time or another, I know you have. It’s a very clear case of meaning being codified in the medium, which is fundamentally difficult to change, but we believe it worth attempting to do so.

This effect is something that Steve and I take very seriously, especially Steve, and one of our main aims with our greetings apps is to allow you to create beautiful, thoughtful greetings that evoke those emotions of feeling cared for, loved, appreciated. The attention to detail in Steve’s illustrations, the fact that they are custom-drawn exclusively for these projects, and the similar appearance to traditional greeting cards, these are all things that make what we offer unique, and not something that just anyone can do. His many years of experience in the professional business really shows through his creations, and I feel lucky, honored even to have the chance to work with him. I hope your experience with his work is as wonderful as mine.

An e-card may never fully substitute for a physical one in many circumstances, but it certainly is a welcome addition, and sometimes, it’s just the right thing.

(On a side note, the Valentine iPhone app turned out to be extremely popular, far exceeding my highest hopes. The 2009 distribution was in the thousands…but the 2010 distribution reached well into the hundreds of thousands. This tells me that, most likely, other people see value and appreciate our unique creative approach. Whatever the reason people like it, it helps to build confidence in what we are doing. Not bad for an app that I built after work one day.)

Thanks
R.

Permalink 1 Comment

malloc_error_break, double free, iPhone 3.0…maybe you fucked up NSTimer?

June 29, 2009 at 11:13 am (iPhone development, Software Engineering) (, , , , , , , , )

Yesterday, while working on a client project that had been rejected from the app store, I was doing some initial diagnostics and came across this wondrously useless error message in the console:

malloc: *** error for object 0x529d20: double free
*** set a breakpoint in malloc_error_break to debug

Apparently, when doing the quick cert-signing and testing previously, we hadn’t looked at the console on all of the versions…because this particular error is only a warning on the iPhone OS 2.2.1, and a crashing error on 3.0.  Don’t have any idea why the difference across versions, but it’s there.  So when we ran this on an iPod Touch 2.2.1, it seemed to execute fine, you had to be looking at the console, without being alerted by the debugger…tricky little bitch.

Now, I know what a double free is, but I have no idea where to find malloc_error_break…and Google doesn’t fucking help much, it’s just a bunch of people posting build errors on forums, with no useful responses.  I’m hoping this post will make it up the list, and you will potentially find something useful here, instead of just a cry for help.

So…faced with an easily recurring error, I was pretty confident I could knock it out in short order.  The malloc_error_break message was sort of helpful, but not enough.  I could set breakpoints, and never quite nail down the error…I could break before it, and after it (on 2.2.1)…but not on it.

The useful piece of information in that error message is twofold…one, the double free indication.  And two, more importantly, the memory address of the object. That is how I found the source of the error.  I couldn’t find malloc_error_break, but I could guess which objects might be getting double-freed by looking at the code.  It turned out, the original engineers had written this code to stop an NSTimer:

- (void) stopTimer
{
  if (ptrTimer)
  {
    [ptrTimer invalidate];
    [ptrTimer release];
    ptrTimer = nil;
  }
}

this code, is wrong.  The release in the middle is extraneous, and is what was causing the double-free.  The invalidate call is all you need to stop the timer, the setting to nil is nice for sanity.  I looked at the memory addresses of the two initial NSTimers set during app load, and noted them at the breakpoint right before the crash.  And bam, one of the addresses showed up in the error message as the object that had been double-freed.

So, that was it.  There happened to be about 7 different timers floating around the app, all mistakenly stopped in the above way, so the app was absolutely going to crash, no matter what you did.  Commenting out the release was all it took for me…and just over an hour later, I had the app all ready for submission to the app store.  We sent it in this morning, hopefully it should be done by friday.

Thanks
R.

Permalink 4 Comments

NSIndexPath for iPhone SDK: .row and .section

May 4, 2009 at 1:01 pm (iPhone development) (, , , , , , )

God, I really love/hate it when Apple, or any other framework & API developer, does shit like this.

Love it, because they do exactly what I want them to, they modify an old existing API with an arcane interface (NSIndexPath in this case) to provide convenient, direct access to what we really need as developers (in this case, the row and section of the UITableView).

Hate it, because they don’t document the new API in a reasonable way. Yes, it turns out that there is at least documentation in this case, but it wasn’t accessible in XCode, the way everything else is…I had to google the problem, and find someone else’s nice reference to the NSIndexPath UIKit Additions documentation. Now that I know it is there, I go back to XCode, and yup, I can find it. And it’s not totally un-obvious, but it’s just that one extra click away for me to have missed it the first time.

The API I’m very happy to have just learned about here, is 2 new accessors added to NSIndexPath by the iPhone SDK, .row and .section, which provide convenient access to the relevant information about a multi-section UITableView. If you do any development on the iPhone, you will at some point very quickly want to use a UITableView, and likely a multi-section variety. The plain one works fine for many cases, but sometimes a multi-section table provides a better or more natural organization.

The normal API for NSIndexPath is really lame, it’s basically an array of numbers, which are themselves indices into a tree of nested arrays. You can read all about it on your own time in XCode, have a blast. The row/section API, makes all the sense in the world, and it’s great to have it.

But please, oh god please, API and framework developers across the lands, make your documentation just as orthogonal as your API (or preferably, even more orthogonal). A poorly documented API is sometimes worse than no API at all (take, well, any API that Microsoft has written since the original win32 api. MFC will suffice. Had microsoft never bothered to release that abomination, no one would have been under the false impression that they could actually *use* the API to do something useful or efficiently, and would have just stuck to the ugly, but reliable, for windows anyway, win32 api) Apple’s API documentation is historically pretty questionable, and their API implementations are also similarly pretty questionable. As much as I love application development compared to web development, comparing the NS* API, on which most of the iPhone SDK is based, to something like Rails…the degree to which the iPhone API falls short is just sad. A part of me deep inside cries whenever I think about it.

But still, at the end of the day, I love to write iPhone applications, and I hope that business continues to allow me to fill my time with client work for iPhone apps. If you or anyone you know needs iPhone work, http://www.rcloudconsulting.com ftw.*

Thanks
R.

*ftw = for the win, meaning if you want the best iPhone developer in the world, that’s where you find him. Any resemblance to the author is strictly intentional.

Permalink Leave a Comment

R.Code: iPhone SDK tutorials

March 12, 2009 at 1:31 pm (iPhone development) (, , )

I just started writing a new column about programming with the iPhone SDK. It’s called R.Code, and is hosted over at www.tenfingersclub.com, a community site for iPhone game developers and the people who play their games. The first article is incredibly introductory, but it turns out that a lot of people still don’t even know how to get started working on an iPhone application, and still need those same questions answered. So, I thought I’d start my column with a how-to-get-started series of a couple articles, and then I’d jump into the good stuff afterwards.

If you are an iPhone developer, I hope you will follow the column and learn something useful. Please send any and all feedback my way, especially ideas for future articles.

Thanks
R.

Permalink Leave a Comment