Adobe is becoming the Jay Leno of developer tools

Adobe needs to take a page from David Letterman: "You get fired, you get another gig! You go across the street and you punish them and you make them eat your words!"

Adobe is trying to leverage public opinion - and even government intervention! - by portraying itself as the victim of a monopoly power. They start with the assumption that the iPhone is the only gateway to the mobile web, and of course it's not. The high road would be to make a Flash runtime for Android that kicks so much ass that Apple has to change their stance or be left behind in the market. This duplicitous war of words is a low road, a beggar's stance. A Jay Leno move.

Can I make a UIView transition to itself?

Sure, why not?

Let's say you have a UIViewController and you want the base view to do a CATransition from itself to itself:

- (void)doTransToSelf {
    CATransition *anime = [CATransition animation];
    anime.type = kCATransitionPush;
    anime.subtype = kCATransitionFromRight;
    anime.duration = 0.5;

    UIView *mySuper = self.view.superview;
    [self.view removeFromSuperview];
    [mySuper addSubview:self.view];
    [mySuper.layer addAnimation:anime forKey:nil];
}

Or, changing this to work on a subview of self.view is trivial.

So, why would you want to do this? In my case, I have a collection of data objects and a UIView that is the user interface for editing one object. When the user is ready to move on and edit the next object in the collection, the user interface doesn't substantially change, I'm really just changing the data object that is the target of the user's edits. So I want to re-use the same view with the same set of IBOutlets, and just do the transition as a visual cue to the user - "okay, you're working on a different object now."

Why won't my backBarButtonItem use its action?

Or, How to make a backBarButtonItem send its action to its target.

Answer: you don't.

Because a backBarButtonItem is a UIBarButtonItem, it has "target" and "action" properties, leading you to believe that if you assign values to those properties, shit will happen. Alas, shit will not happen. Or rather, the usual shit will happen, but not the extra shit you hoped would happen. The backBarButtonItem is special - no matter what you do with those properties, «target» will never receive a message for «action».

What you can do instead is assign a delegate to either your UINavigationController or UINavigationBar. Both of these classes have delegate protocols that give you opportunities to act when the stack of view controllers changes. I've been using my root view controller as the delegate object, since that one never gets popped off the stack.

Putting a background behind a UIView transition

When doing a setAnimationTransition: with a UIView, you can do a "flip left/right" or a "curl up/down". If you do a flip left/right, you'll usually see a blank black screen "behind" the view as it flips. (The built-in Stocks app does this.) Recently someone asked me if you could have something else back there, and I thought "huh, that's interesting, I never tried that" and we investigated. It turns out that you can, but you have to set up the view stack properly.

So let's say we have 3 UIView objects, frontView, backView, and rootView. Before the transition begins, frontView is a visible subview of rootView and backView is not yet in the view stack. You begin an animation block and then (usually) do [frontView removeFromSuperview] followed by [rootView addSubview:backView], then commit the animation block and watch the animation take place. You might think that adding another subview of rootView, one that sits below frontView, would make that view be visible behind the animation during the transition. At least, that's what I thought, but it doesn't work. I'm not sure why, but it seems that rootView and all of his subviews become "invisible" during the transition.

But, but! if you put another UIView under rootView, that view will be visible during the transition. Maybe in your project, your views are already set up that way. But if frontView and backView are immediate subviews of the main window, then of course nothing can be below the main window, and you'll need to interpose another UIView object into your view stack.

Instead of posting sample code, I'm going to suggest downloading the LocateMe sample app from ADC. It's already designed with a "main" view and a "flipside" view who are subviews of a root view, and the root view is a subview of the main window. Get the project, open the MainWindow.xib, and add a UIImageView (for example) in the main window:


