Rather than a long, ranting post you can view some pix and screen captures of my new HTC Incredible over on Flickr.

Some reasons for the switch:

• iPhone OS 4.0. This new OS disenfranchises 1G iPhone users completely and proves Apple under-designed hardware for 3G users. If It truly needs a 3GS or a 4G to gain most of the functionality of their iPhone 4.0 OS (I have been running the betas on my 3G), then there is little point of continuing to buy into their product stream. It's only a matter of time before new apps no longer run on these older phones (but it will still be illegal for you to jailbreak them and continue to get use out of them).
  
  
  
  
• The Apple App Store. I'm really disliking the "gatekeeper" model that many companies are trying to have burned into the minds of the masses. I can load any Android app I want to on my Incredible and have the option to continue to use the Android Marketplace. The disdain for the App Store has been further seeded by the new iBookstore where - if I had an iPad - I could go to buy even more DRM'd books than I already own (a different rant post coming on that at some point as well).
  
  
  
  
• iTunes. Complete bloatware that is slow, buggy and in need of as much (or more) of an overhaul as the OS X Finder.
  
  
  
  
• AT&T. Wretched coverage here in upper New England and very poor customer service. Verizon has actually been much better (so far)

I've only had my Incredible for a few days, but it's very cool having control over my device again and having options. As you'll see in the Flickr set, I use both doubleTwist and the Missing Sync for Android from mark/space to manage my device on my Mac (I also use the built-in OS X Image Capture app). I didn't need to use these apps, but I did not want to have be pigeonholed into using iCal & Address Book sync to Google and manual copying of files to & from SD card & built-in phone storage. I could have used just Missing Sync, but I liked the fact that doubleTwist includes separate app & music stores.

Current "pros" include: speed (which I suspect would be experience if I used a 3GS or the upcoming 4G), enhanced functionality such as multi-tasking, location-triggered events & quick-access widgets (again, some of which I expect Apple to catch up on in the 4G/4.0 OS). I also gain much in the way of security since I am told up-front what the apps I'm loading want to be able to do and can make a conscious choice to be as restrictive or as "vulnerable" as  my risk appetite would have me be. I can sync wirelessly over my 802.11g network and finally take decent pictures and fairly decent video in a pinch. I haven't watched mobile video since having been forced to abandon my bus ride (alas, no mass transit commuting to work between Berwick & Portsmouth), so this has virtually no impact on me.

