Grio Blog

Think Services Turns to Grio to Enhance its Flagship Products

Grio proudly announced the signing of its consulting agreement with Think Services, a division of United Business Media. As part of this collaboration, Grio will assist by designing and introducing an agile software development methodology that fits Think Services' needs. In addition, Grio will be a key player in helping to build the company's next generation of products.

Dealing with JSON on iPhone

You can easily use the JSON (JavaScript Object Notation) data format in client-server communications when writing an iPhone app. This blog is not suggesting that JSON is a more superior format for data exchange than its counterparts such as XML. In fact, we have many projects that don't use JSON. However, handling JSON is relatively straight forward in ObjectiveC.

Unfortunately, Apple iPhone SDK (as of this writing, the latest is iPhone 2.2.1) doesn't come with a built-in JSON parser. But I found out a good one called json-framework. It is both a generator and a parser. As a generator, json-framework can create JSON data from an NSDictionary. As a parser, you can pass to json-framework an NSString that consists of JSON data and it will return a NSDictionary that encapsulates the parsed data.

Next, I'm going to show you several examples. Before you proceed, download the library and make sure you add it to your SDK path list (see INSTALL file that comes with it). If setup properly, you should be able to start using the library by importing its header file:

#import "JSON/JSON.h"

Consider the following code:

NSDictionary *requestData = [NSDictionary dictionaryWithObjectsAndKeys:

 @"grio", @"username",

 @"hellogrio", @"password",

  nil];

This instantiates a new dictionary which we'll turn into a JSON string. To do so, you'll need to use a function called JSONRepresentation. This function is added as a category to NSObject. It means that as long as there's an import of JSON.h file, you can call the function on any NSObject object.

NSString* jsonString = [requestData JSONRepresentation];

And this is what you got when you print (NSLog(@"%@", jsonString);):

{"username":"grio","password":"hellogrio"}

Parsing is just as simple. Consider the following JSON data:

{

"menu": {

"id": "file",

"value": "File",

"popup": {

"menuitem": [

{

"value": "New",

"onclick": "CreateNewDoc()"

},

{

"value": "Open",

"onclick": "OpenDoc()"

},

{

"value": "Close",

"onclick": "CloseDoc()"

}

]

}

}

}

Assume that this is the data that you received from a web service called and is currently stored in an NSString called jsonResult. To parse it, you need to create SBJSON object and call one of its initialization method, objectWithString.

SBJSON *json = [[SBJSON new] autorelease];

NSError *jsonError;

NSDictionary *parsedJSON = [json objectWithString:jsonResult error:&jsonError];

If parsing fails for reasons such as invalid construct of JSON format, jsonError variable will be filled with the error info. If it is successful, parsedJSON will contain keys whose values are either an NSString or NSDictionary. Let's look at the inside of parsedJSON:

NSDictionary* menu = [parsedJSON objectForKey:@"menu"];

NSLog(@"Menu id: %@", [menu objectForKey:@"id"]);

NSLog(@"Menu value: %@", [menu objectForKey:@"value"]);

And here's the output:

Menu id: file

Menu value: File

Observe the JSON data again. popup is an NSDictionary which has an array of menuitem.

NSDictionary* popup = [menu objectForKey:@"popup"];

NSArray* menuItems = [popup objectForKey:@"menuitem"];

NSEnumerator *enumerator = [menuItems objectEnumerator];

NSDictionary* item;

while (item = (NSDictionary*)[enumerator nextObject]) {

NSLog(@"menuitem:value = %@", [item objectForKey:@"value"]);

}

And this is the output:

menuitem:value = New

menuitem:value = Open

menuitem:value = Close

It's that simple. Now you're ready to use JSON in your next iPhone project.

Broadcasting Information: How to use the iPhone Notification Center

There are times when building an iPhone application that you need to inform other parts of the program to do something, without regard to what or where those parts are. The NSNotificationCenter (aka “notification center”) is the way to go in these cases. Using notifications supports ‘loose coupling’, which is a good thing in software design.

A notification center object provides a mechanism for broadcasting information (“notifications”) within a task. An NSNotificationCenter object is basically a notification dispatch table. For those familiar with Windows programming, this pattern is similar to the Windows Message Loop architecture.

For example, one object may be performing a long-running operation (such as downloading a file) and needs to inform view controllers to change the view to indicate this busy state. While we could pass around a bunch of object references, it is much easier to post a notification and let the listening objects decide what to do.

First, we’ll register with a notification center to receive notifications. Here’s the call:

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(myMethod) name:@"DoSomething" object:senderICareAbout];

So what’s going on here? First, we get a reference to the default notification center for the current task (application). Then we add ourselves (the calling object) as an observer of the notification.

The selector specifies the method we want to call when this notification arrives. The selector method takes one argument, which is an NSNotification object. It contains information about the notification, such as the name and sender object.

The notification name is the ‘message’ we are listening for. This parameter can be nil if we want to receive all notifications.

Finally, the object parameter is used to limit incoming notifications to those from a particular object. This can also be nil if you don’t care where the notification came from.

Now that we have an object listening, we can send (“post”) a notification. Here’s the code to do that:

[[NSNotificationCenter defaultCenter] postNotificationName:@"DoSomething" object:self];

