Clinging To Ideas

Treadmill Desk Review

2012-01-20T12:08:00.001-05:00

I have a few days of walking under my belt now, so it's probably a good time to do a preliminary review of my LifeSpan TR1200-DT Treadmill Desk

Unboxing & Assembly

The set arrived in 2 large boxes, 1 for the treadmill base, and one with the desk parts. I knew that the desk needed to be put together first, and I have limited space available, so I started with the desk box. I carefully pulled out and set aside the legs, the cross beams, the desktop, and grabbed a bag of miscellaneous hardware. Manufacturer Mistake #1: this bag contained a handy little note informing me that assembly instructions could be found... in the other box. Diabolical bastards. There is absolutely no reason to put the instructions in the other box. The treadmill doesn't really need instructions; the desk does. So I throw all of the packing materials into the box and carry it out to the garbage to clear room for the treadmill box, just so that I can get to the instruction manual.

The desk is not hard to put together. The cross beams attach to the legs with a few screws. The desktop then attaches to the legs with a couple of bolts… wait a minute, where are the bolts? My hardware baggie is empty. I *gasp* refer to the manual. Sure enough, there is a list of parts, with a specific note indicating these items can be found in the hardware bag. 4 bolts, 4 nuts, nowhere to be found. I can only assume they were still in the original box, perhaps taped to a piece of styrofoam and I simply overlooked them. So I head down to the garbage, and carefully remove and inspect every item in there. Styrofoam, cardboard, plastic wrap, tape. No bolts. I begin to wonder if they slipped another baggie into the treadmill box. Back to the den, and inspect the contents as best as I can without actually removing the treadmill since I don't really have room to get it out of the box yet. No bolts. Curse words. Lightning bolts. The instruction manual provides the specs of those bolts, so I'm moments away from visiting my nearest hardware store, when out of sheer dumb luck I happen to notice something I had missed before. The bolts were already installed on the legs. I had to remove them in order to attach the desktop, then reinstall them. Manufacturer Mistake #2: If the manual says the parts are in the bag, put them in the damn bag.

For some reason they want the legs at full height in order to attach the desktop. Not sure why that made a difference, but it did increase the degree of difficulty a bit. It would have been handy to have the help of a second person, but I was alone at the time, so I did what I could. It's not the heaviest thing in the world, but it's not light either, and it was awkward to maneuver into position. As I reattached *grumble* the bolts, I tried to judge the stability of the surface. The legs by themselves provide a good, solid base. There is only the slightest play side-to-side, and virtually none front-to-back. As I attached the desktop, I noticed a not-insignificant amount of play front-to-back. There is simply too much play between the bolts and the holes in the desktop. I wouldn't call it unstable, but neither is it rock solid. My computer equipment sits towards the back, so most of the time it leans slightly backwards. When I lean on it to start typing, it rocks slightly forward. There are a couple of gaps at the connection, and I intend to shove some shims in there which should address the problem, but it's disappointing that I need to.

After constructing the desk, all that remains is to slide the treadmill into position and connect a couple of cables. There is no hard connection between the treadmill and the desk, so this theoretically helps to isolate any treadmill vibration from the desk. I don't have anything to compare to, but it seems to work just fine.

Treadmill Features

The control panel is located at the front of the desk. I would like it more if it was off to one side, but I can't say that it has really interfered with anything I've tried to do. It has your basic start/stop/mode/speed up/speed down buttons. The display offers elapsed time, a step counter, a calorie counter, distance, and speed.

When the unit is first powered on, it wants you to enter your weight. This is no problem in and of itself, but it starts at the low end of the scale, and, well, I'm heavy. It takes a while to get it up to the correct weight, even if I hold the button down. All that does is require less beeping, it doesn't really go that much faster. What's worse is that there is seemingly no memory. I power the treadmill down at night, so each morning I turn it back on and have to re-enter my weight again. Yes, these are 1st-world problems, but it's annoying nonetheless.

When you hit the Start button to begin walking, there is a 3,2,1 countdown, and then the treadmill slooooooowly begins to move. There are 2 factors at play here. One, there is a slow spool-up, probably in the interest of safety. That's fine, but I'd like a faster curve. It…….. is…….. quite……… distracting……….. to………. walk……… so………. slowly………. But it does eventually get up to speed. The other factor is that every time you start walking, the speed has been reset to the slowest speed of 0.5. So your first steps of the day will be at 0.5. Later, you've been trucking along at 1.3 and need to take a quick break? When you come back: 0.5. I can understand not keeping the speed value through a shut down, but just after a pause? Irritating.

Oh, and stopping the treadmill is the total opposite of starting it. When you hit the stop button, it stops NOW. There is no gentle wind-down, boom, the motor is off, you're done. So you really need to step onto the side rails before telling it to stop. I actually would like a longer wind-down period here.

I haven't watched the step counter over lengthy periods of time, but when I watch it for a few steps at a time, it seems accurate enough. It's a nice feature that I didn't see mentioned on too many other treadmills. I can't really comment on the accuracy of the distance measurement, but it is at least internally consistent. If I walk for an hour at 1.1, then by golly the distance will be 1.1. The calorie counter seems really high to me. So far it says I'm averaging around 250 cals/hr, and my average speed is around 1.2. My earlier readings on desk walking lead me to expect around 125 cals/hr, so either those numbers are off, or these numbers are off. Or maybe I just burn more calories due to my size. As far as weight loss expectations, I'm mentally keeping the lower number in mind. If I start dropping pounds in a big way, then I might be inclined to believe the higher numbers more.

This may have come off a little more negative than I intended. The controls are user-friendly, and the treadmill does what it is supposed to do just fine. There are 2 instances where, if it simply stored a value, the annoyance factor would be reduced tremendously.

The treadmill is reasonably quiet during operation. I've had no complaints from the apartment neighbors or the wife. I tend to wear headphones anyway, so I really don't hear it at all. Even without the headphones, there is not much noise; certainly not enough to be a distraction. The sound of me walking is more than the treadmill itself makes.

LIfeSpan advertises a large walking surface, and they aren't kidding. I haven't accidentally kicked the side rails while walking. More than enough room front-to-back, too. They could easily chop a foot of length off, maybe two. That said, if you consider the space required by my desk chair, the overall footprint of this treadmill isn't much longer than what I used before.

Desk Features

The desk surface could use another 6 inches of width of so. Right now I have a monitor, a docking station for my laptop, iPad stand, iPhone stand, keyboard and mouse, and a large cup of water. The back corner of the laptop dock is hanging off the edge by a couple of inches. I could shift everything over a bit, but then my primary monitor wouldn't be centered. Eventually I would like to purchase a Mac mini and a second monitor, at which point it would probably be a good idea to get one of those swing arms that holds the monitors up in the air. Doing that would alleviate any space issues I currently have, but alas it's not in the budget for a while.

The front edge of the desk has a firm cushion. I had seen a user review video of a woman using this desk, and she was actually leaning on it putting her forearms on this cushion. To me that seemed like the desk was too high. I was expecting to basically hold my arms in the air all day over the keyboard. I also had an issue last year sitting at tables that were hitting lower on my arm closer to my elbow. This resulted in tingling in my fingers, and I'd rather not go through that again. But then when I was getting the desk height adjusted, I found that it actually was pretty comfortable to rest my arms on these cushions. It's not like I'm typing at chin level or anything, but the desk surface is maybe 2 or 3 inches higher than my elbows. The height of the cushion actually matches pretty well with my keyboard. If I start noticing tingling in my fingers again, then I will drop the height pretty quickly, but so far so good.

The desk has a cable pass-thru hole towards the back, but I'm not sure it's really worth it. There is a tray under the desk that I guess is supposed to be some kind of cable organizer, but for me it was mostly just in the way. I dropped a plug through expecting it to hit the floor, when instead it clanked on this tray. So I had to feel around for the plug and fish it out to get it where it needed to go. I don't know if the intention is to put the power strip there, but mine wouldn't fit anyway. Either way, the cables are long enough that the ones that don't need to go very far hang off the back and loop back up. From an organization and appearance standpoint, it's not really doing much.

Cable lengths are a problem with a desktop this high. You basically need about 2 more feet that the manufacturers didn't plan for. I guess if LifeSpan was going to do anything for cable management, what might have been more useful is some kind of tray or something on the back of the highest cross beam for the legs. This would be a decent spot to place a power strip, and would have most likely eliminated any cable length issues. In the absence of that, the smaller desk here actually provided an opportunity. It is over a foot narrower than my regular desk, and the width at the feet is even narrower still. This left plenty of room for me to slide in one of my IKEA EXPEDIT shelves. I have it laying on its side, so it is 2 cubes high. I moved the power strip onto one of the shelves, which allowed all of the power cords to reach just fine. It's also where I relocated my network drives, as I was a little leery about putting them on the desk. My laptop has an SSD, so I'm not too terribly worried about movement there, but the NAS's have regular hard drives, so I'd rather have them on an absolutely-not-moving surface.

Overall

I do have a few minor complaints, but taken as a whole, there is nothing that I regret about this purchase so far. Everything seems well made for the price. I can't yet speak to the long-term durability of either the treadmill or the desk, but I haven't seen any red flags that give me cause for concern.

As I write this, the purchase price is still $1299 with free shipping. This is noted as a sale price, with a list price of $1999. I have no idea how long the sale price will last, or what the regular price will be, but if they can keep it under $1500, then I suspect they will sell a lot of these to those of us without corporate budgets to dip into. The warranty is listed as lifetime for the frame, 3 years for motor and parts, and 1 year labor. One thing to note is that they claim a limit of 3 hours/day (manual actually says 4) of usage, though it isn't clear if this applies only to commercial usage. Either way, this seems to be a ridiculous limitation. I'm only supposed to walk at my desk for 3 or 4 hours a day? What am I doing for the rest of the day? The welcome letter at the front of the manual says that people sit for 11 hours a day. In my opinion, if there is going to be a daily usage limit, it should be no less than 8 hours. I guess we'll find out how much an issue that might be if I ever need warranty service.

Overall, I'm satisfied with the purchase, and would happily recommend it to anyone thinking about a treadmill desk purchase.

Treadmill Desk

2012-01-15T17:22:00.001-05:00

The treadmill desk I bought was this one:

LifeSpan TR1200-DT Treadmill Desk

But before talking specifically about why, I'd like to talk about some of the other options available and why I didn't get them. I'm going to list them by the key reason I didn't choose a particular desk, though multiple reasons often applied.

Too Expensive

Pretty much every ready-made solution out there could fall into this category, even the LifeSpan. But there are some that are absolutely egregious.

Steelcase has 2 different models, depending on what you want. The Walkstation is strictly for standing/walking, while the awkwardly-named Sit-to-Walkstation is wide enough that you can put a chair next to the treadmill and use it for times when you don't want to stand or walk. These things start at $4400, with the bigger one adding another $400. And that's just for the desk and the treadmill. Their pictures show numerous accessories which can add hundreds, if not thousands, more. Now don't get me wrong; I absolutely want one of these. They are great looking desks, I expect them to be sturdy, and I love the back panel and accessory system. But this is simply too much money, particularly for my first treadmill desk. If I manage to stick with it for a year or two, I will definitely consider upgrading. It is just too much money to risk at this point.

The Signature 9000 desk at ~$2500 is 1/2 the price of the Steelcases, so could be viewed in that light as a bargain. I really didn't want to go over $1000, and I definitely didn't want to go over $2000. Bargain though it may be, it was still too pricey. Another strike against them is that I'm too heavy for their entry-level treadmill, so I would have needed to get the upgraded treadmill, which was another $600 or so.

Treadmill-Only

It is possible to buy a treadmill without all of the vertical gadgetry than an average model in a fitness facility would have. I don't need big fancy arms or a giant display as these would most likely not be viewable anyway due to the desk, and would probably limit my desk choices. So if you can find a desk that you like, you don't necessarily have to find some place that sells desk+treadmill combinations. You can buy a treadmill base, usually with a detached control panel, such as the The Tread by TreadDesk. It is $820, but then you need to add another $100+ in shipping, so it isn't cheap. But if you can find or already have a cheap desk, then this is one way to save some money. I did find a competing model, but it was basically the same price.

I mention these only as didn't-buys, not wouldn't-buys. If I hadn't found the LifeSpan, I most likely would have purchased The Tread and one of the desks mentioned below.

Too Cheap

I'm a big IKEA fan, and one desk that routinely turns up in standing/walking desk searches is the FREDRIK. This is advertised as an adjustable-height desk, and while I suppose that's technically true, it looked to me like you'd have to semi-dismantle it in order to reconfigure. This is $150 dollars, so not horribly expensive at all, and there is a narrower version that is even less expensive. I would need to raise the primary desk surface higher than they suggest, but I found numerous examples of people having done exactly that without any problems.

We took a trip to our nearest IKEA to check it out, fully intending to buy that very night. They had a couple of floor models set up that I could kick the tires on, and in general I felt that it allowed entirely too much motion. It was quite a bit wobbly, and since I would set my monitor on the highest shelf, that motion would only be amplified. I was trying to decide if there was any way I could brace it to reduce motion, but the legs are metal. If they were wood, I'd probably bolt a couple of braces to it, but I didn't think there was much I could do with metal, and I didn't really want to risk it. I was a bit disappointed, since this was certainly the least expensive option that I had found, but in my opinion it wasn't sturdy enough. That said, there are numerous examples of people using these just fine, so your mileage may vary.

Too Short

One thing I found frustrating while looking for adjustable-height desks is that they frequently don't account for a tall person standing on a treadmill. I would be on the upper-end of the available height range as-is, but when you add 4-6 inches of treadmill, I'm beyond the maximum height by several inches. Could I make them work? Possibly. But I don't see the point in spending lots of money on something that I can already assume isn't suitable. I don't feel like trying to put the desk up on blocks, or buying additional risers just to get the keyboard up to a decent height. As I type this, my desk is 52 1/2 inches high. It might be a little high, so I have room to go down if I need to. But I also have several more inches I could go up. When most of the desks I found topped out under 50", I was very nervous that they would be too short.

A popular choice, naturally, is the GeekDesk. The smaller model has a maximum height of 48". The larger model (+$200) goes another inch. Each still under 50", and though they come highly recommended, still just short enough that I don't want to risk that they are too short. After I spend some time with the LifeSpan, and possibly make some height adjustments, I might find that 49" is sufficient. But until I know that for a fact, I'm going to choose a desk that has a height range that should easily be accommodating.

There are numerous other desk models in this genre that largely have the same limitation. If you're tall (and I'm not a giant, at 6'1") and will be on a treadmill, chances are that the majority of standing desks will be too short. I've been reading about standing/walking at your desk for a good 8 or 9 months now, and in that time I would say that the concept is increasing in popularity. If I'm correct about that, then I suspect that the standing desk manufacturers will gradually start upgrading their products to add a few more inches of height. In my case, GeekDesk probably lost a sale, as the combination of GeekDesk+The Tread was cheaper than the Signature 9000. But the likelihood of the GeekDesk being too short made it a non-starter for me.

Powered Adjustment

This is basically a sub-set of "Too Expensive". The vast majority of adjustable-height desks have powered height adjustment. While this is convenient, it also adds significant cost to the desk. You can find non-adjustable standing desks, in some cases as low as a couple hundred bucks. The GeekDesk might have been the least-expensive powered height one I saw at about $750 + S&H. That's a lot of money for what is otherwise a very spartan desk. The regular desk I've been using for years has a hutch, file drawers, a compartment for a tower computer, etc. Most powered desks have none of these things. They have relatively basic desktops, those desktops move up and down, and that's about it. So you're paying hundreds, possibly thousands, of dollars for the ability to adjust the height of your desk with the touch of a button.

That's all fine and good, but how often are you really going to adjust the height of the desk? If your intention is to both walk and sit, then you will be adjusting the height a lot, so I can see splurging on the mechanicals to do so easily. But if your intention is solely to stand or to walk, then chances are there won't be much adjusting at all. You'll have to get it dialed in at first, so let's say you futz with it a few times during the first month or so. After that, how often would you change height? Once a year? Ever again? Either way, you've now paid significant money for a motor that sits unused 99.999% of the time. Unless you know in advance the specific height that you need - in which case you could buy a fixed-height desk and probably save lots of money - then you absolutely do want an adjustable-height desk so that you can find your appropriate height. But are you really going to change the height so often that the ability to do so needs to be powered? Probably not.

Just Right

All of that leads me to why I chose the LifeSpan.

Sufficient height range. They claim that 6'8" people can use this desk. That's more than enough for me on a treadmill. Their advertised maximum height is 52", though I just realized I'm currently using it a little above that very height, and still have 3 more clicks available, so I think they are being conservative.
Reasonable price, mostly. At $1300 (and it was shipped free from Amazon), it is roughly 1/4 the price of the Steelcase, and about 1/2 the Signature. It was also cheaper than pretty much ever other combination of standing desk + treadmill that I looked at. About the only way I could have gone cheaper (with new stuff, I mean) is if the Fredrik desk had been sturdy, and even that would have only saved another $100 or so. It still feels like a big chunk of money, and if they could get this down to $999 or so they'd have a solid winner on their hands, but as-is I consider the price to be reasonable.
Manual height adjustment, although I can't say I specifically sought that out as a feature. Would I like powered adjustment? Absolutely. Would I like to add another $500 or more to the price of this desk? No, thank you.
Positive reviews across the board on Amazon.

If you are the DIY type, you can save yourself boatloads of money over what I've done here. I didn't care to invest the time that would be required to do so, and I've never built anything that I'd feel comfortable putting my computer on. Bottom line is that this desk supports my livelihood, now physically as well as financially, and I want it to be a good product. That's worth a couple of bucks to me.

And let's face it, I'm taking a risk here. I already had a bad experience with standing at my desk, but at least that experiment didn't cost me a dime. So this is a new experiment, and if it is ultimately doomed to fail, I'd like to minimize my cash outlay in the process. But if having nicer (-than DIY) equipment ultimately contributes to the success of this project, then that will be money well spent. After considering many options and scenarios, I decided that the LifeSpan fell nicely into the sweet spot between risk and reward.

Project Walk-At-My-Desk

2012-01-15T00:08:00.001-05:00

If you follow my Twitter account at all, then you may remember that last year I posted a few times about Project Stand-At-My-Desk. I had stumbled across an article talking about using a treadmill desk - walking while you work. The concept intrigued me and I searched around for more information.

If you decide to do your own searching, you'll quickly discover that desks fall into 2 general categories: 1) DIY, 2) Sell-a-kidney expensive. I don't trust the resulting quality if I DIM, and I rather like my kidneys. So for the most part, as quickly as I learned about the concept, I just as quickly lost interest.

For some reason, the thought wouldn't go away. At the time, I was walking several miles a day around the neighborhood, and for the most part I enjoyed it. Bad weather and pain or injury would reduce that enjoyment considerably, and after a while it's just boring. The whole reason I started walking around the neighborhood in the first place is that I find stationary exercise machines just boring beyond words. But at the end of the day, I drive a desk for a living. I spend all day sitting. Even the hour or so of walking I was getting just couldn't compete with that much inactivity, and I was putting on weight. And I'm not exactly small to begin with.

Knowing that I needed to do something, I would continue to read and search about treadmill desks. For the most part, it was pretty universal that it is rough to get started, but after a couple of weeks it gets better, and after a month or so people wouldn't go back to sitting at a desk. And in most cases, weight loss over the course of a year or so was not-insignificant. This sounds like the magic bullet. I can distract myself from the boring exercise by doing work at the time.

A semi-universal theme is that people recommend that you don't go straight from sitting to walking. A common recommendation is to stand at your desk first, and then if that holds up, go to walking. This sounded like a good compromise, so I managed to find some storage containers and elevate my keyboard and monitor. This was Project Stand-At-My-Desk.

Cable management becomes a really big deal when you move things ~2 more feet into the air. The effort of getting everything rearranged was enough that I couldn't just give up after 5 minutes and go back to sitting. It required every bit of an hour or two to get everything set up.

In the end, I lasted about 6 weeks. I toughed it out for the first couple of weeks, armed with the knowledge that it would be hard, and you just need to get through it. But the pain never went away. If anything, it got worse. I tried different shoes, I tried an anti-fatigue mat, I tried regular breaks. By the time I finally gave up, I was hobbling around like an 80-yr-old man. I wasn't feeling any healthier, wasn't any lighter, and just generally was miserable. So, I admitted defeat, and mostly forgot about it.

And then this happened.

