Wayne Pan

2009 is ending, a year that started with Sequoia’s RIP: Good Times fresh in everybody’s mind. However, 2009 saw some major M&A activity.

I made some predictions at the beginning of the year, let’s see how they played out. Last year I was 50% correct…

• Twitter will not be acquired – Correct! Many people measure the success of Twitter in terms of traffic to twitter.com, but traffic isn’t what Twitter wants. Twitter is a platform and as Jack put it “Twitter’s a success for us when people stop talking about it”. I also predicted that Twitter would get their first sniff of revenue this year and they did in the form of search deals with Bing and Google.
• Digg will not be acquired – Correct! Digg’s appeal as an acquisition target went up threefold when they launched their innovate ad platform. No numbers have been released but as an avid Digger, the platform definitely works. I’ve clicked on my fair share of Digg ads simply because they appealed to me.
• Apple will open up iTunes infrastructure to developers to start accepting micro-payments – Wrong! Apple did do something around payments, they enabled app developers to charge or in-app purchases in free apps. One step closer to opening up their payment platform. If Apple did this, Square would be belly up.
• Android phones sales will not exceed iPhones, maybe in 2010 – Correct! AdMob’s latest metrics report, which measures ad requests not marketshare it’s clear Apple still has a substantial lead. Even based off ad requests it’s clear Android is no where near Apple and for this purpose, I’m calling it good enough.

  I guess I’m lucky that Google hasn’t released the Nexus One yet. Next year I definitely think Android will have a great marketshare than the iPhone purely based off the number of Android devices (low cost at that too) emerging.

• Facebook connect will become more ubiquitous than OpenID as a way to login to websites – Correct! Facebook says 80,000 websites have implemented Facebook Connect. The best number I can find for OpenID is 25,000. Yahoo will soon use Facebook for it’s social features, Facebook’s platform will only continue to grow.
• IE6 marketshare will fall under 10% by years end – Wrong! IE6 still holds at 22%, and I still cry everyday.

If you haven’t already, go read the DaringFireball piece on PastryKit. Are you back? Good. If you’re the least bit like me, you’re probably a least a little bit intrigued. If you’re sorta like me you probably cut and pasted http://help.apple.com/iphone/3/mobile/dist/PastryKit-ug-compact.js into jsbeautifier.org. If you’re kinda like me you also dug into http://help.apple.com/iphone/3/mobile/javascript.js to see how PastryKit is used. And finally, if you’re exactly like me, you’ve probably already dissected the framework and won’t need to read this post

PastryKit, at least the one on the iPhone User Guide, contains (it’s possible their compiler strips out classes/functions their site doesn’t use)

• PKUtils – collection of util functions (eg. degreesToRadians, objectHasMethod, etc)
• PKClass, PKObject – classes that make inheritance easier. PKObjects to have observer methods for properties and PKClasses are able to synthetize properties ala ObjC.
• PKPoint, PKSize, PKImage – self explanatory OOO objects for points, sizes, and <img>
• PKAnimator – simple animator class taskrunner/setTimeout style. Even PastryKit doesn’t use WebKitAnimations since the API is fubar’d! As far as I can tell nothing in the framework or iPhone User Guide uses this
• PKTransition – This is where all the real animation is done, including the scroll effect, has the ability to commit animation transactions.
• PKView, PKContentView, PKRootView – View hierarchy, akin to one you would set up in Interface Builder. Very Xcode. I echo Gruber’s sentiments that PastryKit could show up in the next DashCode. Or at the very least the remnants of Apple’s web apps as an app strategy circa 2008.
• PKScrollIndicator – The magical class that creates the DHTML scrollbar when a view is scrolled.
• PKSearchBar, PKTableView, PKNavigationView, PKToolbar – the main view classes used to construct an actual app. (Along with PKScrollView, PKTableViewCell, PKNavigationItem, PKControl)

If you’ve built anything in Xcode all this seems very familiar. Applications are built by setting up a hierarchy of views such as:

// create a new navigation view
navigation = new PKNavigationView();
// set a size for the view
navigation.size = new PKSize(height, width);
// init some basic parameters about the view
 // add the view to the root view
PKRootView.sharedRoot.addSubview(navigation);
// build the rest of your views

I gave myself a couple hours to build a basic view app from scratch using PastryKit. It was painful and time consuming. There are plenty of methods that are required by the framework that you must declare unknowingly (eg. tableViewCellForRowAtPath vs tableViewCustomCellForRowAtPath dependent on what your table view is styled). Without proper documentation the framework is difficult to do any real work with. I’ll tinker with it some more but if you’re interested in a semi-prepackaged PastryKit and my work so far you can grab it here.

PKScrollIndicator is the best part of the framework, jQTouch should definitely look into “borrowing” this code. Meanwhile, I’ll be waiting for a documented official release of PastryKit.

Bonus: You can use the following to disable scrolling in Mobile Safari.

document.addEventListener('touchmove', function(e) {
  e.preventDefault();
}, true);

This coupled with window.scrollTo(0,0) is how PastryKit hides the navigation bar.

Update: Sorry, should be document.addEventListener() instead of window.addEventListener(). I’ve added a demo no scroll page here. Just view the source.