I received my shinny, new iPad 2 yesterday. When I turned it on I immediately saw yellowish discolorations along the top, right, and bottom edges. The discoloration at the top right corner is the worse and is about the size of my thumb. I tweeted about the problem to see if others have seen the same issue. A friend pointed me to this site which describes the problem and shows a picture of the discoloration.

So apparently this is a problem with the new iPad 2, but I don’t think it’s a major problem. Nor do I think it’s a problem with iPad 2 only. Here’s why.

It seems that many iPads will show some slight discoloration when displaying an all black screen with full brightness while in the dark. I see this on my first generation iPads, so this is not a new problem with the iPad 2. And I don’t see this as a major problem because under normal use you do not see the discoloration. I have used my first generation iPads (I have two of them) for nearly a year, and I have never noticed this problem. I can only see it when I display an all black screen with full brightness while in the dark, which is not a normal use case scenario.

With that said, the problem with my new iPad 2 is different. Yes, it’s the same yellowish discoloration, but in my particular case the discoloration is noticeable when using the iPad under normal conditions. The discoloration is visible on my device when running apps with black backgrounds (such as Kindle and Instapaper) with the brightness set to a low level while sitting in a room with natural daytime light. This is why I have asked Apple for a replacement. I wouldn’t care about the discoloration if it wasn’t noticeable under normal use, but for my particular device it is noticeable under normal use.

So before you panic and think you have a defective iPad 2 because you can see some discoloration when looking at an all black screen with full brightness while in the dark, see if the discoloration is noticeable under normal conditions. I’m willing to bet your iPad is perfectly fine.

I decided one of my apps should display placeholder text in a text view. Unfortunately UITextView does not have a placeholder property. I’ve always thought this is odd especially given the fact that UITextField has a placeholder property.

I googled to see what others have done. I found some good approaches but no one solution that I liked. So I decided to write my own borrowing from the various ideas of others. The end result is KTTextView.

KTTextView derives from UITextView and enhances it with new features. At the moment the only new feature is the placeholder text. The placeholderText property works same as UITextField’s placeholder property. I also added the property placeholderColor in case an app has the need to use a color different then the default placeholder color.

KTTextView is hosted on github. The project includes a sample app showing how to use KTTextView. I plan to add more features as time allows. One feature I want to add is an option to display the text view in a rounded rectangle giving it a similar look to UITextField. In the meantime, I hope you find the KTTextView’s current implementation useful.

Isn’t not like I need a distraction from work, but I couldn’t resist this one. I saw a tweet about iDOS, a DOS emulator app just released for iPad and iPhone. For fear the app will be pulled from the App Store, I bought it right away. Besides, it’s only 99 cent.

I read a story about someone installing Windows 3.0 inside of iDOS. Sounds cool but I’m not interested in Windows 3.0. Instead, I decided to install Turbo Pascal. Embarcadero recently posted Turbo Pascal v5.5 as a free download so the first thing I did was to grab a copy of it. Next, I grabbed an unzip program so I can unzip TP55.zip in iDOS. (Save time and go here to download unz552x3.exe.)

Here are the remaining steps I followed to get Turbo Pascal up and running on my iPad.

• Connect the iPad to iTunes.
• In iTunes, go to the Apps tab for the connected iPad and scroll down to the file sharing section.
• Drag and drop TP55.zip and unz552x3.exe to iDOS.
• Sync the device.
• Once sync is complete, launch iDOS on the iPad. You’ll find the two files in the root directory.
• Copy unz552x3.exe to a new directory, or just run it in the root directory. This will uncompress the unzip utility files. I prefer running it in a separate directory to keep the root clean.
• Unzip TP55.zip. This will create two directories, DISK1 and DISK2. Again, I copied TP55.zip to a temp directory before unzip.
• Run install.exe found in the DISK1 directory. If your experience is similar to mine, you will get a message saying to insert the oop/demos/bgi/doc diskette. I’m guessing the installer can’t find the directory DISK2.
• At this point, I aborted the install. Not to worry. Turbo Pascal’s IDE, compiler, etc have been installed.
• By default, the IDE can be found in c:\TP. The program file to run is turbo.exe.

That’s it. Happy coding!

Update: If those not lucky enough to grab a copy of iDOS from the App Store, you can download the source code for DOSPad and build your own version.

I’ve recently worked on a number of iOS projects that require a custom background for the UINavigationBar including the navigation bar used by the UINavigationController. Customizing the look of a UINavigationBar is actually pretty simple. You can set the tintColor property to the color of your choice. But sometimes you need to do more. For example, say you want to have a title in your navigation bar that uses a font not available on iPad and iPhone. For this you will need to use an image to customize the navigation bar.