I respect Jeff, and it hits a little closer to home when someone I know is trying something I've been thinking about. I returned to my Googling, and finally found a treadmill desk solution at a price that wasn't too ungodly expensive, and it just arrived yesterday. I'll talk more about it in the next post. I'm determined to make it work this time, and I've spent enough money that I'm not inclined to give up easily.

At the time I gave up standing, I felt pretty confident that the walking would actually be easier. Even when I was mostly hurting, getting out to take my walk usually felt ok. All I needed was the treadmill and an appropriate desk, so now I have that. If it works, then at least in my case, standing before walking was not a good idea. I never quite got around to blogging about standing, so I'll try to be better about updates regarding the walking.

Acknowledgements

2011-12-29T18:57:00.001-05:00

As we finish up what is basically my 2nd full year as an iOS developer, I'd like to take a moment to plug some people who have helped me to become the programmer that I am today.

Big Nerd Ranch

I attended the Cocoa Bootcamp several years ago intending to do Mac programming. Haven't quite followed up on that yet, but what I learned served me quite well on iOS. Their latest iOS book is worth checking out:

iOS Programming: The Big Nerd Ranch Guide (2nd Edition)

Jeff LaMarche and Dave Mark

I truly don't know how I would have gotten started without Beginning iPhone Development. I remember downloading SDK betas and being totally clueless, and it really wasn't until this book came out that I was able to get anywhere. The success of my career is in no small part attributed to their efforts with this book. They recently released a brand new version:

Beginning iOS 5 Development: Exploring the iOS SDK

Jeff's blog is iPhone Development, and Dave's is here.

Rob Napier

After I got past the book and started working on real world stuff, the Big Nerd Ranch mailing list turned out to be invaluable, due in no small part to the participation of folks like Rob. There are a number of practices that I still follow religiously to this day that originated with Rob's advice. He was instrumental in helping me to get "over the hump" in my Cocoa learning curve. He has recently released a book that I haven't had time to read yet, but am eagerly looking forward to:

iOS 5 Programming Pushing the Limits: Developing Extraordinary Mobile Apps for Apple iPhone, iPad, and iPod Touch

Rob's blog is Cocoaphony.

Mark Dalrymple

Mark is another Big Nerd Ranch mailing list participant who was tremendously helpful during my early days. He gets a two-fer mention here, as his Objective-C book is quite good:

Learn Objective–C on the Mac (Learn Series)

And his newest effort:

Advanced Mac OS X Programming: The Big Nerd Ranch Guide

Mark's blog is Borkware.

Thank You

Training and Googling can only get you so far. At some point, there will simply be gaps in the available information, and thus roadblocks to accomplishing your goals. My hat is off to authors like these who can spend the time to learn the new stuff, and then do a great job of conveying it to everyone else. And I have tremendous gratitude for the folks who participate in public forums providing considerable amounts of support for free. It is in their honor that I have spent so much time answering questions on iPhone Dev SDK, and it is due to their efforts that I have the knowledge and skill required to do so.

So I would like to express my sincerest thanks to all of the trainers, authors, forum posters, bloggers, support engineers, and anyone else who has helped me along on my journey.

No Longer Pending

2011-08-22T16:28:00.001-04:00

So a piece of junk mail that I got today informed me that I have been granted a patent. And it turns out to be true. It's a little odd/sad that the way I find out is through junk mail, but hey, as long as I do find out.

Read it and weep: (seriously, patents are painfully boring)

Electro-hydraulically powered lift ambulance cot

Note that the filing date is in 2005, so this is a solid 6+ years in the making. Heck, I haven't even been with the company for 3 years. And I'm a co-inventor; I don't mean for this to sound like it is exclusively my work. It was a good team effort.

The design described in this patent would eventually become the PowerFlexx.

UITableView How-To: Part 5 - More About XIB-Based Cells

2011-03-07T00:17:00.001-05:00

Part 1 | Part 2 | Part 3 | Part 4

(This is really the second half of Part 4, so we'll just continue with the same project)

I've got one more key topic to address, then we'll take a look at some alternate techniques.

By the end of Part 4, we created a custom view layout using IB, so we've got the visual part down. That really just leaves one more basic characteristic to talk about: actions. In addition to customizing the look of your cell, you can customize the behavior of your cell, and this is most easily done by adding controls such as buttons, switches, and so on. We're just going to do a quick button, but the concept applies to any of the other controls you may wish to use.

So, open up CustomTableCell.xib and drop a button smack in the middle:

With a typical view controller, we'd connect this button to an IBAction. That's what we want to do here as well, but the question is: where is the IBAction? There are 2 basic options, in the cell class or in the view controller class. Where you should put it will depend on the goal you are trying to accomplish. If you put it in the cell class, then it really isn't any different than wiring it up as you would in a view controller. Depending on your goal, this approach can either simplify or complicate your ultimate outcome. But for our purposes here, we're going to put the IBAction in the view controller. So add this declaration to BasicViewController.h:

- (IBAction)buttonPressed:(UIButton *)button;

(you are probably accustomed to seeing (id)sender for these things. Go ahead and do that if you prefer. I like the type to be correct, and rarely have a need to mix these methods with multiple types of controls)

Now we just need to wire it up. You're going to drag from the button to File's Owner like you normally would. The only difference is that this is happening in the cell class instead of the view controller class.

All that's left is to make the method do something. You can do a simple stub for now to make sure that this works:

- (IBAction)buttonPressed:(UIButton *)button
{
   NSLog(@"It worked!");
}

Go ahead and run the app, and you should see this message in the console when you hit any button. And now we reach the fun part. As you can see, this method fires when you hit any button. So, how do you know which button?

There are a couple of ways to answer this question and, like so many programming challenges, which way to go will depend on your situation. You could use the tag property of the button. This is a common thing to do when you have multiple buttons and would like to distinguish between them. You would need to declare a property in the cell for the button, and then you could assign the tag value in cellForRow like this:

[[cell theButton] setTag:[indexPath row]];

Then you extract the tag value in the IBAction method:

NSLog(@"Pressed button at row: %d", [button tag]);

For many tables, this will be an adequate and simple approach. However, if you recall some behaviors from Part 3 regarding multi-section tables, then your spidey sense should be warning you that something may be wrong here. We are using the row parameter to identify the cell, but what happens if there is more than one section? You could have row 0 in the first section, and row 0 in the second section, and row 0 in the third section... Remember that row indexes reset in each section. This is why NSIndexPath provides TWO parameters - section and row - because only one parameter is insufficient to find/describe the location.

UIButton doesn't have an NSIndexPath property. If you really wanted to, you could subclass UIButton to add that property. Then the approach above would be the same, except you would provide/extract the indexPath instead of merely the row. I personally tend to view subclassing as a last resort, so I've never bothered doing this. But I suppose I could see some situations where BSTableButton could come in handy. But that isn't why I've brought you here today.

No matter what the approach, you have to do some work. Above we've done a little work in cellForRow, and a little work in the IBAction method. (And if you subclassed, you've done a lot of work in even more places) Also think in terms of performance. You are flicking your way through a table, and you want to get in and out of cellForRow as fast as possible. Assigning the tag (or indexPath) is just one more thing that has to be done that is preventing you from leaving the method ASAP. So instead of doing the work for each cell, just do the work when the user actually hits the button. The question is how.

In the IBAction, I receive the button itself as a parameter. From there, I would like to wind up with an indexPath. This will allow me to know that the 5th button was pressed, so I can go do something to the 5th item in the array. A quick glance at the UITableView documentation reveals a handful of methods that return an indexPath. For all visible rows. For the selected row (before you get excited, this is only for the blue highlighted row, not for tapping on items in the row). The only one that seems useful in this situation is indexPathForCell:. If I have a cell, the table can tell me where it is located.

Ok, so how do I get to the cell from the button. Ah ha! Remember that these are all views, and that they have been arranged into an hierarchy. The button would be a subview of the cell, so since I'm starting with the button, I would need to walk UP the hierarchy. You do that with the superview method.

This part can require some learning and trial-and-error, so let's do it the hard way before we skip to the answer. Add this to the IBAction:

NSLog(@"superview is: %@", [[button superview] description]);

Run it and you should see something like this:

superview is: <UITableViewCellContentView: 0x4d31390; frame = (0 0; 320 43); layer = <CALayer: 0x4d313f0>>

Hrm, UITableViewCellContentView. We're looking for CustomTableCell, so that's not a match. If you look at the top of the UITableViewCell documentation, you'll find the contentView property mentioned, and then you can go read its description. Basically, what we added the button to was the contentView, not the cell directly. So we need to go higher in the hierarchy:

NSLog(@"superview is: %@", [[button superview] description]);
NSLog(@"superview superview is: %@", [[[button superview] superview] description]);

Try again:

superview is: <UITableViewCellContentView: 0x4d31390; frame = (0 0; 320 43); layer = <CALayer: 0x4d313f0>>
superview superview is: <CustomTableCell: 0x4b3ad70; baseClass = UITableViewCell; frame = (0 264; 320 44); autoresize = W; layer = <CALayer: 0x4b39e20>>

Bingo. So, with this particular hierarchy, to go from the button to the cell, we need to go up 2 levels in the view hierarchy. This will depend on your actual view hierarchy, which is why I showed the long steps first. Just keep walking up the hierarchy until you find the cell. (I'm sure you could come up with an algorithm to keep walking, but it's never been worth the effort for me) Now that we know where we're going, our actual line of code is:

CustomTableCell *cell = (CustomTableCell *)[[button superview] superview];

We have the cell, and can now get the indexPath:

NSIndexPath *indexPath = [[self mainTableView] indexPathForCell:cell];
NSLog(@"indexPath is: %@", [indexPath description]);

Now you have the exact same location that you would have in cellForRow. So you can access your array the same way, and go manipulate your data or otherwise make something happen as you see fit.

Cell Identifiers Suck

I mentioned in Part 4 that I don't like the way Apple put the cell identifier into the cell's XIB. About a year ago, I discovered a blog post by Jeff LaMarche that provides a workaround. I won't bother repeating what he has said there, so let's just apply the code with a little twist.

Add this to CustomTableCell.h:

+ (NSString *)reuseIdentifier;

And then add these to CustomTableCell.h:

- (NSString *)reuseIdentifier
{
   return [[self class] reuseIdentifier];
}

+ (NSString *)reuseIdentifier
{
   return NSStringFromClass([self class]);
}

It's the same thing Jeff shows, I just took out the constant declaration as mentioned in the comments. This allows for easy copy-pasting into any cell class.

You can now blank out the identifier setting in IB, or forget to include it altogether.

And Now For Something New

There are a variety of debates regarding XIB-based cells. First there are the usual arguments with the "I only use code, IB is the debbil" people. Then there is another layer for use in cells, with people arguing that XIBs are slower than code because you have to go do disk to load the cell. There must have been some truth to this, because Apple added a new class for OS 4 to address it. It's too bad it took so long, because if anything we needed it more in slower-hardware days of OS 2 than we do today, but they felt it was important enough to create, so we should at least give it a look.

Now presenting: UINib.

Read the documentation and you'll find that it is basically a caching and instantiation class for loading XIBs. You can use it for any kind of XIB loading, but you can be pretty confident that it was developed for table cells. It doesn't wind up making a tremendous difference in terms of code - if anything it adds some - but I'll take Apple at their word that this is faster in terms of performance. I like using UINib as a property, so add this to BasicViewController.h:

@interface BasicViewController : UIViewController <UITableViewDelegate, UITableViewDataSource>
{
   UITableView *ivMainTableView;
   CustomTableCell *ivCustomTableCell;
   UINib *ivCustomTableCellNib;
}
@property (nonatomic, retain) IBOutlet UITableView *mainTableView;
@property (nonatomic, retain) IBOutlet CustomTableCell *customTableCell;
@property (nonatomic, retain) UINib *customTableCellNib;

And then I implement it with a custom getter in the .m file:

@synthesize customTableCellNib = ivCustomTableCellNib;
...

// dealloc
[ivCustomTableCellNib release], ivCustomTableCellNib = nil;
...

- (UINib *)customTableCellNib
{
   if (ivCustomTableCellNib == nil)
   {
      ivCustomTableCellNib = [[UINib nibWithNibName:NSStringFromClass([CustomTableCell class]) bundle:nil] retain];
   }
   return ivCustomTableCellNib;
}

I customize the getter so that I don't have to care who creates it or when. The first time it is needed, it will get created.

So we've added a property, and we've added a method. What's the payoff? Well, not much really. Here is what we had before:

if (cell == nil)
{
   [[NSBundle mainBundle] loadNibNamed:@"CustomTableCell" owner:self options:nil];
   cell = [self customTableCell];
   [self setCustomTableCell:nil];
}

This now becomes:

if (cell == nil)
{
   [[self customTableCellNib] instantiateWithOwner:self options:nil];
   cell = [self customTableCell];
   [self setCustomTableCell:nil];
}

Wow. We changed one line of code. Yay. Well, this is more about performance than it is about code reduction.

A Couple Of Tweaks

Speaking of performance, there is one thing you want to be careful of in cell design, whether it is in code or via XIB: avoid transparency. With our fancy iPhone 4's and iPad 2's, this is becoming less and less of an issue, but the basic premise remains the same: the device likes opacity a whole lot more than it does transparency.

What this specifically means as far as the view items go is to turn on the Opaque toggle, and supply a background color. The Opaque toggle is here:

When you first turn it on, the items will often default to black. Simply apply a different color:

Naturally this won't work if your background is not consistent, like a gradient or an image. In those cases, you're pretty much stuck with the transparency.

The next thing to be aware of isn't performance related, but it is very visual so you'll want to make sure to catch it. For labels (and some others like image views) you will want to specify a highlight color:

This is the color that the text will be when the user highlights a row. Generally speaking you will want it to be white, but that's a design decision for you. At some point in the last couple releases of Xcode, and I'm not sure when this started, the default automatically became white. So hopefully you shouldn't have to mess with this too much. But if you're on a slightly older version of Xcode, be aware that the default used to be black. Regardless, if you tap a cell, and don't see nice white text, this is where you need to go to fix it.

Holy Crap, This Is Long

Now you know why I split this into 2 parts. Head back to the cell's XIB, and we're going to make a slight change. Make the cell taller. You can add more stuff if you want, but for immediate purposes, all I want is something like this:

Depending on how you set up the label's masks, when you run the app now you should get something like this:

Well that's no good. What happened here? I made the cell taller, why isn't it displaying that way? Ah, because nobody told the table that the row height should change. So we need to do that.

The wrong answer is to use this delegate method:

tableView:heightForRowAtIndexPath:

This method should ONLY be used if your table will feature more than 1 row height. If you have tall rows and short rows and everything in between, then this method is pretty much your only option. But if your rows are all the same height, then you will slam against this method over and over and over again (seriously, add some logs and watch how much it gets called) just to return the same number each time.

Fortunately, there is a better answer: UITableView has a rowHeight property. In fact, we've already utilized it, we just didn't realize it. Open up the BasicViewController.xib, select the table view, then hit Cmd-3. Right there at the top of the inspector: row height of 44.0. So we could simply change this number to match whatever our cell height is, and things will be good.

Or will they? Hard-coding numbers is generally something to avoid. And really, we could change the cell design again, and change the height again, and then we just forget to come back and change this setting. Wouldn't it be nice if we could establish a link between our cell height and our row height?

We can't quite get there directly, but we sure can take a measurement and use that to define the row height.

So first we need a cell. viewDidLoad is a good place to do this, and we are literally going to do the same thing we do in cellForRow to get a cell:

[[self customTableCellNib] instantiateWithOwner:self options:nil];

From what we learned before, we know that the cell property is now occupied. So we can grab that cell, take a measurement, and drive the table:

[[self customTableCellNib] instantiateWithOwner:self options:nil];
[[self mainTableView] setRowHeight:[[self customTableCell] frame].size.height];
[self setCustomTableCell:nil];

We get the frame of the cell, then get the height, and give that value to the rowHeight property. Then we clear out the cell property since we're done with it.

Try again:

Muuuuch better. Now you can change the cell's height as much as you want, and the table will always display the correct row height.

Thus concludes a couple of lengthy posts on this topic. But don't let that volume scare you away from using XIB-based cells. After you've run through the process a few times, it gets less intimidating. And once you're there, you get to take full advantage of Interface Builder's promise to make view layout easier.

TableViewTutorial_Part5.zip

UITableView How-To: Part 4 - XIB-Based Cells

2011-03-04T22:30:00.000-05:00

Part 1 | Part 2 | Part 3 | Part 5

Up to this point in the series, the focus has been on basic table and data structures. Now let's take a look at customizing the appearance of the table view.

I'm not intending to spend much time talking about standard cells, but there actually are a number of ways to customize cells without needing to subclass. UITableViewCell's initWithStyle: method accepts a parameter for which Apple has provided several standard options. You can show text in several places, and you can add images and accessories. Take a quick glance at the Settings app on your phone; those are standard cells. So before you dive into subclassing cells, make sure you are aware of the built-in options. They can save you a lot of time. This post at Cocoa With Love is definitely worth reading.

But, let's assume that those standard configurations are inadequate for your awesome table design. Or perhaps you've seen another app that displays lots of crazy things in a table, and you wonder how it was done. Chances are that the answer will be the same either way: custom table cells. Like most visual things in Cocoa, there is a code-based approach and an Interface Builder-based approach. I'm going to focus on using IB, as the layout is significantly easier, although the setup has some nuances. This approach is based on the Apple sample project called TaggedLocations.

Overview

Let's take a quick look at the players involved, because the process to set this up is a tad convoluted:

ViewController.h
ViewController.m
ViewController.xib

TableCell.h
TableCell.m
TableCell.xib

In the same way that you would reference a button in your view by creating an IBOutlet, the same thing will be done here. So the view controller will have an IBOutlet for the cell:

@property (nonatomic, retain) IBOutlet TableCell *tableCell;

In order to do this without causing any build errors, the cell class needs to exist. But this outlet needs to exist in order to to complete the TableCell.xib, so there is something of a chicken-and-egg situation. The basic steps are:

1. Create the view controller class
2. Create the cell class
3. Create the IBOutlet in the view controller
4. Design the cell
5. Rewire the table delegate methods to use the cell

So there is a fair amount of back-and-forth between the classes, but after you get used to it, it's not so bad. Let's begin...

1. Create a view controller. I'm calling this one BasicViewController, but you can use whatever you want. Don't bother getting too hung up with delegate methods for now.

2. Add a new file. This will be a UITableViewCell subclass, and it's not immediately clear how to do this. Just choose Objective-C class, and then select UITableViewCell from the pull-down menu:

Call it CustomTableCell. This will create the .h and .m file, but we want a XIB file, too. So add a new file for that as well. Select User Interface at the side, and then choose a View XIB. iPhone-vs-iPad doesn't really matter, but I tend to go with iPhone.

Give it the same CustomTableCell name. You should now have .h, .m, and .xib files for CustomTableCell.

3. Now create an IBOutlet for the cell in the view controller. You will need @class in the .h file and #import in the .m class. The highlights of what you should wind up with are:

// BasicViewController.h
#import <UIKit/UIKit.h>
@class CustomTableCell;

@interface BasicViewController : UIViewController <UITableViewDelegate, UITableViewDataSource>
{
   UITableView *ivMainTableView;
   CustomTableCell *ivCustomTableCell;
}
@property (nonatomic, retain) IBOutlet UITableView *mainTableView;
@property (nonatomic, retain) IBOutlet CustomTableCell *customTableCell;

// BasicViewController.m
#import "CustomTableCell.h"

@implementation BasicViewController

@synthesize mainTableView = ivMainTableView;
@synthesize customTableCell = ivCustomTableCell;

- (void)dealloc
{
   [ivMainTableView release], ivMainTableView = nil;
   [ivCustomTableCell release], ivCustomTableCell = nil;
   [super dealloc];
}

4. Configure the cell. Open up CustomTableCell.xib, as we have some preliminary things to take care of. You should see:
File's Owner
First Responder
View

Select View and delete it. Now go to your Library palette, find the Table View Cell, and drag it to the spot where View was.

Now we need to change classes. Select File's Owner, and go to the inspector panel for Identity (Cmd-4). Change the class to BasicViewController. Now select the table view cell, and in the inspector change the class to CustomTableCell.

Now we need to connect the IBOutlet we made earlier. Ctrl-click on File's Owner. Select the customTableCell outlet, and drag that to the CustomTableCell item.

