So the other day, that’s what I tried to do. The app is very simple. It takes a randomly generated caption and burns it on to an image. You can pick an image from your camera or your library.

When I wrote the BD’s Mongolian BBQ app, I took stamps and burned them onto an image to create funny mustache pictures. The way I did that was to position UIImageViews inside of a UIView and then render the view to an image. That strategy works fine, but it also drops the image resolution down quite a bit. (It will be whatever the size of the view is)

So this time, I decided to render the text directly onto the image by hand. This involves getting a graphics context, drawing the image into it, then drawing the text into it, and finally getting the resulting UIImage from the graphics context.

My first approach was to use a UILabel to render the text onto the image. That would take care of all the font sizing issues and save some code. This worked great, until I had white text on a light image. There’s a couple ways to solve this problem like putting a stroke around the text or adding a shadow to the text. I’d Cap That uses a shadow. I decided to go for a more meme style look and stroke the text.

Unfortunately, UILabel doesn’t support adding a stroke around the text. So I looked for some classes online that might get the job done. I found a couple, but they didn’t work like I wanted. Luckily, CoreGraphics lets you draw stroked text, you just have to handle more by yourself.

-(UIImage*)getImage:(UIImage*)image withCaption:(NSString*)captionString
{
   UIGraphicsBeginImageContext([image size]);
   [image drawInRect:CGRectMake(0, 0, image.size.width, image.size.height)];

   CGFloat captionFontSize = 300;
   CGSize captionSize = [captionString sizeWithFont:[UIFont boldSystemFontOfSize:captionFontSize]];

   while( captionSize.width > image.size.width )
   {
      captionFontSize -= 5;
      captionSize = [captionString sizeWithFont:[UIFont boldSystemFontOfSize:captionFontSize]];
   }

   CGRect captionRect = CGRectMake((image.size.width - captionSize.width)/2.0, (image.size.height * .95)-captionSize.height, captionSize.width, captionSize.height);

   CGContextRef context = UIGraphicsGetCurrentContext();
   CGContextSetFillColorWithColor(context, [UIColor whiteColor].CGColor);
   CGContextSetStrokeColorWithColor(context, [UIColor blackColor].CGColor);
   CGContextSetLineWidth(context, 3.0f);
   CGContextSetTextDrawingMode(context, kCGTextFillStroke);

   [captionString drawInRect:captionRect withFont:[UIFont boldSystemFontOfSize:captionFontSize]];

   UIImage *outputImage = UIGraphicsGetImageFromCurrentImageContext();

   UIGraphicsEndImageContext();
   return outputImage;
}

The problem with rendering the text yourself is that you need to size the font yourself. The way I’m doing it is picking a large font size (300 in this case) then measuring it and adjusting the font size until it fits on the image. There’s likely a better way, but this works and is fast enough.

I haven’t decided if I’m gonna release this app or not, like I did with my other Afternoon Apps. I have the source code up on GitHub though, so feel free to take a look and use whatever you want from it.

There’s some issues with it. The camera view doesn’t work quite right. There aren’t any icons. One little feature in there is you can add to the list of captions. Of course the real secret sauce of I’d Cap That isn’t the app, it’s the hilarious captions.

Descrumbled is an app for solving Boggle puzzles. Boggle is a word game where you have to find words hidden in a grid of letters. The app lets you enter a board and quickly generate all possible words that can be found in the puzzle. It uses the SOWPODS dictionary to see if a word is valid or not.

I was able to build the app in an afternoon because it is very simple. It lets you pick two board sizes, 4×4 and 5×5. Then you can enter the board, press solve, and seconds later you get a list of all the words. Pressing a word will give you the definition thanks to iOS 5’s dictionary integration.

The hard part was actually solving the puzzle. Generating all the possible words in the puzzle and checking them against a 230,000 word dictionary is no trivial task. I’m going to let you in on a little secret. I didn’t write the boggle solver in a single afternoon. I had written it before by working on it a few hours a day for 3 or so days. It was a programming challenge I found online and I tried to do it. It’s actually a lot of fun solving a problem like this. I get to think about tries and binary searches. Things I haven’t actually had to think much about since college. My first stab at it took about 3 minutes to solve a 4×4 puzzle. Since most online Boggle rounds are 1 or 2 minutes, this obviously wasn’t acceptable. I improved my algorithm and now it takes ~1 second to solve a 5×5 puzzle.

