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 
	GraphAPI* graph = [[FacebookProxy instance] newGraph];

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

	NSArray* thingsILike = [graph getConnections:@"likes" 
	// 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.


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.)


Permalink 1 Comment

iPad Universal app with no nibs

May 5, 2010 at 1:04 am (iPhone development, Software Engineering) (, , , )

I don’t believe in using nib files in my iPhone/iPad projects, not even the magic ones that are generated by the default project templates. So, as I’ve been looking into creating universal apps, I have noticed than no one seems to have published a sample universal project that doesn’t use nibs.

I thought I would take this opportunity to provide such a project, so that anyone who wants to create a universal iPad/iPhone app with no nibs, has a clean template to start from that is already setup with all boilerplate work in place.

The project is a part of my rcloudlib repo on github, I encourage you to take a look at it, I keep it very lightweight and include items I find that need in almost every project I work on. The most recent version of the app template will always be in the rcloudlib/samples/rcuniversaltemplate directory, and will be expanded in the future. If you want a direct download of the .zip of the super-clean version that will never change, use this link instead.

The project complies and runs, in both iPhone and iPad mode. You can run both iPad/iPhone in the simulator, using the steps described here.

If you have any comments, recommendations, fixes, or anything else…I’d love to hear them.


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.


Permalink 4 Comments

Using custom fonts in iPhone applications

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

As any iPhone developer knows, the fonts included on the iPhone can be a bit…limiting.  Sure, they are fine for business and utility applications, but for games and other design-heavy apps, the built-in fonts really don’t get the job done, with MarkerFelt being maybe the only usable, stylistic font.

I worked on typography for just about a decade at Adobe, on such applications as Photoshop, Illustrator, and Flash…so good typographic options are near and dear to my heart.  It pains me to see the limitations that iPhone developers operate with.

What is almost more painful, is the complete lack of a coherent solution from the community.  I spent some time looking around, and found a grand total of 2 solutions, neither of which is complete…but both are usable to some extent.

  1. EasyGlyph – this is a windows only .NET program to create a spritemap out of a font, plus objective-c code to support using the spritemap in your iPhone application.  This solution is good enough for some users, mainly game developers who don’t mind the inherent limitations, and just need some nicely styled text in small amounts.  You are basically just blitting images instead of text, so you are unable to do anything that is not pre-rendered into the images.  Personally, I don’t like this approach, but it would be rude of me not to include it here, as many of you may find that this is just what you need.  It works very well for very simple needs.
  2. A very nice and responsible blogger UIHacker posted this post, which is as far as I can tell, the only fully working solution that anyone had the confidence to post.  It is a very nice packaging up of what is really the best solution right now, which is to operate at the CG* level (CGFont, CGContext, etc).  If you are going to really dive in and use a custom font, this is the way to go.

What I have done, is taken the code that UIHacker posted, and expanded on it…to fit my needs.  Everyone’s needs will differ, but some things are very common.  I will post probably the #1 request I saw, which is how to center text.

  1. To begin, get the CustomFontBase.[hm] from the link above.
  2. in the drawRect() method, look for the line that draws the glyphs, it should look like
    CGContextShowGlyphsAtPoint( context, 0, 0 + fontSize * .25, 
                          glyphs, length );
  3. The second parameter is the x offset, which is what we are interested in.  Replace this call, with the following code:
    if ( isCentered )
    CGContextSetTextDrawingMode( context, kCGTextInvisible );
    // draw the glyphs to get the width
    // hack the y-point to make sure it's not cut off below font baseline
    // - this creates a perfect vertical fit
    CGContextShowGlyphsAtPoint( context, 0, 0 + fontSize * .25,
                                                    glyphs, length ); 
    // get width of text for autosizing the frame later (perhaps)
    CGPoint textEnd = CGContextGetTextPosition( context );
    float adjustment = ( self.frame.size.width - textEnd.x ) / 2.0f;
    if ( isOutlined )
    CGContextSetTextDrawingMode( context, kCGTextFillStroke );
    CGContextSetTextDrawingMode(context, kCGTextFill);
    // draw the glyphs for real
    // hack the y-point to make sure it's not cut off below font baseline
    // - this creates a perfect vertical fit
    CGContextShowGlyphsAtPoint( context, adjustment, 0 + fontSize * .25,
                                                    glyphs, length );
    // draw the glyphs
    // hack the y-point to make sure it's not cut off below font baseline
    // - this creates a perfect vertical fit
    CGContextShowGlyphsAtPoint( context, 0, 0 + fontSize * .25,
                                                    glyphs, length );
  4. You will also need to add a member “isCentered” to support both centered and non-centered drawing.  Also, the “isOutlined” section is optional, but I thought I’d include it since it was something else I added.  UIHacker included support for Glow, and I similarly added support for outlined text.  The color of the outline is controlled by the stroke color, which you can set like this:
    if ( isOutlined )
    CGContextSetStrokeColorWithColor( context,
                                       outlineColor.CGColor );