Hey, wait a second... this isn't my view controller's XIB! You are correct. But the view controller will create this class - it will be the file's owner - so it does make some sense to do this. But don't get carried away. For example, you do see the view outlet, but don't mess with that here as that is being populated in your view controller's XIB. We are doing this for one reason and at this point one reason only: to get access to that cell IBOutlet.

There is a lot of customization we could potentially do here, but in the interest of quickly moving along to see this in action, simply drop a couple of a labels onto the cell. We'll come back later to wire everything up.

5. Configure the table delegate methods. Return to BasicViewController, and for now tell it there are 10 rows. The important change happens in cellForRow:

- (UITableViewCell *)tableView:(UITableView *)tableView
cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
   static NSString *CellIdentifier = @"CellIdentifier";

   CustomTableCell *cell = (CustomTableCell *)[tableView dequeueReusableCellWithIdentifier:CellIdentifier];
   if (cell == nil)
   {
      [[NSBundle mainBundle] loadNibNamed:@"CustomTableCell" owner:self options:nil];
      cell = [self customTableCell];
      [self setCustomTableCell:nil];
   }
   return cell;
}

For the most part, this is pretty similar to what we've done before. Instead of a UITableViewCell, we're using a CustomTableCell, so we change the class types to reflect that. We're still asking for an available cell, and if one isn't available then we create one. The creation part is different than we've done before, naturally since we aren't just using code this time.

The first thing we do is load the XIB file. We indicate which class, and who should own it. The next thing we do is wave our hands and say there is some black magic happening here. Then we assign the cell property to our cell variable. Hrm, what? How did that get there? Well, let's back up and address that black magic.

The documentation has this to say about loadNibNamed:owner:options:

During the loading process, this method unarchives each object, initializes it, sets its properties to their configured values, and reestablishes any connections to other objects.

For our purposes, the important part is the last bit.

Think about what you do with a normal view controller. You place, say, an image view in IB, you create an IBOutlet for it, and then make the connection in IB. So after you instantiate your view controller, what happens? The XIB is loaded, which means an image view is also instantiated, and this image view is then assigned to your IBOutlet/property. When you go to talk to your image view using the property - [[self imageView] setImage:...]; - the image view is there already.

What we're doing here is exactly the same, only splitting things up into separate files. Instead of an image view, it's a table cell, and instead of being in the view controller's XIB, it is in a separate XIB. But the act of loading the XIB causes the outlets to be populated, so we end up with the same result. Black magic indeed.

So:
1. We load the XIB file
2. The IBOutlet gets populated with the cell
3. We assign that cell to our local cell variable
4. We clear out the property since we don't need to keep it around

Go ahead and run the app at this point, and if you've wired everything correctly, you should see:

Configure the cell

Let's circle back around and finish up the cell. First of all, we skipped a really important step. Recall what the initializer for a standard cell looks like:

cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];

We pass two parameters: a style, AND a reuse identifier. Now compare to how we just created the cell:

[[NSBundle mainBundle] loadNibNamed:@"CustomTableCell" owner:self options:nil];

Uh oh, no reuse identifier parameter. That's a problem if we want good table scrolling performance (and we do). I wish Apple would have handled this differently, but what they did is imbed the reuse identifier into the XIB file. So open it back up, and select the cell. Then go to the inspector panel again, Cmd-1.

It will be blank when you first look at it, so you will need to type it in. The important part here, and one unfortunate aspect of Apple's decision to do this, is that whatever you type in here, needs to match what you type in here:

static NSString *CellIdentifier = @"CustomCellIdentifier";

So you have to make sure the same thing is typed in 2 places, and if you screw up either one then you won't recycle cells. This will hurt scrolling performance. I really wish Apple had gone with more of an initWithNibName:bundle:reuseIdentifier: approach for these cells. Oh well.

Let's add some properties to the cell so that we can talk to the labels.


// CustomTableCell.h
@interface CustomTableCell : UITableViewCell
{
   UILabel *ivRedLabel;
   UILabel *ivGreenLabel;
}

@property (nonatomic, retain) IBOutlet UILabel *redLabel;
@property (nonatomic, retain) IBOutlet UILabel *greenLabel;

// CustomTableCell.m

@implementation CustomTableCell

@synthesize redLabel = ivRedLabel;
@synthesize greenLabel = ivGreenLabel;

....

- (void)dealloc
{
   [ivRedLabel release], ivRedLabel = nil;
   [ivGreenLabel release], ivGreenLabel = nil;
   [super dealloc];
}

Standard stuff here. Where it gets tricky is actually making the connections in IB. You are probably accustomed to dragging from File's Owner to establish IBOutlet connections. Ah, but remember which class we're dealing with here. File's Owner is the view controller, but we are adding these IBOutlets to the cell. So you can drag from File's Owner all that you want, but you won't be able to create the links. You have to drag from the cell class to the labels:

Now let's head back to the view controller and put some data in the labels. I'm not going to bother setting up any data; refer to Part 3 for some thoughts on how to arrange your data for this purpose. For now, just drop in something so that you can see different text in each field:

   ...

   NSUInteger row = [indexPath row];
   [[cell redLabel] setText:[NSString stringWithFormat:@"Red %d", row]];
   [[cell greenLabel] setText:[NSString stringWithFormat:@"Green %d", row]];
	
   return cell;
}

With standard cells, you are talking to [cell textLabel] or [cell detailTextLabel]. Same idea, just using the properties that you've created.

Your cell is a blank canvas ready to be customized to your heart's delight. Want 5 labels? Good. Want 10 images? Great. Go nuts.

This is turning into a longer post than I thought, and I still have a lot to talk about. So I'm going to split this up into 2 posts. Tune in later for the sequel.

TableViewTutorial_Part4.zip

UITableView How-To: Part 3 - Multiple Sections

2011-02-02T22:47:00.001-05:00

Part 1 | Part 2 | Part 4 | Part 5

In my experience so far, people seem to have a knack for making multi-section table views harder than they really are. The key to simplifying things is to prepare your data in such a way that pain is removed from your table delegate methods. If your delegate methods are nothing but switch/case statements, then you've likely given yourself a pretty good headache.

Let's quickly revisit some key elements from Part 1. To determine the number of rows, we did this:

NSInteger rows = [[self contentsList] count];

...and to get the information to show in the cell, we did this:

NSString *contentForThisRow = [[self contentsList] objectAtIndex:[indexPath row]];

We count up everything we have, and then we use the row parameter to extract the specific piece of information. That's fine when we have one continuous list, but if you want a sectioned display, then you don't have one continuous list anymore. And this is true regardless of the display type.

There are two default display options for table views. Plain:

And grouped:

This is purely visual fluff. You can go back to the exercise in Part 1 if you want and flip it to grouped, and nothing else needs to change. The easiest way to manage this sectioned/grouped appearance is to group your data as well. The long list of 500 names that you have in your address book needs to be broken up into pieces.

How you actually get your data broken up is a programming exercise that I'm not going to go into here. There are lots of ways to do it, and the 'correct' approach will depend on your actual data and your specific needs. What I will show here are two different structures that you can use that simplify the delegate methods considerably. They are:

An array of arrays

A dictionary, and an array of keys

But first we need to introduce a delegate method that we haven't seen or used yet. In Part 1, we answered the question "how many rows in this section". The second half of that question is important, as we never indicated how many sections there are. This is yet another question the table view can ask, and it is:

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView

This is an optional method, as evidenced by the fact we didn't use it in the previous exercises. But clearly the table works without it, so what gives? As noted in the documentation, the default value is 1. So the tables we've seen so far actually were sectioned table views, just with only 1 section.

Just like we did for the number of rows, we should probably base the answer on a calculation. If you have a simple table that will only ever have 2 sections, then by all means go ahead and hard-code a 2. But if the number could change, it needs to be related to your data somehow. More on that in a moment.

For now, I'm going to take the code from Part 1, remove a couple of colors, and then set the number of sections to 3.

Notice that the rows repeat; I have 3 groups of the same thing over and over again. Why is that? Well, let's remember how we collected the data to display:

NSString *contentForThisRow = [[self contentsList] objectAtIndex:[indexPath row]];

Using the row alone, we pull data from the array. Why does it repeat? Because the row numbering starts over for each section. Section and row numbers look like this:

Section 0
   Row 0
   Row 1
   Row 2
Section 1
   Row 0
   Row 1
   Row 2
Section 2
   Row 0
   Row 1
   Row 2

Three sections, so the table view asked for something to display in Row 0 three times. And that's exactly what we gave it: the first item in the array, 3 separate times.

This is why arranging the data in a particular way is important.

How do we find our way around in the table? Well, we've already seen this:

[indexPath row]

Now we also need to use this:

[indexPath section]

NSIndexPath actually does a lot more than this, but for most iPhone purposes it is used to describe a section and row location in a table view. In Part 1, we used the row parameter to select an item from the array. We are still going to do that, but we will now use the section parameter to decide which array.

Array of Arrays

As previously stated, the key is arranging your data in a way to facilitate a sectioned table view. We'll keep the same contentsList array that we had before, but we'll change the contents. Before, it contained only strings. Now, it will contain arrays. Those arrays will contain strings.

NSArray *firstSection = [NSArray arrayWithObjects:@"Red", @"Blue", nil];
NSArray *secondSection = [NSArray arrayWithObjects:@"Orange", @"Green", @"Purple", nil];
NSArray *thirdSection = [NSArray arrayWithObject:@"Yellow"];
	
NSMutableArray *array = [[NSMutableArray alloc] initWithObjects:firstSection, secondSection, thirdSection, nil];
[self setContentsList:array];
[array release], array = nil;

Same basic idea as before, but we've added some structure. We need to make adjustments to the delegate methods to account for this new structure. First, our new delegate method for number of sections:

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
{
   NSInteger sections = [[self contentsList] count];
	
   return sections;
}

This is the same calculation we started with, but now we are answering a different question. In Part 1, this calculation was for the number of rows. Now it is the number of sections. So far so good. Now we need to define the number of rows. You'll note I set up the arrays so that each one has a different number of objects. This is to help reinforce that these numbers probably shouldn't be hard-coded. You want everything to work whether your array has 5 objects or 500 objects.

In Part 1, the number of rows was the number of items in the main array. That is no longer the case. We must first identify which sub-array we're interested in, and then count that sub-array. There was a parameter we ignored before:

- (NSInteger)tableView:(UITableView *)tableView
numberOfRowsInSection:(NSInteger)section

How many rows are in this section? We've told the table how many sections there will be, and the table will now call this method for each section, passing in the appropriate value. We'll use this to identify which array we want.

NSArray *sectionContents = [[self contentsList] objectAtIndex:section];

For the first section in the table, I want a reference to the first sub-array in the main array. Second array for the second section, and so on. The number of rows is then the count of this sub-array.

- (NSInteger)tableView:(UITableView *)tableView
numberOfRowsInSection:(NSInteger)section
{
   NSArray *sectionContents = [[self contentsList] objectAtIndex:section];
   NSInteger rows = [sectionContents count];
	
   return rows;
}

So it is the same idea as what we did before, we just have to count a different array each time. It's not horribly complicated, you just have to plan for it.

We use this same concept again to determine what the row contents are. The only difference is that we get to the section value through the indexPath parameter.

NSArray *sectionContents = [[self contentsList] objectAtIndex:[indexPath section]];

Now we do the same thing we did before, using the row parameter, but using this array instead of the main one.

- (UITableViewCell *)tableView:(UITableView *)tableView
cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
   NSArray *sectionContents = [[self contentsList] objectAtIndex:[indexPath section]];
   NSString *contentForThisRow = [sectionContents objectAtIndex:[indexPath row]];
   ...

After this, nothing is different than what was done in Part 1. Feed this string into the cell, and you should be good to go. If everything is wired up correctly, then you should see:

That's really all there is to it. Once you have this structure in place, you can add or remove as many colors as you want - to/from each section - and you don't have to mess with the delegate methods anymore. We added 1 delegate method, and 1 line of code each to two existing delegate methods (plus the extra stuff for setting up the data) vs. what we had in Part 1. Easy!

A dictionary, and an array of keys

Again there are many possible ways to structure your data, so I offer this next one merely as another example. But it is handy if you want even more data in your table view, specifically headers. If you look at the address book, you'll see letters for each group of people - A's, B's, etc. - and this data has to be set up somewhere, somehow.

Dictionaries store data using keys, typically strings. So you store something by name, and you retrieve something by name. Those names can be easily used as section headers. The problem is that dictionaries do not have order. There is no first object, second object, etc., and tables really like for things to be in order. So in addition to using the dictionary, we will continue to use an array to provide order.

Again, how you set up the data is pretty important. So let's start with the basics, we have a dictionary and an array:

@interface DictionaryViewController : UIViewController <UITableViewDelegate, UITableViewDataSource>
{
   UITableView *ivMainTableView;
	
   NSMutableArray *ivSectionKeys;
   NSMutableDictionary *ivSectionContents;
}

@property (nonatomic, retain) IBOutlet UITableView *mainTableView;
@property (nonatomic, retain) NSMutableArray *sectionKeys;
@property (nonatomic, retain) NSMutableDictionary *sectionContents;

I've kinda shown my hand here with the names. The dictionary will hold the contents of each section, and the array will hold the keys. The contents will be arrays, just like in the previous example. We're just going to access them in a different way. The data is prepared like so:

NSMutableArray *keys = [[NSMutableArray alloc] init];
NSMutableDictionary *contents = [[NSMutableDictionary alloc] init];
	
NSString *colorKey = @"Colors";
NSString *clothingKey = @"Clothing";
NSString *miscKey = @"Misc";
	
[contents setObject:[NSArray arrayWithObjects:@"Red", @"Blue", nil] forKey:colorKey];
[contents setObject:[NSArray arrayWithObjects:@"Pants", @"Shirt", @"Socks", nil] forKey:clothingKey];
[contents setObject:[NSArray arrayWithObjects:@"Wankle Rotary Engine", nil] forKey:miscKey];
	
[keys addObject:clothingKey];
[keys addObject:miscKey];
[keys addObject:colorKey];
	
[self setSectionKeys:keys];
[self setSectionContents:contents];
	
[keys release], keys = nil;
[contents release], contents = nil;

This should look reasonably similar to what we did before. We've added a dictionary, and you add data to a dictionary differently than you do an array, but otherwise it is the same idea. If you're paying attention to details (and as a programmer, you should be) then you'll notice that the order I added the keys is different than the order I added the arrays. I only did this to illustrate that the order of the dictionary doesn't matter, and the order of the array is what will be driving the table.

After this, the approach is pretty similar to what we did before. We need to tell the table how many sections:

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
{
   NSInteger sections = [[self sectionKeys] count];
	
   return sections;
}

Since the dictionary and the array have the same number of objects, I could have counted either one. But typically you'll want to use the array. If I'm testing various arrangements, I will often make the contents the same regardless, and observe differences by messing with the keys. Don't want colors today? Just don't add the key to the array, and nothing else needs to change.

Now we need to provide the number of rows. This is the same approach as last time, just going through the dictionary.

- (NSInteger)tableView:(UITableView *)tableView
numberOfRowsInSection:(NSInteger)section
{
   NSString *key = [[self sectionKeys] objectAtIndex:section];
   NSArray *contents = [[self sectionContents] objectForKey:key];
   NSInteger rows = [contents count];

   return rows;
}

We grab the key using the section parameter, then grab the sub-array using that key. Same thing for the row contents:

- (UITableViewCell *)tableView:(UITableView *)tableView
cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
   NSString *key = [[self sectionKeys] objectAtIndex:[indexPath section]];
   NSArray *contents = [[self sectionContents] objectForKey:key];
   NSString *contentForThisRow = [contents objectAtIndex:[indexPath row]];
   ...

At this point, we've essentially recreated the first example. But we went this way for a reason, and that reason is section headers. There is another delegate method:

- (NSString *)tableView:(UITableView *)tableView
titleForHeaderInSection:(NSInteger)section
{
   NSString *key = [[self sectionKeys] objectAtIndex:section];
   
   return key;
}

We've already seen how to grab the key, so we simply do that and use the key as the header.

Food For Thought

Usually when I see rookie attempts at multi-section tables, there is a lot of code like this:

if (section == 0)
{
   ...
}
else if (section == 1)
{
   ...
}
...

For a simple structure: Ok, it probably doesn't make a big difference
For a complex structure: No, just no

This is paving the way for a modification nightmare. We've only looked at cellForRow so far, but you're going to do the same thing in didSelectRow (we'll get to that later), too. If you decide to rearrange things, you've got to remember everywhere that it is supposed to change, and of course you'll forget, and things will go badly.

You'll notice that the code I've posted so far doesn't look anything like this. The logic is provided up front by the structure of the data, so it isn't necessary to complicate the delegate methods. All they have to do is select data, no other decisions are necessary.

But let's assume for a moment that there is indeed a reason to further customize in the delegate methods. Let's say that all of the text in the colors section should be red. No problem. But you still don't want to hard-code like this. What happens if tomorrow you decide that colors should be section 5? Then you have to change all of these statements.

There isn't really a good option for the array-of-arrays case, so this may be a good vote in favor of the dictionary approach. Rather than hard-coding the section number, I can be flexible according to the section key.

if ([key isEqualToString:@"Colors"])
{
   // Make them red
}
else
{
   // Make them black
}

Now you've got a condition that will trigger correctly regardless of the order of the data. And if today you are testing without colors, no problem. Drop the key, and this condition will never trigger.

Once you get comfortable with the basic concepts here, you may want to take a look at a post I made a long time ago: Taming Table Views. There, I show the structure of a custom model class that I use all of the time with sectioned table views. This would be used with the array-of-arrays approach, but instead -of-arrays, it would be -of-DisplaySections. It has a field for the header, a field for the letter index, a field for behind-the-scenes stuff if needed, and it has an array property for the contents. A couple months after I wrote that, I discovered that Apple has a similar class (actually a protocol) for working with CoreData stuff called NSFetchedResultsSectionInfo.

One last comment regarding searching. If all you do is take the code in these samples and apply them to your project from Part 2, then searching will not work. Keep in mind the way we've changed the structure. It used to be an array of strings. It is now an array of arrays of strings. So you will have to adapt the search routine to this new structure. It is along the same lines as what we've done above in the delegate methods, so you should be able to figure it out.

TableViewTutorial_Part3.zip

UITableView How-To: Part 2 - Search

2010-02-24T17:37:00.002-05:00

Part 1 | Part 3 | Part 4 | Part 5

If you have a lengthy list of data, you should provide the ability for your users to search through that data. Starting with OS 3.0, Apple made integrating search into table views easy enough that there really isn't a good reason not to include it.

This post is based heavily, if not entirely, on Apple's sample project called TableSearch.

UISearchDisplayController

The search UI that Apple provides is basically a table view with a search bar. They provide some pretty animations, such as sliding the search bar up to cover up the navigation bar (handy for maximizing available space, especially in landscape). The search table view is overlaid onto your existing view, so both your original table and the search table need data. The principles of delegate and data source as discussed in the last post still apply.

In addition to creating the controller itself, Apple also gave UIViewController a searchDisplayController property, which makes it easier to access. This obviously isn't populated by default, but be aware that it exists.

Data

Say you have a list of 10 items. The user performs a search, and only 2 items meet the criteria. Now think back to our datasource and delegate methods. We are answering a lot of questions about the table: how many sections, how many rows, what cell should be displayed (and what should the cell contain)? We still have to answer those questions, only now there are two tables involved. Even if there was only a single table, something would still have to be done with the data. There are two basic approaches you can take: 1) Remove items that don't match, or 2) Create a whole new list containing only items that do match. If you go with #1, you need some way of restoring the full list. So really, in either case, you are talking about 2 sources of data: the full list, and the search results. Since a separate table is involved for the search results, #2 probably makes more sense, and is what Apple shows in their demo.

Step Up To The Bar

We'll start with the easiest part of this project. Open up the view controller XIB in Interface Builder, and make sure you can see the table view. Find the Search Bar And Search Display Controller item in the library.

Do note that this is a separate choice from the standalone search bar. You can certainly roll your own solution using just the bar, but the controller is what makes the work relatively easy. So be sure to grab the one with the little orange circle.

In order to get the search bar to scroll with the table, we are going to add it as the table's header. Grab the library item, and drag to the upper portion of the table view. You should see a blue highlight, which is your confirmation that you will get the header.

A number of things happen automatically when you do this. Let's take a quick look at the object list:

Even though we didn't directly place it there, the Search Display Controller has been added. If we inspect the connections...