So what did I actually do in an afternoon? I built a UI around my boggle solver class. I had to get a C++ class working on the iPhone (which is actually really easy) and build a UI for entering the board. The squares on the board auto advance the cursor through a grid of UITextFields. It also makes sure the board is complete before it tries to solve. Then I had to make a way to clear the board and switch between a 4×4 grid and a 5×5 grid. The word list UI is just a very simple UITableView. When you press a row, it will open up the definition of the word in a UIReferenceLibraryViewController (new in iOS 5).

That’s it. The app is meant to be simple and easy to use. It really is a minimum viable product. I did this as an exercise to see if I could build a simple app and submit it to the app store in an afternoon. I want to keep doing these Afternoon Apps every few weeks. I’d love to see if other people have done similar things and find out how your experience went.

The app should be live any day now. Check it out!

Images. With the iPhone 4, Apple introduced an image naming schema that would allow you to load large images for the retina display and small ones for devices without it.

When the iPad launches an iPhone app, it launches it at the original iPhone resolution of 320×480. When you press the 2x button on the iPad it will stretch it out to 640×960 (the same resolution as the retina display).

This stretching, makes everything double in size and it all looks pixelated. So if you have an image that is 100 pixels wide, it will become 200 pixels wide and look like crap. But what happens if the image you provide is already 200 pixels wide?

It turns out that it looks pretty good. It shows up at the correct resolution with no pixelation.

The only problem with this is that if you give it a low res image, it will load it. Then it stretches and looks like crap. What you need to do is forget about the low res images and just include hi-res images.

“Won’t it look bad on the iPhone 3GS?” No. It’ll look fine. It’s scaling by half. Even the most rudimentary scaling algorithms look fine when it’s perfectly halved. You might lose a little bit of detail on some images, but it’s not much more detail than you’d lose using Photoshop to scale the images. Nobody will notice.

You can use the @2x naming convention if you want to, the images will all load just fine. There is a bug in Xcode 4’s interface builder that causes it to fail to load the images unless you put the @2x in the image name. This used to work in Xcode 3 before.

Including 2 images now is kind of silly. It makes the app larger (which can prevent you from downloading over 3G) and adds extra files that you need to manage. It’s easy to misname an image and end up with a pixelated piece of crap on your phone. The large images look just fine on the low res screens. I promise. It’s really too bad that iOS doesn’t render an iPhone app at the larger resolution on the iPad. It already knows how to draw the app at the double resolution for the retina display. Maybe with iOS 6.0.

Because of this, code written for the iPhone needs to be compiled twice, once for the simulator and once for the device. This makes working with static libraries a bit of a pain, because you need two of them, one for each architecture.

Luckily, it’s possible to build a “universal” binary that will work with both architectures. Apple did this during their switch from PowerPC to Intel.

I found the directions in this StackOverflow post.

• All you need to do is create a new static library target.
• Add a “Run Script” build phase.
• Copy and paste this script in.
• Your build output should be in a folder labeled Debug_universal or Release_universal

# Version 2.0 (updated for Xcode 4, with some fixes)
# Changes:
#    - Works with xcode 4, even when running xcode 3 projects (Workarounds for apple bugs)
#    - Faster / better: only runs lipo once, instead of once per recursion
#    - Added some debugging statemetns that can be switched on/off by changing the DEBUG_THIS_SCRIPT variable to "true"
#    - Fixed some typos
#
# Purpose:
#   Create a static library for iPhone from within XCode
#   Because Apple staff DELIBERATELY broke Xcode to make this impossible from the GUI (Xcode 3.2.3 specifically states this in the Release notes!)
#   ...no, I don't understand why they did this!
#
# Author: Adam Martin - http://twitter.com/redglassesapps
# Based on: original script from Eonil (main changes: Eonil's script WILL NOT WORK in Xcode GUI - it WILL CRASH YOUR COMPUTER)
#
# More info: see this Stack Overflow question: http://stackoverflow.com/questions/3520977/build-fat-static-library-device-simulator-using-xcode-and-sdk-4

#################[ Tests: helps workaround any future bugs in Xcode ]########
#
DEBUG_THIS_SCRIPT="false"

if [ $DEBUG_THIS_SCRIPT = "true" ]
then
echo "########### TESTS #############"
echo "Use the following variables when debugging this script; note that they may change on recursions"
echo "BUILD_DIR = $BUILD_DIR"
echo "BUILD_ROOT = $BUILD_ROOT"
echo "CONFIGURATION_BUILD_DIR = $CONFIGURATION_BUILD_DIR"
echo "BUILT_PRODUCTS_DIR = $BUILT_PRODUCTS_DIR"
echo "CONFIGURATION_TEMP_DIR = $CONFIGURATION_TEMP_DIR"
echo "TARGET_BUILD_DIR = $TARGET_BUILD_DIR"
fi

