Monthly Archives: July 2012

What He Said

Dave Winer: “Working with computers isn’t conducive to a whirlwind approach. You really can’t do writing, design or development work inbetween crazy-busy-life tasks. Computers don’t lend themselves to that kind of thought. You often don’t find the problem till you have a chance to quietly and dispassionately go through the situation, asking all kinds of questions along the way. It’s been observed many times that the problem often turns out to be something dumb that you overlooked. That’s exactly the kind of thing you can’t see when you’re whirling around. “

When it comes to coding I tend to stare at the screen for a long time before writing a line of code. Often I create experiments and throw them away before doing the real version. It’s not always like that, I usually do that when I’m trying something new, but work like that takes uninterrupted time.

I think Dave really nailed it.

What Does That Mean?

The Verge: “He said that instead of wanting companies who “build off Twitter,” he prefers “a world where people build into Twitter” (emphasis ours).”

All this talk around building inside, and becoming a hub for events? Sounds like the MySpace mistake.

I wonder if they’re going to use Posterous as the engine to help people build inside Twitter?

Does building inside mean writing lowest common denominator HTML? Ick. With all the power we have in the palm of our hands why use it to make a less than stellar web based experience. Oh, right, it worked for Facebook.

Here’s hoping, once again, they don’t kill off third party clients.

The Sparrow Acquisition Is A Good Thing

A wonderful boquet of flowers.Selligy Weblog: “This is not a good trend for Apple. Apple is depending on apps like Sparrow to make the iOS platform shine. Excellent apps like Sparrow cost a lot of money to build and maintain. Apple should be working hard to ensure independent app developers can earn even more than top salaries at Google, or they will all be poached away.”

Why should, or would, Apple care about keeping developers around? If someone walked up to me with a big pile of cash and wanted to acquire my popular, or unpopular app, and I felt it was a good thing, I’d do it in a heartbeat. So would a lot of people. This is the American Free Market at its best. A company puts together a group of talented people, creates a product people love, and gets the attention of a bigger company. That bigger company comes along and gobbles up the talent. Sure, as a user of Sparrow you may be a bit bummed, but it won’t last for long. As a little guy just getting started this is an opportunity. It means if I wanted to, I could pick up where Sparrow left off and create a great email client that looks and acts just like it. Filling that hole. Heck, maybe I’ll do something MUCH better. It will happen.

I have a feeling there is a company, or individual, out there today, slinging code in hopes to bring a new Sparrow-like client to life.

That’s pretty exciting.

Google Acquires Sparrow

“While we’ll be working on new things at Google, we will continue to make Sparrow available and provide support for our users.” – Sparrow

It sounds like Google bought a development team. Hopefully this leads to great new iOS and Android GMail clients.

Here’s hoping.

UPDATE: Oh, wow. From the Sparrow App Store page.

“As the team works on new projects, there will be no new features released for the Sparrow apps, other than minor maintenance and bug fixes.”

Do you think that will kill sales?

UPDATE 2: Matthew Panzarino, of The Next Web, has the best coverage. It includes a statement from Google that pretty much says they bought a development team to work on GMail.

Revisiting Objective-C, REST, and JSON

I get a lot of hits on this site for two posts.

  1. Objective-C REST and JSON
  2. Objective-C Objects from JSON

Both posts touch on using JSON to create Objective-C objects. The first one mostly talks about great Cocoa Libraries you can use to make REST calls and parse JSON results.

Since that time JSON parsing has become a part of iOS. In iOS 5 Apple introduced NSJSONSerialization.

For a presentation on REST and JSON to @NSSLO back in May I created a super simple project that used NSURL, NSMutableURLRequest, NSURLConnection, and NSJSONSerialization to call the iFixIt API.

If you’re interested in grabbing the project, it’s available on GitHub.

Will write C/C++ for food

The Code

Most of the RESTTest project is a boiler plate iOS application. There are a couple places in MasterViewController.m you should pay attention to and we’ll take a look at the iFixItBadges and the iFixItBadge classes.

The Basics