...we see a whole host of additions. The searchDisplayController property on the UIViewController has been populated. The necessary delegate and datasource connections have been made for the search controller, and the delegate has also been specified for the search bar itself. Not bad for one drag-n-drop operation. We are now done with IB, the rest is handled in code.

Changes to .h

Here is the end result, then I'll explain what's going on.

//  SampleViewController.h

#import <UIKit/UIKit.h>

@interface SampleViewController : UIViewController <UITableViewDataSource, UITableViewDelegate, UISearchDisplayDelegate, UISearchBarDelegate>
{
   UITableView *mainTableView;
	
   NSMutableArray *contentsList;
   NSMutableArray *searchResults;
   NSString *savedSearchTerm;
}

@property (nonatomic, retain) IBOutlet UITableView *mainTableView;
@property (nonatomic, retain) NSMutableArray *contentsList;
@property (nonatomic, retain) NSMutableArray *searchResults;
@property (nonatomic, copy) NSString *savedSearchTerm;

- (void)handleSearchForTerm:(NSString *)searchTerm;

@end

First, we conform to the UISearchDisplayDelegate and UISearchBarDelegate protocols. Same idea as what we did for the table view previously.

Next we declare a couple of new instance variables and properties. The searchResults array will hold items that match the search criteria. The savedSearchTerm is something that Apple shows in their sample, and they use it to restore the search when returning to this screen.

Finally, we declare a method that will do the grunt work of searching through the data.

Changes to .m

We'll start at the top and work our way down. First, synthesize properties and handle memory management duties.

@implementation SampleViewController

@synthesize mainTableView;
@synthesize contentsList;
@synthesize searchResults;
@synthesize savedSearchTerm;

- (void)dealloc
{
   [mainTableView release], mainTableView = nil;
   [contentsList release], contentsList = nil;
   [searchResults release], searchResults = nil;
   [savedSearchTerm release], savedSearchTerm = nil;
	
   [super dealloc];
}

- (void)viewDidUnload
{
   [super viewDidUnload];
	
   // Save the state of the search UI so that it can be restored if the view is re-created.
   [self setSavedSearchTerm:[[[self searchDisplayController] searchBar] text]];
	
   [self setSearchResults:nil];
}

That last bit is from Apple's sample. The counterpart is here:

- (void)viewDidLoad
{
   [super viewDidLoad];
	
   ...
   
   // Restore search term
   if ([self savedSearchTerm])
   {
      [[[self searchDisplayController] searchBar] setText:[self savedSearchTerm]];
   }
}

Saving/restoring the search criteria, nothing fancy. Then we get to the search routine itself:

- (void)handleSearchForTerm:(NSString *)searchTerm
{
   [self setSavedSearchTerm:searchTerm];
	
   if ([self searchResults] == nil)
   {
      NSMutableArray *array = [[NSMutableArray alloc] init];
      [self setSearchResults:array];
      [array release], array = nil;
   }
	
   [[self searchResults] removeAllObjects];
	
   if ([[self savedSearchTerm] length] != 0)
   {
      for (NSString *currentString in [self contentsList])
      {
         if ([currentString rangeOfString:searchTerm options:NSCaseInsensitiveSearch].location != NSNotFound)
         {
            [[self searchResults] addObject:currentString];
         }
      }
   }
}

First we store the search term. Then we lazily create the searchResults array if needed. Next we clear out any previous search results. Then we loop through our main data, find any matching items, and add them to the searchResults array.

This method could vary greatly depending on what kind of data you are working with, and how it is arranged. This particular implementation is based on an example in the Mark/LaMarche book.

Now we get to the fun part: the table datasource and delegate methods. We've discussed a bit already about the need to have 2 separate data lists, and pointed out that we will be dealing with 2 separate tables. However, we only have one set of delegate methods here in the controller. We could use a completely separate object, as mentioned in the previous post, but that's not really necessary. So, we need some way of determining which set of data to use. You might get away with using some kind of flag, say BOOL isCurrentlySearching or something along those lines. I have fought enough battles with the search display controller in attempting to do other tasks to know that this approach won't work. Thus, we'll go with the way Apple's sample shows, and that is to make decisions based on which table is asking for information. In hindsight, this is a really obvious approach, but I'm not always on the ball as quickly as I should be.

First, the number of rows:

- (NSInteger)tableView:(UITableView *)tableView
 numberOfRowsInSection:(NSInteger)section
{
   NSInteger rows;
	
   if (tableView == [[self searchDisplayController] searchResultsTableView])
      rows = [[self searchResults] count];
   else
      rows = [[self contentsList] count];
	
   return rows;
}

The important thing to realize here is that all of these table view delegate methods include the table view itself as a parameter. This allows you the means to identify which table is making the request. If you had a reason to design a view with multiple tables, this is exactly what you would do. If the table asking for info is the search table, we provide an answer based on the search list, otherwise we use our main list.

We do the exact same thing when providing a cell:

- (UITableViewCell *)tableView:(UITableView *)tableView
		 cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
   NSInteger row = [indexPath row];
   NSString *contentForThisRow = nil;
	
   if (tableView == [[self searchDisplayController] searchResultsTableView])
      contentForThisRow = [[self searchResults] objectAtIndex:row];
   else
      contentForThisRow = [[self contentsList] objectAtIndex:row];
	
   static NSString *CellIdentifier = @"CellIdentifier";
	
   UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
   if (cell == nil)
   {
      cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
   }
	
   [[cell textLabel] setText:contentForThisRow];
	
   return cell;
}

Constructing the cell itself doesn't need to change just because we're using a search table. The key thing is to make sure we're grabbing the right piece of information to populate that cell. "Green" might be at row 4 in our main list, but it could be at row 2 in the search results. Once again, we make a decision based on which table is asking, and grab data from the appropriate list.

I'm not really going into cell selection yet, but you would need to do something similar in tableView:didSelectRowAtIndexPath:. The index path can, and most likely will, be different depending on which table is being shown.

At last, we reach the part that makes this all work. We've been dealing with table delegate methods up to this point, but the search controller has delegate methods of its own. So we'll utilize a couple of those to make the actual search happen. First, to begin the search:

- (BOOL)searchDisplayController:(UISearchDisplayController *)controller 
shouldReloadTableForSearchString:(NSString *)searchString
{
   [self handleSearchForTerm:searchString];
    
   return YES;
}

And that's it. The documentation notes this is an optional method, and NOT implementing it will cause the search table to reload as the search term changes. So the only reason we're doing this is to define what logic should be performed in response to the search string. And this next part is also optional, but if you want to do any cleanup after the search, this is where you could do it:

- (void)searchDisplayControllerWillEndSearch:(UISearchDisplayController *)controller
{
   [self setSavedSearchTerm:nil];
	
   [[self mainTableView] reloadData];
}

We no longer need the search term to be saved, so get rid of it. And maybe it is appropriate to refresh the main table view.

That's pretty much all there is to it at a basic level. Obviously this is a simple app so far, but the search display controller handles a lot duties on its own. Here is the sample project for everything so far:

TableViewTutorial_Part2.zip

UITableView How-To: Part 1 - View Controller Setup

2010-01-27T00:03:00.002-05:00

Part 2 | Part 3 | Part 4 | Part 5

6 months ago, I was preparing for a semi-major restructuring of SlickShopper. My 1.0 had hard-coded sizes everywhere, but I wanted to support screen rotation, so something had to change. I was in the process of rebuilding things using Interface Builder when I made some key discoveries about UINavigationControllers (they have a toolbar property) and UITableViewControllers (they inherently support resizing due to rotation). I bailed on the IB stuff, and started over using table view controllers exclusively. Version 1.5 onward contains table view controllers exclusively. I patted myself on the back for so deftly having avoided IB.

Today, I'm long past my fear of IB, and I've mostly given up on pure table view controllers. I use IB as much as possible, and prefer to set everything up as a plain view controller. I enjoy the flexibility this provides. (Tip: Don't name your view controllers as SomethingTableViewController, because the 'Table' part becomes incorrect if you change your mind about implementation later) I encounter a number of people struggling with basic aspects of table views, so I'm going to pool together the techniques I've learned from books and Apple's sample programs.

This will be the first installment of several posts devoted to the creation of plain view controllers that feature a table view. Today I'm going to focus on basic setup of the view controller. Future installments will look at using IB-based table cells, how to implement a search bar, and any other useful things I think of along the way. Please feel free to post requests in the comments area. My intention is to be as step-by-step as necessary, but I will also attempt to include a sample project at the end of each post.

Initial Setup

I'm not really going to go into the various places this view controller could be used. Theoretically, it should be perfectly usable in a view-based app, a navigation-based app, tab-based app, etc. So, create a new project using whatever template you like. I'm going to use the navigation-based template, as I intend to show how to pass data to a sub-controller at some point in this series. But feel free to use whatever template you want, as the choice doesn't really impact what I'm going to do here.

After the project has been set up, create a new file.

Choose a UIViewController subclass, and hit the toggle to indicate that you want to use a XIB file.

I'm calling mine SampleViewController, you can call it whatever you want. The XIB checkbox is relatively new, so if you don't have it, simply create your own XIB file, and give it the same name. And then start downloading the newest version of Xcode.

We need to do work in all 3 files that were just created, but in order to avoid bouncing around I'm going to work in this order: .h -> .xib -> .m.

Prepare The Header

Your .h file should look like this:

#import <UIKit/UIKit.h>

@interface SampleViewController : UIViewController {

}

@end

Since this is a plain view controller, we need to add some information to it in order to work with a table view. The parts that we are about to add are included for free with table view controllers, hence the appeal. But it is easy enough to add manually, so here we go.

First, we need to adopt a couple of protocols. Table views are designed to be generic, and rely on other objects to provide customization. For our immediate use, customization mostly refers to providing content, but it can also apply to appearance. The necessary protocols are UITableViewDataSource, and UITableViewDelegate. Data source, as the name implies, provides the content. The delegate pattern is used throughout Cocoa, and indicates that one object will be doing work on behalf of another object. There are two protocols because they serve different needs, and if desired they could be distinct objects. We are already in a class that is perfectly capable of doing the work, but if you had a reason to do so, you could certainly make two more external classes to accomplish the same thing. For simplicity, generally speaking you'll just use your view controller. To indicate that your view controller can serve in these roles, add this to the .h file:

#import < UIKit/UIKit.h >

@interface SampleViewController : UIViewController <UITableViewDataSource, UITableViewDelegate>
{

}

@end

There are no required methods in UITableViewDelegate, but there are in UITableViewDataSource. So, if you build your project before we finish up, you will get some warning messages related to the absence of those required methods. You can ignore the warnings for now, but by the time we finish up, make sure the warnings are gone.

We are going to graphically place a table view into our main view in Interface Builder, just as if we were placing a button or a label. We will have a reason to talk to that table view object. The way to establish that line of communication is to declare IBOutlets here in the .h file. We need to declare a table view instance variable, and we'll communicate with it using a property, like this:

#import < UIKit/UIKit.h >

@interface SampleViewController : UIViewController <UITableViewDataSource, UITableViewDelegate>
{
   UITableView *mainTableView;
}

@property (nonatomic, retain) IBOutlet UITableView *mainTableView;

@end

You may have seen the "IBOutlet" tag on the first line, and you may have seen it on both lines. Apple's examples are shifting towards showing it only on the second line, so that's what I will do. Showing it in both places is not necessary.

I recommend that you not call it "tableView". It's probably not a huge deal necessarily, but the delegate methods will use "tableView" as a local variable name, so best to avoid the clash. Also, table view controllers automatically have a tableView property, so using a different name helps to reinforce that we aren't using a table view controller.

We're basically done now, but before we move on, let's take care of the structure that will hold our contents. I'm just going to use an array for now, as arrays work quite well with the way table views expect to receive information.

#import 

@interface SampleViewController : UIViewController <UITableViewDataSource, UITableViewDelegate>
{
   UITableView *mainTableView;
	
   NSMutableArray *contentsList;
}

@property (nonatomic, retain) IBOutlet UITableView *mainTableView;
@property (nonatomic, retain) NSMutableArray *contentsList;

@end

Lay Out The Interface

Open up the XIB file. We want the view to be capable of supporting landscape, so we need to change the resizing masks. Select the view, then hit Cmd-3 to bring up the size inspector. Toggle the masks as shown here so that the view is fully flexible, and go ahead and make the height 480 for good measure.

If you are unable to make these changes, hit Cmd-1, turn off any simulated UI elements like the status bar, then come back and try again. (Disclosure: I only figured that out just now while typing this up... I thought it was a bug. I've been deleting and re-creating the view for quite some time)

Drag a table view from the palette onto the view. It should automatically expand to fill the entire view.

The resizing masks should already be set, but go ahead and verify them for the table view just in case.

In order to talk to the table view, we need to use the IBOutlet that we declared in the .h. To do that, Right-click (Ctrl-click) on File's Owner, and drag to the table view. (I've resized the view for sake of screen capture here)

You should see the table view highlight, and you should see "Table View" appear in a little box at the lower right, thus confirming your selection. When you let go, a window will appear:

Select the name of the IBOutlet that was created in the .h file.

We're not quite done yet. Remember the data source and delegate from the .h file? That declaration simply published the fact that our view controller is willing to serve that role. But that alone does not mean that the table view knows who to talk to. There could be any number of conforming classes eligible, so we need to identify specifically which class(es) this table view will use.

Select the table view, and hit Cmd-2. At the top of the inspector are outlets for the delegate and dataSource. Select the circle next to each one, and drag to File's Owner (regular left-click drag).

So, the view controller is able to talk to the table view, the table view will request information from the view controller, and the whole thing is resizable. Thus concludes our trip to IB.

Implement

Now for the hard part. Most of what we will be doing in the .m file would be exactly the same or very similar if we were using a table view controller instead. Let's start at the top and work our way down.

First, synthesize the properties:

#import "SampleViewController.h"

@implementation SampleViewController

@synthesize mainTableView;
@synthesize contentsList;

Most examples show dealloc at the bottom, but I prefer to have it up top so I can quickly glance at the properties. Follow memory management rules and release the properties.

- (void)dealloc
{
   NSLog(@">>> Entering %s <<<", __PRETTY_FUNCTION__);
	
   [mainTableView release], mainTableView = nil;
   [contentsList release], contentsList = nil;
	
   [super dealloc];
	
   NSLog(@"<<< Leaving %s >>>", __PRETTY_FUNCTION__);
}

Somewhere we need to build the data that will appear in the table view. For a simple case like this, viewDidLoad will work just fine.

- (void)viewDidLoad
{
   NSLog(@">>> Entering %s <<<", __PRETTY_FUNCTION__);
	
   [super viewDidLoad];
	
   NSMutableArray *array = [[NSMutableArray alloc] initWithObjects:@"Red", @"Blue", @"Green", @"Black", @"Purple", nil];
   [self setContentsList:array];
   [array release], array = nil;
	
   NSLog(@"<<< Leaving %s >>>", __PRETTY_FUNCTION__);
}

Build an array, stick it into the property, then release it.

For this example, we aren't too worried about the displayed contents being incorrect. But in a real app, if activity in another view controller could cause the contents here to change, we want to make sure that the user sees the updated information. To make the table refresh every time the view is displayed, we'll use viewWillAppear.

- (void)viewWillAppear:(BOOL)animated
{
   NSLog(@">>> Entering %s <<<", __PRETTY_FUNCTION__);
	
   [super viewWillAppear:animated];
	
   [[self mainTableView] reloadData];
	
   NSLog(@"<<< Leaving %s >>>", __PRETTY_FUNCTION__);
}

I mentioned before that UITableViewDataSource has some required methods, so let's get those out of the way. First, the table is going to ask the data source how many rows are involved. The answer should be based on our array, and we use this method to respond to the table's question:

- (NSInteger)tableView:(UITableView *)tableView
 numberOfRowsInSection:(NSInteger)section
{
   NSLog(@">>> Entering %s <<<", __PRETTY_FUNCTION__);
	
   NSInteger rows = [[self contentsList] count];
	
   NSLog(@"rows is: %d", rows);
   NSLog(@"<<< Leaving %s >>>", __PRETTY_FUNCTION__);
   return rows;
}

Note the section variable that we aren't using here. So far, we only have one section, so there isn't a need to worry about it. In a future post, I'll show how to do a multi-section table, at which point this method gets a bit more involved.

Next, the table is going to ask for a view to display in each row. Apple has provided a UIView subclass called UITableViewCell that is pre-configured for many common table needs. You create a cell, give it some content, and then give that cell to the table. Repeat as needed for each row. A lot of explanation is going to be needed here, so let's jump to the end result, and I'll discuss afterwards...

- (UITableViewCell *)tableView:(UITableView *)tableView
		 cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
   NSLog(@">>> Entering %s <<<", __PRETTY_FUNCTION__);
	
   NSString *contentForThisRow = [[self contentsList] objectAtIndex:[indexPath row]];
	
   static NSString *CellIdentifier = @"CellIdentifier";
	
   UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
   if (cell == nil)
   {
      cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
      // Do anything that should be the same on EACH cell here.  Fonts, colors, etc.
   }
	
   // Do anything that COULD be different on each cell here.  Text, images, etc.
   [[cell textLabel] setText:contentForThisRow];
	
   NSLog(@"<<< Leaving %s >>>", __PRETTY_FUNCTION__);
   return cell;
}

In summary:

Grab the object that has (or in this case, is) the information we want to display for this row

Ask the table view if any cells are available for recycling.

If not, create a new cell

Specify the content for the cell

I'll talk more about cell customization at a later date, but for now please note the comments I added regarding where you should customize different elements of the cell.

First, a little bit about the NSIndexPath. If you were trying to describe the location of a point on a grid, you would most likely use (X,Y) coordinates. The index path provides a way of describing a location within the table, but instead of (X,Y) coordinates, it is using (section, row) coordinates. These are numbered in the exact same way an array is, so the first item is 0, the second item is 1, and so on. We only have one section, so we will only be dealing with section 0 for now. Within our only section, we are providing five pieces of information, so we'll be talking about row 0, row 1,....up to row 4.

So this method begins with the table asking the question "Hey, I'm now at the first section and the second row... what should I show here?" We need to figure out which row is being requested, and we do that by asking the indexPath for its row value. [indexPath row] (later we'll do the same thing to get a section value). Assuming we are building the table up from scratch, we should be dealing with the first row, so row 0. Now I know which piece of information I want from the array: the first item, so the item at index 0. For convenience I assign that to a local variable.

Next I declare a string variable. I don't actually know what "static" technically means, other than the obviously implied "this does not change". I suppose you could #define a constant instead. The purpose of this string will be to allow the table view to identify cells in a queue that it will create.

The table's cell queue exists because flinging your way through a list of data needs to happen as fast as possible, but building a cell from scratch can be expensive from a performance standpoint. If we were providing 1000 strings for this table, we don't want to actually create 1000 cells. We only need to create enough to cover the visible screen, plus a couple extra for buffer, and then we can reuse those cells over and over again. As a cell slides off the top of the screen, it goes into the queue, only to reappear at the bottom of the screen with new content. We don't want to build new cells if it can be avoided.

Thus, the next thing we do is ask the table if any cells are available for reuse, here:

UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];

We use the string identifier, because there could be multiple kinds of cells being stored, so we want to make sure we get the right kind. If a cell is available, it will be provided to the cell variable. However, if there aren't any cells available (as would be the case when starting from scratch), the return from this call is nil. So, we find out if we actually have a cell right now:

if (cell == nil)
{
   cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
   // Do anything that should be the same on EACH cell here.  Fonts, colors, etc.
}

If there is a cell, this part doesn't happen. If there isn't a cell, this part will build a new one.

Lastly, we provide our content:

// Do anything that COULD be different on each cell here.  Text, images, etc.
[[cell textLabel] setText:contentForThisRow];

Standard cells have a label property, and I'm setting the text using our content string. I'm going to again emphasize the comments I've put in there. When you get to this point of the method, you have 2 possibilities: 1) The cell is brand new, or 2) The cell has been recycled. Recycled cells will most likely still have their old content, so you cannot make assumptions about the state of the cell you are working with. It could be pristine, it could be dirty. So this area of the method MUST make sure the end result is correct. If you alternate font colors between red and green, then you should have an if/else statement here that makes the font red OR makes the font green. You cannot assuming the incoming color is correct.

That covers the required methods for the data source. There are many, many other optional methods - from dataSource and from delegate - for performing a variety of tasks, but for now I just want to draw attention to one of them.

If you build-and-run your app, you should see the list of colors in your table. If you tap a row, it will stay highlighted. Let's turn that off. This method is how the table says "Hey, I was touched here... what do you want me to do about it?"