There are definitely "cons". A portion of my library is still DRM'd and it will take a burning/ripping effort to truly get out of that hole I put myself in since many of the albums & tracks have no iTunes Plus counterparts yet. I'm also out all mobile video I've purchased from Apple, but any DRM'd video will be proprietary and one can get by with ripping or transcoding from other sources. (Here's a handy Incredible preset for Handbrake that you can import if you remove the ".txt").

Android apps exist for everything I rely on, including Google Mail, Evernote, Dropbox, Twitter & Flickr. There is no loss of functionality and there is even more inter-operatibilty across apps (again, Apple will be catching up soon).

Something that is part of the freedom of the Android world - but is also a detriment - is the lack of UI standardization. The major factor in making the Incredible "incredible" is the HTC components that smooth out the quirks in the interface & apps. Not all apps take advantage of this and many just buck all implementation guidelines and community standards and present some of the worst interfaces I've ever seen, but I've also seen my share of horrible iPhone apps as well.

If you would like to know any of the details that the gadget blogs have left out of their standard device reviews or have specific questions on the migration from iPhone to Android, drop a note in the comments or find me on Twitter (@hrbrmstr). Tweeting is sparse these days as work and home eat up much of my energy, but I'll be glad to carve out some time to reply to Android questions.

Forgot to disable auto-post from the NotObvious blog.

Catch the original over there

Others, most notably the Tweetie developer, have discussed this, but I wanted to share my two cents on fast scrolling in UITableViews with (or without) dynamic cell heights.

I've been working on an app (I can let the cat out of the bag soon) that has (amongst other items) three main UITableViews. The first has static-height UITableViewCells with just three UILabels and the second has static-height UITableViewCells three UILabels and one UIImageView. For those two, the following settings are pretty important (translate Interface Builder settings to iPhone SDK calls if you are working – as I am – purely in code):



The next item of utmost importance is doing all of the calculations for the content of the cells outside of tableView:cellForRowAtIndexPath:. When I was prototyping, I had a good portion of the transformation code in that method and have since moved it to the XML parsing routines. Since I was not able to set my cells to be opaque, limiting the number of "inner" UIViews was also high on the priority list. I did not need to background load the images in the cells, so I did not have to resort to using a subclass of UITableViewCell but I *did* implement a very rudimentary caching system which helped to speed things up a bit:



For the dynamic height cells, I setup an NSMutableDictionary called "heights" (the key is the row number) which caches the row heights of each cell since one of the UILabels can drastically vary in height. You need to do something like the following in tableView:heightForRowAtIndexPath::



and then explicitly set the UILabel's frame size each time in tableView:cellForRowAtIndexPath: and also retrieve said hight and calculate the number of rows in tableView:cellForRowAtIndexPath::



If your table cells get any more complex or you need to delay or thread the loading of the images, then you will need to implement a custom table cell. When writing code to see what goes on behind the scenes, it turns out that there are many, many, many calls to those two methods for each table view, so it is very important to make them as lightweight as possible.

I needed to strip the tags from some HTML that was embedded in an XML feed so I could display a short summary from the full content in a UITableView. Rather than go through the effort of parsing HTML on the iPhone (as I already parsed the XML file) I built this simple method from some half-finished snippets I found. It has worked in all of the cases I have needed, but your mileage may vary. It is at least a working method (which cannot be said about most of the other examples). It works on the iPhone and in standard OS X coding.

- (NSString *)flattenHTML:(NSString *)html {

    NSScanner *theScanner;
    NSString *text = nil;

    theScanner = [NSScanner scannerWithString:html];

    while ([theScanner isAtEnd] == NO) {

        // find start of tag
        [theScanner scanUpToString:@"<" intoString:NULL] ; 

        // find end of tag
        [theScanner scanUpToString:@">" intoString:&text] ;

        // replace the found tag with a space
        //(you can filter multi-spaces out later if you wish)
        html = [html stringByReplacingOccurrencesOfString:
                           [ NSString stringWithFormat:@"%@>", text]
                     withString:@" "];

    } // while //
    
    return html;

}

RDN should look a bit better on your iPhone these days. I migrated the whole site over to an updated version of Drupal and then made some tweaks to auto-check for the browser-type and render appropriately for mobile devices, with some special attention paid to the iPhone.

There were some "canned" solutions for this I had hoped to use that wound up not working. I am also a bit disappointed in the state of the Drupal 6 series and hope Drupal 7 kicks some serious butt, otherwise I'll be heading elsewhere for content management.

I'll be tweaking the iPhone rendering over time, but I wanted to get something up quickly in the event folks feel the need to visit the site while mobile (or if you're using a mobile Twitter client and click a link that goes to a post I made here on RDN). Once I get a decent base I'll see about submitting it to drupal.org and will definitely post a "how to" here.

If anything is broken that you relied on, let me know in the comments and I'll try to get it back in. I went light with the modules this time and disabled some features.

UPDATE: It should look even better now. Added some additional CSS and a few elements from the iUI toolkit.

I haven't been slackin'...just lots of Apple postin' on TAB...

• Twiterriffic 3.1 beta
• ScreenSteps 2 mini-review
• iPhone Development Preview
• iPhone Web Development Starter
• My Apple TV Upgrade Experience

Here is what was fixed, security-wise in the 1.1.3 update:

Foundation
CVE-ID: CVE-2008-0035
Available for: iPhone v1.0 through v1.1.2, iPod touch v1.1 through 1.1.2
Impact: Accessing a maliciously crafted URL may lead to an application termination or arbitrary code execution
Description: A memory corruption issue exists in Safari's handling of URLs. By enticing a user to access a maliciously crafted URL, an attacker may cause an unexpected application termination or arbitrary code execution. This update addresses the issue by performing additional validation of URLs.

Passcode Lock
CVE-ID: CVE-2008-0034
Available for: iPhone v1.0 through v1.1.2
Impact: An unauthorized user may bypass the Passcode Lock and launch iPhone applications
Description: The Passcode Lock feature is designed to prevent applications from being launched unless the correct passcode is entered. An implementation issue in the handling of emergency calls allows users with physical access to an iPhone to launch an application without the passcode. This update addresses the issue through an improved check on the state of the Passcode Lock.

Safari
CVE-ID: CVE-2007-5858
Available for: iPhone v1.0 through v1.1.2, iPod touch v1.1 through 1.1.2
Impact: Visiting a malicious website may result in the disclosure of sensitive information
Description: WebKit allows a page to navigate the subframes of any other page. Visiting a maliciously crafted web page could trigger a cross-site scripting attack, which may lead to the disclosure of sensitive information. This update addresses the issue by implementing a stricter frame navigation policy.