Let’s take a look at the various ways to customize the navigation bar.

The UINavigationBar has a style property called barStyle. barStyle can be set to UIBarStyleDefault or UIBarStyleBlack. The default uses a blue gradient background. When using UIBarStyleBlack you can also set the translucent property to YES to give the navigation bar a partially opaque look. If you are using Interface Builder, then you will set the Style property in the Inspector window. Here you have the option to style the navigation bar as Default, Black Opaque, and Black Translucent.

What if you want a color other than blue and black? You can set the tintColor property (aka Tint in IB) to any color you like. This changes the navigation bar’s color. Best of all, setting the tintColor will also change the background color used by the bar button items displayed within the navigation bar.

Sometimes, however, just changing the tint of the UINavigationBar isn’t enough. Sometimes you want to have a fancier background. Maybe the background you want has a different gradient style or lighting effect, or maybe you want a title displayed in the center of the navigation bar to use a font not available in iOS. How would you change the look of the navigation bar for these scenarios? Simple. You use an image that is drawn on the navigation bar.

There are two approaches you can use to draw an image on the navigation bar. You can create a new class that inherits from UINavigationBar and override the drawRect method. For example:

@interface KTNavigationBar : UINavigationBar {

}
@end

@implementation KTNavigationBar

- (void) drawRect:(CGRect)rect
{
   [super drawRect:rect];

   UIImage *image = [UIImage imageNamed: @"navbar.png"];
   [image drawInRect:CGRectMake(0, 0, self.frame.size.width, self.frame.size.height)];
}

@end

In this example, the image navbar.png is used to customize, or skin, the UINavigationBar. This is a nice, clean, object orientated way to customize the look of your navigation bar. The only thing you must remember to do is to use your custom UINavigationBar class within your application. This means changing the class type for those of us using IB.

Another trick you can use that doesn’t require changing the class type is to use a category. For example:

@interface UINavigationBar (KTCustomLook)

- (void) drawRect:(CGRect)rect;

@end

@implementation UINavigationBar (KTCustomLook)

- (void) drawRect:(CGRect)rect
{
   UIImage *image = [UIImage imageNamed: @"navbar.png"];
   [image drawInRect:CGRectMake(0, 0, self.frame.size.width, self.frame.size.height)];
}

@end

I admit I have used this approach in more than one project, but doesn’t feel right to me. It feels more like using voodoo or black magic then following good OO design. But this approach does work and it does save you time by eliminating the need to change the class type for each instance of UINavigationBar within your app. [Update: This approach doesn't feel right because it overrides a method in a category. You should know this is a bad, bad thing, and I don't encourage others to do it. That said, it does work.]

One thing to note when using an image to customize the UINavigationBar, you still want to set the tintColor for the navigation bar. As I mentioned, setting this property will also change the background color used by the bar button items. So you want to set the tintColor to the appropriate color making the button color fit in with the navigation bar color style.

For those of you who want to see these concepts in action, I posted a sample project, called CustomNavBar, on github. Enjoy.

Fall is almost here and it’s going to be a busy on for me. Not only will I be heads down trying to finish my upcoming book, I will be speaking at two iOS developer conferences. The first conference is Voices That Matter in Philadelphia on October 16 and 17. This will be my first VTM, and I’m very excited to be apart of the event. There are a lot of great talks planned for the 2-day conference. My talk will be on the advantages of writing universal apps for iPad and iPhone. Early bird pricing ends today so register now to save money. Use the discount code PHASPKR to save even more money.

The second conference I’m speaking at this fall is 360iDev Austin. It’s no secret that 360iDev is one of my favorite developer conferences. I have made numerous friends since attending my first 360iDev last year, and the networking I’ve done at past 360iDev conferences has help land me paying gigs. My session at 360iDev will be on the fundamentals of iPad programming. This session is intended for anyone just starting out with iPad programming. Earlier bird pricing as already ended for 360iDev Austin but even at the full price of $599, it is money well spent if you are serious about iOS programming.

Today is my final update on the pricing experiment I started back in May. You can read the previous posts here and here. The goal of the experiment was to see if the sales trend for Labor Mate would continue at the higher price of $1.99. After three full months, I can say the higher price has done more harm than good.

Labor Mate continues to bring in over $1K per month despite the higher price, but the trend doesn’t look good. Over the last few weeks, the number of sales has decreased everywhere except in Japan. For some reason, sales are up in Japan and if not for Japanese sales in August, Labor Mate would have posted it’s worse sales month in 6 months.

