Hipmunk for the iPhone - here's how we built it | Hacker News Reader

Hipmunk for the iPhone - here's how we built it

blog.hipmunk.com

173 pointskn0thing36 comments

It's refreshing to see this level of humility from a developer and a cool startup. No one knows everything, and realizing that is the first step to allowing yourself to learn.

Kudos on a sweet app! I'm looking forward to seeing what you guys build next!

Oh, and thanks for sharing! If everyone was more open about the tools they use, I think apps would be a lot better in general.

Really glad you enjoyed the post! More than ever, we're standing on the shoulders of giants. Glad to share whatever insight I can to make things easier on others.

Creating my first iPhone app for a company too as my graduation project, and have very much the same feeling: "when will the catch me". So far so good, but oh how I hate the tools. First time working with OS X and X Code, an some things just suck. For example, Android's location support is 200x better and has native support for loading a KML file as a route. I have to use someones custom class for iPhone, and can't test "significant movement notification" without an iPhone 4 on hand and actually walking a mile...

Apple want to keep their developers trim. This is a feature :)

"Even our iPad developers are 1/3 slimmer in the new version."

I completely agree. Nothing new ever comes if we just work within our comfort zones and don't continue to learn.

Kudos to Steve and Adam on hiring Danilo.

     From a UX perspective, I’m really pleased with how 
     the pinchable, stretchable, draggable time bars came
     out in the application. They feel really good to use.
     But from a development perspective, this is some of 
     the stupidest, craziest code I’ve ever written in my
     life. Don’t ask me how I did it because it did it
     entirely the wrong way. Maybe I'll share once I figure
     out the non-stupid approach.

But this is perhaps the most interesting part of the app that you should talk about. I'm okay with seeing the stupid implementation :)

I'm insecure enough sharing code I know works. Code I know is stupid is untenable for me. It comes from starting off as a newb and being led down the wrong path by people who'd blog without really knowing they were wrong. So I'd waste my time, or worse, internalize a bad design pattern because I didn't know any better.

Hard to be that guy.

> So I'd waste my time, or worse, internalize a bad design pattern because I didn't know any better.

Maybe. Or maybe someone would point out that you took a wrong path, you'd be embarrassed for a few minutes and learn the better design pattern way faster.

I say this, but it's not something I do. I'm working on it though.

I just booked a trip to Key West, FL recently. I used KAYAK and throughout the entire process, I was thinking, there must be a better way. What took me nearly two hours a few weeks ago, would have taken me mere minutes on this site. I will not forget this site.

I've never heard of Opacity before but this looks pretty awesome. Anyone else used it for iOS or Mac apps and can weigh in on how well it works?

You've already heard a bit of my endorsement, but I'll give you more in the hopes you'll try out the app. It comes with a trial period, so don't be squeamish.

The awesome:

- Fucking persistent corner rounding for rectangles. So you can adjust the size without screwing up your round rects' corners. WTF, Photoshop? How hard is this to do?

- edit: ALSO, easy Retina display support. No thought required

- Factories, as described in my post

- Badass pen tool for bezier shapes. Anchor points snap to guides in a very intuitive way, as do those fiddly little handles for curvy anchor points. It's much easier to create an arbitrary shape in Opacity than it is in PS or Illustrator.

- Much more flexible layer layer styling than Photoshop. Want two strokes on that vector? Fuck yeah, there you go.

- Variables. No shit. So, say you want the same button in five different colors. Set up a color variable, tie it to the button's fill property, then set up five factories with different color variables. Change the button's appearance, then the factory will dump out five brand new versions identical to your new changes

- Code generation: So maybe you suck at Quartz or want to use a GUI to create a starting point. Build your image in Opacity, then use the "Source Code" factory type. It'll spit out native drawing code using the drawing library of your choosing (Cocoa, Quartz, Core Animation). Variables work with this, too.

What needs improvement:

- Drawing performance is spotty, especially when dealing with bezier vectors. I see more pinwheels than I'm used to in Opacity, and that's on a late 2010 machine. This has been improving – I sent a sample file to the dev and he made some optimizations that helped a lot. Still, needs more work here.

- If you've built your existing UI assets in Photoshop, there's no easy way to get them into Opacity. You're probably going to end up recreating them, but since Opacity's tools are for the most part much better, this isn't terrible. Gives you a chance to spruce things up.

I think you've sold me. I can't wait to really sit down and dig into the demo tonight.

I had way more than $90 worth of headaches on my last iOS project keeping UI assets straight. I had no automated workflow; it was "do this in Photoshop then change the color manually for each one and then probably forget once or twice to export the correct resolution and tear my hair out wondering why it looks like crap."

I absolutely hated making minor iterations to the design, because I'd have to waste half an hour changing everything for a few pixels difference.

Thanks for the recommendation on this!

We use Opacity for everything, everything. It's fucking fantastic. I'm torn between telling everyone how great it is, and trying to keep it my secret to give me a competitive edge. Way worth it for the expensive version.