- (void)tableView:(UITableView *)tableView
didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
   NSLog(@">>> Entering %s <<<", __PRETTY_FUNCTION__);
	
   [tableView deselectRowAtIndexPath:indexPath animated:YES];
	
   NSLog(@"<<< Leaving %s >>>", __PRETTY_FUNCTION__);
}

We will do a lot more with this method later, but for now we'll simply deselect the row.

And thus concludes this edition of table talk. Tune in, uh... later... for the next installment. In the meantime, here is the sample project for this stage of the exercise.

TableViewTutorial_Part1.zip

Goals and Achievements

2009-11-20T02:00:00.000-05:00

Today marks the 1-year anniversary of the loss of my job. Well, technically, I lost it on Nov 21, 2008, but it was the Friday before Thanksgiving, so this is close enough. A quick glance back through relevant blog posts:

A few days after, no clue what I was going to do.
A month later, still toying with going back to engineering, just starting to mess with iPhone programming.
A couple months after that, bailed on engineering, unsure of where iPhone stuff will go.
Three months later, iPhone app available for sale.

Since I'm forging my way into a brand new world, I didn't really have any idea of what to expect. But I did have some rough goals in mind, so let's take a quick look at how I did.

In early March, I decided to join Apple's iPhone Developer program. The standard program costs $99 + tax, and is required to test programs on an iPhone, and sell apps on the store. My app, SlickShopper, was coming along well enough I felt this to be a prudent step. I had no idea what to expect in terms of sales, but figured I had mostly missed the gold rush that happened in the early days of iPhone apps. So my first goal was simple: recover my developer fee. With tax, that was $105.44. My app went on sale May 31, and my sales data says I hit $106.57 on June 27, so four weeks.

And I was thrilled!

Of course developers don't get this money right away. Apple pays out in certain minimums, and for a previous time period. So I would not actually get my first check from Apple until July 30. And due to the way Apple pays out for various regions, that first check was for only $86.10. This car is going to Vegas, baybee!

The next couple of goals are a bit intermixed, so bear with me for a moment. This will make sense in a few paragraphs.

Towards the end of March, I made the decision to attend Apple's World Wide Developer Conference (WWDC). This was something of a gamble at the time, as I still had no idea if iPhone development was going to be my future, and I was still quite a ways off from having an app ready to sell. I decided to go for it. In hindsight, worth every penny, and definitely put me on the path to where I am today. But, it was a big cost nonetheless. The conference itself isn't cheap, plus travel, hotel, and so on. So the next goal was to recover that cost.

Now it is important to state that my accomplishment of this goal is NOT due to sales of my app. Far from it; in fact to date the app has only brought in maybe 1/3 of that cost. I have supplemented that income in other ways. However, after being negative for most of the year, I did finally reach break-even in the first week of September.

Again, thrilled!

That supplemental income? Strange/funny story.

You would be hard-pressed to perform a Google search for anything iPhone development-related and not turn up a link on iPhone Dev SDK. I've found many answers there, and continue to do so. Sometime in July, I came to the realization that I actually had enough knowledge to answer questions for other people. I made an account, and soon was burning a significant amount of time responding to posts. I enjoyed doing it; it reminded me of the time I used to answer I-DEAS questions on the ICCON mailing list. And I loved being in a teaching mode. I seem to do my best learning when I'm teaching other people. So with a decent nudge from WWDC, time spent on iPDSDK really helped to refine and solidify my understanding of concepts I've been struggling with for a couple years.

One day, a clearly frustrated guy was lamenting that he could not find good answers. He had even offered to pay people $10/question, and didn't get good results. I jokingly responded that I'd be happy to answer questions for $10, not really expecting anything. I'd been answering lots and lots of questions for free, and probably would have in this case, too. But hey, if he wants to offer, I'll accept.

We emailed back and forth a bit, and he was able to look at my post history and determine that I had a decent chance of knowing what I was talking about. He sent me his code, I spent a couple of hours going over it and making notes, recommending better techniques, pointing out where problems were and how to fix them. I returned his code, expecting that to be the last I ever heard from him. A couple days went by, I hadn't heard anything, so I assumed my initial assumption was correct.

But wait! An email. He's having trouble sending me a PayPal payment. Uh huh. Sure. But he is not in the US, so let's go see what options are in PayPal... huh. Sure enough. Toggle that, change that. Ok buddy, try again. Another day or two goes by. Yeah, that's what I thought.

But wait! Another email. This time with a screen shot of his attempt to send me PayPal. And for $20! Back to PayPal options. I now accept money from anyone, anywhere, for any reason. The next day, I get money.

Let's back up a moment. I developed SlickShopper for me. I wanted it. It was my first app, my practice app, my test of "can I actually do this?" If other people are willing to buy it, great, but this is for me. But, I was not ignorant of the fact that it was also my programming resume. I don't know that I had any specific expectations, but in the back of my mind I thought it would be nice if this app would help me to land a new job. I guess I was thinking more in terms of a regular 9-5 job, but whatever.

So, someone else - excluding SlickShopper customers - paid me money for my efforts. I received that first payment on July 29th, beating my first check from Apple by a single day. I received the last severance check from my job in February, so my period of zero income ended at five months. It certainly wasn't Real Money yet, but anything is better than zero.

Things continued like this for several weeks. He'd ask questions, I'd answer, he'd send me money. It took me a while to grasp what I had stumbled into. In the middle of this, other people started coming to me looking for similar arrangements. In some cases, I'd already been helping someone in a public thread, and they'd decide they were willing to pay for individual attention. In other cases, people would browse the forums, land on some of my posts, decide I sounded knowledgeable, and ask if I could help.

Eventually I would take a more proactive role towards landing jobs. There is a jobs forum, and people will frequently post that they are looking for developers. Most of the ones I went after would turn out to be beyond my skill level, and I'd have to decline. But I'd get smaller ones, and gradually built up a small pool of regular clients. Now I'm doing everything from basic support to full-bore application development.

At this point, I'm happy to report that BriTer Ideas LLC has experienced 5 consecutive months of record revenue, and signs are looking good for the future.

I found my new job.

The ratio of contract services income : SlickShopper sales is so skewed it isn't even funny. I can make more in an hour doing work for other people than SlickShopper will make in a week. I actually have started on version 2, but I'm so busy with other things (read: actually making money) that I don't honestly know when I'll have time to finish it. And I feel bad, too, because the new features are things that I want but didn't know how to do for version 1.

I still have a ways to go in order to regain my former glory. I'm hovering at just under half of what my former salary was, so I'd like to find ways of bringing in more income. Exceeding my former salary is my next main goal. I feel like the potential is there, I just need to put myself into position to take advantage of it. Also, like most small/home business owners, I need to add on the stress of being concerned about from where the next job will come. That will be less of a concern once my wife finds a new job, but for the moment it's nerve-wracking.

Otherwise, I'm having a blast. I can't remember the last time I had this much fun in engineering, if I even ever did. I literally do work 7 days a week. I won't pretend that I'm 100% productive each day, but I've been hitting it hard for months and don't feel like I'm forcing myself to do it.

A year ago, I said:

"One way or another, 2009 should be an interesting year."

I was right. And I'm really looking forward to 2010.

Subversion Basics In Xcode

2009-09-12T17:03:00.001-04:00

My last post discussed how to set up Xcode to use Subversion via Beanstalk. Now let's take a look at some common activities.

Editing Files

This is easy enough... make some changes to a file, then save it.

The SCM column will provide status information when appropriate for each file. In this case, 'M' is shown, indicating that the file has been modified. You could see any number of M's, depending on how many files you change between commits (more on commit in a moment). See the Apple documentation for a complete list of possible symbols.

Adding Files

Whether you create a new file inside your project, or add existing files from elsewhere, the end result is the same:

The SCM column will display a '?', and as seen from the help pop-up, that means the status is unknown. This indicates that the file is not yet in the repository - it is in your local project only.

To indicate that you would like to add these files to your repository, right-click on any appropriate files, and choose 'Add to Repository'.

The '?' will change to an 'A'.

This indicates that the file will be added to the repository during the next commit.

Committing Changes

I am more accustomed to "check in" terminology, but a commit is exactly the same thing. Local changes will be uploaded to the repository.

Go to the SCM menu, and choose 'Commit Entire Project...'.

I believe you can do commits on individual files, but I haven't had much of a reason to do so. I pretty much always commit the entire project.

Xcode will present a dialog box allowing you to enter notes related to this commit.

Once you are done, the M's and A's should all be gone, indicating the files are now in the repository.

How often you commit is up to you. I personally attempt to do so at minimum nightly for any files that I work on. If I achieve some major milestone earlier in the day, I'll send up an extra commit.

Updating Files

If other people share your repository, or if you access it from multiple computers, you will probably see this at some point:

The U indicates that the file in the repository is newer than your local file, and it needs to be updated. As a convenience, Xcode will repeat the status indicator on the group folder, just in case you are not displaying all files at the moment.

You can either right-click on individual files and update...

...or you can update the entire project.

And this concludes what I know about Subversion. Hopefully these two posts will get you off to a good start. Enjoy.

Getting Started Using Beanstalk With Xcode

2009-09-12T01:08:00.001-04:00

I have lived in a data-managed world for years. I-DEAS has long distinguished itself as one of, if not THE, only CAD programs with an integrated data manager. So I am quite comfortable with the concepts of access control, version control, and pretty much any other -controls that go along with data management.

When I first got started coding, I quickly realized that it sure would be nice to have the backups that go along with regular check-ins into a managed database. I did some poking around, and it sounded like Subversion was a pretty safe way to go. But as far as actually implementing it, well, that sounded like a bigger hurdle than I was willing to tackle at the time.

I don't remember the specifics, but I was doing some Googling for hosted Subversion services, and landed on Beanstalk. I knew nearly nothing about it, and don't know much more today, but most importantly they offer a freebie account. It's a nice way to try out Subversion; it doesn't cost anything other than time.

The question then became how do I get the work I've already done into Beanstalk, and then how do I use it? If there is a handy guide out there, I didn't find it. So allow me to present my attempt at providing that guide.

I should preface this by saying that beyond initial setup, I don't know a whole about Subversion. I'm only working by myself; I'm not trying to coordinate efforts with a whole team of people. I don't know how to branch. I really only use it to commit my changes regularly, and if necessary revert back to an older version of something.

Preamble out of the way, let's begin...

Repository Configuration

Once you have created your Beanstalk account, using your web browser go to the Repositories tab.

Click on the desired repository

Then copy your repository URL.

You are now finished with your web browser, as pretty much everything else is done in Xcode. So, fire it up.

You will be using the SCM menu a lot, so find it now, and select Configure SCM Repositories.

This takes you into Xcode's preferences under the SCM tab.

Here you can see that I have several repositories already. Click the + button at the bottom of the Repositories list to create a new one. Keep your eye on the green dot that says 'Authenticated', as that will be important.

Xcode will prompt you for a name for this repository, so call it whatever you want. This does not need to be the same name as your project, but you will probably want it to at least be related. Select 'Subversion' for the SCM System.

We now have a new blank repository.

Notice that our green dot is no longer a green dot. By the time we're done, it should be, and that's the indication that everything is set up correctly.

If that Beanstalk URL isn't in your clipboard anymore, go back and copy it. Paste it into the URL field. Any time you make a change to a text field here, tab out of it to see the result.

Notice that the scheme, host, and path were automatically determined from the URL. And our green dot is now an angry red dot. Fear not, you merely need to provide your username and password. Don't forget to hit tab after each text field change.

Once your information is correct, you should have a green dot. If not, verify your login and password.

Initial Upload

At this point, Xcode can talk to Beanstalk. However, there aren't any files in there yet to talk to. You can exit the Preferences panel, and go back up to the SCM menu and hit Repositories.

You'll see a listing of your repositories, and if you select one, you'll see the files and folders contained therein. This is looking at Beanstalk; these are not local files. The existing folders - branches, tags, trunk - I believe are relatively standard for Subversion.

We are interested in the trunk folder, so select that.

To add your project, hit the 'Import' button.

Select the folder that contains your project.

If you want, enter in a comment indicating what you are doing. But since this is the first time you are doing anything, it should probably be pretty easy to figure out later.

After you hit 'Import', Xcode will begin uploading your local files into Beanstalk.

You can click around to verify that all of your files are there.

Initial Download

I don't know if this next part is actually required, or if you can continue working with your local files. For the sake of this blog post, we're going to assume it is required. If you poke around in Subversion documentation, you may see the phrase "Working Copy". This refers to the local files on your hard drive that you have retrieved from Subversion. So, we need to create that working copy.

In the Repositories window, select the same folder that we just uploaded. Then hit the 'Checkout' button.

Xcode will prompt you for a download location. I personally use my Dropbox folder for an additional layer of protection.

When the download is complete, Xcode will provide an option to open that project. Go ahead and do so, because we aren't quite done yet.

Final Setup

Once the project is open, right-click on Groups & Files, and turn on the SCM option.

This will reveal a new column that displays status information about the files.

There isn't much to see yet, since we haven't done anything. But the key thing to notice is that the SCM icon has an X through it. I don't really know why, but there is one thing left to do. Select the project file, then right-click, Get Info.

This will take you to the project info panel. I'm taking these screenshots using Xcode 3.2, and this panel did see some slight modifications, but the core element we're looking for is still there in previous versions, you just may have to poke around for it a bit.

Select the 'General' tab.

Then hit the 'Configure Roots & SCM' button.

Make sure the pull-down menu says Subversion. In the Repository column, hit the pull-down there to select your repository. The name will most likely have "Recommended" next to it. I honestly don't know why this step is necessary; Xcode seems to know this stuff already, so you'd think it could set itself up. Oh well.

Once that is done, the X should disappear from the column's icon.

At last we are set up!

Come back later for part 2, at which point I'll discuss some usage basics.

Taming Table Views

2009-09-10T00:45:00.000-04:00

This is the table view from one of the primary screens in SlickShopper.

It may not look like much, but there is actually a lot going on here. The key aspects I want to talk about now are the sections headers and the index. More specifically, what the presence of those items means as far as preparing the data that is to be shown in the table.

Naturally I have a complete list - an array - of all grocery items. However, as soon as I made the decision that that I wanted section headers, I could no longer use that list directly. Well, that may not be technically true, but from a "reasonable effort" standpoint, true enough. In order to display section headers, the table view data has to be broken up into groups, with each group corresponding to a section in the table.

The number of sections is defined using the table view data source method:

– numberOfSectionsInTableView:

I've got "selected" and "not selected", so all I need to return here is 2. So far so good. I need 2 arrays, one for selected, one for not selected, and I need to run through my master list and add each grocery item to the appropriate array. The remaining tableview delegate methods are straightforward; needing only to ping each array for information. Easy.

...until I decided that having the index on the side would be a really useful thing. Why does that matter? Well, the first clue is in the method name that provides the index:

- sectionIndexTitlesForTableView:

Index titles for a section. Well, at the moment I only have 2 sections, but I'm going to want potentially almost 30 items to appear in the index. Although you don't technically have to have a 1:1 section:index title ratio, it's a lot easier if you do. When tapping the letter 'G' in the index, you want to navigate to items starting with the letter G, and that is most easily accomplished by grouping those items together, and having that be a section in the table.

So now I'm looking at a whole mess of arrays: one for items starting with A, one for B, and so on. Not a problem, I can add each of those separate arrays to one main array, and go from there. Oh, but if no items start with a particular letter - say, Q - I don't want to show the letter in the index. My array contains 24 arrays, and I'm looking at the 6th one, so which letter should appear in the index? F? What if there were no E's... it could be G. Ugh. Now I need another array to keep track of index letters. I suppose I could grab grocery items and extract their first letter on the fly, but that has some issues (ex: I want to display "#" instead of "1", "2", etc). I've already got my array of arrays to provide the contents, now I have another array for the letters, but I think we're almo... aw, crap... The section headers! The screen shot above is only showing 2 headers, but there are indeed many sections involved. And I have a different view of this same information that uses many headers. Now I need some means of keeping track of the headers - maybe another array? I've got dozens of arrays now, each keeping track of different-but-related pieces of information... stop the insanity!

After spending way too much effort doing exactly that, I finally hit upon what I consider to be a better way: a custom container object. Something that can correlate to the sections in a table, and contain the necessary pieces of information all in one place: the section contents, the section header, the index letter, and for bonus points some handy methods for messing with all of that stuff. So, I now present what I call a DisplaySection:

//  DisplaySection.h
//  SlickShopper
//
//  Created by Brian Slick on 4/5/09.
//  Copyright 2009 BriTer Ideas LLC. All rights reserved.
#import Foundation/Foundation.h  (Yeah, I know)
@interface DisplaySection : NSObject
{
   NSString *myName;
   NSString *mySectionHeader;
   NSString *mySectionIndexLetter;
   NSMutableArray *myContents;
}
// A few sample methods...
- (void)addGroceryItem:(GroceryItem *)item;
- (NSUInteger)countOfGroceryItems;
- (GroceryItem *)groceryItemAtIndex:(NSUInteger)index;
@end

There are a lot of ways to tailor this to individual liking. If you like _instanceVariable names, do that. If you want to make this generic with things like addObject, or countOfContents, do that. If you want to access the properties directly without going through wordy method names, do that. Those are implementation details that do not affect the core concept.

The point here is that everything I want to know about my section is here in one place: contents, section header, section index letter. On top of that, I found it necessary to add an extra property for behind-the-scenes purposes.

How does this work? Well, I don't want to give away all of the family jewels, but in essence most of the sorting work that I described before still has to happen. I still have to iterate through my master list of grocery items. I still have to have a place to put each item, so that means creating a bunch of these DisplaySections, and filling them with appropriate content. And I want these to be presented nicely for the table, so that means putting a bunch of these DisplaySections into an array.

So what's really different? For one thing, I've moved all appropriate logic into the sorting routine. Take the section header, for example. Before, I was defining that in the table delegate, making decisions based on the index path. If section is 0, header is this, else if section is 1, header is that, and so on. Those decisions still have to be made, but I no longer do that in the delegate methods. As I iterate through the main array, I make those decisions at that time, and react accordingly. This is my first DisplaySection, so the header property should be set to this. This DisplaySection will contain all items starting with H, so set the index letter accordingly. All of the logic is in one place. If I want to change behaviors, that's where I go.

A side effect of this is that it simplifies the delegate methods tremendously. Here is how the header gets returned:

- (NSString *)tableView:(UITableView *)tableView
titleForHeaderInSection:(NSInteger)section
{
   return [[[DataController sharedDataController] displaySectionAtIndex:section] sectionHeader];
}