The parameters here are pretty straightforward. We post the name of the notification, and the sender object (self in this case). If we don’t care about the sender object, we can use:

[[NSNotificationCenter defaultCenter] postNotificationName:@"DoSomething"]

which will set the sender object to nil in the received NSNotification.

A notification center delivers notifications to observers synchronously. In other words, the postNotification: method does not return until all observers have received and processed the notification. If you want to send notifications asynchronously, you should use a notification queue (NSNotificationQueue). We’ll save that discussion for another day.

A note of caution: in multithreaded applications, notifications are delivered in the same thread that the notification was posted, which may not be the same thread in which an observer registered, so be careful. If you are threading a long process, you should send the notification in the main thread, not the thread created for the process.

Now you have the information you need to start broadcasting notifications to your hearts content. This will help keep your application code mean and clean.

Scrum is like 20th Century Politics (Part 1 of 3)

Scrum is a bit like 20th century politics. You have your burn-down crazed fascists, your ground-up "power to the coding plebe" reds, greedy ladder climbers hiding under the guise of scrumocracy, and on very rare occasions... responsible elected representation.

Fascism

Let's deal with the fascists first. Your average scrum doctrinaire falls back on phrases like "command and control" to describe the tired, archaic waterfallists. They should poke their own chests with that finger. I'm going to stick my neck out here and suggest that a large percentage of businesses practicing scrum err on the side of a Gestapo-like control. Why? Well let me answer you with a question: What do you think got your Product Owner or Director of Engineering their job in the first place?

Answer: great references, perfect school grades since the age of two and never, ever screwing up. These guys are simply NOT going to let the project fail. They are a proud and elite race of corporate warriors dreaming of business Valhalla (a promotion, crown, or scepter) and the scrum team had better get behind that.

Now occassionally even a proud fascist has to hide their true nature. So while the business proponents listen gently to your Fibonacci estimates during planning poker, you can be sure that behind those polite smiles lies a calculator...translating to hours and days...translating to reich marks. "Are you SURE that's a 13, Bob?" - strained silence.

"Individuals and interactions over processes and tools"

You got it, that's from the scrum manifesto. So why the Mingles, the Jira GreenHoppers, the ScrumDesks and the plethora of other surveillance tools on the market? Whatever happened to good 'ol 3M sticky notes and a whiteboard? Rightwing scrumists are staunch apologists for complex tools and doohickies and demand that their troops log a good 10-15 minutes per day up and down and up and down the square.

Not only does this daily logging crush the team's will, impede creativity and keep them in lockstep, it also allows the scrum dictator to assess performance from the comfort of their bunker (cube) without the burden of attending standups. Who wants to suffer the humiliation of being called a "chicken" in public? While I can't exactly answer that, I can claim with confidence that a self-respecting despot will not.

A strong ruler does not tolerate insubordination, and this makes the proponents of the communist school of scrum (described later) intractable enemies that need to be rooted out and destroyed. The reds want to empower the team itself to make decisions and write the schedule, and this flies in the face of middle management's divine right to rule.

A dictatorial stakeholder will often recruit allies and moles from among the scrum teams in order to attempt to dismantle the scrum process and consolidate power (military coup towards a waterfallist dictatorship) or to bend the scrum process to their will and claim credit (imperialist scrum by mass popularity). It is these two scenarios which scrum-members of communist ideals most fear and have vowed to fight.

Coming soon in Part 2: Communism

KillerDeals 1.0.1 hits the shelves

Last Thursday KillerDeals v1.0.1 hit the shelves in the iPhone AppStore. It was only a minor update to fix a few bugs that appeared post release. So we got right to work hammering out a quick fix and Apple approved the update in no time flat. This was good news.

The necessity for the "emergency" update got us all really talking about the future of this application and where we want to head in the future. Here's a short list of the plans that will be rolling out over the next few releases:

1. Create a KillerDeals web service - Currently our application communicates directly with the ODAT web sites, retrieves the content, parses it, and redisplays it in its current format. Although this is a completely acceptable approach, we are at the mercy of Backcountry. If their developers change the website format or content, our app is too tightly coupled to handle this change and thus we would need to release another application version through the iPhone store. But if we moved the retreval and parsing code to a Grio owned server, we can make changes on the "fly" without ever having to release an update through Apple. Much faster response time to content related issues.
2. Push notifications -This app was meant to incorporate Apple's Push Notification system. Apple has been promising this technology for quite some time and iPhone 3.0 will finally deliver it. We all very excited about this. We have some very unique ideas about how Push alerts should be configured but you'll just have to wait to check out our innovative approach.
3. More sites -  Recently added to the ODAT family are Brociety.com and Chainlove.com. Expect to see these sites in KillerDeals sooner than you might think. But with 6 stores the tabs might get a little crowded. So we'll just have to see what our crafty Grio developers come up with.
4. More information - KillerDeals is lacking a few bits of crutial information in its current state. Items and time remaining are key indicators for the ODAT sites. Expect to this this data ticking down the seconds in an upcoming version of KillerDeals

In summary, I guess you can expect KillerDeals just to get better with every release. Remember we are exicted to here from our users so drop us a note or leave us a blog comment. We'll be waiting.