Integrate it with Xcode and treat your vector artwork as source -- when you build the project it will spit out all the little PNG files you need at all the different sizes. Your artists just tweak the opacity files, and when you build the PNGs get made. So awesome. We had to buy an extra copy for the CI server, but it was worth it to never again need to sit around and export png files.

Plus, if you need to draw something with Quartz, you can mock it up first in Opacity, and then have it generate the source code for your drawing, which you then integrate into your class. We quickly made classes that implement dynamically blurred drop shadows, customized numeric "badges" of any size, shape and color, and so on, just by drawing the effect we wanted, generating the source code, and combining the drawing code into a custom class. So awesome. Feels like cheating. (You have to work around Quartz's lack of Unicode support, but still.)

> Integrate it with Xcode and treat your vector artwork as source -- when you build the project it will spit out all the little PNG files you need at all the different sizes

Whoa, really? Badass. How do you set this up? Have a link?

Sorry, I didn't come back to this thread yesterday. The link is http://likethought.com/lockfocus/2008/05/compiling-opacity-i...

"Opacity includes opacityutil, a command line utility that can convert images between the formats supported by Opacity. You can use this functionality in Xcode to create a Build Rule that will dynamically convert .opacity images in your project to TIFF files (or any other supported format) at compile time."

>Plus, if you need to draw something with Quartz, you can mock it up first in Opacity, and then have it generate the source code for your drawing, which you then integrate into your class.

Wow, that's worth the price of admission alone. Writing drawing code by hand takes forever and is the worst kind of time sink: the almost-but-not-quite mindless kind.

I've used it for a few iOS projects. It's strength is making multi-state things like buttons and automating different resolution images (i.e. Retina). The factories feature combined with "variables" makes it a powerful vector editor. I'm not affiliated with the developer, I just think it's a great app.

Kudos to the Hipmunk team !! The fact that a talented young developer sought them out with his vision of a product for them as opposed to the safe/usual choices like facebook/Google etc. , speaks volumes for the excitement they have created around their venture.

Just wait until there are free candy dispensers all over the office ;)

Great link to Impostor Syndrome. Another thing I have that I didn't know I had.

> I have a confession: At first, I didn’t get Hipmunk. I mean, I understood the merits of the interface, I respected the user focus of the site, all of that was awesome and drew me to the iPhone project.

Danilo: How did you pitch them? Or did they pitch you?

You have mad design skills (Opacity does rock) for a coder. Dangerous!

Thanks for kind words. I actually started with Photoshop around age 13, and didn't learn to program until I was 20, so that helped round me out a little bit.

Short version: I wrote a post about Hipmunk that got Adam's attention, then didn't leave him alone until he gave me the gig. Here's the longer story, if you're curious:

http://blog.hipmunk.com/hipmunk-for-iphoneipod-touch

Binary plists over the wire? That's a hardcore innovation that I will file away in the back of my head for next time I'm building a backend for a mobile app.

All credit to Apple's WWDC 2010 session on building server driven applications. Great stuff in there, grab the video off of iTunes U if you've joined the developer program. Among other things, they break down the performance of various payload formats.

https://developer.apple.com/videos/wwdc/2010/

Most JSON frameworks are faster than binary plists on iOS. I learned it the hard way, after spending a day writing a Python module for the server side and doing some tests. However, binary plists were around 5% smaller, so they might help if your bottleneck is the bandwidth (it wasn't my case).

Edit: removed wrong link

Post-mortem means after death...not after the fact.

The project to build 1.0 is dead.

http://www.codinghorror.com/blog/2006/11/the-project-postmor...

Post natus?

Why do you tie my flight searches with my UDID and submit it to third parties like flurry?

> Why do you tie my flight searches with my UDID and submit it to third parties like flurry?

We collect the following data points via a single third party tool, namely Flurry. There aren't any others, aside from the obvious booking partners who book your flight at the end of the process.

- How long is the import process

- What tasks throw exceptions or otherwise crash the application

- Which cities are most chosen

- How far into the future do users most often search

- Do people bother with flights displayed lower on the screen

- Do people bother with the alternate booking mechanisms we made

This is useful to both confirm initial hunches on how the app's UX should work and helps direct modifications and enhancements in future versions. Flurry collects UDIDs for a promotional program they do for app discovery but Hipmunk doesn't participate in that.

Can you use their tool without submitting my UDID? If not, can I opt out (other than by not using the app)? I like your app, but that is essentially a tracking supercookie.

Actually if I am not mistaken, it is against the app store TOS to submit a UDID to a third party without the user's consent. Apps that use Flurry's agent in particular took heat from Apple for this. This is basically spyware.

http://www.tuaw.com/2010/06/02/flurry-agrees-to-stop-device-... http://forums.spybot.info/showthread.php?t=57992

Really, there is no reason to track activity by UDID for booking a flight.

I am not trying to troll here - I actually love your website. But I really hate spyware!

For your other uses, most reputable apps ask the user if they would like to participate in a customer feedback program, and inform them what will be collected, and allow them to opt out.

I believe PrivaCy supports Flurry, if nothing else works: http://cydia.saurik.com/package/com.saurik.privacy

We're not using AppCircle, so there should be no UDID shenanigans. I've asked Flurry to confirm this.