To get the ball rolling we make a call to a private method: getBadges.

- (void)getBadges; {
	NSURL *url = [NSURL URLWithString:@"http://www.ifixit.com/api/0.1/badges"];
	NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url
                                                           cachePolicy:NSURLRequestReloadIgnoringCacheData 
                                                       timeoutInterval:10];
	if (request) {
		[request setURL:url];
		connection = [[NSURLConnection alloc] initWithRequest:request delegate:self];
	}
}

This method is pretty straight forward and uses three of the four classes we mentioned above; NSURL, NSMutableURLRequest, and NSURLConnection. That’s all it takes to do a simple(REST) HTTP GET call. Yes, it’s sample code, so it’s not complex and is not something you’d find in a shipping application as is. It would need some beefing up and it definitely changes if you’re going to do a POST, or DELETE call, not to mention the lack of authentication. I picked the badges call because it didn’t require authentication.

When we allocate and initialize NSURLConnection it takes off and starts doing the work. Notice we’ve specified self as the delegate, which means NSURLConnection will expect us to have implemented the NSURLConnectionDelegate Protocol.

The next method we’ll want to take a look at is connectionDidFinishLoading.

- (void)connectionDidFinishLoading:(NSURLConnection*)connection
{
	NSString* s = [[NSString alloc] initWithData:receivedData encoding:NSASCIIStringEncoding];
	NSLog(@"Received data %@", s);

    badges = [[IFixItBadges alloc] initWithData:receivedData];
    
    [self.tableView reloadData];
}

This is called by NSURLConnection when it’s finished receiving the response from our badges call. At this point we should have a nice JSON response to parse. Notice we’re working on receivedData, which is private and is built in the didReceiveData method. I’d recommend building the code and running it in the debugger to see how it works.

Back to connectionDidFinishLoading. We have our receivedData (an NSMutableData*), now we’re going to create an IFixItBadges object.

Creating objects from JSON

To review. We’ve called the iFixIt badges method and we’ve received our response data. Now we need to do something with it. Say hello to NSJSONSerialization.

- (id)initWithData:(NSData*)data;
{
    if ((self = [super init])) {
        badges = [[NSMutableArray alloc] init];
        
        NSError *error = nil;
        NSArray *resultData = [NSJSONSerialization JSONObjectWithData:data
                                                              options:kNilOptions
                                                                error:&error];
        if (resultData && nil == error && badges) {
            NSDictionary *badgesData = nil;
            NSEnumerator *resultsEnum = [resultData objectEnumerator];
            while (badgesData = [resultsEnum nextObject]) {
                IFixitBadge *badge = [[IFixitBadge alloc] initWithDictionary:badgesData];
                [badges addObject:badge];
            }
        }
    }
    
    return self;
}}

When we get our result back we create an iFixItBadges object, which is a collection of iFixItBadge objects. We could’ve just as easily used NSMutableDictionary or NSMutableArray to hold these objects.

Notice the use of NSJSONSerialization. One call. That’s all it takes to create an array of data we can then iterate over to create an iFixItBadge to add to our collection. Once the collection is created we tell the table view to reload itself using [self.tableView reloadData];

That’s it in a nutshell. If you have any questions about this, or find a problem, please feel free to leave a comment or send email to rob.fahrni@gmail.com.

Happy coding.

My @Twitterrific for iOS Wish List

It’s no secret I’m a big fan of Twitterrific from The Iconfactory. I’ve tried a number of Twitter clients, but I keep coming back to Twitterrific. I think it has a lot to do with the minimalistic design. It just works and doesn’t have a lot of extraneous features. But, and there’s always a ‘but’, there are some things I’d like to see. Mostly I’d like a small change to the user interface. It’s something I’ve designed in my top secret design notebook, but since I’ll never create my dream Twitter client, I might as well share these minor UI tweaks in hopes someone will do it. Hopefully, The Iconfactory does it. You never know, it could happen.

Oh, please forgive the mess. I can’t spell Photoshop, much less use it. At least this hack should get the idea across.