Make sure the toggleView method is using UIViewAnimationTransitionFlipFromLeft(Right) in its animation block (it doesn't make sense with the curl up/down animation) and then build and run the project.

iPhone: Development provisioning profiles and the Entitlements file

I found what appears to be a disconnect between Apple's provisioning documentation and what actually goes on in Xcode. If you want to build your project for development (testing) on your own device, the documentation says to select the top-level build target of your application, open the Info window, click the Build tab, and set "Code Signing Identity" -> "Any iPhone OS" to be "iPhone Developer: YourFirstName YourLastName". (Presumably you must enter your name exactly as it appears on the Team page of your developer portal.) That part works fine. Next, according to the documentation, you should set "Code Signing Provisioning Profile" to be the provisioning profile you created for your combination of name/device/application. When I go to my XCode, there is no such entry!

Instead, just above "Code Signing Identity" is an entry called "Code Signing Entitlements". What I had to do is create a new property list file in my project called Entitlements.plist. The contents of that file look like this:



Where the application-identifier is the exact App ID from your developer portal, including the 10-character prefix. And then back in the Info window, set the value of "Code Signing Entitlements" to simply be "Entitlements.plist". Drag and drop the provisioning profile onto the XCode Organizer, if you haven't already. Now you can build and push the app to your iPhone.

In case you missed it in the 80s, here comes the sequel

App Store: I'm out (Fraser Speirs)

Apple Extends NDA to Rejection Letters (Arnold Kim)

Beneath Apple (Brent Simmons)

"[Microsoft] is annoying, but (in the end) not half so annoying as watching Apple inscrutably and relentlessly destroy itself."
   - Neal Stephenson in 1999

Dear Mac developers: the mobile app market existed before you came along

One of my friends sent me this excellent article examining the state of the mobile app industry. People who want to bitch about the iPhone app model should read some history first. Then at least they can do some informed bitching.

Mobile Applications, RIP

Wishlist: more efficient scrolling for the iPhone

I've had an iPod Touch for about a month now, and I love it to death. But as humans tend to do, I'm going to be general in my praise and detailed in my gripes. But wait! because I have a proposed solution to my gripe.

My praise: it's awesome. It's still not my perfect iTablet, but I'm using it for the same reasons - I can access the net, in comfort, without using a keyboard.

My gripe: there is no way to jump to the bottom of a web page in Mobile Safari, or to quickly scroll through a very vertical page. This recently got especially tedious for me while I was skimming some archives of Daring Fireball, because some of his essays are rather long, and the link to the next article is always at the bottom. Flick, flick, flick, flick, flick, flick, to get to the bottom of the page. Link to next page, repeat.

Now when you put your finger on a page and start to drag it, a translucent scrollbar appears in the margin to give you a sense of where you are in the page. But you can't grab that scrollbar and use it for anything. It's more of a "scroll indicator."

So my proposed solution: why not let me grab it? If I put one finger on the page, the scrollbar appears, and then I can "pin it" under another finger (probably a finger of the opposite hand) and as long as I have it pinned, moving my finger to the bottom of the screen takes me to the absolute bottom of the web page, and the top of the screen, vice versa. The rate of the scrolling would be relative to the size of the page, just like a windowed app on a desktop computer. I'll be the first to say this isn't intuitive or even convenient - it's actually a little awkward. But dammit, it would work and it would be there for people who know about it.

My other gripe: there's no "Find in Page" with Mobile Safari. What's up with that? For about the first week I kept going to the magnifying glass when I wanted to find a word on the page. Even though I knew that button brings up Google, my brain kept trying to map my ⌘-F reflex to something. I don't have a solution for that, except - add it!

iPhone keyboard isn't faster - but who cares?

I keep Slashdot in my RSS because it's still a great clearing house for links. But the asinine commentary that comes with the links drives me crazy. Case in point:

"One of the selling points of the iPhone was its revolutionary touch-screen full keyboard. But a study has shown that text messages sent from iPhones contain significantly more typso than messages from phones with other kinds of keyboards — and aren't entered any faster."

Yes the virtual keyboard was touted as a revolutionary selling point. But the revolution is not to be "better" or "faster." The point is that the virtual keyboard allows for a mutable interface. When you don't need the keyboard, it's not there, not taking up precious real estate on the surface of the device. Equally important, the touch screen allows for intuitive interfaces that aren't forced thru the keyboard. Slide to unlock, touch a voicemail to hear it, touch a link to follow it, etc. So the virtual keyboard doesn't need to be "better", it just needs to be "good enough."

Will the iPhone become the Phone?

By now everyone who knows about the iPhone also knows that Cisco owns the trademark on "iPhone" in the United States. Cisco and Apple were in negotiations over the US trademark, but then Cisco got mad and decided to take it to court. Everyone assumes it's a matter of money. But now Cisco has said something very interesting:

What were the issues at the table that kept us from an agreement? Was it money? No. Was it a royalty on every Apple phone? No. Was it an exchange for Cisco products or services? No.

Fundamentally we wanted an open approach. We hoped our products could interoperate in the future.

- http://blogs.cisco.com/news/2007/01/update_on_ciscos_iphone_tradem.html

Reading between the lines, Apple already tried greeting Cisco with a dumptruck full of cash, and Cisco said "no, thanks, we already have several of those." Rather, Cisco wanted to be allowed to play in Apple's new ballpark. Rather a cagey move by Cisco. But Apple, famous for exerting end-to-end control over their products, naturally balked at that.

But then why did Apple go ahead and announce it as "iPhone" anyway?

For starters, Apple does own a trademark on "iPhone" in some other countries, just not in the United States. If you announce a product which will (eventually) be sold in those countries, but you make the announcement in a country where you don't hold the trademark, have you broken the law? I don't know.

Also, remember that about 6 months ago, Apple pre-announced a product codenamed "iTV" which is now officially known as tv (or, AppleTV.) Are they going to defend against the lawsuit by saying iPhone is just a project name? Is that a defensible position? Again, don't know.

Several people, including the venerable Bob Cringely, are going with the theory that any publicity is good publicity, and announcing it as the "iPhone" now cements the correlation between iPod and iPhone in the public consciousness, even if it ships under another name.

Or, did Apple just assume everything would work out the way they wanted? That would be a very John Sculley thing to do, but it's not beyond possibility.