(I'm using a singleton object for the data controller... go here for more info)

I can assure you that this was more than one line of code previously. Now I ask the sorted array for the appropriate DisplaySection, and I grab the needed piece of information. The logic is removed from the delegate, and it merely does what it is supposed to do - relay information from the model to the view.

For the index letters, I elected to spin my own array in the delegate method. I really wish Apple had gone with more of a:

- (NSString *)tableView:indexTitleForSection:

approach, but they didn't. So I just loop over each DisplaySection, grab the index letter property, and build a new array in:

- (NSArray *)sectionIndexTitlesForTableView:

There is probably a better way, but this covers my needs. I'm pretty sure that this method is only hit once during a reloadData, so I don't consider it much of a performance hit.

How do I handle the case of nothing-starts-with-that-letter? That's part of the sorting routine. I actually go ahead and build the maximum possible number of DisplaySections up front, and add them to the array. Then I loop through the grocery items, and add them to the appropriate DisplaySection. After that is done, I loop back through the DisplaySections, and remove any that are empty.

Once I had this technique down, it was a lot easier for me to go back and add the index to several more of my views. So I'm very happy with this approach, but I'm always interested in suggestions. Have a better way?

It's NSLog, NSLog...

2009-08-17T15:07:00.003-04:00

What rolls downstairs, alone or in pairs, and over your neighbor's dog?
What's great for a snack, and fits on your back? It's NSLog, NSLog, NSLog!

I do crazy amounts of logging in my programs. This has proven to be an invaluable tool for me as I learn how Cocoa/Cocoa Touch works. Being relatively new to Object-Oriented Programming, it has taken me a while to wrap my head around when methods get called, in what order, and so on. So I borrowed a technique I was using in the I-DEAS macro language in order to help me figure out what was happening:

NSLog(@"Now entering viewDidLoad in RootViewController");
// Do stuff
NSLog(@"Now leaving viewDidLoad in RootViewController");

The console will then present a nice history of what the program did. This is useful, especially for things like UITableView delegate methods, where simply putting the view on the screen can cause several methods to be triggered. Read back through the console, see which methods were called, note the order, learn how the system works.

I do both the 'entering' and 'leaving' part because simply putting the 'entering' one does not provide enough information, especially when trying to track down where a crash happened. A given method could branch out into any number of other methods, so without knowing when a method has finished, you don't really know which one crashed. You can make some partial assumptions by figuring out if expected methods were NOT called, but still, you don't get the complete picture. By adding the 'leaving' message, it's a matter of figuring out which method(s) started, but didn't finish.

The information provided by this technique is incredibly valuable, but it has (at least) two key drawbacks:

1. The log messages themselves must be customized for each method, in each class. You can get away with some copy-n-pasting, but you are going to have to retype something every single time. That's annoying, time consuming, and a good source for mistakes (if you forget to change the information).

2. The performance hit from displaying this many log messages is considerable, particularly on the iPhone. It's useful for debugging, but is not something you want to do for shipping code.

It's NSLog, it's NSLog... It's big, it's heavy, it's wood.
It's NSLog, it's NSLog, it's better than bad, it's good!

I was doing this - what I'll call "the hard way" - for while before I decided there had to be an easier way. I did some Googling, and landed on this page. There are several good tips there, but this is the important part:

NSLog(@"%s", __PRETTY_FUNCTION__);
Will print a log line similar to:
*2008-12-12 09:22:49.552 Healthcheck[79016:20b] -[HealthcheckAppDelegate applicationDidFinishLaunching:]*

Perfect. That is copy-paste-able, no additional typing required. However, I still want my entering/leaving deal, so adapting this to my preferred style:

NSLog(@">>> Entering %s <<<", __PRETTY_FUNCTION__);
// Do stuff
NSLog(@"<<< Leaving %s >>>", __PRETTY_FUNCTION__);

And I do this everywhere. Every single method. I'm not kidding.

Experienced programmers reading this are thinking I'm pretty ridiculous right now. But I need the extra help. And I highly, highly recommend this for people just getting started. I've been answering a lot of questions on iPhone Dev SDK, and am amazed at the number of people who know nothing about logging. And I don't mean noobs, I mean people with apps on the store! I'd probably still be floundering around with my very first bug without liberal use of logging. So, my hat's off to people who can get by without, but I have to assume that life could be easier for them.

Everyone wants a NSLog
You're gonna love it, NSLog

So that addressed the first problem, but what about the second? Fortunately, I got an answer to that without really even asking the question. After finding the pretty function thing, and posting on Twitter about how awesome that is, Danilo Campos was kind enough to make an off-hand remark that I should disable my log messages before submitting my app to the store. I had no idea how to do that, so with a couple of generous emails, he got me squared away. So full credit goes to him for this technique.

First, your program should have a *.pch file in it somewhere, named something like <YourAppName>_Prefix.pch. In my case, this file is SlickShopper_Prefix.pch. Add the following to that file:

#ifdef DCBLOCKNSLOGSTATEMENTS
#define NSLog(format, ...)
#else
#define NSLog(format, ...) NSLog(format, ## __VA_ARGS__)
#endif

The 'DC' part is for Danilo Campos, so if you want to change that, you can. I've decided to leave it alone, along with a commented note giving him credit. Now I won't claim to totally understand what this says, but it looks like if DCBLOCKNSLOGSTATEMENTS is defined, do something to NSLog statements, if not, do something else. In this case, the 'do something' part is to make the NSLog statements not do anything, and the 'do something else' case is leave them alone. So that's the easy part. The harder part is getting this to work.

What you need to do now is mess with the settings in your build configurations panel. To do this, select your project, and hit the Info button, like so:

Next, go to the 'Build' tab, select the "Release" configuration, and do a search for "preprocessor". Ex:

You are looking for the ones listed under "GCC 4.2 - Preprocessing" - the "Preprocessor Macros" one and the "Preprocessor Macros Not Used In Precompiler" one. I occasionally cannot find these items. The solution seems to be to go to the 'General' tab. There is a pull-down menu next to "Base SDK for All Configurations". Set that to "iPhone Simulator 3.0", and then try searching again.

It is very important that you select the Release configuration. Do not do this in Debug. We're about to kill NSLog statements; we want those in Debug.

Now, double-click in the 'Value' column field next to Preprocessor Macros. A sheet will slide in.

Click the plus button to add a new value.

Paste in "DCBLOCKNSLOGSTATEMENTS" (or whatever you called it).

Hit OK...

...and then do the same thing for the second item.

And that's it. Just as a quick check, flip over to the Debug configuration:

You do NOT want to see the items we just added here.

If you have additional configurations already, say one for beta-testing and another for App Store submission, you will probably want to repeat these steps for those configurations as well.

Now test it out. Build-and-go with Debug, and observe your log messages. Do it again with Release, and observe the lack of log messages, and the snappier performance.

Next, head over to Danilo's web site and buy some of his apps as a thank you for making this technique known. And uh, if you want to buy mine for typing this up, well that'd be nice, too.

Have a better way? Let me know in the comments.

Everyone wants a NSLog. You're gonna love it, NSLog
Come on and get your NSLog. Everyone needs a NSLog
NSLog NSLog NSLog!

Now Presenting... My iPhone Presentations

2009-07-20T11:58:00.001-04:00

The Mobile Mini-Conference has come and gone. I was not told whether Awesome Inc would be providing the presentations after the fact, so I'll just short-circuit the process and make mine available now. Here you go:

iPhone Development Resources, Tips, and Tricks (~7MB PDF)

UITableView Overview (~1MB PDF)

Feel free to contact me with any further questions. Contact info is at the end of each presentation.

Now Presenting... Me

2009-07-12T00:41:00.001-04:00

Awesome Inc is hosting what they are calling Mobile Mini-Conference at their facility in Lexington, KY on Saturday, July 18th. This is ostensibly a generic mobile device conference, but as the schedule demonstrates there will be a particular focus on the iPhone. Here is a fancy badge:

I have been invited to speak, and will be giving two presentations. They are:

UITableView Overview

iPhone Development Resources, Tips, and Tricks

I hadn't even started SlickShopper 6 months ago, so if you had told me then that I'd be giving iPhone presentations now, I'd have thought and said you were crazy. But here we go. It's tough to do much justice to any development topic in 30 minutes, but I think my presentations will be worthwhile.

I'm not really nervous, per se, as I've done plenty of presentations before. However, this will be the first in a long time where I'm presenting on a topic where I don't have a solid and lengthy background. I'm also accustomed to practicing my presentations on my coworkers, but I don't have any of those at the moment. I'll do fine on the speaking part, but I'm not looking forward to fielding questions. Whenever I talk about I-DEAS, I'm among, if not THE, most knowledgeable subject experts in the room. I'll be shocked if that is the case with iPhone development, and a couple of well-placed questions could shatter the illusion that I know what I'm talking about. But, this is a brand new conference, so I don't really know what to expect.

So at any rate, if you are within a reasonable drive of Lexington and have any interest in iPhone development, come check us out.

Rethinking The Problem

2009-07-02T18:30:00.000-04:00

I believe this is officially the first of what will hopefully be many technical posts about my iPhone program SlickShopper. I'm just about to release a semi-major update, and a couple of revelations I had along the way are, I feel, deserving of some attention.

The Reason

SlickShopper doesn't break any new ground in the area of user interface. It is a simple, table-driven interface that uses built-in widgets almost everywhere. But the actual table cell - the row of information that is displayed - is a key area where I needed to provide something a little beyond what Apple includes out of the box. Here is a sample that is typical of my three main list views:

It's not super fancy, but for sake of this discussion, the important thing to notice is the number of pieces of information. There is the 1) description, 2) quantity, 3) cost, and 4) checkbox. So far, so good.

I am a big believer of options in software. As a user, I generally want options, and as a developer, if two reasonable people can see two reasonable ways of doing something, then if possible I'd like to support both people. And I carried this philosophy into this program. Except for the description, each other piece of information can be disabled. If you don't care about costs or quantities, you can turn them off. I personally can't stand having the checkboxes there (they are great looking; don't get me wrong... but I don't like having the second touch zone that they provide), so I turn those off, too.

The more math-oriented readers might already see the factorial that is forming here. I have 3 items with different display possibilities, so right now I have 3! = 3x2x1 = 6 variations. But I'm not done yet. I do have one display mode where I need to show the checkboxes, even if the user has turned them off. I need them for visual distinction between selected and not-selected, but I just want them for display; I don't want the second touch zone. So add one more option, and now I'm at 4! = 4x3x2x1 = 24 possibilities. It actually isn't this bad; due to some overlap of the options, it turns out that I really only have 12 scenarios to handle. For example:
checkboxes ON, quantity OFF, price ON; or
checkboxes ON, quantity ON, price OFF
...and so on. The logic for determining which scenario I'm in is going to be convoluted pretty much no matter what, but what about displaying of the actual cells?

The First Attempt

This would have been much simpler without the checkboxes. I've had enough trouble getting my head wrapped around the use of Interface Builder for iPhone development as is, but I couldn't find any examples that included a button in the cell. The only examples I could find built the cells in code, so that's what I did. I'm not going to bother laying out the code for them, but I'll list a few of the file names just to give an idea of what I was doing:

CompleteListCell.h
CompleteNoCheckListCell.h
CompleteImageOnlyListCell.h
MinimalListCell.h
MinimalNoCheckListCell.h
MinimalImageOnlyListCell.h

So first I decide how much information is being shown, based on the preference settings. If costs, prices, and checkboxes are all turned on, then I use the CompleteListCell. If the user turns off the checkboxes, then I fall back to CompleteNoCheckListCell. BUT, if the user then chooses a display mode where I need to show the checkboxes, I swap in the CompleteImageOnlyListCell, which replaces the button with an image.

This approach certainly does work, and is what shipped with my 1.0 and 1.1 versions. When I originally planned this out, I came up with 12 variations, so I have 12 of these files. Making them was easy enough; I built the most complicated one first, then pretty much just copy-pasted to make the others, removing code that no longer applied. And as long as I don't ever need to change anything (HA!), these files will be just fine. But if I decide to, say, change the font used for the description, I have to make that change in 12 places. And if I decide to add more information to my cell, I'm going to need a crapload of new files. So, this approach is workable, but ultimately doomed.

Duh

The first revelation concerns the checkboxes. What normally happens when a user taps on a row is that tableView:didSelectRowAtIndexPath: is called, and in the method you decide what you want to do in response to that tap. In this case, I want to slide in a detail view:

Easy enough. However, the whole point of having the checkbox is to provide an alternate action. If the user hits the checkbox, I want the row to animate out, like this:

I have the checkbox pointed to a buttonPressed: method, where I do the necessary steps to animate out the row.

The stumbling block was when I needed to show the checkboxes, but I didn't want them to function as buttons. So instead of imbedding the button into my table cell, I chose to make extra cells that contained the checkmark image. And then based on the appropriate preference setting, I chose which cell to display. I was thinking about this far too literally.

It suddenly occurred to me that I don't need to care about what kind of physical item - button or image - is being displayed, I only care about what happens when it is touched. If it is an image, normal row selection should happen, if it is a button, something extra should happen. But how do I tell the difference if I don't use a physically different item?

The answer is so blindingly obvious (in hindsight, of course) and simple that I'm really mad I didn't figure it out sooner. And that answer is the buttonPressed: method. I already have a method for declaring what should happen when the button is tapped, so what I need to do is make a small change to it to accommodate both of my needs. Here is the code:


if (![userDefaults boolForKey:kPrefsCheckboxesKey])
{
     [self tableView:[self tableView] didSelectRowAtIndexPath:indexPath];
     return;
}

First, I figure out what the preference setting is. If the checkboxes are turned off, I redirect to the exact same method that would normally be called when a row is tapped, and then bail out of the rest of the method. The end result appears to be only a single touch zone for the user, even though technically it is still two. I get my desired behavior, and this lets me remove the CompleteImageOnlyListCell.h cell and equivalent variations. So, this realization alone allowed me to go from 12 to 8 cells.

Don't overthink the problem, kids.

A Better Example

I didn't get super motivated to evaluate my cell structure until I saw this post on the Cocoa-dev mailing list by mmalc Crawford. I had glossed over it originally, not realizing it was actually an iPhone question. But sure enough, down under the 'Replicated content' section he provides instructions for using Interface Builder to graphically build cells that contain buttons. I believe that mmalc is one of Apple's tech writers, and have since found almost the exact same explanation in the "A Closer Look at Table-View Cells" section of the "Table View Programming Guide for iPhone OS". There is also a relatively new example called TaggedLocations that demonstrates the technique.

So, just like the first go-around, I laid out the most complicated version first, just to see if I could make the technique work. Here is what that looks like, with color added so that you can more easily see the different UILabels involved:

There really isn't too much code going along with this cell. This is my header file, and the implementation doesn't contain a whole lot more. It pretty much just synthesizes the accessors, inits, and deallocs.


@interface CompletePortraitListCell : UITableViewCell
{
 UIButton *checkButton;
 UILabel *primaryLabel;
 UILabel *leftSubLabel;
 UILabel *rightSubLabel;
}

@property (nonatomic, retain) IBOutlet UIButton *checkButton;
@property (nonatomic, retain) IBOutlet UILabel *primaryLabel;
@property (nonatomic, retain) IBOutlet UILabel *leftSubLabel;
@property (nonatomic, retain) IBOutlet UILabel *rightSubLabel;

@end

So that's good, but doesn't really help me a whole lot yet. Don't I need 7 more of these? As it turns out, no, this is the only file I need, and it can handle all 8 of the remaining variations.

I should probably take a moment to say that everything I'm about to achieve probably could have been used on my older code-only cell, too. But I do feel confident in saying that it probably would have been a bit more complicated to do so. And I can make size and position changes in IB so much more quickly than I can in code.

We begin with the complete cell as shown before, and let's take a quick look at it running on the phone to make sure it works:

The first option I want to handle is when the user has elected to display only one piece of additional information - quantity OR cost, but not both. I made the decision early on that in this case, the piece of information would be displayed at the left (green box), regardless of which piece of information it was. I can redirect the text into either box, so that's not hard. And it turns out that choosing not to display a box isn't hard, either. UILabel inherits from UIView, which in turn has a hidden property. So, after initializing my cell, all I have to do is:

[[cell rightSubLabel] setHidden:YES];

This results in:

Or, if only cost is being displayed:

So if hiding can make things go away, maybe I can do that with the button, too. And I can:

[[cell checkButton] setHidden:YES];

...which results in:

So the checkbox is gone, but now the text looks funny dangling out in space. I need to shift the text over to occupy the space vacated by the checkbox. This is accomplished by messing with the UILabel's frame. First, I'll grab the existing frame for the description label:

CGRect primaryFrame = [[cell primaryLabel] frame];

Then I'll feed that frame right back into the label, but make an adjustment to the X coordinate:


[[cell primaryLabel] setFrame:CGRectMake(primaryFrame.origin.x - 30,
                                         primaryFrame.origin.y,
                                         primaryFrame.size.width,
                                         primaryFrame.size.height)];

Let's see what that does for us:

Well, we did succeed in pulling the label to the left, but the entire label moved. With short descriptions, the user might never notice the difference, but once they get some longer titles, they'll see their text getting truncated at an odd location. So at the same time we're moving the box to the left, we need to make the box wider to fill up the space. So, with a minor correction to the previous code, we now do this:


CGFloat adjustment = 30;
[[cell primaryLabel] setFrame:CGRectMake(primaryFrame.origin.x - adjustment,
                                         primaryFrame.origin.y,
                                         primaryFrame.size.width + adjustment,
                                         primaryFrame.size.height)];

...and check our results:

Bingo. We can do the exact same thing with the green box. The blue one doesn't need to move in this case.

Speaking of moving a text box, that can probably handle the case where prices AND quantities are turned off. All that needs to happen there is for the description label to move down. Since we don't want the box to get taller as it moves, all we need to do is increase the Y coordinate:


CGFloat adjustment = 8;
[[cell primaryLabel] setFrame:CGRectMake(primaryFrame.origin.x,
                                         primaryFrame.origin.y + adjustment,
                                         primaryFrame.size.width,
                                         primaryFrame.size.height)];

And of course hide the two detail boxes:

[[cell rightSubLabel] setHidden:YES];
[[cell leftSubLabel] setHidden: YES];

...resulting in:

At this point, the only differences between selected and not-selected are the checkbox state, and the color of the text. We'll stay with the black for selected items, so for unselected items we'll change the text color:

[[cell primaryLabel] setTextColor:[UIColor grayColor]];

The checkbox is similarly easy. In Interface Builder, select the button, and then in the Inspector set an appropriate image for "Default State Configuration", and the checked image for "Selected State configuration". After that it is simply a matter of feeding a boolean in for the state, which in this case is based on a property of my data model:

[[cell checkButton] setSelected:[currentItem isSelected]];

So after all of this, we are left with two cases: 1) not-selected item, no checkbox, 2) selected, but all options (checkbox, prices, quantities) turned off. Technically, our same cell could handle this. Set the checkbox to hidden, make the appropriate transformation to the frame coordinates, and we're there. But, this may perhaps be overkill. After all, we're talking about a cell that contains only a single line of text. That's a basic UITableViewCell. No reason to reinvent the wheel for that. Set the font size and color, done.

And as an added bonus - and my real reason for messing with my cells in the first place - this all works in landscape, too:

There's a little sneak peak at SlickShopper 1.5 for loyal readers.

Yeah, So What?

What did I actually accomplish? The key difference is that I went from 12 custom cell classes to only 1 (plus 1 built-in cell). That's less code to manage. And the new custom class is designed in Interface Builder, which means even less code. Less code is always good (less to break). And by having all of the important cell design in one place, that means a one-time change can have a wide-ranging impact.

I'm sure at some point I'll learn about a reason not to have done this, but for now it's working just fine. The only real weakness I can see at the moment is when I move the labels in code. Right now the transitions are all relative, so if I move the red box in IB, then the red box will also move in the simplified display. I'll have to make corrections to the code at that point. I could hard-code the destination coordinates, but then I'm really putting a wall between the nice stuff I now have in IB and what is happening in my code.

But for now, I'm happy, proud of myself, and grateful to mmalc.

WWDC Recap

2009-06-14T01:03:00.001-04:00

I'm on my way home from WWDC and have a bit of a layover here in Minneapolis/St. Paul, so I thought I'd jot down some passing thoughts.

Let's Get Physical

I've identified three categories of physical activities that happened a lot during this conference. Unfortunately, I only prepared for one of them.

1. Walking. Lots and lots of walking. This is the one I prepared for. I've been doing a couple laps around the neighborhood each day for several weeks, and that exercise served me well.
2. Standing. Standing in line. More standing in line. Even more standing in line. And yeah, some more standing in line. Oh, and also some standing around during the social mixers. And don't forget about standing in line. Oddly enough, I found that even though the standing really wore on me, as soon as I started walking I was fine. I don't know exactly how to prepare for this, but I'd suggest simply standing for a 1/2 hour several times a day. Maybe shuffle forward a couple feet every few minutes. For bonus practice, hold your laptop bog.
3. Sitting. I thought the worst seats on this trip would be on the airplanes. I was wrong. On Monday I was thanking and asking for another, on Tuesday I was able to keep to name, rank, and serial number, but by Wednesday I was giving up state secrets and begging for mercy. In order to prepare for this, I suggest finding a nice concrete block, and bringing along a small sheet of plywood for a backrest. Sit on this for an hour, four times a day. You probably still won't be adequately prepared, but at least you'll be more ready to accept the almost total loss of the concept of personal comfort. Chances are you won't be able to sit on the end of a row, so as you sit practice keeping hold of your laptop without crossing your legs.

Big Brother

This is the first conference I've attended where all of the content was provided by the host company. Every single lecture was given by Apple employees. I don't think I can adequately articulate how much less useful PLM World and SolidWorks World would have been with exclusively UGS- and SW-provided content. Certainly, it is nice to get information direct from the horse's mouth, but there is so much valuable knowledge in the user base. On average, the useful information acquired that can be immediately applied tends to come from user presentations. This is largely due to the fact that the host company is mostly talking about what's coming up. The next version of SolidWorks, the next version of NX, etc.; capabilities that aren't even available yet and won't be for months. Users stand up and talk about what they've been doing for the last year, and provide a little reality to combat the unicorns and roses offered by the company. I was already overwhelmed by the amount of information that Apple provided, but I can't help but wonder how much more valuable and tangible information I could have acquired from a few decent user presentations.

