In Review

In Part I of Ditching NSLog, we introduced our good friend NSLog and why there is a time and a place for him, but that those are few and far between. We also discussed the different types of logging, and why you might want to use them, as well as how NSLog, in general, cannot satisfy these requirements.

In this post, we’ll go over some of the options you have available in your developer tool-belt to make your tasks easier to tackle. I always tell myself that good tools (or even the proper tool) make building things much easier. The same is true for building an app as it is for building my new bike I have sitting in pieces in the garage. Obtain and use the correct tools, and you’ll be more likely to produce a solid product.

Pre-Disclaimer: My original intent for the second part of this post was to actually use every library before writing about them. I found so many different libraries, that this never actually ended up happening. I present here a synopsis of each logging library on the basis that I have used some of them, but I have not used them all. Blame my day job and Battlefield 3. Yes, I am weak.

Logging Libraries

Simple Macro Replacement

While not really a “library” per se, this method is the most basic of all the options that will be listed here and will only get you part of the way to logging nerdvana.

Every iOS developer has used NSLog. We use it as a debugging tool to see the what data the system sees at a particular time while the application is running, or even to track the path our data takes when moving through our applications. But NSLog is not the be-all, end-all logging mechanism many of you think it is.

If you’re new to iOS, you may want to sit this one out until you get annoyed by NSLog - then come back here and read this.

I Use NSLog and I think it’s awesome. Isn’t that enough?

Umm… Let me count the ways. You may think of NSLog as your awesome friend with the boat who lets you join him on the weekends, but in reality he’s that guy on a Friday afternoon at the bank who’s exchanging three years worth of saved coins and asking about the interest rates on free checking accounts. I hate that guy.

There are more forces at work than you might think operating behind the scenes in order to get your log messages to both the console and into Xcode console log. Let’s go over some of the issues I have with NSLog:

Performance

NSLog is slow. This wouldn’t be so bad if it were asynchronous - but it is most definitely very synchronous. This is why you can set a breakpoint, step through your code and instantly see your NSLog statements show up in the console after you step over them. Make enough calls with NSLog in highly-iterative, performance-oriented or drawRect: code and the performance-penalty begins to add up. This is also not to say that we don’t sometimes need a synchronous logging mechanism. After all - if your code is in an unstable state, wouldn’t you want to know about both synchronously and immediately?

WWDC was a ton of fun. One of my coworkers equated it to drinking from a fire-hose all week, and that’s exactly what it was like - hardly any time to process any of what you’re taught all week. The sessions were really good, being surrounded by others who do what you do was inspiring, and the labs gave me access to Apple engineers to ask them whatever I wanted. I got some really good feedback on my iOS ad integration class, as well as some help integrating auto layout with some existing projects. There is a ton of material that is not mentioned in the videos (and sometimes even in the documentation) about how a class functions or was built. This is when access to the engineers that actually build the API is infinitely useful. I’ll definitely be more prepared next year.

For those wondering, the WWDC minty boost did in fact work to charge my devices (which was totally necessary every single day), but heated up the AA’s due to the current draw and re-melted the hot-glue that was protecting the PCB to the battery chassis. I only got one use out of it, but really didn’t need it any longer once you know to plug your phone in to charge at every opportunity.

It also humbles me as an engineer to be surrounded by so many people from all over the world who have gone on to do such publicly “great” things by comparison to what I feel like I’ve done. Most of the work I do can’t be shown to anyone else as my work, so I often find myself longing for a very public application or open source project to put my name on. Something I can say that I built or had a significant impact in building and it’s something that millions of others love and find useful. All good things come in time to those who work hard, so we’ll see where the next few years takes me. But for someone who really likes being openly proud of his work instead of just knowing intrinsically that I worked on something public, private white-label consulting is difficult for me - at least in that way. I’m not entirely sure how I would do in a single-project setting where the company I worked for was the product and I wasn’t able to bounce around multiple projects if I wanted to, but I’m sure I would manage just fine.

Of all of the lists I have read about what to bring with you to WWDC, or suggestions on what veterans say you should do, the most consistent and unanimously present suggestion from all sources is that you will need to extend the battery life of your mobile device. In the case of WWDC, there is a 99.99 (repeating, of course)% chance that it will be an iPhone. Being a procrastinator, I did not order one online like I should have from monoprice or similar. Being a cheap, stingy software engineer, I refused to pay between $60-$100 for similar Li-Ion battery packs that carry anywhere from 3000-6500mAh of power. Being an electrical engineer by schooling, you tend to have stuff like this lying around the house. Specifically, I had the minty boost powering an Arduino/Xbee assembly that is feeding temperature data from my HVAC exaust to Cosm. You can read all about that here. It ultimately didn’t work for this application due to it’s limited supply time (only lasted about 6 hours at a time).

This will enable me to use two rechargeable AA batteries at a time to at least get my iDevice back on it’s feet. I don’t intend for this to get me to a full charge, but it should suffice to get me to the next wall outlet.

Also, since Altoids does not make the Altoids gum that the Minty Boost was originally designed for, I had to improvise using some engineering magic:

This Eclipse mints container works perfectly for the Minty Boost, even if I did have to reverse the lid to get it to fit.

According to the battery rating, as well as the specs on the iPhone’s battery and Adafruit’s own website, I should be able to get about half a charge on two high-capacity NiMH AA batteries (the green Energizers shown above):

Input: 2 * 1.2V * 2450mAh * 80% = 4704 mWh

Output: 4704mWh/5V * 80% = 753 mAh

Charges: 1420 mAh iPhone 4 Capacity / 753 mAh = ~1/2 charge of iPhone 4 on two fresh AA rechargeable batteries

Good enough, I say.

Just put up a new page that will be home to the status of all house gadgets that can have a status. Some things I’d eventually like to have in it are things like NAS status, A/C temperatures, ambient temperatures, light levels, computer status, electrical power consumption, etc. For now, all you’re gonna get is a rant about how hot my apartment is.

Edit: We’ve moved - so I’ve dismantled the arduino temperature monitors and taken down the page.