#####################[ part 1 ]##################
# First, work out the BASESDK version number (NB: Apple ought to report this, but they hide it)
#    (incidental: searching for substrings in sh is a nightmare! Sob)

SDK_VERSION=$(echo ${SDK_NAME} | grep -o '.\{3\}$')

# Next, work out if we're in SIM or DEVICE

if [ ${PLATFORM_NAME} = "iphonesimulator" ]
then
OTHER_SDK_TO_BUILD=iphoneos${SDK_VERSION}
else
OTHER_SDK_TO_BUILD=iphonesimulator${SDK_VERSION}
fi

echo "XCode has selected SDK: ${PLATFORM_NAME} with version: ${SDK_VERSION} (although back-targetting: ${IPHONEOS_DEPLOYMENT_TARGET})"
echo "...therefore, OTHER_SDK_TO_BUILD = ${OTHER_SDK_TO_BUILD}"
#
#####################[ end of part 1 ]##################

#####################[ part 2 ]##################
#
# IF this is the original invocation, invoke WHATEVER other builds are required
#
# Xcode is already building ONE target...
#
# ...but this is a LIBRARY, so Apple is wrong to set it to build just one.
# ...we need to build ALL targets
# ...we MUST NOT re-build the target that is ALREADY being built: Xcode WILL CRASH YOUR COMPUTER if you try this (infinite recursion!)
#
#
# So: build ONLY the missing platforms/configurations.

if [ "true" == ${ALREADYINVOKED:-false} ]
then
echo "RECURSION: I am NOT the root invocation, so I'm NOT going to recurse"
else
# CRITICAL:
# Prevent infinite recursion (Xcode sucks)
export ALREADYINVOKED="true"

echo "RECURSION: I am the root ... recursing all missing build targets NOW..."
echo "RECURSION: ...about to invoke: xcodebuild -configuration \"${CONFIGURATION}\" -target \"${TARGET_NAME}\" -sdk \"${OTHER_SDK_TO_BUILD}\" ${ACTION} RUN_CLANG_STATIC_ANALYZER=NO"
xcodebuild -configuration "${CONFIGURATION}" -target "${TARGET_NAME}" -sdk "${OTHER_SDK_TO_BUILD}" ${ACTION} RUN_CLANG_STATIC_ANALYZER=NO BUILD_DIR="${BUILD_DIR}" BUILD_ROOT="${BUILD_ROOT}"

ACTION="build"

#Merge all platform binaries as a fat binary for each configurations.

# Calculate where the (multiple) built files are coming from:
CURRENTCONFIG_DEVICE_DIR=${SYMROOT}/${CONFIGURATION}-iphoneos
CURRENTCONFIG_SIMULATOR_DIR=${SYMROOT}/${CONFIGURATION}-iphonesimulator

echo "Taking device build from: ${CURRENTCONFIG_DEVICE_DIR}"
echo "Taking simulator build from: ${CURRENTCONFIG_SIMULATOR_DIR}"

CREATING_UNIVERSAL_DIR=${SYMROOT}/${CONFIGURATION}-universal
echo "...I will output a universal build to: ${CREATING_UNIVERSAL_DIR}"

# ... remove the products of previous runs of this script
#      NB: this directory is ONLY created by this script - it should be safe to delete!

rm -rf "${CREATING_UNIVERSAL_DIR}"
mkdir "${CREATING_UNIVERSAL_DIR}"

#
echo "lipo: for current configuration (${CONFIGURATION}) creating output file: ${CREATING_UNIVERSAL_DIR}/${EXECUTABLE_NAME}"
lipo -create -output "${CREATING_UNIVERSAL_DIR}/${EXECUTABLE_NAME}" "${CURRENTCONFIG_DEVICE_DIR}/${EXECUTABLE_NAME}" "${CURRENTCONFIG_SIMULATOR_DIR}/${EXECUTABLE_NAME}"

#########
#
# Added: StackOverflow suggestion to also copy "include" files
#    (untested, but should work OK)
#
if [ -d "${CURRENTCONFIG_DEVICE_DIR}/usr/local/include" ]
then
mkdir -p "${CREATING_UNIVERSAL_DIR}/usr/local/include"
# * needs to be outside the double quotes?
cp "${CURRENTCONFIG_DEVICE_DIR}/usr/local/include/"* "${CREATING_UNIVERSAL_DIR}/usr/local/include"
fi
fi