CVE-2008-0034 (bypassing of the passcode lock) is ugly and I hope this is the last time this feature has a vulnerability. CVE-2008-0035 is what was used by those "cool" folks to break their phones to run apps on it. I still stand by my position that it is unwise to publish the means to decimate the security of any device for the sole purpose of being able to make it do what you want it to do. Who knows how many folks were exposed to real iPhone vulnerabilities as a result of the work of these "fine" engineers.

The fine folks over at Simple Weather have kicked out a mobile version that looks great on your iPhone. Bookmark simpw.com and you'll have speedy, one-touch access to current conditions and local forecast info.

(It also works on more pedestrian mobile devices)

I kinda knew this was coming and it's great to see it finally in the wild. Nice job, guys!

Via: simpleweather blog

NewerTech announced a new iPhone dock & speakerphone combination gadget today that is priced right at $35.00 (USD) and looks pretty decent (though I hope that shiny, white polymer is not just a really cheap, plastic shell).

Drop a note in the comments if you pick one up. Very interested in the sound quality and how they've handled the GSM<=>speaker interference problems that plague these types of configurations.

My review of the Shure MPA-3C headset adapter is up on TAB.

A teaser for you:

One of the issues I’ve had with with Apple’s iPods is the inclusion of those annoying ear-bud headphones. From sound quality to comfort, they are without a doubt the worst part of the package. When Apple released the iPhone they did manage to enhance the wretched, white audible tether with a decent microphone and control mechanism that wound up being useless to folks like me who cannot use the earbuds. It drove some to hardware hacks (YouTube link warning) and others, like Shure to the design room and manufacturing line.

MacNN purports that the iPhone is in the top five of e-disappointments this year. Part of their argument relates to the problems folks faced after they deliberately cracked the security of their device to load unsupported apps and then tried to keep up with official patches. That's just silly.

I've written some poor posts, but that author really needs some time off to find that lost clue.

The Zune isn't exactly a wholesale failure or disappointment either (tho the iPod Touch wins with a KO in round #1 of any battle between it and the Zune).

Apple is slowly rolling out features for the iPhone that people have been pining for. Their forthcoming API takes center stage, but an innocent end-of-year update to GarageBand makes it possible for folks to createcustom ringtones (I can hear the teeth gritting of the RIAA executives as I type).

I've always considered ringtones something that should have died in the 90's, but folks seem to like them (they spend tons of cash on them every year) and they aren't going away any time soon.

The downside is that we will all be subjected to the wretched sounds inspiring compositions of self-described prodigies on buses, trains, ferries and elevators since Apple has now made it far too easy to get your own frequencies on your iPhone (anyone can use GarageBand...it's a cool app).

While it's great that Apple is turning the cell phone industry on its collective ear, I for one, hope Jobs gets coal in his stocking this Christmas for the "joy" we're all about to receive.

Erica over at TUAW posted this from a tip by NerveGas. You may disclose PII from your lost or stolen iPhone without even realizing it (and the bad guys can get to it even if you've been a good Apple citizen and not hacked your device):

Secure Your iPhone: What's in that data file? - The Unofficial Apple Weblog (TUAW): "f you've hacked your iPhone for disk access, have you ever peeked at the dynamic-text.dat file in /var/root/Library/Keyboard? You might be surprised at the contents. All your personal words that don't show up in the default dictionary get stored in this file. If you're using a business iPhone, you may want to especially monitor this file. It's not a keylogger but there's a lot of personal data that ends up there."

Packet Storm just posted four iPhone and/or iPod Touch exploits, the last of which can do a simple DoS by killing your battery.

When you rely on breaking the security of your device to do "cool" things with it, you get what you deserve. i'd like the phone to be open now and be able to write apps for it, but I'm not desperate enough to hack it and expose new vulnerabilities to the world.

Hopefully the next firmware will be out soon with fixes and some new features.

You probably know that iTunes 7.4.1 kills the simple ringtones hack for the iPhone. You may also know that Apple finally added that ringtone-creation functionality today. If you didn't bother to upgrade (I didn't since it was obvious why the update was released) then you'll be glad to know that you can still purchase/make ringtones using iTunes 7.4.

Now, the only question left would be *why* you want to make/use ringtones in the first place.