iOS

My CocoaPods Catalog

Posted on by lennypham

I can tell you the license plate number on my mom’s car in 1988, but if you asked me which CocoaPods I used on my last project, I couldn’t tell you. Fortunately, through the magic of source control, I can go back in time and look through all the open source libraries I’ve used in the past. Of course, that’s kind of a huge pain in the ass to have to go back through all those projects. To that end, I’ve decided to start making my life a little bit simpler by cataloging all of the open source projects that I’ve used (plus a few that I haven’t) and made them publicly accessible via my github repo. FYI, it’s still a work in progress. OH and you’re welcome 🙂

https://github.com/lennypham/LKPCocoaPodCatalog

Apple CarPlay: What problem does it solve?

Posted on by lennypham

Featured Image -- 266

After a year of no news, Apple as re-announced it’s in-car iOS integration system CarPlay

I have to be honest, as a full on diehard raging Apple fanboy, the availability of such features will greatly influence my next car buying decision. However…

In what seems like a huge marketing oversight, neither Apple nor any of the car manufacturers have mentioned any of the primary use case(s) of what iOS integration could potentially offer:

    1. Real-time push notifications for traffic alerts
    2. Real-time alerts for family members. The car sends an alert to your loved ones letting them know that you’re on your way and how long ’til you get there
    3. iOS integration with on-board sensors (Low gas, low tire-pressure, check engine, etc.)

Maps, Messages, and Music? I can already do that…except for the texting part of course. I’ve NEVER texted while driving *looks down and to the left*

All CarPlay is doing (so far) is to give me an easier way to access that information through the car’s dashboard. That’s really cool and all, but it doesn’t address any problems in the context of my everyday driving experience. Here’s hoping there’s more to come.

iOS7 vs KitKat Adoption

Posted on by lennypham

Full Disclaimer: Still an Apple Fanboy

That said as a developer of mobile and tablet apps, I live in both worlds so the adoption rate of new operating systems is of key interest for me.

According to mixpanel, as of this morning ~80% of iOS users are now running iOS7 (chart).

In comparison only 1% of android users are running KitKat. To be fair iOS7 was released more than a month before KitKat but the numbers are nonetheless staggering.

Happy Coding!

“I don’t like documenting my code. If it was hard to write it should be hard to read”
– Anonymous

Is the iOS7 NDA lifted yet? How ’bout now?

Posted on by lennypham

Happy belated iOS7 day to all the devs out there. Not that the rest of the interwebs paid any attention to the Apple Dev NDA, but now that I’m legally allowed to talk about all things iOS7 related, here’s a code nugget for anyone using modal view controllers with a stand-alone UINavigationBar

If you’re following the new iOS7 design paradigm, you’ll want your nav bar to seamlessly extend to the top edge and blend in beneath the status bar. If you’re using a navigation controller this is automatically done for you. However, if you’re building your own custom modal view controller AND add a standalone UINavigationBar to your storyboard, this is what you’ll get:

BEFORE

You can see that the nav bar sticks out like a sore thumb. So to fix this, here’s what you’ll need to do:

1. Make sure (in your storyboard scene) that your UINavigationBar is set to ‘Translucent’

Screen Shot 2013-09-19 at 12.41.25 PM

2. Set the delegate property of your UINavigationBar to your View Controller (or some class that implements the UINavigationBarDelegate protocol).

3. In your delegate class (e.g. your View Controller) implement the following code:

- (UIBarPosition)positionForBar:(id )bar
{
return UIBarPositionTopAttached;
}

And now you should see something like this:

AFTER

Hope this helps!

“Delete all your comments. If it was hard to write it should be hard to read”
-anonymous

The best IDE ever written

Posted on by lennypham

I’ve been turning caffeine into code for a long time and for my money the new Xcode 5 (still in beta) is the most delightful IDE I’ve ever used.

I remember back in the 20th century when I wrote code using just a plain ‘ol text editor. Those were the days. Cars had tape decks and the sun shone everyday. But re-compiling your app meant taking a fifteen minute smoke break, and god help you if you had one jar dependency missing in your ant scripts.

I know right?

Over the years there have been a few improvements, Emacs, ultra-edit, Eclipse, Visual Studio, etc. but by and large the advances have been few and far between. Up until recently, every platform has required developers to work really hard in order to accomplish really simple things. Lots of boilerplate code just to get a “hello world” app working. I mean, have you ever tried to putting together a RESTful web-service using Microsoft’s WCF? You might as well try to come up with a unified theory of physics while you’re at it.

Since it’s still in beta (and under NDA), I won’t get too much into the new features of Xcode 5, but I will say this:

Your tools should work for you and not the other way around.

For the first time in the history of computing I’m really excited about my IDE. Here’s what you can look forward to with Xcode 5:

  • It’s freaking FAST!
  • The debugging tools are immensely improved
  • They FIXED auto-layout. Trust me. No more surprises. You don’t have to pull all your hair out. It just works…the way you need it to.
  • Did I mention how FAST it is?
  • Improved git integration (if you’re not on git, switch…now)
  • New and improved testing framework
  • Support for Doxygen style comments

And I haven’t even gotten to the good stuff yet. Of course there is still one outstanding bug with the Apple LLVM compiler. It still only does what I tell it to do and not what I meant for it to do. Hopefully they’ll fix that in Xcode 6.

Buttons are a hack (revisited)

Posted on by lennypham

The recent hype surrounding the re-design of iOS has gotten me thinking a lot about the current state of UI/UX/HIC (give it a name) and its direction in the future.

For starters, let me quickly remind all the trolls out there that when Mac OS X was released, many (if not most) of the designers hated it. The iPad, when it was initially released, was resolutely bashed by most as “an oversized iPod”. Time and and ultimately, the market, will determine whether iOS7 was a success. Let’s just leave it at that.

Back To The Future

Looking at the progression from iOS6 to iOS7 I can’t help but think back to a great presentation given by Josh Clark two years ago:

Buttons are a Hack: The New Rules of Designing for Touch

It’s a fairly lengthy presentation but the two key points that stuck out in my mind were:

Touch interactions will help us sweep away buttons and a lot of existing interface chrome by moving us closer to the content and away from GUI abstractions.

User interfaces are an illusion. But with touch interfaces we can cut through the illusion and let people interact directly with content.

If you agree with these points, and Clark’s motif in general, then you would have to agree that iOS7 is a step forward and not a step backwards. There are certainly a number of things that could have been done better, but in my opinion I think Jonny Ive is moving us in the right direction.

Please don’t misunderstand me, there are problems with the new design of iOS. For example, the new concept of a “borderless” button and using color to indicate action is somewhat ambiguous – in my opinion. In a world where buttons have no borders, the cognitive load is increased by virtue of the fact that a user cannot reasonably determine all the touch targets on a screen simply by looking at them. For example

Take this QUIZ

If you had to think about your answer, there’s already a problem. So there are issues, but isn’t that the gap designers and developers are supposed to fill for our end users? Cheers!