While this is still very limiting, only single-line text is currently supported…it is a very good start, and is very easily extendable to as much functionality as you are willing to code up.  Type engines are no easy task, but I think as long as the community continutes to share and build off each other’s success, we can make good progress.

I am considering putting together a more fully featured version of this and sharing it, if there is sufficient interest in the same features.  For now, I think this is a good enough starting point, that anyone can make good use of it in any iPhone app.

Permalink 3 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.*


*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

Spellwars update: and new Screenshots!

April 29, 2009 at 9:31 am (iPhone development, spellwars) (, , , , , , )

Well, it’s been a long time since I’ve posted here, I’ve been quite busy. But with a lull today, I thought I’d give an update on spellwars, since the forums are still private…and if you are following the game from the outside, you might be wondering what’s going on.

I’ll tell you what’s going on: a hell of a lot! The most obvious changes are visual, the UI has had a complete overhaul, which is probably 30-40% finished, by my lead UI designer Ryan Sumo. He’s been working hard and producing very high quality work, I can’t say enough about how great he is to work with, and how much I love what he produces. There are still some very obvious things not done yet, but they are on “the list.”

Jeffrey Lai has produced some absolutely incredible Spell artwork for Spellwars, I am so proud to have him as our marquee artist. I am still looking for more artists to draw spell art, so if you are interested, please contact me.

Arron Hirst over at RzFLY is working away on a new app icon, and a set of tab icons.

Rudi Cilibrasi has implemented a server, so our multi-player version has officially gotten off the ground (though we still plan to ship a single-player version first). He has also just jumped ship from the windoz desktop experience and ordered a macbook + iPhone, so it looks like I will finally have a partner to pitch in a little bit with some of the iPhone code. Rudi’s programming abilities surpass those of just about everyone I’ve ever known, perhaps mine, so having his support and involvement means a lot.

In terms of gameplay, things are gelling quite nicely. The basic concept hasn’t changed, spells are played out on a 280×280 gameboard, they have attack and defense, and special abilities that are all resolved in a priority stack, so spells with a higher speed resolve first, moving down the list to the slowest spells. Every feature I’ve added that affects combat has been meant to add to the strategic element, while keeping the game still simple and quick. Everything is very visual, so while there is a slight bit of a learning curve, it’s not more than a few minutes before you can learn everything there is to know.

And now, what I know you all want…screenshots!

All things considered, I couldn’t be happier with how Spellwars is coming along. I wish I could move it faster…but I wish for a lot of things, and Spellwars will be ready when it is ready. Hopefully, soon.

If you are interested in getting involved, contact me, there is room for people to contribute at almost all levels. From art, game concepts, playtesting, coding, feedback, and everything in between, if you have the interest, I’ve got room for you. The Spellwars ning group is by invite only, but I am happy to invite anyone who is interested in contributing.


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.


Permalink Leave a Comment

Observer pattern in Objective-C: NSNotificationCenter

February 27, 2009 at 12:59 pm (iPhone development) (, , , )

I want to take a moment and thank the thoughtful developers at Apple (technically NextStep probably, but whatever) for the wonderfully simple, and elegantly powerful NSNotificationCenter. I won’t bother going over the API, there’s already many great blog posts on that (my favorite is here), but I wanted to raise awareness of it, and talk about how I’m using it in Spellwars…as well as discuss the potential pitfalls of abusing an event-based architecture.

The basic premise of the Broadcaster/Observer pattern is to decouple components, so that events can be fired and handled without everyone having to know about everyone else. This allows, for example, pieces of the UI (in my case, information labels that display stats of the selected spell) to update when a Spell is selected by the user, but the Spell objects don’t have to have explicit links back to the UI components. They just fire off their event (SpellSelected) and the UI controllers can listen for that event, then update the labels. It makes for a very clean implementation when done correctly.

When I finally got around to refactoring my super-hacky direct method invokations for this particular use case, I was able to remove 80% of the related code, and remove 90% of the complexity. Requiring back-pointers all over the code was making me nauseous. I was just about to implement my own solution when I came across several blog posts referring to said NSNotificationCenter, and once I saw the super-simple 3 method API I knew it was exactly the way to go. Nuff said.

Now, I will warn against going too far down the Broadcaster/Observer path, commonly called an Event-driven architecture, because I’ve seen it abused to the point of making code completely incoherent and impossible to understand or debug. Events are a natural way to pass information between unrelated objects, but between related objects, just invoke the methods directly. It more precisely expresses your intention as a code designer, and it also more precisely executes your intention.

At a startup I worked with over a year ago that shall remained unnamed, they were using Flex to build several web applications. Flex has a very well developed Event architecture, made even better by the Cairngorm micro-architecture. The problem with the product that the company was developing, is that they used Events for everything, absolutely everything. There were basically no direct method invocations on any objects, even when you naturally had the target object already in scope, and it was a child or some other natural relationship. This meant that every time flow control has to pass from one object to another, it required a listener to be added, an event to be defined, said event to be fired, and said listener to then be removed after. If that flow didn’t look obviously wrong to anyone else in the company, there’s nothing I could say to help them. It was such an absurd abomination I just didn’t even know where to begin.

