Archive for the 'cocoa' category
iPhone: nibless
February 28, 2010 5:07 pmUIProgressHUD replacement
February 27, 2010 11:22 pmDear internet: I have been searching for a UIProgressHUD replacement for many, many months. Why have you failed me? I don’t suppose it was because of that other, similarly named UIProgressHUD replacement? Which I am not going to link to or name, because it sucks. Sorry, yes I am a jerk, but it does. If I have to explain to you why it’s a bad idea to make a progress view that’s launching background tasks, then there is no helping you.
UIProgressHUD
So, anyway. In case you’re new to this. UIKit has a nice control called UIProgressHUD for displaying a heads-up, semi-transparent view with a spinny-control on it, and a single line of text. It looks good, it works well, it’s easy. The only down side is that it’s undocumented, so you can’t use it in apps destined for the App Store.
I used UIProgressHUD in a project I was writing for a client a few months ago. This particular app was not destined for the App Store, so it seemed like a nice shortcut. Maybe that’s not such a hot idea, but they weren’t paying much, so I couldn’t justify a detour for writing a brand-new view. But now here I am again, needing the exact same thing for my card game, and google searches still only turn up that progress view that thinks it’s an app launcher. Hrmph. Time to write my own, I guess.
WBProgressHUD
My goal was to write an exact, drop-in replacement for that view I can’t use. I’ve included screenshots of Apple’s original view, and my clone view. Pretty darn close, don’t you think? The only real differences are details that I don’t want to change. For example, I think they picked a font size that’s a bit excessive.
It would be great if I could just paste the source file and header file right into this post, for your amusement. My view is mercifully short, and would lend itself to that. Alas, it requires several support modules, so I had to make it into an example Xcode project. I’ve developed a huge library of iPhone support code by this point, so it doesn’t make sense to duplicate things in every single view and controller I write.
One clever feature of my demo project: you can change one line of code and it will use either UIProgressHUD or my own WBProgressHUD. No other code has to change, because the two views are that similar, dawg. It makes for a good test bed for developing a clone view such as this one.
Download wbprogresshud.zip by clicking here. If you like this project, how about hiring me to write more stuff like it? My contact details are on my About page.
iPhone and iPad SDK coexistence
February 14, 2010 7:14 amiPhone: UIImage rotation and scaling
January 31, 2010 8:03 pmiPhone: keyboard trouble
August 28, 2009 3:07 am
It is possible to type into two or more of these fields without dismissing the keyboard
A couple of months ago, a user of my card game reported a bug. He said that when he tried to change the names of all the robot players at once, only one of them actually changed. I tried to duplicate the problem, but couldn’t. For me, all three robot player names changed. I asked him for more details, but like many non-technical users, he wasn’t able to articulate the problem very well. He said he kept fiddling and fiddling and eventually got all three names changed. I had made a real effort to duplicate the bug and failed. So I wrote this one off as user error.
Over the next few weeks, the same bug got reported three more times. I was still not able to reproduce it. I asked for more specific instructions on how to tickle the bug, but none of this batch of people took the time to send a second email. I can’t blame them. Most people view it as a frivolous time-wasting diversion, useful for whiling away a few minutes while in line at the grocery or something.
Fortunately for me, the fifth report came from a fellow programmer. He provided very explicit instructions, and I was finally able to reproduce it. Now that I understand what was happening, it’s no small wonder that it evaded me for so long. The problem was that my mental model of how the iPhone accepts text input was wrong.
I had assumed the sequence of events was always like this:
• User touches an editable text field
• Keyboard rolls up into view
• User types some text
• User presses the return key on the keyboard
• Program forces the keyboard to disappear
• Program processes the new text
But guess what, here is another possible sequence of events:
• User touches an editable text input field
• Keyboard rolls up into view
• User types some text
• User touches a second text input field
• User edits the second input field
• User presses the return key on the keyboard
• Program forces the keyboard to disappear
• Program processes the new text
A third possible outcome is that the user navigates away from the current view to a different one, and therefore never presses the return key.
This sounds complicated, but it turns out that the fix is pretty easy. You simply have to treat “user pressed the return key” and “user finished editing” as two separate events, rather than conflating them as one.
The assumption here it that your users are typing into UITextField objects. The fix I’m proposing is for UITextField delegates, i.e., whatever object implements the UITextFieldDelegate protocol. Here’s an example implementation of one of those methods:
-(BOOL)textFieldShouldReturn:(UITextField*)textField { [textField resignFirstResponder]; return TRUE; }
This is the delegate method that gets called when the return key is pressed. I used to process the newly-edited text field contents in here. That was a mistake which led to the bug I’m talking about. In a typical implementation of this method, the only thing you want to do is make the keyboard go away, which is what the [textField resignFirstResponder] line does.
Here’s the method you should implement to deal with new text field contents:
-(void)textFieldDidEndEditing:(UITextField*)textField { // deal with new text field contents here }
I can’t show a typical implementation, because only you can decide what you should be doing with the new contents of the text field. But as far as I can tell, this method is always called when the user is finished editing the text field, regardless of why that happened. It could be because the return key was pressed, or because the user switched to a different text field, or because she switched away from the parent view altogether, or perhaps other reasons I’m not aware of.
NSLog() sucks
July 18, 2009 8:15 amDrawing NSStrings in unusual rotations
June 1, 2009 8:10 pmIf you’re used to writing apps for desktop computers, the iPhone’s screen can seem awfully small. You must make creative use of every pixel available to you. One way to do that is to draw some text vertically, rather than horizontally, which I decided to do for an iPhone app I’m working on right now.
For drawing normal horizontal text, UIKit has a category called UIStringDrawing that provides convenient methods for drawing the contents of an NSString to the current graphics context, like drawAtPoint:withFont: and drawInRect:withFont:. Sadly, UIKit does not provide methods for drawing text in any other orientation except standard horizontal. I will now present an NSString category you can add to your own iPhone projects that allows you to draw vertical text from bottom to top, top to bottom, or horizontal text upside down.
My category supports the same three UITextAlignment options that UIKit provides for left, right, or centered text alignment. If using my drawInRect:... method to draw a string that’s too wide to fit within the rectangle supplied, the right end of the string will be truncated to fit, with an ellipsis character added.
UIKit does a better job of handling long strings than my code does. UIKit can wrap text to two or more lines, for example, which I did not try to emulate. The UIKit methods also allow you to provide a UILineBreakMode enum value, which gives you fine-grained control over how strings are truncated. I personally don’t need that much flexibility, so my category has no such support.
Finally, there is one last limitation of my category that might be a deal-breaker for you. The standard UIKit string-drawing functions can be used to display any Unicode character, so long as the font you’re using has a glyph for it. My category is limited to the roughly 255 characters present in the MacRoman character set. That means my code is good for displaying text in English and most European languages, like French and German, but it is completely unsuitable for text in, say, Chinese.
I’m aware that this is an outrageous limitation. You’d be hard-pressed to find a programmer who is more gung ho about Unicode than I am. I struggled mightily for several days trying to find a way around this. Sadly, this is due to the way that the underlying CoreGraphics drawing routines work, and there is no good way around it that I can see. I’ll cover this in more detail later, in case you’re interested.
Using the WBTextDrawing category
I’ve included a sample Xcode project that demonstrates the use of my WBTextDrawing category. Download the project by clicking here.
I’ve provided a screen-shot, but it isn’t much to look at. There are five strings displayed onscreen. The four strings at the edges of the view are displayed with my own WBTextDrawing category, drawn in all four available orientations. The string in the center is drawn with one of UIKit’s own drawInRect:... methods. The lines in red show the bounding rects used to draw the five strings. The four strings around the edges all have an associated green pixel, which illustrates the draw point used to draw that particular string. Naturally you wouldn’t draw the green and red bits in a real app. I added them to this demo so you’ll have a better idea of what’s going on.
Almost all the code in the project is boilerplate that can be safely ignored. To add my string-drawing category to your own program, copy WBTextDrawing.mm and WBTextDrawing.h out of this project and into your own. All other source files presented here are for demonstration purposes only.
You will note that WBTextDrawing.mm ends with an mm extension, rather than the usual m. That’s because this source file must be compiled as Objective-C++, due to the fact that it contains a small amount of C++. I know many Objective-C programmers have a strong aversion to C++, and believe me, I understand! But the underlying CoreGraphics method that’s used to draw rotated strings insists on being given a const char*. It does not work with NSString objects directly. So I chose to convert NSString objects to std::string objects just before drawing them. Yes, I could have accomplished this without leaving the confines of Objective-C, but std::string seems to me like the best tool for the job.
Specifying text drawing locations
UIKit’s UIStringDrawing category contains several drawAtPoint:... methods for drawing NSString objects. The point you pass to these methods is the far left end of the font’s baseline, as illustrated by the green point in the first figure. For the sake of compatibility, I chose to use this same convention for the drawAtPoint:... method in my own WBTextDrawing category. No matter what drawing orientation you’re using, the specified draw point is always the far left end of the font’s baseline, relative to the string being drawn. This is also the way the low-level CoreGraphics drawing routines work, conveniently enough. See the second figure for what this looks like when drawing a bottom-to-top vertical string.
UIStringDrawing also has several drawInRect:... methods. In this case, the rectangle supplied is the entire area allotted for drawing the string, illustrated by the red rectangles in figure one and figure two. Again, my own WBTextDrawing category does the exact same thing, for compatibility’s sake.
Text drawn is limited to MacRoman
This is without a doubt the worst limitation of my WBTextDrawing category. I see no good way around it, however.
Whatever method you use for drawing rotated text, you must accomplish two goals: 1) Apply a given font to the current drawing context, and 2) Draw the NSString supplied by the caller. The easiest way I can see to apply a font is to use CGContextSelectFont(). That method gives you two encoding options: kCGEncodingMacRoman, which uses the MacRoman encoding, or kCGEncodingFontSpecific, which means you must provide your own character-to-glyph translations, as far as I can tell. Ahem. UIKit can’t do this by itself, apparently, but the expectation is that us lowly app programmers should be able to do it? As if. So the only real option here is to use the MacRoman encoding, then use CGContextShowText() to display the text. This is the way my category works. Anything outside the MacRoman character set displays as gibberish.
There’s another method you can use to apply a font to the current context: CGContextSetFont(). This method doesn’t take any kind of encoding parameter at all, so it would appear to be immune from the problems presented by CGContextSelectFont(). Alas, once you’ve called that method, CGContextShowText() doesn’t work anymore. The CoreGraphics docs say you should instead call CGContextShowGlyphsAtPoint(). That function expects its caller to supply an array of glyphs, not characters. Which implies that you’ve got some method up your sleeve that will convert characters to glyphs for a given encoding. I don’t know about you, but I don’t have any such method lying around. So I’m stuck with boring old MacRoman.
This seems like an awfully strange limitation to build into the low-level CoreGraphics text drawing routines. If you know of any way around it, please tell me what it is, so I can update my text-drawing category appropriately.
Beta testers wanted
May 14, 2009 1:42 amcocoa: app memory usage
May 3, 2009 6:30 pmiphone: drawing rectangles
April 28, 2009 9:33 amMac/AppKit and iPhone/UIKit development are more alike than different. In general, I’d say the iPhone APIs feel more “fresh” than their Mac equivalents. It seems to me like the current crop of Cocoa engineers at Apple have learned a lot in the years since the company ditched “classic” MacOS for an updated version of NextStep, and they’ve used that wisdom to design this new crop of frameworks. And they’re not afraid to revisit past decisions that didn’t work out so well: they discarded MacOSX’s view-origin-in-the-lower-left-corner mistake and put it in the upper left corner for the iPhone, where it belongs.
On the other hand, AppKit is far more complete than UIKit. Almost anything user-interface-related you might want to do on the Mac is covered by APIs in AppKit. UIKit is missing many of those amenities, likely because it is targeted at resource-constrained devices that don’t have the space for dozens of multi-megabyte frameworks. The practical upshot is that I’ve spent a lot of time writing iPhone stuff that AppKit would have provided for me. All the more reason to write blog posts like this one, so coders can google up the answers rather than spending days reinventing wheels.
I like drawing rectangles. Only rarely do they end up in my final apps, but I use them a lot while debugging, to ensure that a view area I’ve staked out is where it should be. On the iPhone, this kind of thing is done with Core Graphics. It is a very complete framework. You can do anything with it. The down side is that CG code tends to be verbose and complicated, requiring lots of function calls to do the simplest things. This is a situation crying out for wrapper functions.
I’ve written a UIView category that provides methods for drawing just about any type of rectangle you can think of: filled or outlined, rounded corners or square, including point-drawing methods. You can provide a color to draw with, or use the current draw color, which is black, unless you change it. You can draw a translucent rectangle by specifying a draw color that has an alpha value of less than one. You can change the radius of the rounded corners drawn by fiddling with the constant kCornerSize at the top of the implementation file.
This is beginner-level stuff, so I guess I should add that UIKit doesn’t let you draw things whenever you feel like it. (That’s true for all GUI environments I’ve ever programmed for, now that I think about it.) You must draw only within a UIView’s drawRect: method. If this is news to you, you should read one of Apple’s introductory texts before continuing.
Here’s a sample drawRect: method you can add to an existing view to demonstrate the rect-drawing methods:
-(void)drawRect:(CGRect)rect { CGRect test = CGRectMake(0.0, 0.0, 20.0, 20.0); [self strokeRect:test color:[UIColor magentaColor]]; test.origin.x += test.size.width; [self strokeRoundRect:test color:[UIColor yellowColor]]; test.origin.x += test.size.width; [self fillRect:test color:[UIColor blueColor]]; test.origin.x += test.size.width; [self fillRoundRect:test color:[UIColor redColor]]; }
… which produces the output shown in the screen-shot. here’s the header file for the category:
// WBViewRect.h -- rectangle drawing methods for UIView // by allen brunson march 2 2009 #ifndef WBVIEWRECT_H #define WBVIEWRECT_H #import <UIKit/UIKit.h> @interface UIView (WBViewRect) // save and restore graphics context -(void)contextRestore:(CGContextRef)context; -(CGContextRef)contextSave; // points -(void)drawPoint:(CGPoint)point; -(void)drawPoint:(CGPoint)point color:(UIColor*)color; // filled rects -(void)fillRect:(CGRect)rect; -(void)fillRect:(CGRect)rect color:(UIColor*)color; // filled rects with rounded corners -(void)fillRoundRect:(CGRect)rect; -(void)fillRoundRect:(CGRect)rect color:(UIColor*)color; // outlined rects -(void)strokeRect:(CGRect)rect; -(void)strokeRect:(CGRect)rect color:(UIColor*)color; // outlined rects with rounded corners -(void)strokeRoundRect:(CGRect)rect; -(void)strokeRoundRect:(CGRect)rect color:(UIColor*)color; @end #endif // WBVIEWRECT_H
Finally, here’s the implementation file:
// WBViewRect.mm -- rectangle drawing methods for UIView // by allen brunson march 2 2009 #include "WBViewRect.h" #pragma mark module data static const CGFloat kCornerSize = 5.0; static CGRect rectStrokeAdjust(CGRect rect) { rect = CGRectIntegral(rect); rect.origin.x += 0.5; rect.origin.y += 0.5; rect.size.width -= 1.0; rect.size.height -= 1.0; return rect; } static void roundRect(CGContextRef context, CGRect rect, CGFloat ovalWidth, CGFloat ovalHeight) { CGFloat fw = 0.0; CGFloat fh = 0.0; assert(ovalWidth >= 1.0); assert(ovalHeight >= 1.0); CGContextSaveGState(context); CGContextTranslateCTM(context, CGRectGetMinX(rect), CGRectGetMinY(rect)); CGContextScaleCTM(context, ovalWidth, ovalHeight); fw = rect.size.width / ovalWidth; fh = rect.size.height / ovalHeight; CGContextMoveToPoint(context, fw, fh / 2.0); CGContextAddArcToPoint(context, fw, fh, fw / 2.0, fh, 1.0); CGContextAddArcToPoint(context, 0.0, fh, 0, fh / 2.0, 1.0); CGContextAddArcToPoint(context, 0.0, 0.0, fw / 2.0, 0, 1.0); CGContextAddArcToPoint(context, fw, 0.0, fw, fh / 2.0, 1.0); CGContextClosePath(context); CGContextRestoreGState(context); } @implementation UIView (WBRectView) -(void)contextRestore:(CGContextRef)context { CGContextRestoreGState(context); } -(CGContextRef)contextSave { CGContextRef ctxt = UIGraphicsGetCurrentContext(); CGContextSaveGState(ctxt); return ctxt; } -(void)drawPoint:(CGPoint)point { [self drawPoint:point color:nil]; } -(void)drawPoint:(CGPoint)point color:(UIColor*)color { CGRect rect = CGRectMake(point.x, point.y, 1.0, 1.0); [self fillRect:rect color:color]; } -(void)fillRect:(CGRect)rect { [self fillRect:rect color:nil]; } -(void)fillRect:(CGRect)rect color:(UIColor*)color { CGContextRef ctxt = [self contextSave]; if (color) { CGContextSetFillColorWithColor(ctxt, [color CGColor]); } UIRectFill(rect); [self contextRestore:ctxt]; } -(void)fillRoundRect:(CGRect)rect { [self fillRoundRect:rect color:nil]; } -(void)fillRoundRect:(CGRect)rect color:(UIColor*)color { CGContextRef ctxt = [self contextSave]; roundRect(ctxt, rect, kCornerSize, kCornerSize); if (color) { CGContextSetFillColorWithColor(ctxt, [color CGColor]); } CGContextFillPath(ctxt); [self contextRestore:ctxt]; } -(void)strokeRect:(CGRect)rect { [self strokeRect:rect color:nil]; } -(void)strokeRect:(CGRect)rect color:(UIColor*)color { CGContextRef ctxt = [self contextSave]; if (color) { CGContextSetStrokeColorWithColor(ctxt, [color CGColor]); } UIRectFrame(rect); [self contextRestore:ctxt]; } -(void)strokeRoundRect:(CGRect)rect { [self strokeRoundRect:rect color:nil]; } -(void)strokeRoundRect:(CGRect)rect color:(UIColor*)color { CGContextRef ctxt = [self contextSave]; rect = rectStrokeAdjust(rect); roundRect(ctxt, rect, kCornerSize, kCornerSize); if (color) { CGContextSetStrokeColorWithColor(ctxt, [color CGColor]); } CGContextStrokePath(ctxt); [self contextRestore:ctxt]; } @end