Since it’s inception date, revenue for Labor Mate has been on a slow but steady rise. The higher price has reversed that trend. Labor Mate now appears to be on a slow but steady fall. Not only that, Labor Mate, which at one time was in the Health and Fitness Top 100 category in App Stores throughout the world, is not longer visible on any Top 100 chart, anywhere. This three month pricing experiment maybe the start of a slow death for Labor Mate, but it’s not done for yet.

I have big plans in the works, and a new update is just around the corner. I was planning a big release in a few weeks that would hopefully justify the $1.99 price tag in the eyes of consumers but I’m changing my strategy. Starting today, Labor Mate is back down to 99 cents, and instead of a big update in a few weeks, I’m going to release 3 or 4 updates over the next 1 to 2 months. My goal here is to get Labor Mate back on track and return to the trend I was seeing before the price increase.

Update: One thing I should point out is Labor Mate has a lot of competition. The other similar apps cost between free and 99 cents. This maybe a key reason why a $1.99 Labor Mate cannot sustain the slow but steady growth seen by the 99 cent Labor Mate.

I admit I don’t have a strong need for a stylus when using my iPad, but there have been occasions when I wish I had one. Using my finger to take notes in a drawing app is sometimes frustrating to me. My finger drawn text is usually too large, and on hot summer days, my finger doesn’t always glide smoothly over the surface of my iPad. So I decided to give an stylus a try. The problem was, which stylus to buy.

I narrowed my search down to two styluses, the Pogo Sketch from Ten One Design and the Boxwave Capacitive iPad Stylus. I spent more time than I should have reading reviews of both only to come to the conclusion: I don’t know which one to buy. So I bought both.

The Pogo Sketch gets points for price ($10.78 on Amazon at the time), which is much less than the Boxwave ($20.95 plus $4 shipping). Both work well on my iPad. The Pogo Sketch is longer and thinner, and felt cheaper than the Boxwave. The Boxwave stylus is heavier and thicker, much like a nice ball point pen, but it is short. I personally don’t mind the shortness since I’ve carried short pens in my pocket for most of my life, but others might not care for it.

The tip on the Pogo is shaped differently than on the Boxwave. With the Pogo tip, I can hold the stylus in different positions as I draw, sort of like a pencil. The Boxwave, on the other hand, is like using a pen. I find myself holding it in the same position as I would a pen.

The Pogo tip also looks like it could wear out quickly. With both styluses I must use more pressure to draw than I would with pencil and paper. I can’t help but feel I will flatten out the Pogo tip quickly with regular use. On the other hand, the Boxwave tip looks and feels solid, and I don’t have the same concern of it wearing out.

After spending time with both, I decided I prefer the Boxwave Capacitive iPad Stylus over the Pogo Sketch. I like the thickness and weight of the Boxwave, and it doesn’t have that cheap feel that the Pogo does. But $25 is a lot to spend. Given the amount of time I will use a stylus and having played with both, I know I would have been happy with the Pogo Sketch. But since I bought both, I will continue using the Boxwave stylus, and I will likely give away the Pogo Sketch at an NSHappyHour or similar event.

Speaking of NSHappyHour, I brought both styluses with me to the July NSHappyHour for others to try out. Jon Lee was kind enough to email me his own review, which I’ve included here. I love his final verdict.

Finger:

Pros: Always available when you need it. If you lose one, there is always another.

Cons: Pen tip is too squishy, and big. Writing by finger is an awkward user experience.

Pogo Sktech

Pros: Tip feels smaller, like you’re drawing with a thin Crayola marker. Using a stylus is familiar as a experience, as compared to finger painting.

Cons: The squishy sponge material makes me afraid that if I press too hard I will scratch the iPad surface with the edge of the ring that holds the sponge. Sponge feels very rippable after continued use.

Boxwave Capacitive iPad Stylus

Pros: Good weight, feels substantial. The tip, being rubber, feels like it could last longer than the Pogo.

Cons: The rubber end is like the bulb end of a turkey baster. And it feels like you’re writing with one. The thicker footprint does not make me feel like I have a high chance of being accurate when I draw. And $20? Really?

Verdict:
Make your own.

Last week I tweeted about having rotation issues with an iPad app I’m working on. This is the second time in recent weeks I’ve encountered rotation issues in an app. In both instances I was using a UIScrollView so I started thinking the UIScrollView was source of my problems. In the most recent instance the UIScrollView contains a UIView that uses a number of CALayer instances for content display.

For those who don’t know, in Mac OS X 10.5 and greater, CALayer has the autoresizingMask property. Unfortunately this property does not exists under iOS, so it’s up to my code to do the resizing CALayers as needed. This is where the rotation issue revealed itself.

As the device is rotated from portrait to landscape, or vice versa, my view must resize and adjust the layout of the CALayers. Because UIView does not receive the rotation notifications I decided to be smart and use the orientation property from UIDevice. So in my view I had code similar to this:

