Grio Blog

Uploading Files from iPhone

We recently completed an iPhone application that allows user to, among other things, perform voice-recording and upload the recorded file to a server. For uploading, it uses HTTP multipart POST against an Apache webserver. This type of arrangement is a very common way of sending a file to a webserver. I am certain that similar implementations can be found in several different programming languages. Here is my Objective C implementation...I tried to focus on brevity and encapsulation.

The code:

/**

 * Upload a file to a webserver thru http post.

 * uid is the http request id

 * requestData is list of key/value pairs to be sent along with the file

 * url is the destination url

 * filePath is absolute file path of the file to be uploaded

 */

- (void)postUpload:(NSString *)url

  :(NSString *)uid

  :(NSDictionary *)requestData

  :(NSString *)filePath

{

NSURL *theURL = [NSURL URLWithString:url];

NSMutableURLRequest *theRequest = [NSMutableURLRequest requestWithURL:theURL 

     cachePolicy:NSURLRequestReloadIgnoringCacheData 

 timeoutInterval:20.0f];

[theRequest setHTTPMethod:@"POST"];

[theRequest setValue:uid forHTTPHeaderField:@"uid"];

// define post boundary...

NSString *boundary = [[NSProcessInfo processInfo] globallyUniqueString];

NSString *boundaryString = [NSString stringWithFormat:@"multipart/form-data; boundary=%@", boundary];

[theRequest addValue:boundaryString forHTTPHeaderField:@"Content-Type"];

// define boundary separator...

NSString *boundarySeparator = [NSString stringWithFormat:@"--%@\r\n", boundary];

//adding the body...

NSMutableData *postBody = [NSMutableData data];

// adding params...

for (id key in requestData) {

NSString *formDataName = [NSString stringWithFormat:@"Content-Disposition: form-data; name=\"%@\"\r\n\r\n", key];

NSString *formDataValue = [NSString stringWithFormat:@"%@\r\n", [requestData objectForKey:key]];

[postBody appendData:[boundarySeparator dataUsingEncoding:NSUTF8StringEncoding]];

[postBody appendData:[formDataName dataUsingEncoding:NSUTF8StringEncoding]];

[postBody appendData:[formDataValue dataUsingEncoding:NSUTF8StringEncoding]];

}

// if file is defined, upload it...

if (filePath) {

NSArray *split = [filePath componentsSeparatedByString:@"/"];

NSString *fileName = (NSString*)[split lastObject];

NSData *fileContent = [NSData dataWithContentsOfFile:filePath options:0 error:nil];

[postBody appendData:[boundarySeparator dataUsingEncoding:NSUTF8StringEncoding]];

[postBody appendData:[[NSString stringWithFormat:@"Content-Disposition: form-data; name=\"audioBody\"; filename=\"%@\"\r\n", fileName] dataUsingEncoding:NSUTF8StringEncoding]];

[postBody appendData:[@"Content-Type: application/octet-stream\r\n\r\n"

dataUsingEncoding:NSUTF8StringEncoding]];

[postBody appendData:fileContent];

}

[postBody appendData:[[NSString stringWithFormat:@"\r\n--%@--\r \n",boundary]

dataUsingEncoding:NSUTF8StringEncoding]];

[theRequest setHTTPBody:postBody];

NSURLResponse *theResponse = NULL;

NSError *theError = NULL;

NSData *reqResults = [NSURLConnection sendSynchronousRequest:theRequest

  returningResponse:&theResponse

  error:&theError];

if (!reqResults) {

NSLog(@"Connection error for URL: %@", [url description]);

UIAlertView *alert = [UIAlertView alloc];

[[alert initWithTitle:@"Error in connection"

  message:[theError localizedDescription]

delegate:self

cancelButtonTitle:nil

otherButtonTitles:@"Quit", nil] autorelease];

[alert show];

}

}

Here's an example of how you can use this method:

NSArray *keys = [NSArray arrayWithObjects:@"recipients", @"title", @"textBody", nil];