Now that iOS 5 is out, I can talk about a better way to do it. Apple will now let you set the tintColor: property on the bar button item. That’s it. No more weird hacks with images or segmented controls.

There’s even a cool new appearance proxy that will let you change all controls from your app with a single line of code. (More about UIAppearance here)

So lets say you want every UIBarButtonItem in your application to be blue. That’s easy just call [UIBarButtonItem appearance] setTintColor:[UIColor blueColor]]

Remember, this is iOS 5 only. If you want your app to support iOS 4, you’ll have to do it the old way.

Clicking a link that says myTwitterApp://sendTweet?tweet=hello could send a tweet from your twitter app. It could also be used for configuring your app. Maybe you have an email app that needs some special server configurations. It could be set up so that you just have to visit a webpage on your server and click a link and have it automatically configure your email settings.

Facebook uses the URL scheme for authentication in their iPhone app. If I have an app that wants to authenticate with Facebook, it will try and talk to the Facebook app on the phone so I don’t have to authenticate again in my other app.

I think this is a pretty underused feature and I would bet there are TONS of clever things people can do with it. So how do you actually do it?

I’m going to show you how I’m adding it to the next versions of Thoughtback.

Your first step is adding a URL type to your app’s info.plist. You will add the same key if you’re making an iOS or Mac app. The raw key is CFBundleURLTypes.

Once the key is added links that start with thoughtback:// will launch the apps on both iOS and OS X.

Just launching from a URL is fine, but how do you get any information out of the URL that was clicked? That’s where the process differs between the two platforms.

iOS
Go into your applicationdelegate and override either of these two methods.

- (BOOL)application:(UIApplication *)application 
           handleOpenURL:(NSURL *)url

- (BOOL)application:(UIApplication *)application 
            openURL:(NSURL *)url 
  sourceApplication:(NSString*)sourceApplication 
         annotation:(id)annotation

I should mention that the first method is deprecated, but the second one is only available on iOS 4.2 or later.

Mac OS
This is slightly different on the mac, URL handling is not part of the NSApplicationDelegate protocol.

What you’ll need to do is tell the application to respond to an Apple Event.

-(void)applicationWillFinishLaunching:(NSNotification *)aNotification
{
    NSAppleEventManager *appleEventManager = [NSAppleEventManager sharedAppleEventManager];
    [appleEventManager setEventHandler:self
                           andSelector:@selector(handleGetURLEvent:withReplyEvent:)
                         forEventClass:kInternetEventClass andEventID:kAEGetURL];
}

- (void)handleGetURLEvent:(NSAppleEventDescriptor *)event withReplyEvent:(NSAppleEventDescriptor *)replyEvent
{
    NSURL *url = [NSURL URLWithString:[[event paramDescriptorForKeyword:keyDirectObject] stringValue]];
}

Parsing the URL
So now that you have the URL that launched your app, you’ll want to get the information out of the string. The most typical way to send information is with a query string. Here’s an example that Thoughtback will use.

thoughtback://send?thought=Interesting Thought&redirect=http://fredandrandall.com

We want to pull out a few different things from that. First we want to grab “send” because that’s the action thoughtback will take. Then we want to get the thought that will be sent and the url that Thoughtback will redirect to when it’s done sending the thought.

To parse out “send” we can use NSURL’s host method.

To get the query string, we can use NSURL’s query method.

Parsing the query string is a little more difficult but this block of code, that I found on StackOverflow, will put it into an NSDictionary for you.

