Daring Fireball: PastryKit | Hacker News Reader

Daring Fireball: PastryKit

daringfireball.net

176 pointssant0sk142 comments

I pulled everything down and started to play with it. it looks really interesting. I put it up on github so you can go check it out there http://github.com/ryankshaw/PastryKit

(remember, dont actually use that code for your own website, I'm sure apple wouldn't like that), the only reason I put it up on github is because I found it interesting to learn from and thought others might too.

Some interesting notes:

1. the redirect if you are not coming from an iphone does not happen in this code. it is something done on the server. it has nothing to do with these PastryKit javascript files.

2. I took all of the minified css files and js files and made an uncompressed version next to it with the name <filename>.uncompressed.js for the css files I converted it to SASS because I like that and I can see better visually what they are doing with it. (ps, if nothing else, look at the css they are using, there is some awseome webkit-proprietary stuff you can do with your styles if you are targeting only the iPhone)

Some cool things:

1. check out the stuff they are doing with the html5 databases in classes/datacontroller-database-uncompressed.js that is pretty cool. 2. the loading image they do with pure css ( @-webkit-keyframes loadingImageAnimation ) in stylesheet.css is pretty cool.

I actually did the same a few hours ago, and just pushed it to GH. You can see mine here: http://github.com/grinich/PastryKit

>I'm sure apple wouldn't like that. What I don't understand is WHY we can't use it since they have this statement. "Copyright (C) 2006, 2007, 2008 Apple Inc. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: etc. etc. Linda

As much as I'd like to think Apple will officially announce PastryKit at some preview event Q1 2010, it just doesn't seem very Apple-like to do anything at this point that could dilute the ongoing popular attention to the App Store.

Actually, maybe that's it: Perhaps PastryKit was developed originally as a "plan B" in case the App Store didn't take off. Its development probably tracks back to before 2007, when third-party native development was still in question, and was kept in the back pocket as the App Store was launched.

My guess is it will stay a stealth project unless the voice of devs burned by App Store policies becomes too loud and Apple needs to bring out an alternative.

    Perhaps PastryKit was developed originally as a "plan B" in case the
    App Store didn't take off. Its development probably tracks back
    to before 2007, when third-party native development was still in
    question, and was kept in the back pocket as the App Store
    was launched.

Actually, given the history of 3rd party development on the device, I think this was "Plan A" and the App Store was "Plan B." When you watch the first couple of Stevenotes that came during and after the iPhone's public announcement, you'll note that Apple was originally expecting developers to only make web apps. But there was a big push-back from developers complaining that they couldn't make apps good enough to stand side-by-side with the built-in ones. (And people also pointed out the pointlessness of advertising to devs that the iPhone was using the same technologies as OS X if they couldn't be directly accessed.)

