Tag Archive for iPhone

Going Mobile: Overcast

icon_340This is the second entry into Going Mobile, my series of reviews on mobile software. Frequent readers of this blog will notice that this series used to only focus on productivity software but is now expanding to the wider app ecosystem. I’m still taking a special focus on apps that actually allow you to “get things done” or provide a certain level of productive value.

This week I’m really excited to be taking a quick look at a brand new app by the nerd-famous Marco ArmentOvercast. Overcast is basically a high-end iOS only podcast client. As a podcaster myself, please check out Coder Radio if you are into development, I get really excited when a top-tier developer like Arment puts something out in the space.

The Good: Overcast is fast. I mean lightening fast. I’ve been using it since day one and have yet to find any noticeable lag or stuttering with any of the animations in the app. To be fair, some of this is due to the app’s arguably spartan design; in fact, other than the app’s logo, it uses all standard iOS controls, something that works surprisingly well and is refreshing when compared to some of the overly “designed” apps we’ve seen over the past few years.

Though I am not a huge fan of playing podcasts at higher than 1X speed, it’s good that Overcast offers the ability to finely control how fast you are playing back the audio. Like all of the app’s features, this is elegantly tucked away and is in now way intrusive.

The Bad: Overcast is free to download and use to a point and Arment has been pretty generous in what features he allows you to access before paying the $4.99 upgrade price; in fact, you can use some of the premium features for free with limits without paying – it is a little shocking that Apple allowed this, given their relatively hard position on trials of any kind. However, Arment’s generosity doesn’t make up for the fact that “smart speed”, the apps signature feature, is just not very impressive and I’ve found to not work pretty very well for the majority of podcasts in my somewhat extensive library.

The Ugly: It is a little disheartening that someone like Arment who has a following and could release even the simplest of apps and still get some immediate and great press felt that even he had to go with a freemium model to make a decent profit on the app. Arment’s done freemium in the “cleanest” way I’ve seen so yet but it still feels a bit unfortunate that it had to be done.

Conclusion: If you subscribe to more than three podcasts and use an iPhone, then you should give Overcast a shot.

Crisis Coding: Stop The High-Res Madness

As someone who lives less than five miles from the Atlantic ocean in NJ, I’ve been having a bit of a bad time recently due to  Hurricane Sandy. Luckily, I was not harmed nor were any of my loved ones in the crisis. I did, however, notice something important: even  my non-techie friends and relatives were glued to their smart phones, hoping to hear some news about the storm, find out when their vital services (power / gas) might be restored, or (most importantly) check on their loved ones.

There are plenty of mobile apps that can be very helpful for handling a crisis, however, this recent crisis has shown me that there is something rotten in the state of app development — especially on the iOS side.

Let’s frame the scene a bit. During Sandy battery power was worth more than gold-plated platinum; for those of you unfamiliar with mobile development one of the most battery intense things most apps do is download data — especially image data. Up until today, I was out of power and the only access my fiance and I had to the outside world was out smartphones. Between us we have an iPhone 4S, a Galaxy Nexus, and a Lumia 900. We used all three phones to find pertinent data regarding the crisis.

I noticed some trends for roughly equivalent apps on each platform. The Windows Phone apps tended to load the fastest with the Android apps loading about as fast — I had no tools to do any real benchmarking, so these observations are all anecdotal. Sadly, my iPhone did not perform so well. I wondered why for a few minutes. After all, they were all on  3G  (the LTE Nexus had LTE turned off to conserve power) and the Lumia which was on AT&T should have been at a distinct disadvantage since Sandy had already claimed one of the local AT&T towers.

The difference was not with the network or OS’s or devices. It was about priorities in the apps themselves. While the Android and Windows Phone apps focussed on providing pertinent data in simple text based lists, the iOS apps were constantly trying to download images alongside the data. These images took a long time to load and therefore used an unnecessary amount of battery power. Worse still, after I regained my power earlier today, I reopened the iOS apps in question and they committed what is in my mind a mortal sin of mobile development: they all tried to download ‘retina’ resolution images over 3G.

Ridiculous. I understand that high-res images can make an app look good, but there is no need to download them over the air. Still, if you insist on downloading images that large, then please only do so over wifi. This is especially true if you app is geared toward helping people in a crisis.