Brush With Greatness

I didn't get to meet everyone that I wanted to, but I did wind up being surprised at the numbers I did encounter. Several book authors, several of my Twitter followers, and so on. It's tough to meet people when all you know is a screen name. Who knows how many times I walked past someone I would have liked to meet, but didn't know that's who they were. I did see a couple of people I would have liked to talk to, but didn't have a convenient situation to do so, and judging from Twitter there were a significant number people present that I would have loved to meet but never saw. Maybe next year, on the assumption this whole programming gig lasts long enough to justify a return, I'll have to send out some emails in advance to arrange meetings.

Conference Comparison

2009-06-10T02:59:00.001-04:00

This week I'm in San Francisco attending Apple's World Wide Developer Conference (WWDC). This represents a number of firsts for me. First time attending an Apple conference of any kind, first time attending a non-CAD (well, week-long) conference, might even be my first visit to San Francisco (don't remember).

It is only natural that I draw comparisons to my prior conference exposure. I attended PLM World for several years, and last year attended SolidWorks world for the first time. I don't remember if I blogged about it, but I believed at the time that SWW was hands-down the best conference experience I had witnessed. Can Apple trump that? In short, no, but they come pretty close. So let's take a look at some aspects that have jumped to my attention.

It should be noted that I have missed the last 2 PLMW conferences, so some of my information may be out of date, and my complaints may have been addressed in the meantime.

Planning Ability

PLMW and SWW both announce their conference dates for the following year at each conference, and sometimes even 2 years in advance. Although everyone knows there will be a WWDC each year, Apple announced the early-June dates in late-March, barely 2 months of warning. That's no good. There's no reason to be so secretive about the dates.

Winner: PLMW/SWW
Loser: WWDC

Preparing Ability

I got used to PLMW publishing session schedules well in advance of the conference. There would often be revisions, but the bulk of the schedule was made public early on. Either SWW's site really sucked, or I am an idiot, or blind, whatever, but I didn't find session schedules until almost immediately before the event. In fact, I think it was my wife who pointed out to me where it was on the site, and I swear I didn't see it before then. So I'm willing to acknowledge it could have been my oversight, but it left a bad taste in my mouth either way. Apple only released a session list about a week or so before the event. So that's bad. BUT, they did provide the ability to broadcast a calendar subscription, and indicate on their web site which sessions I would want to attend. This updated directly into iCal, so I was quickly able to see that there were far too many interesting sessions for 1 human being to attend. And about 2 days before the event, they made an iPhone app available that hooked into the same scheduler, and also provides maps and things.

Winner: Apple for capabilities, PLMW for timeline
Loser: SWW, but might have been my fault

Registration and Schwag

The day before things kick off, you go to the registration tables to get your various badges and things. Registration is registration, so I can't say that there is anything particularly noteworthy about any of them, so let's focus on schwag.

PLM World started off pretty well for me, then quickly went downhill. The very first conference I attended, they handed out Palm Pilots to all attendees. The next year was a memory stick. The next, a shirt. The next, either another shirt, or nothing, I don't remember. Meanwhile, they found a sponsor to hand out a horribly crappy bag. Think of a re-usable canvas grocery bag, only much, much, much cheaper. That became a standard for several years, and they mostly handed it to you to keep track of all of the sponsor ads and other miscellaneous crap they also handed out. The bag was really only useful for carrying this stuff back to the hotel room, never to be touched again.

SWW was a shirt and a backpack. I still wear the shirt periodically to this day, and would be using the backpack if I didn't already have a great one. It is a pretty decent backpack.

Apple is a shirt and a backpack. It's more of a stylish backpack than a particularly useful one (cue Apple haters...). Shirt's not bad.

I should point out that I am actually carrying around a shoulder laptop bag that I got from PLM World. But, this was one of the gifts I received for being a presenter, and not part of the general handout. It's an odd bag, and has proven to be surprisingly useful at events like this, but I'm not going to count it since it is a special case.

Winner: SWW
Loser: Recent PLMW

Identification

PLMW has long gone with the fairly standard huge identification lanyard. Ugly, but always functional. Large, easy to read letters so you could catch the names of people without too much trouble, handy little slots for business cards and pens. No complaints. SWW took a slightly different route, with a clear plastic holder. But they added two particularly useful innovations. First, attached to my name card was a printout of the sessions I had indicated I was interested in during registration. THAT was handy. Second, they managed to cram the entire conference agenda into a small booklet that slid into a slot on the back of the ID holder. This is noteworthy because PLMW's conference agenda is a freaking Sears catalog. Apple has gone with a plastic card about the size of a credit card. The text is rather small, and the card has a gift for rotating around so the wrong side is facing out, so you can't see names anyway. About the only thing positive I can say about it is that it's easy to stuff in a pocket when leaving the conference center so that you aren't displaying your "please rob me, I'm from out of town" bullseye.

Winner: Tie between PLMW and SWW, slight edge to SWW
Loser: WWDC

Innovations

Again, PLMW got off to a great start. They handed out the Palm Pilots because they included conference software that listed the sessions and locations. They never handed out such devices again, and I don't believe they offered the conference software again (I have missed the last two, so they may have updated in the meantime). SWW didn't really go for technology in this area, but their conference agenda was very clever, and I don't mean the small one that was in the ID pouch. They produced a spiral-bound version that was roughly half as thick as PLMW's catalog, despite having significantly more content, AND the back half of that contained blank engineering paper for doodling or taking notes. You almost didn't need to carry anything else around with you. I'm not going to give Apple too much credit for having an iPhone app; after all, it's a developer conference, with particular focus on the iPhone. It would be more significant if there wasn't an iPhone app. But I'm still going to give credit for providing the calendar subscription. It's a nice touch.

Winner: Each, for different reasons
Loser: Recent PLMW

Keynotes

PLMW keynotes were spectacularly dull and uninteresting. I cannot think of a single positive thing to say about any of them. I don't think they understood their audience. The presentations were always geared towards my boss, or even my boss's boss, but neither of them were at the conference. I was. The keynote did not once speak to me. SWW was like a breath of fresh air. The keynote was interesting, entertaining, and relevant to me. Not my boss, not my VP, me. It was a highly charged, highly motivating experience. How does that compare to one of Apple's legendary keynotes? I didn't actually care to wait in line to see the keynote (not sure if I would have felt differently if el-Steve-o was presenting), I just wanted breakfast. But you had to wait in line to get inside to get to the conference food, so I bailed and went to Starbucks. The line was already several blocks long, and by the time I came back was nearly wrapped all the way around the conference center. I believe the line came full circle by the time they started letting people in. As is, I was in line for roughly 45 minutes, and got shuffled into an overflow room 15 minutes after the keynote had started. Was it worth it? Meh. Oh, don't get me wrong, they announced some cool stuff. But I really didn't leave with a sense of "Oh wow, I want to go write some code!" I totally wanted to go design something after the SWW keynote. It's not the same audience, not really even the same purpose, but I'm afraid to say that SWW out-keynoted Apple.

Winner: SWW
Loser: PLMW

Meals

PLMW has always had decent catering. The crowd is shuffled into a large room with plenty of tables, all pre-stocked with silverware, condiments, and usually a choice of water or tea. (Hopefully) soon after being seated, food would be served, and an eager wait staff would whisk finished plates away. The food was usually fancy, but not really my thing. I won't say it was bad, just that I would have preferred a bit more of a common menu. As I type this, I can't remember what SWW meals were like, so it must not have been noteworthy in either direction. WWDC's meals are pre-packaged. They seem to offer 3 choices - yesterday was ham & cheese sandwich, chicken wrap, or vegetarian - and you move pretty quickly through a line to get what you want. Food quality isn't bad, though it is significantly lower quality than PLMW. But you can grab and go. Generally there are better things to do at a conference like this than to wait on your food to be served, so I think that's an advantage.

Winner: WWDC for speed, PLMW for quality
Loser: PLMW often had long food delays

Snacks-n-Things

PLMW did a pretty good job of leaving out water bottles on a regular basis, and there would be sweets in the afternoon. They typically did a pretty good job of covering a wide area in the conference center, so you wouldn't miss out on a cookie just because you were on the wrong floor. SWW stepped this up a notch, providing custom-labeled water bottles constantly, and if anything the snacks were even better than PLMW's. I kept reading tips for WWDC recommending that you grab the water bottles from your hotel room ($3 for a modest bottle). Surely this is unnecessary, I thought. They have to provide water bottles.

They don't provide water bottles! Apparently if you know where to look, you can find some office-style water jugs, with paper cups. During meals and during snacks, they basically wheel out these barrels filled with ice and a couple flavors of canned drinks, and I've seen some varieties of juices in plastic bottles. But not much water. And let's talk quantities. Maybe I was just in the wrong place at the wrong time, but when I wandered out for a snack, there was exactly one table available with cookies and M&Ms. One table. This is the largest conference I've attended. One table. Twice the size of PLMW, edging out SWW by a bit. One table. And of course, hungry software developers lacking in people skills descended upon this table like a pack of wild dogs. I've never seen so much interest in M&Ms, and I struggle to think of the last time I saw such a poorly organized means of delivering food. The CAD conferences typically naturally form lines and efficiently retrieve food. This was almost scary.

Winner: SWW, CAD users
Loser: WWDC, software developers

Signage

For as long as I can remember, PLMW has used custom-printed foam board propped up on easels for session topic signs. I was amazed when I attended SWW, and they had big LCD screens outside of each room indicating the next session subject. Apple has, of course, stepped that up with a level of style.

Winner: WWDC
Loser: PLMW

Granted, I'm not even half way through WWDC yet, but based upon initial impressions, I'd have to say that SolidWorks World will hold onto its coveted title of "Most Impressive Conference Brian Has Attended". Seemingly everyone involved genuinely cared that the attendees had a great - not merely good, or acceptable, but great - time, and SolidWorks was willing to throw around some serious dollars. PLM World has been hamstrung with budget issues, no doubt in part to being a separate entity, and being roughly half (in terms of number of attendees) the size of the other two. WWDC is falling somewhere in between, although definitely closer to the SWW end of the spectrum. Apple is throwing some money around, but I'm not certain that it is winding up in the right places, and I'm not getting quite the same level of enthusiasm. Maybe it is social differences - although engineers and programmers aren't too far apart on the introverted nerd scale - maybe it is the always-present Non Disclosure Agreement hanging over everything here. Not sure, but SWW got "it", whatever "it" was.

It Has Begun

2009-06-01T13:35:00.001-04:00

So, Brian... what have you been up to lately? Quite a bit, thanks for asking.

On November 17, 2008, I placed an order for Beginning iPhone Development: Exploring the iPhone SDK, by Jeff LaMarche and Dave Mark. I had no way of knowing that just a few days later, I would lose my job as a Mechanical Engineer. In pretty much every way except financially, this has turned out to be one of the best series of events in my life. Rather than moping around about losing my job (did enough of that the last time I lost my job), I threw myself into the book, determined to make myself into an iPhone programmer.

I am not a total beginner, but not too far from it. Roughly two years ago, I attended a programming class at Big Nerd Ranch, one of the best Mac programming instructional organizations in the world. I toyed a bit with Mac programming for a little while after that, but for various reasons didn't keep much momentum. When Apple made it possible for anybody to create programs for the iPhone, I jumped at the chance to dive back in to programming. Unfortunately, I am still a beginner, and Apple was still new at supporting this particular ecosystem. The examples and documentation were hard to understand, tutorials non-existent, and the available tools didn't work as well as their Mac OS counterparts. As Apple continued to release updates to the developer tools, I downloaded each one hoping that things would finally get to a point where I could figure them out, but it just wasn't working.

Thank you, Jeff and Dave.

At last, a well-written book appeared that would pave the way for what hopefully turns out to be my new career. I spent the next several weeks patiently and diligently working through the examples in the book. Somewhere around Chapter 9, I decided that I probably knew enough basics to start working on my own program. I started putting together small sample programs, testing different functions that would be components of an application that I wanted to make, and proved to myself that I could make it happen. Looking back at my project history, somewhere around mid-February is when I started to create my real program.

I'm planning to do a separate blog post detailing the creation of my program, so for now let's just say that my initial estimate of 6-8 weeks to completion was, um, inaccurate. I'm sure that someone who knew what they were doing could have completed the program in half that time. I slammed into speed bumps and brick walls constantly, rewrote the entire thing from scratch at least 3 times, and spent many a late night trying to squash bugs. I have learned that I am unable to get to sleep if my program crashes. My learning curve has been more of a jagged, rocky, and steep cliff face.

On May 28, 2009, Apple approved my program - SlickShopper - for sale on the App Store. I was really hoping to get it onto the store in March. And then I was really hoping to get it on the store in April. And then I was hoping I would just finish the darned thing. I finally bit the bullet and submitted the app into the approval process, and then nervously waited for what turned out to be 7 business days, meanwhile watching a competitor conduct a major advertising campaign. But it finally happened. My program exists. It is available for purchase. People who aren't friends or family have bought it.

I am an iPhone developer.

This is by no means the end of the story. For one thing, SlickShopper only sells for a dollar, so it's going to require a truckload of unit sales to provide useful income. I'm not expecting that to happen. For another, my wife will be losing her job in just a few weeks, which will drastically cut down on the amount of time I can do this iPhone thing before I have to go bring in real money elsewhere. And SlickShopper isn't done. There are several features I still want to add, and the main reason they aren't there yet is that I just plain don't know how to do them. So I have some learning to do. This doesn't take into account what my paying customers might want the program to do that I haven't even thought of yet.

Step 1 was to ship software. Now that I've made that happen, I can figure out what step 2 will be.

What Was That Noise?

2009-03-10T21:21:00.001-04:00

What noise? Oh, that? That was the sound of the other shoe dropping.

Loyal readers (both of you!) know that I have have been unemployed since late November. I'll talk more about what I've been doing in the meantime at a later date, but basically I haven't been trying all that hard to find another job. That may need to change sooner than I had hoped.

Teri was informed on Friday that her position will not be renewed this summer. It's not a 100% done deal, but close enough that there's no real point in hoping that she'll keep her job. She will finish up at the end of June. I suppose we could view this as she is getting nearly 4 months severance, but she still has to work for it. Heh.

Although it's always shocking to learn of job loss, it wasn't a complete surprise. The university, like everyone else, has been facing budgetary issues. Also, in response to being questioned about job security, her boss hinted a few weeks ago that she should keep her eyes and ears open. That's what we in the business call "a sign".

This will be the first time Teri has lost her job, and it's just a great big happy freaking coincidence that it happens when I am also jobless. So this drastically reduces the amount of time that our savings will last. With Teri employed, our pile 'o cash can go for roughly 3 years. With no income, that drops to about 9-10 months, or roughly a year from today. So we still have time to find jobs, but a lot less of it.

Semi-related side note: If you have a nice, perfectly functioning - and paid off - automobile, and are thinking about selling it, buying something cheaper, and using the difference to pay off credit cards, DON'T DO IT! Nothing sucks like have to pay for repairs on a POS car when you don't have a job. Reliable transportation is very important. Also, if you think that used cars devalue slower than new cars, um, no. My POS car is worth roughly half of what I paid for it not even 9 months ago. Did I mention repair costs?

Anyway, Teri has spent the last few days applying for other jobs. Basically none of them are local. So chances are, our lives are about to change. Once we are both jobless, aside from a couple of friends, the only thing keeping us here is the house. And as one of those friends said: "Gotta eat!" Damn straight. So the house will most likely go up for sale and we'll move. No idea where or when yet. The good news is the pretty much everything Teri is looking at comes with a decent pay increase. How the cost of living will increase is yet to be determined.

I've started waking up my headhunter network, so I'll probably go off and do some contract jobs in the meantime to bring in some money (so I can buy a better car!). Depending on the timing of when Teri finds a job and where it is, or when I do, we may be spending a fair amount of time apart this year.

As I was typing this, it occurred to me that I've been in Cincinnati for almost 11 years. This puts it 2nd on my list of "places I've lived the longest" (cities, not specific addresses). I was moved away from Anderson when I was 12, so if we're still here next year, I'll tie that record.

Go, economy!

The (Official) End of an Era

2009-02-23T12:40:00.001-05:00

Although I lost my job back in November, the severance package worked out to be 3 month's pay. Rather than giving me that money in a single lump sum, the company elected to simply continue paying me for 3 more months. I deposited the final check yesterday.

Up till now, I've basically had an extended paid vacation. Now, I lose money. Well, technically, March 20 is the first date that I will have failed to receive a paycheck, so that is when I will really feel the difference.

I'll be honest; when I first lost my job, I thought I would have a new one by now. But the reality is that I just haven't found anything that interesting, and certainly not enough to warrant a lower salary than I previously had. I had a flurry of phone calls from recruiters in January, and even did a couple of phone interviews, but February has been pretty quiet. Few of the opportunities have been local, and most of the out-of-area opportunities have been in places with ridiculously high costs of living. I'm a long, long way from needing a job for the sake of bringing in a paycheck, so I'm not feel overly motivated to go do something that I don't find interesting. I don't want another job, I want a career. Only one single opportunity presented to me has represented a potential career, and due to the economy I won't find out if that opportunity still has life until April.

So I have mostly given up on the job search for the time being. That's not exclusively my decision, of course, as I haven't been getting too many recruiter phone calls lately. Instead, I've decided to focus my attention in a different direction.

Shortly after losing my job, I purchased an iPhone programming book, and have spent the time since trying to become an iPhone programmer. The learning curve has been brutal, and progress has been slow, but nonetheless I am making progress on my first iPhone app. I figure I'm another week or two away from having all of the raw functions that I want, then I will need to spend some time refining the interface. I have recently applied for the Apple iPhone developer program, which will allow me to conduct beta testing on phones, and eventually allow me to post my app on the store. If all goes well (and so far, it hasn't), I hope to have my first app posted by the end of March.

Assuming I do eventually get the app onto the store, I will then watch what happens for a few months. If it looks like I can bring in some money this way, then I may just give up on engineering altogether and focus on programming. Maybe I can make my own new career, rather than hoping someone else will provide me a good opportunity. I have plenty of time to find out. Wish me luck.

The Poorly Argued Point

2009-01-26T18:29:00.002-05:00

Hey, this might be my first ever rebuttal-to-another-blog post. A post by Paul Hamilton showed up in my feed reader. I don't know who he is or why I'm watching his blog, but his profile indicates he is CAD-related, so I must have read a previous posting and subscribed.

Today Paul argues that costs can be saved with history-free CAD modeling. This might ultimately be a true sentiment, but Paul argues it badly. I see that a previous post of his argues the benefits of history-based modeling, so maybe he is just playing devil's advocate this time around, which would explain the weakness of some of his points.

The first set of ten points addresses improvements in effeciency. Let's take a closer look.

1. Lower your training costs with history-free modeling. There is simply less to learn when there is no history tree to create and manage. Intuitively interact with the geometry, directly.

Speaking as a former CAD trainer, I suppose there is some slight merit to this point, but it certainly isn't significant. For an introductory class with 20 chapters, one (maybe two) was spent on history, so for a five day class we are talking about a couple hours, tops. Significant? Hardly. Would the omission of this topic enable dropping to, say, four days? No.

With CAD, you have to know how to create stuff, and you have to know how to modify stuff. I haven't seen anything in the history-free world that suggests the creation tools are really significantly different and/or easier. Call that a wash. So how about the modification tools? Well, you have to know what you are doing in either case. Even within the realm of a history-free modeler, there will be rules and nuances that will still need to be trained or otherwise learned with experience.

2. Get the right people engaged at the right time. Eliminate CAD knowledge from the criteria for assignments and resource management.

So, history-free modeling is so easy that anyone could do it, eh? Right. This ignores the knowledge required for CAD model creation.

3D modeling is a mind set much more than a skill set. It's an ability to visualize the desired item so that you can sit down and make it happen on the computer. If you can do that, then the tools are just a matter of training. If you can't, it doesn't matter how easy the software is. I have encountered everything from the newbie with zero CAD experience to grizzled old veterans, and not once has the ability to interpret a history tree been the deciding factor between "gets it" and "doesn't get it".

3. Hire the best designers and engineers, not just CAD jockeys. Eliminate CAD knowledge from the criteria for hiring/staffing.

I haven't encountered too many quality designers or engineers who were not highly skilled with computers and the appropriate tools for the job, which should include CAD. Indeed, at my previous company, most of our best engineers were hired without experience in the specific CAD program (which is history-based), but they did have decent CAD backgrounds, so training wasn't that big of a deal.