UIInterfaceOrientation interfaceOrientation = [[UIDevice currentDevice] orientation];
if (UIInterfaceOrientationIsLandscape(interfaceOrientation) == YES) {
  // Adjust for landscape.
} else {
  // Adjust for portrait.
}

What I failed to realize, however, is that the property orientation will always return 0 unless orientation notifications are enabled. Here is a quote directly from the Developer Documentation:

“The value of this property always returns 0 unless orientation notifications have been enabled by calling beginGeneratingDeviceOrientationNotifications.”

Doh! Guess I should have RTFM sooner.

Because the orientation property will return 0, sometimes the view in my app would not rotate. But I didn’t know this was the source of the problem at the time.

After banging my head over and over on the wall, I decided to investigate exactly what was happening. I never suspected [[UIDevice currentDevice] orientation] but eventually I noticed it was returning 0. This seemed odd so I checked the Developer Documentation. I wasn’t expecting to learn anything new. Boy, was I wrong. I was surprised when I read the property always returns 0 when orientation notifications are not enabled.

I now knew the source of my rotation problems, and a likely quick fix to the problem would have been to call beginGeneratingDeviceOrientationNotifications, get the device orientation, then call endGeneratingDeviceOrientationNotifications. But this just seemed wrong to me. The better fix, in my opinion, is to rely on the rotation notifications received by the view controller, so that’s exactly what I did.

Now in my particular situation, there are two times I want to resize and layout the CALayers in the UIView. One of those times is when the device is rotated, which is when the view controller receives the willRotateToInterfaceOrientation:duration: message. This was easy to solve. I added an adjustLayoutToInterfaceOrientation: method to my UIView and I call the method inside the UIViewController’s willRotateToInterfaceOrientation:duration: method. For example:

- (void)willRotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation
                                duration:(NSTimeInterval)duration
{
   [view_ adjustLayoutToInterfaceOrientation:toInterfaceOrientation];
}

The other time my UIView needs to adjust the layout of the CALayers is when the UIScrollView scrolls. I’m using a modified version of Matt Gallagher’s virtual pages in a UIScrollView approach, so the contents of my view changes as the user scrolls. This is where, previously, I was trying to be smart and use the orientation property from UIDevice. But what I really need is the current orientation as received in the most recent call to willRotateToInterfaceOrientation:duration:.

My solution was to add the ivar currentOrientation to my view controller. My view already has a reference to the view controller. I exposed currentOrientation so my view can retrieve the property value. This allowed me to replace the [[UIDevice currentDevice] orientation] code with [controller currentOrientation]. Now the view always knows the current orientation and the app does not need to enable orientation notification in code.

As a result, the first code snippet in this posting changes to:

UIInterfaceOrientation interfaceOrientation = [controller_ currentOrientation];
if (UIInterfaceOrientationIsLandscape(interfaceOrientation) == YES) {
  // Adjust for landscape.
} else {
  // Adjust for portrait.
}

And the willRotateToInterfaceOrientation:duration: implementation changes to:

- (void)willRotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation
                                duration:(NSTimeInterval)duration
{
   currentOrientation_ = toInterfaceOrientation;
   [view_ adjustLayoutToInterfaceOrientation:toInterfaceOrientation];
}

This has been an eye opener for me, and I now have a new rule of thumb. Never use UIDevice orientation in code that is responsible for the resizing and layouts of subviews and CALayers.

Last week I had the opportunity to teach a one-day class on learning iPad programming. One of the students asked what books I recommend. A friend asked the same question over the weekend, so I thought I might as well post the list of books on iOS and Objective-C programming I have found helpful.

• Beginning iPhone 3 Development, Dave Mark and Jeff LaMarche
• More iPhone 3 Development, Dave Mark and Jeff LaMarche
• iPhone App Development, the missing manual, Craig Hockenberry
• Core Data, Marcus Zarra
• iPhone SDK Development, Bill Dudney and Chris Adamson
• iPad Programming, Daniel Steinberg and Eric Freeman
• The iPhone Developer’s Cookbook, Erica Sadun
• Programming in Objective-C, Stephen Kochan
• Tapworthy, Designing Great iPhone Apps, Josh Clark

A friend asked if I would put together a sample iOS app that shows how to display a stopwatch timer like the one used in Labor Mate. It seemed like a fun exercise to break up the night, so I said, “Sure, why not.”

I decided others might find the sample source code useful so I posted the project to github for all to enjoy. The piece devs might find interesting is the KTStopwatch class. This is a simplified version of the class I use in Labor Mate. It supports wall clock and elapsed time.

The source code is licensed using The MIT License, so do with it what you like. Enjoy.