I pretty much decided to begin by finding a new job.

Anyway, there was this one bug where some previous employee of the company had left a big nasty ball of mud with some problem in it, and because of the number of events fired, and the ability for multiple objects to respond to any event, it was just impractical to figure out what was going on, much less track down the problem.

Lesson: Just because you can, it doesn’t mean you should. Like all engineering tools, apply with discretion.

Permalink 2 Comments

Collision detection between circles

February 19, 2009 at 9:21 pm (iPhone development, Uncategorized) (, , , , )

Collision detection can be a little difficult with complex paths like arbitrary bezier objects.  But when the two objects are circles?  piece of cake! Find the center of each circle, then compare the distance between them. If that is less than the sum of the two radii, they collide.

The calculation is from high school geometry, and yes most of you have forgotten it. As apparently, did I. You probably recognize this:

x^2 + y^2 = z^2

and you might even remember what it applies to. When programming on the iPhone, we have x and y in coordinates from the UIView. When making the comparison between the above mentioned distance between points and radii, it’s easier to compare the squares of the respective z values, so we don’t have to compute 2 unnecessary and expensive square roots.

So anyway, I implement said solution, and go about my business. Over the next week or so, I notice that my collision detection is a little bit inaccurate. Not a lot, but a little. One night I decide I’m going to get it pixel perfect, since I should be able to pretty easily.

A few hours later, I give up and call in my wife. You see, she actually does this kind of math all day, every day. Well, not all day every day, but on a regular basis, every week. She’s a structural engineer, and they have to do calcs to make sure your house doesn’t fall over because of an over-imaginative and under-detail-oriented architect.

It turns out, I made a small…tiny mistake in how I formed the final equation. Rather than squaring the sum of the two radii, I squared each one separately, then added them together. That is:

I wrote:

rad_1^2 + rad_2^2


(rad_1 + rad_2)^2

Very easy to do in code, so watch out for it. It’s a nasty little bug to track down, because the inaccuracy changes based on the size of the circles…which varies in my app.

The final code I ended up with is below:

CGRect m_frame = [self frame];
CGRect o_frame = [otherView frame];

float m_rad = m_frame.size.width / 2;
float o_rad = o_frame.size.width / 2;

CGPoint m_center = m_frame.origin;
m_center.x += m_rad;
m_center.y += m_rad;

CGPoint o_center = o_frame.origin;
o_center.x += o_rad;
o_center.y += o_rad;

CGPoint dt;
dt.x = m_center.x – o_center.x;
dt.y = m_center.y – o_center.y;

float x_sq = dt.x * dt.x;
float y_sq = dt.y * dt.y;

// this is wrong, I screwed up the original calculation
//float mrad_sq = m_rad * m_rad;
//float orad_sq = o_rad * o_rad;

float rad_sq = (o_rad + m_rad) * (o_rad + m_rad);

return (rad_sq) > (x_sq + y_sq);


Permalink 1 Comment

iPhone SDK: The price of logging

February 18, 2009 at 5:48 am (iPhone development) (, , , , , )

While working on a few run-throughs of my currently in-development iPhone game, I came across a performance issue.  When I started playing, the game was pretty zippy…but with each turn it would continue to get slower.  And not just a little slower, a lot slower.  At first a turn might take .2 seconds or so, but by turn 6 or 7 it was up to around 4 seconds to process a turn.  What was going on?  Why am I bothering to share this with the world?

It turns out that the logging was updating a UITextView for each NSLog call, so that a player could tap on a tab and see all the results of the computer resolving all the spells.  Once there is more than one or two spells in play, a single turn could contain maybe 25-30 logging calls.  Each call would copy the whole text out of the UITextView control, append a line to it, then set the text value.  This became incredibly cpu intensive, and was slowing down the app way more than I would have ever imagined.  The instrument panel showed me everything.

system load with unbuffered logging

I was really horrified at how long a single UITextView.text = @”really long multiline multiparagraph log-like string” line can take.  It seems to me that one of the most common use cases is to append text to a control, so being forced to copy the text out, append to it, then copy it back in is really slow and painful.  Is there not a better way?  really?  It’s 2009, do I need to write this kind of control buffering myself?  Apparently, yes.

And it’s worth noting, this only became apparent while running and debugging the app on a device.  The performance issue never really showed up in the simulator, and even once I identified it, the simulator was useless even with the instrument panel.  As much as I love the simulator, and I really do, for performance work don’t waste your time.

So, the solution?  I went with the simple and obvious: create a buffered log.  I only update the LogView when I commit the buffer, while the NSLog calls still go to the console immediately.  Works like a champ!

system load with buffered logging


Permalink Leave a Comment