Yeah, yeah, I know, it’s all hacked up, but it’ll do.

On the left Twitterrific as it sits today, on the right is what I’d like to see. What’s different?

  1. The account back button is gone.
  2. The title “All Tweets” is gone, replaced by the account name.
  3. The Profile Icon, gone. Replaced by the “Compose Tweet” button.
  4. The bottom bar/toolbar, gone. No replacement.

Since the back button is now gone for choosing an account it’s replaced by the account name in the top bar. Tapping on the name allows you to choose which account to view or what you’d like to view for the current account; All Tweets, Mentions, Messages, Favorites, or Search.

In the upper right corner we’ve replaced the Profile icon with the Compose Tweet icon. To show your profile you can tap on your avatar in a tweet, which works today.

In the lower left corner the refresh button has been removed. I kind of like having an explicit refresh button, but “Pull to refresh” is ubiquitous. If you’d like to have a refresh button, put it in the upper left corner.

The purple bar across the bottom works as it does today. It pops up for a few seconds after a refresh, then goes away.

I think that does it for now.

Updating Twitter from a Facebook RSS feed

Last November Eureka Burger opened a new store in San Luis Obispo and I wanted to keep up to date on events, so I searched for them on Twitter. No luck. They didn’t have a Twitter account, but they did have a Facebook page.

@EurekaBurgerSLO

Since I knew I could publish to Twitter from the excellent ifttt using an RSS feed I setup an Unofficial Eureka Burger SLO Twitter account, @EurekaBurgerSLO. A few clicks to create a Recipe on ifttt and the account was up and running.

Enter Facebook Timelines

When Facebook switched on the new Timeline feature the RSS feed for Eureka Burger SLO stopped working and the @EurekaBurgerSLO account stopped updating. Since I didn’t have a Facebook account I asked my wife to go through the process of finding an RSS feed for a Facebook Timeline. We couldn’t find one, so I gave up on the account and approached a Manager at Eureka Burger SLO about taking over the account. He agreed and I turned over the account to Eureka Burger. I was absolutely trilled. I no longer had to maintain the account and all the problems that might come along for the ride.

Why isn’t it updating?

After a while I noticed the @EurekaBurgerSLO account stopped updating. Why? Well it looks like they had one person updating the feed, instead of hooking it to their Facebook account to automagically publish to Twitter. As of this writing the last update was June 8, 2012. That really bummed me out.

Introducing @SLOEurekaBurger

That’s right, I’ve created a new account so I can automagically update it and see what beer is featured on “Steal the glass night.”

This time around I did a bit of digging, ok, I did a single Google query that lead me to this entry of Stack Overflow. It allowed me to dig out the Facebook RSS feed for Eureka Burger SLO with a couple URL’s.

How To Find a Facebook Wall RSS Feed

We’re going to use the Eureka Burger SLO Facebook account as an example, since it’s what I used.

Step 1: Right click the GIGANTOR image, known as a Cover, and copy the URL.

Step 1: Copy the URL

In this case the URL is:

http://www.facebook.com/photo.php?fbid=335049253213178&set=a.335049249879845.89916.234741763243928&type=1

All we need is the fbid parameter, in bold above.

Step 2: Check the Facebook Graph for that fbid

http://graph.facebook.com/335049253213178

The graph call will produce a JSON feed that looks like this:

Step 1: Copy the URL

Notice the highlighted number id. We need to copy that number for the next step in the process.

Step 3: Get the RSS Feed

https://www.facebook.com/feeds/page.php?id=234741763243928&format=rss20

Once again, notice the bold text above. That’s the id we copied from step two. Now you have an RSS feed for a Facebook Wall. Very nice.

Step 4: Create an ifttt Recipe

Since I needed a way to publish that RSS feed to the new @SLOEurekaBurger Twitter account I chose to use ifttt. I’ll let you go explore that. Ifttt is an awesome service if you need to transform data from one format to another, or from a format to a social media stream, like going from a Facebook RSS feed to Twitter.

Hopefully someone will find this useful. I know I did. Let’s hope it works.