NSArray *objects = [NSArray arrayWithObjects:uids, inputSubject.text, inputMessage.text, nil];

NSDictionary* postData = [NSDictionary dictionaryWithObjects:objects forKeys:keys];

// post now...

[[WebService alloc] postUpload:URL_ENDPOINT_SEND_MESSAGE

  :appDelegate.uid

  :postData

  :[recorder recordFilePath]];

URL_ENDPOINT_SEND_MESSAGE is set to the URL that can receive a multipart POST. To test this out, I have quickly written the following PHP code. 

<?php

define('FILE_SAVE_DIRECTORY','/folder/to/save/uploaded/files/');

error_log("Requesting upload file....");

error_log(print_r($_SERVER, true));

error_log("\n\n");

error_log(print_r($_FILES, true));

if($_POST && isset($_FILES['file'])) {

error_log("  the file:...." . $_FILES['file']['name']);

$file = $_FILES['file'];

$dst = FILE_SAVE_DIRECTORY . basename($file['name']);

if (move_uploaded_file($file['tmp_name'], $dst)){

echo 'Upload Successfully: '.$dst;

}

else {

echo 'Error uploading the file.';

}

}

?>

Put this code in your php-enabled webserver. Then, set URL_ENDPOINT_SEND_MESSAGE to point to the script.

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

Feel My Pain: NSXMLParser Problems Upgrading to the iPhone 3.0 SDK

I set out a couple of weeks ago to port the Killer Deals application from the iPhone 2.2.1 SDK to 3.0. “No problem”, I thought; the application doesn’t veer far from the standard APIs and controls, and it is a relatively straightforward application, implementation-wise.

As I was making my updates (some minor method and property name changes here and there), I stumbled upon a show stopper: The NSXMLParser was no longer parsing my XML data. After scratching my head for a few hours, I finally figured out the problem.

It seems Apple has removed support for Windows-1252 character encoding in the latest iteration of the NSXMLParser. I used this encoding to prevent the appearance of those funny characters you occasionally see on a web page. Those funny characters are caused by a character-encoding mismatch between a text renderer and the document. Some Microsoft tools use the Windows-1252 character encoding for documents by default. Unfortunately, some of the Killer Deals data is only available in this encoding.

While the previous version would give a NSXMLParserUnknownEncodingError and continue to parse, the new version simply stops parsing after the error (although strangely, the parserDidStartDocument() method is still called after the error).

At this point, I was going to force the encoding to UTF-8 on the server, and put a hack in the code to convert the ‘invalid’ characters to the proper UTF-8 equivalents. That ended up in an invalid character error via the parser.

It seems Apple has degraded the parser and offers less tolerance for ‘unsupported’ formats. Does this have anything to do with bad blood between Apple and Microsoft? Hmmm…

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.

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.

KillerDeals v1.0 iPhone Application submitted to Apple

Recently, we submitted our new iPhone application to Apple and it is currently under review. It has been approved and is available at iTunes store. It's called KillerDeals. It's a lifestyle application targeted at users who are either currently fans of sites like Steepandcheap.com and Tramdock.com or new users who are looking for amazing retail deals on outdoor clothing and equipment.

KillerDeals gives you access to 4 of the hottest sources for outdoor gear on the web in the one convenient application. Now you can check the latest deals anytime, anywhere.

KillerDeals features products from:

- SteepandCheap ®
- TramDock ®
- WhiskeyMilitia ®
- ChainLove ®

KillerDeals displays all the relevant information for each gear deal including photos, detailed descriptions, prices, and even customer reviews.

Not familiar with these sites? Here's the scoop:  These sites offer one awesome piece of gear at a stupidly low price until it sells out; then the next deal appears. The first crazy deal drops
each midnight (MT) and sells ‘til it’s gone. And they always sell fast. After that another steal drops and sells till it's gone, then another, and another, ... Get the idea? Killer.

Here's some screenshots to get you excited.