Resizing a UITableView’s tableHeaderView

Resizing a UITableView’s tableHeaderView

For many who use UITableView, unless you’re doing something like a Contacts application, the tableHeaderView (and related, tableFooterView) are rarely used.

What’s even more perplexing (at least when at first experienced), is that these elements are not repainted when a [UITableView reloadData] is issued; you have to manually issue field / image resets yourself.

Sometimes – like when handling a variable amount of data in the header, say for user status messages – you even have to adjust the size of the tableHeaderView in order to accomodate a growing / shrinking amount of real estate.

Here’s the trick:

CGRect headerFrame           = self.profile.tableHeaderView.frame;
headerFrame.size.height      = self.myStatus.frame.size.height + offset;
self.header.frame            = headerFrame;
self.profile.tableHeaderView = self.header;

First, grab the current header frame.  Then, adjust the size of the frame (in my example, I’m adjusting the height only).  Then, reset the tableHeaderView with the view again.

This is important – the size will not be adjusted until the tableHeaderView (or tableFooterView) variable is reset.

That’s it.

Hope this helps some of you struggling with this not-so-well documented problem.

Where Are Your Markets?

Where Are Your Markets?

I had a conversation with a friend today about the changing business of software services.  I’ll keep everything anonymous to protect the innocent.

Our conversation was basically about how one can no longer depend upon only those companies physically located nearby to fund ongoing development for small software contract services companies.

In traditional contract services, a software services company would approach or be approached by a company to develop software for hire for a specified cost (hourly or fixed) and for a specified deliverable or scope of work.  For most companies, this activity was geographically localized and software services companies tended to associate themselves with particular platforms (MS Windows, Novell, Apple, etc.).

That was then  THIS is now.

With the economy giving many hiring company the jitters, it’s especially tough for a localized software services company to find work and keep all of their employees “off the bench” (i.e., working on billable projects) – never mind that rising healthcare insurance costs and outsourcing have reduced margins on generalized software development projects.

In effect, for survival, companies that once depended on long lasting personal relationships with localized corporations are having to seek business beyond what was once a very comfortable bubble.

We certainly have been forced to do so.  In fact, I would say our business over the past twelve months has been about 90% outside of our local area (or international) and the remainder performed with companies in the greater Nashville area.

As cool as web development is, and as insular the echo chamber of social networking is, it becomes easy to lull oneself into thinking that social networking and web development constitute the be all and end all of software development today.  And that would be a mistake, because there is a ton of legacy and NEW desktop development ongoing today by armies of corporate developers and the software services houses that cater to them.  Getting entre to those companies and into the inner sanctums of the decision makers for these projects is tougher today, owing to the pressures listed above, and small software services houses simply have to cast broader and more diverse nets to get access to those opportunities.

Some obstacles to moving beyond a localized emphasis for these development opportunities and remote development opportunities are:

  • Finding a good fit with projects that are well specified and appropriate for remote development
  • Good management practices on both ends of the engagement that support and accommodate the remote development environment
  • Understanding that managing a geographically separated development team differs vastly from operating a development team in a collaborative or bullpen environment.

Immediately following 9/11, we had to significantly rethink our software services marketing strategy, because this was the first time that our company faced these pressures.  This became even more important to us when we were located in Florida during 2003-2005 and survived 3 hurricanes in six weeks.  If we had to depend upon local corporations solely, we would have died a sudden and inglorious death.

Doing business nationally and internationally today is worlds easier than it was when we started out back in 1996.  Tools for payment, such as PayPal, make it relatively straightforward to conduct business with people you may never actually get to meet in person.  In fact, I would say that accurately represents almost all of the business that I have done this year,with possibly one or two exceptions.

Business is not static.  Your views of your markets should not be, either.

Where do you fish?  Why, where the fish are, of course.

Where are your markets?