Apple employs a big pile of talented individuals, but I highly doubt they went from developer pushback in Summer 07 to the SDK in Spring 08 (when the SDK started hitting Apple's partners). Particularly considering the huge changes to the API calls between iPhone's OS 1 and 2.

It looks to me much more like the SDK was dependent on an OS build that just wasn't ready for primetime in 2007 and Steve was just trying to spin what they had as something you want.

PastryKit is a red herring. If Apple decides that it wants to fully support webapps as rivals to native apps then PastryKit is just a nicety. What real commitment from Apple would give you is bug-fixes and improvements to Webkit.

Why re-invent something in Javascript when you control the underlying browser?

Could this have been originally implemented in the period before the iPhone was publicly released, when Apple was planning on implementing all the simpler 'native' apps this way?

That's my theory (http://news.ycombinator.com/item?id=997886) as well...

Remember that until iPhone OS 2.0, we didn't have: CSS Animations or HTML5 local-storage stuff. So it's really not that likely.

You don't think they could have been iterating it?

It could also have been developed during the initial post-launch pre-app-store period when they were encouraging webapps, but not released publicly until 2.0 or later.

Momentum scrolling makes huge ergonomic difference.

The batteries on my Magic Mouse (which has momentum scrolling) are dead, so I'm using my Mighty Mouse today, and boy, is it a drag.

A link to the source of PastryKit. Github seems to be kinda lame with the syntax coloring =/

Beautified Gist: http://gist.github.com/257514

Compacted Orig: http://help.apple.com/ipodtouch/3/mobile/dist/PastryKit-ug-c...

[EDIT] A slightly nicer to read version with better coloring - http://dpaste.de/n2CR/

Fascinating--it looks like they've implemented a micro-Objective-J-like language and then, based on that, implemented a whole micro UIKit in that language.

micro-Objective-J might be a stretch (everything looks like straight JS to me), but they have a lot of Cocoa JS libs floating around:

http://help.apple.com/iphone/2/Contents/Frameworks/Foundatio... http://help.apple.com/iphone/2/Contents/Frameworks/Foundatio... http://help.apple.com/iphone/2/Contents/Frameworks/Foundatio... . . . etc

oh, and http://help.apple.com/iphone/2/Parts/license.txt too.

Related note: Has anyone tried using this: http://code.google.com/p/iui/

Yes, that's been around for quite a while.

We used it for the built-in help files in our iPhone app (Grafly, a graphing calculator).

Ok, thanks.

I'm wondering how users on mobile browsers which aren't iPhones would react to that interface...? (And also, how well it would render.)

It works well enough on Android and Palm Pre, although without the fancy OpenGL-accelerated CSS transforms (it gracefully degrades to more traditional CSS animations if WebKit transitions are not available).

The underlying HTML is just a bunch of unordered lists and divs, and all the advanced behavior is via CSS and Javascript - if you want to make sure it'll work on less-capable browsers it's doable, but you'll need to keep an eye on how you're loading things.

You may wind up needing to to browser sniffing on the server and serving up different HTML if you see various browsers; we didn't get that far in the project we worked on.

Not sure about iUI, but jQTouch uses webkit-enhanced markup so any webkit engine will read it correctly. jQTouch apps look great in desktop Safari, iPhones, and Android devices. It's even marginally passable in firefox.

Though, Android is very late getting some features (HTML5 manifests, local storage, and navigator.geolocation) and I'm still not sure if it supports support CSS animations.

We used iUI for the PAX scheduling app a friend and I hacked together in a few days (best seen on iPhone, mostly works on Android): http://pax.expojunkie.com/

iUI is a pretty decent way to get going quickly - it's a fairly simple framework once you start digging into it, and you can make some decent looking stuff. The AJAX loading of sub-pages is a nice touch and is handled well. We had to do a lot of the fancier map scrolling/etc. ourselves, though, and there are still a ton of shortcomings that we can't get around due to lack of native events (fixed toolbars, proper scrolling, a few other fiddly things that you might notice but are too esoteric to mention here.)

jQTouch is getting a lot of buzz right now, and we might look at rewriting ExpoJunkie using it early next year: http://www.jqtouch.com/

Apple recently did something weird with the Cocoa documentation. It seems like the titles of and links to all API docs and user guides are stored on one gigantic page. They then invoke some JavaScript magic to search through the titles of all documentation. The end result is that the page is slow and jerky in Safari, extremely slow and jerky in Firefox and refuses to work properly in Opera.

I wish people stopped using JavaScript to do things it wasn't supposed to do :(

EDIT: Momentum scrolling is delicious. I'm really enjoying this :D

The one problem with super-fast-scrolling: even with an iPhone-designed web app, you can easily go past the boundary that Safari has rendered and wind up with the checkerboard pattern.

PastryKit looks cool, but jQTouch is cool and freely available to use today. Check it out if you haven't:

http://www.jqtouch.com/

OP referred to it, and pointed out it has no momentum scrolling.

The linked iPhone user guide (in fact the very default one from my iPhone) does not now load on my iPhone. On Firefox Windows I get redirected to http://support.apple.com/manuals/iphone/. Don't know if that's in reaction to the article or what.

This page is easy to break, at least using Safari on a Mac. Just pull the top list item, Getting Started, down the screen a little. Now when you try to scroll the gray scroll bar on the right moves but the content doesn't scroll.

Still, this is a very cool piece of JavaScript.

Being able to break it on a Mac isn't really relevant, though, since the only way to access it on a Mac is to deliberately spoof a mobile browser.

I've just tried this out and it is indeed deeply cool, although the scrolling even on my 3GS is not quite native-like. I would love to know how they're managing fixed-position toolbars; has anyone reverse-engineered that bit yet?

The page itself isn't actually scrolling. There are Javascript event handlers that are capturing the swipe events and adjusting the positioning of the main content block via WebKit CSS transformations and/or standard CSS positioning. Since it's never actually scrolling the page, the toolbars don't change position.

There are a few JS demos that show this off floating around for iPhone, though they tend to have a variety of potential problems. (Intercepting every touch event via Javascript and handling it yourself results in a lot of edge cases you need to handle; see what happens in the User Guide if you drag your finger off the edge of the screen...)

Of, of course. He even mentions this in the article.

The "sticking" problem when you drag your finger off the bottom of the screen doesn't happen when you add the app to your home screen and launch it that way (because there's no safari menu at the bottom of the screen, presumably).

is there a non-Mac iphone emulator which can be used to test out a webapp ?

It does'nt kinda make sense if I have to have a Mac and iPhone to develop web apps for the iphone!

Just change your user-agent string. The best experience is going to be with Safari, which has an optional debug menu that will change your user-agent to various versions of Mobile Safari.

I don't know how close Safari on Windows will get.

But really, "feel" is a huge part of the interface and you should be testing on a real device for any handheld dev. An iPod Touch is your cheapest option here.

> It does'nt kinda make sense if I have to have a Mac and iPhone to develop web apps for the iphone!

It makes sense for Apple.

The big question I have is how they disable the top URL location bar... didn't catch anything in first skimming of the code. Anyone else have better luck?

I haven't looked at the code, but it may be by scrolling the window so it goes out of view and then setting up the fixed menus etc.

I am totally guessing based on the comment in the article that if you double tap the top of the screen it brings the address bar into view, sort of implying it was just scrolled away.

Looks like you're spot on, good call. I'd misunderstood the other comment, as you only have to tap the top of the screen once to scroll to the top. I wonder if they could just capture and prevent onscroll?

    PKUtils.disableScrolling = function (a) {
      a.stopPropagation();
      window.addEventListener("touchmove", PKUtils.preventEventDefault, true);
      window.addEventListener("touchend", PKUtils.restoreScrollingBehavior, true);
      window.addEventListener("touchcancel", PKUtils.restoreScrollingBehavior, true)
    };

When I run this on my G1 with the iPhone user-agent it doesn't look anything like this. I guess I don't see why they would specifically change it here.

My suspicion would be that your G1 doesn't have all the magic webkit extensions that are in safari mobile.

Anyone figure out how to actually use Pastrykit to hide the address/nav bar?

> But on the whole this User Guide app and the PastryKit framework are rather amazing. The $64,000 question, though, is whether PastryKit is something Apple intends (or that a team within Apple hopes) to ship publicly. It seems like a lot of effort to build a framework this rich just for this iPhone User Guide, so I’m hopeful the answer is yes.

Is he talking about a different Apple than the one that I know of?

Reply on news.ycombinator.com