There is nothing, absolutely nothing, about history-free modeling that equates to "nothing to learn", so the notion that you can remove an item from your desired skills hiring checklist is ludicrous.

Besides, those guys that are "the best" are going to want to be paid accordingly, so how does this help to reduce costs? This point would make more sense if it argued in favor of hiring lower-caliber people, since you supposedly wouldn't be paying for CAD experience.

4. Enhance the concept design process with flexible 3D modeling. Concept design and history-based modeling are like “oil & water”; they don’t go together very well.

Since this is about concept design, naturally we are talking about model creation, so refer back to my previous point about the creation tools. As the modification process goes forward, it is really going to come down to the specifics of what you are doing and what needs to be changed; that it is hard to generalize in favor of either direction. And really, this point is more about design intent than history modeling. If you put in a lot of design intent up front, then you are going to be frustrated when a necessary change doesn't jive with that intent. I'm forced to assume that even history-free modeling possesses some means of capturing design intent - otherwise it would be nearly useless - so this is still a wall you can smack against. Some changes may be easier to implement in a history-free environment, but I can find just as many cases that would be easier with history. This simply isn't a good point to generalize about, because it is so case-by-case.

5. Improve productivity for each individual by focusing on design, rather than model creation methods, technique and process. Reduce costs by focusing all effort on product design rather than 3D modeling.

There aren't creation methods, techniques, and processes in history-free modeling? All I have to do is think it and the model appears on my screen? Incidentally, I think that last sentence is a sales slogan for many history-based CAD programs.

CAD is all about shapes, obviously. So in the design process, the quality CAD user is thinking to himself "how do I make that shape in this software?" That thought process still has to exist even in a history-free environment. There are still steps to take to create the shape. Maybe one CAD program has a handy command that does what you want in one shot, maybe another CAD program requires two or three steps to accomplish the same thing. History or not, you still have to know what you are doing, and how to make it happen.

6. Repurpose existing data easily with no need to understand model history. Optimize parts once and reuse to the max.

Maybe I'm not understanding the point being made here, but how does part reuse correspond in any way to how it was constructed in CAD? If the 3-spoke widget you designed for Product A might also be used in Product B, then go use it in Product B. How does history even enter the equation? Optimization is a function of FEA and testing, not history, so test it against the requirements in Product B and determine if it is appropriate for use.

This is a data management point more than a CAD modeling point.

7. Greatly improve teamwork, team design and interaction with downstream and upstream partners to improve quality, innovation and reduce costs. By eliminating the history tree, team members can immediately interact with the CAD data. No need to study the model history.

This is such a curious sentiment from someone with PLM experience. The whole bit about teamwork is completely a function of the data management capabilities, and has nothing to do with CAD modeling. Do you really want your vendor making changes to your model? Of course not. But you do want a nice handy way for your vendor to convey those requested changes back to you. So now we're in the realm of geometry viewers, markup capabilities, and managed permissions. This has absolutely nothing to do with the CAD creation methodology.

And again, assuming that even history-free modelers possess design intent capabilities, then you absolutely should study your model before diving right in.

8. Get the maximum value from your rich CAD data by making it available, and understandable, to the extended team.

Why is history-free CAD data rich? Is an IGES or STEP file rich? In my world, we call those dumb solids for a reason. And again, data availability is a function of data management and viewers, and has nothing to do with CAD creation methodology.

9. Minimize IT infrastructure load. Utilizing explicit history-free modeling technology can reduce average file size by 60% to 80%. Can minimize RAM requirements, storage space requirements and network traffic. This is made possible by eliminating data space requirements that are typical of the history tree.

I don't buy this for a second. With history-free, you are storing all geometry all of the time, and that will always be larger than the instructions to recreate the geometry if necessary. Which occupies more space, the house or the blueprints? If you want to say that instructions + geometry > geometry alone, fine, but at least you have the option to strip away the geometry and go with the instructions alone.

The stated percentages are going to be a function of how much geometry the history-based modeler stores, and this will be a function of each software's implementation. If the history-based modeler stores only the final geometry, then the resulting file size should be within a tiny percentage of the history-free's model.

10. Improved general performance and load/store times for each CAD user by taking advantage of the lightweight footprint of explicit history-free modeling.

Lightweight models are not unique to history-free modelers.

So 10 ways to improve efficiency with history-free modelers, of which most having nothing to do with the CAD modeling paradigm, and what's left really doesn't create a convincing argument. If anything, several of these points are fine arguments for the implementation of a decent data management system, which of course has nothing to do with how the CAD model was created.

Paul then goes on with 10 ways to reduce waste. He makes better points here, so let's take a look.

1. Eliminate the waste of history tree management and structuring. Focus on the task of design. And don’t make the incorrect assumption that you cannot capture design intent without a history tree.

Ok, so he confirms that there is indeed design intent in a history-free modeling paradigm. This alone kills any implication that there is nothing to worry about in such an environment. I'm willing to grant that history tree manipulation can be a big deal, but this is also a factor of each software's implementation. Figuring out the design intent is going to be the key task, and my gut says that this is more easily done with a history tree, but I'm willing to be proven wrong.

2. Eliminate the need to rebuild models, something that is too common with history-based tools. (especially if you do concept design with them)

So, with number 12 we finally land on a completely legitimate point, no question. About the only thing I'd like to add is that the time spent on rebuilding is highly dependent on software implementation, and hardware capabilities. For example, SolidWorks smokes I-DEAS on pure rebuild performance, due simply to having a newer, faster algorithm. On the flip side, I-DEAS provides some methods such that a complete tree doesn't need to be rebuilt (however, there is some of that history tree management involved). I'm going to guess that on average, if the hardware in question has the necessary guts to do live changes on raw geometry, then it can probably burn through a history rebuild without too much trouble also.

3. Eliminate the need to create and manage standards and best practices for creating and managing history trees / history-based models.

Although I can think of some general best practices off the top of my head - mostly dependent on the software implementation - I can't remember ever feeling burdened by them, nor were they ever enforced. Start with a coordinate system (manual in I-DEAS, automatically there in SolidWorks), put fillets last, that's about it.

4. Add intelligence (features, parameters, …) to models and assemblies only when needed. History-based systems may force the addition of this intelligence whether it will be used or not. They will force relationships (parent/child), again whether this added information is actually useful or not.

Parent/child is about the only legitimate difference between history-based and history-free. Aside from that, you can do unconstrained modeling in most history-based programs. "Only when needed" is a comment on design intent, which exists in both paradigms, so I don't see much of a point here.

Also, the implication that there are no parent/child relationships in history-free modelers is false. There may be fewer of them, and they may not be as rigid, but they are there. Some operations, like fillets and draft angles, have to occur after other geometry is created. You can't fillet something before the geometry is created, and if some of the participating geometry is removed, the fillet can't exist. That is a parent/child relationship.

5. Upward compatibility can be a big issue with history-based modeling and can result in rework and duplication of effort. There is no compatibility issue when working with geometry; i.e. explicit history-free modeling.

"No compatibility issue" is certainly a bold statement, and given the various issues I've seen with IGES files over the years, one that I'm willing to believe could be proven false easily. While it may be true that there is less to break with a history-free model, to suggest it is unbreakable is placing far too much faith in our robotic overlords. It implies that nothing more needs to be fixed, or no more performance needs to be improved, in the code which is never the case. Messing with code carries along with it the possibility for breaking with legacy data.

6. Greatly reduce the effort of data exchange with suppliers and vendors. History trees are proprietary.

Pretty much all of the vendors I've ever worked with wanted either whatever their native software uses, or IGES or STEP files which are easily generated by history-based modelers. While history trees may be proprietary, so are file formats, so unless these history-free modelers are working with something like IGES as their native format, this is a moot point at best. Unless someone developed the holy grail of open, widely-recognized and utilized 3D formats when I wasn't paying attention, there is still the potential for translation and compatibility issues, regardless of the modeling paradigm.

7. Eliminate the need for other team members to study the history tree of other team member models just to make use of them.

I'll say it again: you still have to study the design intent. History is merely an element of the design intent. I have yet to encounter an environment where design intent is completely unnecessary and completely undesired.

8. Designers will spend an estimated 25% of their “CAD time” managing and manipulating the history tree and related attributes and data. Your designers can be 25% more productive by eliminating this activity.

This sounds like a made up statistic, because there is zero chance I've spent anywhere close to 25% of my time on history manipulation, but let's take it at face value. What percentage of that time is spent on interpreting design intent, an activity that will still need to occur in the history-free environment? I'd be willing to bet that the difference will be made up in the additional time spent in the history-free environment, where the user does not have the history tree to provide additional information about the design intent.

9. Greatly reduce the need to recreate CAD data just to get it into an editable format

Under what circumstances? 2D -> 3D would be no different. Changing CAD programs? The file will still need to be exported and converted (again, if there is some commonly-accepted history-free file format that all history-free modelers are using and can easily exchange, I'm willing to be educated). After we decide that history actually was kinda nice and we need to go back to it? Oops, it's all gone, have to start over...

10. Reduce the time consumed in the change cycle, but eliminating the need to study the model creation history. Focus on the process of change.

How many bullet items need this same point? And I'll keep repeating mine: you still. have. to. study. the. design. intent. first.

I can't shake the feeling that Paul really doesn't believe that much about what he wrote, but felt like he needed to make a counterpoint to his previous article. I'm not sure what his motivation was, but as far as sales pitches go, this was not convincing.

Incidentally, the gist of each of his points - make CAD available to more people (or everyone), easier to learn, easier to do, focus on design and not CAD - are almost verbatim the same things that the SolidWorks folks say, and SolidWorks is - wait for it - history-based. Lack of parent/child relationships and lack of rebuilding are about the only legitimate points to differentiate history-free, and the rebuilding one is the only one that is hands-down a weakness of history-based. Parent/child will depend on the situation.

Really though, I see nothing here justifying a history-free approach that would not also be on the order of magnitude of simply switching to a different CAD program. Performance improvements here, easier to learn there, less expensive over there in the corner, and so on. In my case going from I-DEAS to SolidWorks, I'm going from old, Unix-based, expensive software that hasn't significantly been enhanced in years, to relatively new and cheap Windows-based (actually, maybe that should be despite being Windows-based...) software that is being rigorously and regularly updated. There's going to be a huge amount of win there, no question. That most likely would have also been true had we gone with SolidEdge or Inventor instead. In fact, nearly every point that Paul made could apply to our transition to SolidWorks. So why would I want to go with a history-free approach, and give up the things that history does provide? No thanks.

More Macro Tidbits

2009-01-06T18:15:00.002-05:00

If you notice (or care) that the blog looks different, I changed to a template that isn't fixed-width. The other template kept wrapping code snippets, which I find can be confusing. One of these days I'll get around to making my own template, but for now this was the least ugly variable-width one that Blogger provides. If code wraps now, stretch your browser window. Or get a bigger screen.

First, I'd like to do my best to answer a question asked about one of my previous posts. An anonymous person (leave names, people, please!) asked:

What is hard for me for doing macros is the format? How and when to use () spaces and such.

This is basically about syntax, so let's focus there. For the most part, syntax is absolutely critical in pretty much any programming language. Computers are very good at doing exactly what we ask them to do, but not so good at doing what we really wanted them to do. The difference is in the syntax.

Syntax Your Brain

There are a couple of nuances in the I-DEAS macro language to be aware of. For one, although you can run a single program that will bounce back and forth between Modeler and Drafting, they actually have separate languages. The languages are very similar, and understanding one for the most part will help to understand the other, but they are distinct. I've spent most of my time in the Drafting macro language and found it to be far more forgiving than the Modeler one. This may be related to the fact that Drafting has excellent documentation and Modeler doesn't. A quick sample of the difference between the languages:

Drafting:

C: This line is a comment

Modeler:

C : This line is a comment

Note the space before the colon in Modeler. This isn't necessarily a huge deal, although it would be nice if they were the same, but the main problem is that Modeler does not provide useful error messages that help direct you to fix a syntax error. I've had several occasions in Modeler where it turned out that the real problem was I put in an extra space somewhere; it was a big deal in Modeler, but an equivalent situation in Drafting would have been just fine. Without access to software, I'm not able to generate any sample error messages, but trust that I've spent some quality time arguing with Modeler about what should and shouldn't be legal. I usually lose.

The next interesting thing about the macro commands is that they can provide more than a single response when asked a question. If you read through the documentation, each command help page will provide a full description of the command that looks something like this:

Read Paper Size ( [Xsize], [Ysize], [Units], [DimStd], [Text] )

I won't recreate the entire page here, but underneath this command is a description of each parameter. For example, the [Units] parameter is of type Integer, it is an output variable (as opposed to input), and the description reads "Drawing units, where 0 = inch, 1 = metric" so it is basically a boolean. Xsize and Ysize should be obvious enough, DimStd refers to the dimensional standard (ANSI, ISO, etc) being used, and Text will report a standard size (A,B,C,D) if applicable, or "EXPLICIT" if the size is custom. So with a single command, you can retrieve a lot of different information in several different forms.

First, you define your variables, maybe something like this:

# REAL Width_Of_Sheet
# REAL Height_Of_Sheet
# INTEGER Unit_System
# INTEGER Dims_Std
# STRING Sheet_Size

(The necessary variable types were in the help document for the command) Then you plug those variables into the command like so:

# Read Paper Size (Width_Of_Sheet, Height_Of_Sheet, Unit_System, Dims_Std, Sheet_Size)

First of all, note that the [] used in the help document are not actually used in the macro. It's basically placeholder notation in the help files. Running this single command will populate all five of these variables with information. To verify this, you could do the following:

# Show Message ("Width_Of_Sheet is: " + Width_Of_Sheet)

If it is blank, something went wrong, otherwise you should see the width of your sheet. You could add four more message commands, one for each variable. I actually recommend doing so as a troubleshooting tip.

But what if you don't need all of these values? Maybe you are only interested in the height of the page. You can do that, but the kicker is you still have to provide the commas. This is so that I-DEAS will know which variable you actually want to populate. Your new command would look like this:

# Read Paper Size (, Height_Of_Sheet,,,)

I-DEAS now knows that you would like to get information supplied to the second parameter in the command, which happens to be for the height of the sheet. If that looks odd, basically what you are doing is this:

# Read Paper Size (~~Width_Of_Sheet~~, Height_Of_Sheet, ~~Unit_System~~, ~~Dims_Std~~, ~~Sheet_Size~~)

So if you are ever handed someone else's code, and see all of those crazy commas, what's happening is that the original author did not wish to take advantage of everything the command had to offer. In case the variable names aren't useful enough on their own, you'll want to visit the help document for the given command to research which parameters are being used or ignored.

In some cases, if possible, it may be worth the effort to work with a simpler command. In this particular case, since what I want is the size of the drawing, I could also use this command:

Inquire Drawing Information ([dname], [sizex], [sizey], [partNumber], [version], [revision], [libStatus], [writepriv])

Here I have eight different parameters to play with, but I really don't care about the version, or the revision, etc. Read Paper Size may be a better, more concise, option. It all depends on what information you will need later. If the revision will be useful, then Read Paper Size will not be enough on it's own, and you are going to wind up querying the same information again when you Inquire Drawing Information. Not every situation has the choice between multiple commands, however, so generally you are looking for the only one that will provide the information you need (and feeling pretty lucky if you find one).

I'm afraid I don't have any other real tangible tips regarding syntax. Refer to the documentation and/or existing programs as much as possible for guidance.

I Object

I'm still relatively new to object oriented programming (OOP), having only dabbled a bit as I've tried to learn Mac/iPhone programming over the last couple of years. I still struggle with some concepts here and there, but for the most I think I "get it": modular, reusable code. The I-DEAS macro language is not object oriented. But, through some careful planning you can still achieve a mostly modular result.

I, of course, was not smart enough to think of this when I first started writing my programs. About the second or third time I write the same basic code to do the same basic thing, it finally set in that I was doing more work than I needed to. Unfortunately, ripping out existing code to reformat around a modular approach can be challenging, and you risk breaking code that already works. But in the long run, you do yourself a huge favor by only having to fix code in one place, and the various modules make it easier to create new programs.

Let's take an easy example, applying the current date. I have several cases where I would want to do this. When a user creates a new drawing, I like to automatically provide the creation date on the face of the print. Same thing for when they add a revision. No problem, let's dive into the help documents to find a command to help out. Ah, this looks good:

Inquire Date ( Doption, [Padding], Date )

Reading through the rest of the document, Doption is basically Date Option (MM-DD-YY or DD-MM-YY, for example), Padding essentially lets you force 2 digits for dates, so 03 for March instead of just 3, and then the Date is the output. The previous code examples did not include any input parameters, but this one does, which I need to do in order to format the results the way I want. The only problem is that the actual format I want - MM/YY - is not one of the built-in options. I do not see any other commands that get the current date, so I'm going to have to find a way to work with this command. The help document notes that the Date parameter is a text string, and I just happen to know that there are commands for slicing and dicing text strings up, so maybe I can extract the information I need and then build my own date string.

First, the actual inquiry command:

# Inquire Date ("dmy", 1, cur_date)

dmy sets the output format to be dd-mm-yy, and the 1 forces each section to be two digits. This is a key setting, because it will be more complicated to slice my date string up if I don't know exactly which characters I need. On 1-1-09, the month is the 3rd character, and the year is 5th and 6th. But on 11-11-09, month becomes the 4th and 5th characters, and the year shifts, too. By forcing each section to have 2 digits, I know which characters to aim for, regardless of the actual date. The result is dumped into the cur_date variable. Now to slice it up.

The help files have a page called Functions, and it describes the various math and string functions that are available. Probably the only one that will help here is STRMID(str1,a,b) which is defined as "Access a subset of "str1" beginning at character number "a" and up to and including character number "b" (if a=1, assumes start with first character)". Take a string, start at one character, go until another, and copy that out to make a new string. Perfect. But there is a pesky dash between MM-YY, so I can't just pull it all out in a single string. Oh well, do it twice, and assign the result to a different variable:

# NewDate = STRMID(cur_date,4,5) + "/" + STRMID(cur_date,7,8)

I take the 4th and 5th characters for MM, add my slash, then the 7th and 8th characters for YY. I now have today's date formatted the way I want it.

So what's the big deal? It's only two lines of code, how hard is that to copy and paste periodically? In this case, it's not a big deal. But if the code were more involved, there are more chances for bugs, and that bug would get repeated every time I copy-n-paste it until I actually fix it, at which point I then need to go revisit every program that contains the code and fix it again. I know I don't have my entire program suite memorized, so I'll probably forget to fix it somewhere, and good luck if anyone else has to figure it out in my place. But it doesn't even have to be about bugs. Let's say that we change our minds about the format of the date, and now I want MM/DD/YY. It sure would be nice to only have a single place to make that change, and then all of the other programs get it for free. And that's exactly what I'll do. Rather than leaving this code buried inside of other programs, I'll pull it out into its own program:

# IF (trace EQ 1) THEN Show Message ("}}}IN{{{ Entering get_date.prg")

C: --- Determine date
C:
# Inquire Date ("dmy", 1, cur_date)
# IF (trace EQ 1) THEN Show Message ("cur_date is: " + cur_date)

C: --- Reformat date to MM/YY
C:
# NewDate = STRMID(cur_date,4,5) + "/" + STRMID(cur_date,7,8)
# IF (trace EQ 1) THEN Show Message ("NewDate is: " + NewDate)

# IF (trace EQ 1) THEN Show Message ("{{{OUT}}} Done finding date...")

# EXIT

Anytime that this is run, I know that the variable NewDate will be populated with a date in my desired format. So in any other program where I would want that date, I just need to run this program like so:

# Execute Macro ("C:\get_date.prg",,)

That's mostly all that needs to happen. There are some additional considerations that I'll discuss at a later time, but for the most part this works really well. I have several of these single-purpose little modules: get user name, get sheet size, get all attributes out of a symbol, check the permissions on a drawing, and so on. This way I don't have to reinvent the wheel each time I start a new program. I utilize whatever pieces I already have, and then focus on what will be custom to my new program. For the most part, once the modules work, I've found them to be very reliable, so if errors crop up, I generally know to focus my attention on other areas of the code. Or, if there is a problem in a module, (well, for one it's probably causing a problem in a lot of different places) I fix it one time in one place and get all of the downstream benefits.

So there you have it. It's certainly not OOP in its purest form, but it is about as close as I could manage within the I-DEAS macro paradigm.