Simply Loading TableViewCells from a Nib

UITableViews drive a significant portion of iOS apps. Apple has provided some pretty great tools for developing decent looking apps based on them, but there are times when you might want to do something a little more stylish than what iOS provides. That’s when you probably consider writing your own UITableViewCell subclass or at least adding a category to UITableViewCell, though I find that is probably the less appropriate option in most cases. Getting your cells to look just right can be more than a little time consuming. Luckily, there is a bit of a shortcut you can take: loading the cells from a nib.

Before I show you how to do this, you should know going in that there are some drawbacks to doing this and that this is not an appropriate solution a some cases. Loading cells from a nib is less performant than just drawing the entire thing in code. Generally, you would not want to do something like this in a resource intensive app, such  as a game for example.  Ok, now that we have gotten that disclaimer out of the way, let’s get back to the point:

- (id)initWithStyle:(UITableViewCellStyle)style reuseIdentifier:(NSString *)reuseIdentifier
{
   self = [super initWithStyle:style reuseIdentifier:reuseIdentifier];
   if (self) {
       NSArray* nibContents = [[NSBundle mainBundle] loadNibNamed:@"SpecialCell" owner:self options:NULL];
       NSEnumerator* nibEnumerator = [nibContents objectEnumerator];
       NSObject* nibObject = nil;
       while ((nibObject = [nibEnumerator nextObject]) != nil) {
           if ([nibObject isKindOfClass:[SpecialCell class]]) {
               self = (SpecialCell *)nibObject;
               break;
           }
       }
   }
   return self;
}

The above code presupposes that SpecialCell is a subclass of UITableViewCell; I omitted the header for the sake of brevity. So, let’s get the obvious stuff out of the way. This method is overwriting initWithStyle and yes you could write a second method rather than overwriting that one. We have the normal if (self) check that we see in inits. All pretty much standard.

Ok, so what is actually loading the nib? Well, if you look nib is being loaded and its contents are being placed in the nibContents array. Once the the contents of the nib are all in the array, an enumerator is created based on it. After that we simply loop through all of the objects, assign self the the one whose class is SpecialCell and return it.
Pretty easy, right? Just keep in mind that this can be a source of slow down on your table and may not be an appropriate solution for your app, but this can be a good time saver for prototypes or non resource intensive apps. If you have any feedback I can found Twitter or Google+.

All About ARC

ARC (short for automatic reference counting) is one of the most talked about and interesting additions to the iOS developer toolchain. However, in recent conversations with other developers I’ve found that there are a lot of misconceptions surrounding the technology. Hopefully, this clears up some of the confusion.

The first mistake that people often make when talking about ARC is that they equate it to garbage collection in languages such as C# and Java. This is simply incorrect. Boiling it down to its most basic explanation, a garbage collector runs in your application and checks to see what objects are no longer needed and removes them. This means that garbage collectors are very convenient for developers, but they take a small (depending on the implementation) amount of resources themselves. ARC is a special setting that can be set from within XCode that tells the compiler to insert release statements for you. So, this means that when you have ARC enabled the compiler is following the same retain / release rules you would normally follow for your own memory management, but this only happens at compile time, so there is no performance hit and you never see that statements themselves. This is useful because the compiler is far less likely to make a mistake than the average developer, especially in tricky situations, such as those that arise with multiple autorelease pools.

The second common belief developers hold surrounding ARC is that all their projects should use it. For new projects, this makes sense as long as you don’t mind targeting iOS 4.3+. However, converting legacy projects to use ARC can be a little hairy and like all magic that is made for developer convenience, when ARC causes a problem, it tends to be a tough one. Of course, that is not always the case and you mileage will certainly vary, but this is something to consider before hitting that shiny convert button.

Lastly, a number of developers that I have spoken to are under the mistaken impressions that all libs or external projects that you project is taking advantage of must be compatible with ARC for your codebase to use ARC. This is not the case. You can toggle ARC on and off for individual projects within your project (I know that sounds weird to me too) and safely use your legacy C libs or non-ARC Objective-C frameworks.

Overall, ARC is a great addition to the iOS developer’s toolbox, but it is like any other new technology and should be understood for what it is and adopted when appropriate.