I thought it would be neat if I could take a note and put it on the home screen as a separate app icon. I’ve done some work with home screen bookmarks before and thought I might be able to get it done with a simple web app.

The result is Notemark.io. Notemark lets you type out a note and saves it using HTML5 localStorage APIs. Not only does it use localStorage, but it also uses app caching. This allows Notemark to run even without an Internet connection.

So, in typical Afternoon App fashion, I hacked something together that’s somewhere between a proof of concept and an actual working product. Use it all you can, but just be aware that there are probably some bugs. If you notice something wrong, feel free to open an issue on Github or send me a message, but just be warned that I might not get around to fixing the problem.

I’m not a web developer by trade so the code is messy with plenty of inefficiencies. You can critique my code all you want though!

The hardest part of a Boggle app is knowing what words are valid. You need to take a grid of 16 letters and evaluate the thousands of possible combinations against a dictionary of over 200,000 words. Luckily, that was already done.

I didn’t want this to be quite as simple as Descrumbled. I wanted to make it actually worth playing. To do this I added Game Center achievements and a social challenge option.

Basically, there are achievements designed to get you to play the game more. The achievements require you to do things like play 100 games and get certain high scores. There is also a leader board that people can use to see how they stack up against the rest of the world.

Achievements and leader boards are great, but I wanted to add a little bit of a multiplayer aspect to the game. So I added a feature so you can send someone a game board as a challenge. When they click the link in a text, tweet, or email it will open up that game board and let you play it.

The only other sort of interesting thing I did was with advertising. Instead of relying only on iAds, I put in an ad of my own, for Descrumbled. Sometimes iAds fail to load. When that happens, I show a button with an ad for Descrumbled asking the user if their puzzles are too hard. It’s not super exciting, but it might drive a few more people to download one of my apps and it looks better than a blank space where the ad didn’t load.

This app didn’t take a single afternoon. I think I spent probably 3 afternoons on it. When I had it mostly working, I decided to add the social challenge feature and had to change the way the app was architected. That took a little bit more time than I wanted it to.

Be sure to check it out and let me know what you think.

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!

HappyCampfire is an objective-c wrapper around most of the Campfire API. It has model objects like users, messages, and rooms. It should allow anyone familiar with Cocoa programming to get right to work on using the Campfire API. It is designed to work on both OS X and iOS but most of the work/testing has been on OS X.

I wanted to put this out there to help people make good innovative uses of Campfire, without having to deal with too many of the nitty gritty details. It’s definitely still a bit of a work in progress so feel free to fork it and send me a pull request if want to fix/add anything.

The framework is designed to be asynchronous and uses ASIHTTPRequest for the network communication. It also allows you to make use of Campfire’s streaming API to get message updates. The project includes a test app for OS X that will let you test all of the different parts of the framework.

To get started you’ll create an object like this

campfire = [[HappyCampfire alloc] initWithCampfireURL:@"https://YOUR_CAMPFIRE_URL.campfirenow.com"];
campfire.authToken = @"YOUR_AUTH_TOKEN";

[campfire sendText:@"Hello World" toRoom:@"ROOM_NUM" completionHandler:^(HCMessage *message, NSError *error){

   NSLog(@"%@", message);

}];

If you’re interested in using the streaming API that’s really easy too.

campfire.delegate = self;
[campfire startListeningForMessagesInRoom:@"ROOM_NUMBER"];

// Then you'll implement the CampfireResponseProtocol
-(void)messageReceived:(HCMessage *)message
{
   NSLog(@"Message: %@", message);
}

Check it out on GitHub

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.

They compared it to what Android did to iOS. Some other big provider who would have done the same thing will step in and capitalize on the people’s indignation just like Android capitalized on people’s disappointment over Apple’s closed model.

Sure, lots of people hate Apple’s closed model. It’s bad for geeks. We can’t tinker with things like we can on our desktop computers. You know who doesn’t hate it? Everyone else. Apple’s model is perfect for the general consumer. They make it easy to install apps. They make it easy to put music on the phone. They basically make using an iPhone fun and easy. People don’t care about “open”. They care about shiny.

The smartphone wars are not about operating systems. They’re about phones. Of course Android is going to have a bigger market share. There are over 100 Android devices you can buy. There are 6 iOS devices. The fact that iOS is even in the running shows how good of a job Apple has done with it.

Regular people don’t look at specs. They don’t think or know about how much money Apple takes from developers. They don’t realize there is a review process where Apple can arbitrarily block apps from being in the App Store. What they know is that their iPhone can play Angry Birds and that whatever they want to do “there’s an app for that.” My sister-in-law recently got an EVO 4G, but after about a week, she took it back and went to Verizon and got an iPhone. You know why she switched? Because she couldn’t get service with Sprint in her house. That’s why regular people buy phones. It doesn’t have anything to do with tethering or openness. I asked her which phone she liked better, she told me the iPhone because it was easier to use and she loved playing with Instagram.

I think what people reading Engadget often forget is that we are not regular people. I know my worldview is warped because the things I read and the people I hang out with are not normal. I live in a bubble where everyone is tech savvy (I’m a software engineer) and keeps up with the latest and greatest gizmos and gadgets. The rest of the world doesn’t care about the same stuff we do and that’s fine.

Android is not going to beat iOS in the consumer world anytime soon. The cultures of the two companies are too different. Google is a hardcore engineering company. They want to solve the most interesting problems and build the most powerful products. Apple, while certainly not lacking in the engineering department, has a culture of design first. They attack problems differently and solve them in a way that is best for the consumer. With that said, I think Google is doing something great with Android. They’re bringing smartphones to everyone. Apple is never going to target the guy that is only going to buy a 15 dollar pay as you go phone. Just like BMW isn’t trying to sell to Joe Schmoe that lives in Detroit and works on an assembly line.

On the iPhone, one way to create UIImages is like this:

[UIImage imageNamed:@"compassGreen.png"];

It’s very simple and easy. Now how do you take advantage of the retina display?

Just make your image twice as big as the control.

Thats it? Yes, that is it, sort of. What if your designer doesn’t trust the cocoa touch scaling algorithm? How do you load a different icon for the older iPhones?

if( has retina display )
{
   [UIImage imageNamed:@"hiResImage.png"];
}
else
{
   [UIImage imageNamed:@"regularResImage.png"];
}

NO! Don’t do that. You could do it that way if you really wanted, but then every time you wanted to use an image you’d have to type that if statement. Also, what would you do for images in Interface Builder?

Luckily, Apple knows what they’re doing and added a URL naming scheme to solve this problem. Name your regular resolution image image.png and then your high resolution image will be image@2x.png. Then all of your calls will use the regular image name. So you just say [UIImage imageNamed:@”image.png”] and then it will automatically load the correct image based on your device.

It wasn’t all puppies and rainbows. I had a hard time getting some of my images to load correctly. I couldn’t figure it out. They looked great in Interface Builder but they wouldn’t load on my phone. It was just the hi-res versions too. It turned out that when I was saving them in Photoshop I didn’t change the image format. I just changed the file extension. This meant that even though the files looked like PNGs to me, they were actually PSDs. For some reason, they work just fine in Interface Builder, even though they aren’t PNGs.