NSString *query = [url query];
NSArray *queryPairs = [query componentsSeparatedByString:@"&"];
NSMutableDictionary *pairs = [NSMutableDictionary dictionary];
for (NSString *queryPair in queryPairs) {
  NSArray *bits = [queryPair componentsSeparatedByString:@"="];
  if ([bits count] != 2) { continue; }

  NSString *key = [[bits objectAtIndex:0] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
  NSString *value = [[bits objectAtIndex:1] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];

  [pairs setObject:value forKey:key];
}

At that first meeting, he told me that bd’s Mongolian Grill, one of their clients, wanted an iPhone app and they had no idea how to make one. That was where I came in. We talked a lot about the whole process of building an app and what was even possible to do with an iPhone. I was expecting something more like a job interview, but was surprised when it wasn’t. They told me that they were going to talk about what features they wanted to put in the app and get back to me.

A few days later, I came in again to talk about the features that they wanted to add and to see if what they wanted was realistic. At this point I wasn’t sure if I was going to be making the app or if they were evaluating me. I guess they had pretty much already decided I would be hired, since either at that meeting or in an email right after, they asked how much I would charge to build this app for them.

How much should I charge?

How much to charge is a really hard question. On one hand, I wanted them to hire me and was afraid that if I charged too much they’d try to find someone else. On the other hand, I’m a qualified, professional, software engineer and my time is worth real money. I was really hoping they were going to make me an offer so I wouldn’t have to come up with the number myself.

I did some googling and found some crazy numbers. People were saying anywhere from $10,000 – $50,000. I tried doing an estimate of how many hours it would take and then multiplying it by what I get payed at my day job. All these numbers seemed unreasonable to me. $10,000 dollars is a TON of money. Remember, this is NOT how I make my living so I don’t actually need the money, it’s all gravy. I ended up picking a number that would let me take a couple pretty awesome vacations, but still not be unreasonable for a smaller company to pay. I think I lowballed myself a little bit because obviously development takes longer than you think.

You’re worth more than you think!

If I had any advice for someone else in my situation, pick a number that seems just a little bit too high. Remember, you can’t get money you don’t ask for. Don’t worry if it’s something you haven’t done before. Odds are good that you can. One of the reasons I think I went low is because I wasn’t sure I could actually do what they wanted. Now that I actually finished it, that seems silly because I was able to do everything they wanted (and more).

How long is this going to take?

Of course, with the money estimate, they wanted a time estimate. This was another tough one. I had never done an iPhone app of this scale before. They wanted lots of stuff that I’ve never done before like Facebook sharing, Twitter sharing, and use of the iPhone’s Camera. So I went through each feature and figured out how long I thought it should take in hours. Then I added a little padding time because everything always takes longer than expected. Thankfully, my client understood that too and added some more padding of their own onto the deadline.

You suck at estimating!

Well, maybe you don’t, but I do and so do most other people I know. There are always a ton of factors you don’t think about when making that first estimate. In my case, I was thinking I would spend about 2 hours a day working on the app after I got home from work. What I wasn’t thinking about was my weeklong vacation to Florida and all of the time I wanted to spend having a life (hanging out with my girlfriend, playing video games, going to movies, etc.). So towards the end of the project, 2 hours a day turned into 3 or 4 and some weekends were even longer. I also wasn’t anticipating all of the changes that my client would want me to make. I had to completely change some functionality mid way through because they wanted something different. This brings me to my next point.

Working for a client is NOT like working for a company that sells software!

Where I work, we don’t have clients. We sell software to consumers. Our deadlines are self imposed and we have to come up with our own specs. When you work with a client, they set deadlines and they tell you what they want in the app. They get what they want, because they’re paying for it.

Will you do it again?

Hmmm, it’s hard to say. This has been a very positive experience. It’s a great way to pull in some extra spending cash and I learned a TON about iPhone development. The company I worked with was really great. We kept in constant communication the whole time and they gave me a lot of freedom in finishing out some small parts of the design that weren’t in their mockups.

Even though it was awesome, it was a lot of work. I don’t really need the money and as much as I like doing development on the side, it’s nice to be able to set something down when I want to.

I would recommend any developer with some spare time to try something like this at least once. I really learned a lot, not just about development, but about communication and working with others.

EDIT: There is a new way to do this in iOS 5 that is much easier and nicer. If you want to support iOS 4, keep reading.

A UIBarButtonItem is an item that goes on a UIToolbar or a UINavigationBar. It’s typically a button but it can be a bunch of different things. I’m going to talk about the button. A UIBarButtonItem button takes on the color of the bar that it is on. You can set the tint of a UIToolbar, but you can’t change the colors of the buttons on it.

I found lots of different solutions for this online, most involving adding a UIButton as the customView of the UIBarButtonItem and having some sort of image for the color you need. That works fine, until you need a color that you don’t have an image for.

I found a better solution here. Basically what they figured out was that a UISegmentedControl with a style of UISegmentedControlStyleBar looks just like a UIBarButtonItem. A key difference is that UISegmentedControl has a nice tintColor property that you can use to change the colors.

So what I did was take CharlyBr‘s code and put it into a UIBarButtonItem category.

+(UIBarButtonItem*)barButtonItemWithTint:(UIColor*)color andTitle:(NSString*)itemTitle andTarget:(id)theTarget andSelector:(SEL)selector
{
	UISegmentedControl *button = [[[UISegmentedControl alloc] initWithItems:[NSArray arrayWithObjects:itemTitle, nil]] autorelease];
	button.momentary = YES;
	button.segmentedControlStyle = UISegmentedControlStyleBar;
	button.tintColor = color;
	[button addTarget:theTarget action:selector forControlEvents:UIControlEventValueChanged];

	UIBarButtonItem *removeButton = [[[UIBarButtonItem alloc] initWithCustomView:button] autorelease];

	return removeButton;
}

You can check out my example project on GitHub.

To get started imgur has some good examples of how to upload in a variety of programming languages. I grabbed the iPhone example and copy and pasted it in thinking, “Well that was easy”. It turns out there was a little bit more to do.

Here is the iOS example from their website (with a few typos corrected)

-(NSData *)uploadPhoto:(UIImage *) image {
       NSData   *imageData  = UIImageJPEGRepresentation(image,1);
       NSString *imageB64   = [self escapeString:[imageData base64Encoding]];  //Custom implementations, no built in base64 or HTTP escaping for iPhone
       NSString *uploadCall = [NSStringstringWithFormat:@"key=%@ℑ=%@",imgurKey,imageB64];

       NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http://api.imgur.com/2/upload"]];
       [request setHTTPMethod:@"POST"];
       [request setValue:[NSString stringWithFormat:@"%d",[uploadCalllength]] forHTTPHeaderField:@"Content-length"];
       [request setHTTPBody:[uploadCall dataUsingEncoding:NSUTF8StringEncoding]];

       NSURLResponse *response;
       NSError *error = nil;

       NSData *XMLResponse= [NSURLConnection sendSynchronousRequest:requestreturningResponse:&response error:&error];

       return XMLResponse;
}

The problem with their example was that it wasn’t quite finished.
That Database64Encoding method is not a part of the iOS sdk. You need to do that yourself. So what does it mean exactly?

It means that you need to convert the image data to Base64. That basically means turning your image data into a string so it can be sent up via a POST request. So I did a little bit of Googling and found some code that converts NSData to a Base64 NSString. I got the code from the MGTwitterEngine, but it can be found in a few places.

So after that I thought I should be done. I ran the code and got an error back from imgur. Then I noticed the weird ℑ character in the request. I’m not sure what it’s for, but it didn’t work. I replaced it with “image” and I got a success back from imgur.

Hooray, everything seemed like it was working, but it still wasn’t. When I went to the URL in the response, there was no image. Nothing loaded. What was wrong?

I had a suspicion that there was some funny stuff going on with the encoding so I wrote the base64 encoded string out to a file (it was waaaay too long for NSLog to handle) to see what was actually in it. There were a bunch of /’s and +’s. These are valid URL characters that can definitely mess up query string parsing if you want them to be in one of your arguments.

I pulled out an NSString category I had written to escape valid URL characters and called my stringByEscapingValidURLCharacters method on the base64 string. After trying again I was getting valid stuff back and my image URLs were loading correctly.

So, to prevent others from going through the headaches to make a simple imgur uploader, I decided to open source some example code code.

This code is very simplistic. It is a simple iPhone app that lets you choose an image from the camera or your phone’s library and send it to imgur. The ImgurUploader class calls out to imgur and returns the URL of the original sized image by calling a delegate method. It doesn’t handle any errors right now either. You will also need to get an API key from imgur, which only takes a second. This comes with the “works on my machine” seal of approval.

Check it out on GitHub

If you saw my earlier post on how to use high res images in your app, you might expect the app icon to be the same. Unfortunately it isn’t, at least not exactly. At first, I just put in the high res icon. That seemed fine. Everything looked good and all was well. Until I submitted it to the app store. Upon submission, I got an error saying that I needed to provide an icon that was 57×57 pixels. That low resolution doesn’t look so great on the iPhone 4.

So I did what I did for my other images. I created a 57×57 icon file called appicon.png and a 114×114 icon file called appicon@2x.png thinking that it would automatically load the high res icon on the iPhone 4. This was not the case, it only loaded the low res version.

Here’s how I got it working.

There is another value in your info.plist for icons. It is CFBundleIconFiles. Apple added this because there were beginning to be a semi-ridiculous amount of icons for iPhone/iPad apps. There is the app icon and the search icon, but with the iPad and iPhone 4 you have 4 more icons you need to have since they’re all different resolutions.  It’s a problem that I think Apple could solve a little bit more elegantly.

So there you go, just put that into your apps info.plist instead of the default icon key and everything should be fine. Hopefully this will prevent you from having the minor headache it caused me.