Apple contacted a(n unknown-to-me) number of iPhone web app developers on Thursday, offering advice on how to make their apps work properly on iPhone in time for launch Friday. (Let me say publicly: That gesture was *greatly* appreciated!) I was contacted by a member of the iPhone/Safari/WebKit team in order to improve the "iScopes" app I created for Astrology.com:
(If you stop at just "/iphone", you'll get a landing page that's missing an iPhone-specific optimization (namely, the viewport meta tag we've all come to know and love), which is rather funny considering the heading. :) That page should be updated "soon".)
I've been released from the Non-Disclosure Agreement covering the conversation, so I'll share some of the things from it. Consider this information second-hand and hardly definitive. I don't speak for Apple, and it's entirely possible that I misinterpreted some things that were said. (In particular, I mention a few times that my contact didn't offer workarounds for this or that limitation. That doesn't necessarily mean that there *aren't* decent workarounds, perhaps even "easy" ones; my contact may simply be unaware of them or unwilling to go into them or whatever.)
x iPhone Safari isn't the same as Safari 3.0. They "forked" a while ago. If you don't have iPhone, they recommend testing apps in Safari 2.x and 3.0 on your Mac (or, presumably, PC). On iPhone, an app will tend to perform somewhere between the two. (Note that iPhone-Safari has a great deal more CSS3 support than Safari 2 (though not quite as much as in Safari 3). So, your app might look *terrible* in Safari 2 --mine does-- but still render nicely in iPhone.)
x For animations, they recommend using 'setTimeout's with wait parameter set to 0:
function startAnimation() { // set up animation global variables, etc.
setTimeout( "stepAnimation()", 0 ); }
function stepAnimation() { // do something
if ( !finishedAnimating ) setTimeout( "stepAnimation()", 0 ); }
The contact considers 'setTimeout's better than 'setInterval's, although that might just be his personal preference. (Still, he recommended changing all my 'setInterval's to 'setTimeout's during our debugging session.)
Note that, on a Mac, animations set up this way will zip along in a flash, making debugging tricky. However, on iPhone, they're *much* slower.
x The first tip given was about that viewport meta tag
<meta name="viewport" content="width=320" />
My contact didn't say anything about scaling parameters, however. (I didn't know about them at the time, so didn't ask. Perhaps I should now. :)
x iPhone-Safari doesn't send any specific messages when flipping to landscape mode.
Naturally, I lamented greatly about how my landscape- specific stylesheet was going to go to waste, but the response was basically, "Sorry about that". My contact offered no real hope of a workaround, which is why I was very pleasantly surprised by Christopher Allen's recent viewport experiments that show there *are* resize messages being sent eventually. And, as Joe Hewitt has shown, one can do continuous polling to determine if the screen dimensions have changed. These "hacks" may be our only options at this point. (My conclusion, not anything suggested by Apple.)
x Flick-scrolling. This is, as I surmised in a different thread some time ago, a "meta" feature of Safari that is meant *exclusively* as a way for the browser to move the entire window up and down quickly. That's why the title bar moves. So, the only way to flick-scroll through a list is to display that entire list on a really tall page. Flick-scrolling is not, therefore, for manipulating scrolling divs *within* a web page. Again, I lamented that I'd been *expecting* users to flick-scroll through items in one of the "panels" of the iScopes web app, and again, the response was "Sorry about that". No suggestion to use iframes or other workarounds.
x Contrary to what we may have seen in Apple's promotional videos, there's no way to hide the Safari location bar or tool bar (yet). (I'd *swear* the guy said "yet" ... but don't hold them to that.)
x There's apparently no way to suppress that "darkening" effect when clicking on a div that takes a mouse event. (Very unsightly when your buttons aren't rectangular and/or don't extend to the boundaries of the clickable div.) I was told that they'd "look into it", but don't expect anything anytime soon.
x They're working to put together documentation and guidelines and sample code (for "cool effects") for all of us, but I was given no idea of the time frame on that.
I think that's all I have at this point. Feel free to ask for clarification, although I don't know if I can offer any more clarity. Our primary focus in the conversation was getting my *specific* app working properly. Many of the things I list above came from tangential comments related to what we were discussing. I didn't think it an appropriate use of my contact's time to pump him for details on every open question about iPhone web app development. (I certainly don't want to wear out my welcome with Apple; as you might imagine, I value it highly.)
I was also contacted by someone from Apple, and he made me sign a document, but I read it and it was definitely not an NDA (it was more of a "if you get sued, Apple is not responsible and you can't forward the lawsuit to us" document).
All I was told was about the viewport tag (it was funny because he gave me the line and started off by saying "less than sign, meta, space, ...., greater than sign", and he tried to tell me about the Google Maps integration (which I already knew about from someone who attended WWDC and contacted me), but he never really got through to me on that since by the time he called for that, I was already waiting in line for my iPhone.
On Jul 2, 2:05 am, DayLateDon <dayl...@gmail.com> wrote:
> Apple contacted a(n unknown-to-me) number of iPhone web app developers > on Thursday, offering advice on how to make their apps work properly > on iPhone in time for launch Friday. (Let me say publicly: That > gesture was *greatly* appreciated!) I was contacted by a member of the > iPhone/Safari/WebKit team in order to improve the "iScopes" app I > created for Astrology.com:
> (If you stop at just "/iphone", you'll get a landing page that's > missing an iPhone-specific optimization (namely, the viewport meta tag > we've all come to know and love), which is rather funny considering > the heading. :) That page should be updated "soon".)
> I've been released from the Non-Disclosure Agreement covering the > conversation, so I'll share some of the things from it. Consider this > information second-hand and hardly definitive. I don't speak for > Apple, and it's entirely possible that I misinterpreted some things > that were said. (In particular, I mention a few times that my contact > didn't offer workarounds for this or that limitation. That doesn't > necessarily mean that there *aren't* decent workarounds, perhaps even > "easy" ones; my contact may simply be unaware of them or unwilling to > go into them or whatever.)
> x iPhone Safari isn't the same as Safari 3.0. They > "forked" a while ago. If you don't have iPhone, > they recommend testing apps in Safari 2.x and > 3.0 on your Mac (or, presumably, PC). On iPhone, > an app will tend to perform somewhere between > the two. (Note that iPhone-Safari has a great deal > more CSS3 support than Safari 2 (though not quite > as much as in Safari 3). So, your app might look > *terrible* in Safari 2 --mine does-- but still > render nicely in iPhone.)
> x For animations, they recommend using 'setTimeout's > with wait parameter set to 0:
> function startAnimation() > { > // set up animation global variables, etc.
> The contact considers 'setTimeout's better than > 'setInterval's, although that might just be his > personal preference. (Still, he recommended changing all > my 'setInterval's to 'setTimeout's during our debugging > session.)
> Note that, on a Mac, animations set up this way will zip > along in a flash, making debugging tricky. However, on > iPhone, they're *much* slower.
> x The first tip given was about that viewport meta tag
> <meta name="viewport" content="width=320" />
> My contact didn't say anything about scaling parameters, > however. (I didn't know about them at the time, so > didn't ask. Perhaps I should now. :)
> x iPhone-Safari doesn't send any specific messages when > flipping to landscape mode.
> Naturally, I lamented greatly about how my landscape- > specific stylesheet was going to go to waste, but the > response was basically, "Sorry about that". My contact > offered no real hope of a workaround, which is why I > was very pleasantly surprised by Christopher Allen's > recent viewport experiments that show there *are* > resize messages being sent eventually. And, as Joe Hewitt > has shown, one can do continuous polling to determine if > the screen dimensions have changed. These "hacks" may be > our only options at this point. (My conclusion, not > anything suggested by Apple.)
> x Flick-scrolling. This is, as I surmised in a different > thread some time ago, a "meta" feature of Safari that > is meant *exclusively* as a way for the browser to move > the entire window up and down quickly. That's why the > title bar moves. So, the only way to flick-scroll through > a list is to display that entire list on a really tall > page. Flick-scrolling is not, therefore, for manipulating > scrolling divs *within* a web page. Again, I lamented that > I'd been *expecting* users to flick-scroll through items > in one of the "panels" of the iScopes web app, and again, > the response was "Sorry about that". No suggestion to use > iframes or other workarounds.
> x Contrary to what we may have seen in Apple's promotional > videos, there's no way to hide the Safari location bar or > tool bar (yet). (I'd *swear* the guy said "yet" ... but > don't hold them to that.)
> x There's apparently no way to suppress that "darkening" > effect when clicking on a div that takes a mouse event. > (Very unsightly when your buttons aren't rectangular > and/or don't extend to the boundaries of the clickable > div.) I was told that they'd "look into it", but don't > expect anything anytime soon.
> x They're working to put together documentation and > guidelines and sample code (for "cool effects") for all > of us, but I was given no idea of the time frame on that.
> I think that's all I have at this point. Feel free to ask for > clarification, although I don't know if I can offer any more clarity. > Our primary focus in the conversation was getting my *specific* app > working properly. Many of the things I list above came from tangential > comments related to what we were discussing. I didn't think it an > appropriate use of my contact's time to pump him for details on every > open question about iPhone web app development. (I certainly don't > want to wear out my welcome with Apple; as you might imagine, I value > it highly.)
Aha! Two-finger scrolling, with correct viewport setting, is the key to generating those mousewheel events I've seen but been unable to reproduce reliably before now. I'm about to gen a dedicated example to make available for the rest of the list. Thank you Don.
-- Tahoma
P.S. Cute app, by the way...
On Jul 1, 11:05 pm, DayLateDon <dayl...@gmail.com> wrote:
> Apple contacted a(n unknown-to-me) number of iPhone web app developers > on Thursday, offering advice on how to make their apps work properly > on iPhone in time for launch Friday. (Let me say publicly: That > gesture was *greatly* appreciated!) I was contacted by a member of the > iPhone/Safari/WebKit team in order to improve the "iScopes" app I > created for Astrology.com:
> (If you stop at just "/iphone", you'll get a landing page that's > missing an iPhone-specific optimization (namely, the viewport meta tag > we've all come to know and love), which is rather funny considering > the heading. :) That page should be updated "soon".)
> I've been released from the Non-Disclosure Agreement covering the > conversation, so I'll share some of the things from it. Consider this > information second-hand and hardly definitive. I don't speak for > Apple, and it's entirely possible that I misinterpreted some things > that were said. (In particular, I mention a few times that my contact > didn't offer workarounds for this or that limitation. That doesn't > necessarily mean that there *aren't* decent workarounds, perhaps even > "easy" ones; my contact may simply be unaware of them or unwilling to > go into them or whatever.)
> x iPhone Safari isn't the same as Safari 3.0. They > "forked" a while ago. If you don't have iPhone, > they recommend testing apps in Safari 2.x and > 3.0 on your Mac (or, presumably, PC). On iPhone, > an app will tend to perform somewhere between > the two. (Note that iPhone-Safari has a great deal > more CSS3 support than Safari 2 (though not quite > as much as in Safari 3). So, your app might look > *terrible* in Safari 2 --mine does-- but still > render nicely in iPhone.)
> x For animations, they recommend using 'setTimeout's > with wait parameter set to 0:
> function startAnimation() > { > // set up animation global variables, etc.
> The contact considers 'setTimeout's better than > 'setInterval's, although that might just be his > personal preference. (Still, he recommended changing all > my 'setInterval's to 'setTimeout's during our debugging > session.)
> Note that, on a Mac, animations set up this way will zip > along in a flash, making debugging tricky. However, on > iPhone, they're *much* slower.
> x The first tip given was about that viewport meta tag
> <meta name="viewport" content="width=320" />
> My contact didn't say anything about scaling parameters, > however. (I didn't know about them at the time, so > didn't ask. Perhaps I should now. :)
> x iPhone-Safari doesn't send any specific messages when > flipping to landscape mode.
> Naturally, I lamented greatly about how my landscape- > specific stylesheet was going to go to waste, but the > response was basically, "Sorry about that". My contact > offered no real hope of a workaround, which is why I > was very pleasantly surprised by Christopher Allen's > recent viewport experiments that show there *are* > resize messages being sent eventually. And, as Joe Hewitt > has shown, one can do continuous polling to determine if > the screen dimensions have changed. These "hacks" may be > our only options at this point. (My conclusion, not > anything suggested by Apple.)
> x Flick-scrolling. This is, as I surmised in a different > thread some time ago, a "meta" feature of Safari that > is meant *exclusively* as a way for the browser to move > the entire window up and down quickly. That's why the > title bar moves. So, the only way to flick-scroll through > a list is to display that entire list on a really tall > page. Flick-scrolling is not, therefore, for manipulating > scrolling divs *within* a web page. Again, I lamented that > I'd been *expecting* users to flick-scroll through items > in one of the "panels" of the iScopes web app, and again, > the response was "Sorry about that". No suggestion to use > iframes or other workarounds.
> x Contrary to what we may have seen in Apple's promotional > videos, there's no way to hide the Safari location bar or > tool bar (yet). (I'd *swear* the guy said "yet" ... but > don't hold them to that.)
> x There's apparently no way to suppress that "darkening" > effect when clicking on a div that takes a mouse event. > (Very unsightly when your buttons aren't rectangular > and/or don't extend to the boundaries of the clickable > div.) I was told that they'd "look into it", but don't > expect anything anytime soon.
> x They're working to put together documentation and > guidelines and sample code (for "cool effects") for all > of us, but I was given no idea of the time frame on that.
> I think that's all I have at this point. Feel free to ask for > clarification, although I don't know if I can offer any more clarity. > Our primary focus in the conversation was getting my *specific* app > working properly. Many of the things I list above came from tangential > comments related to what we were discussing. I didn't think it an > appropriate use of my contact's time to pump him for details on every > open question about iPhone web app development. (I certainly don't > want to wear out my welcome with Apple; as you might imagine, I value > it highly.)
I was not contacted by Apple, even though two of my apps (Digg and Chat) got considerable press coverage, so they must have been aware of them. I hope this is a sign that they will be releasing a native iChat app in the near future and either deemed it unnecessary to get my chat app working or didn't want to dodge my inevitable questions about the need for my app.
-d
On Jul 2, 2:05 am, DayLateDon <dayl...@gmail.com> wrote:
> Apple contacted a(n unknown-to-me) number of iPhone web app developers > on Thursday, offering advice on how to make their apps work properly > on iPhone in time for launch Friday. (Let me say publicly: That > gesture was *greatly* appreciated!) I was contacted by a member of the > iPhone/Safari/WebKit team in order to improve the "iScopes" app I > created for Astrology.com:
> (If you stop at just "/iphone", you'll get a landing page that's > missing an iPhone-specific optimization (namely, the viewport meta tag > we've all come to know and love), which is rather funny considering > the heading. :) That page should be updated "soon".)
> I've been released from the Non-Disclosure Agreement covering the > conversation, so I'll share some of the things from it. Consider this > information second-hand and hardly definitive. I don't speak for > Apple, and it's entirely possible that I misinterpreted some things > that were said. (In particular, I mention a few times that my contact > didn't offer workarounds for this or that limitation. That doesn't > necessarily mean that there *aren't* decent workarounds, perhaps even > "easy" ones; my contact may simply be unaware of them or unwilling to > go into them or whatever.)
> x iPhone Safari isn't the same as Safari 3.0. They > "forked" a while ago. If you don't have iPhone, > they recommend testing apps in Safari 2.x and > 3.0 on your Mac (or, presumably, PC). On iPhone, > an app will tend to perform somewhere between > the two. (Note that iPhone-Safari has a great deal > more CSS3 support than Safari 2 (though not quite > as much as in Safari 3). So, your app might look > *terrible* in Safari 2 --mine does-- but still > render nicely in iPhone.)
> x For animations, they recommend using 'setTimeout's > with wait parameter set to 0:
> function startAnimation() > { > // set up animation global variables, etc.
> The contact considers 'setTimeout's better than > 'setInterval's, although that might just be his > personal preference. (Still, he recommended changing all > my 'setInterval's to 'setTimeout's during our debugging > session.)
> Note that, on a Mac, animations set up this way will zip > along in a flash, making debugging tricky. However, on > iPhone, they're *much* slower.
> x The first tip given was about that viewport meta tag
> <meta name="viewport" content="width=320" />
> My contact didn't say anything about scaling parameters, > however. (I didn't know about them at the time, so > didn't ask. Perhaps I should now. :)
> x iPhone-Safari doesn't send any specific messages when > flipping to landscape mode.
> Naturally, I lamented greatly about how my landscape- > specific stylesheet was going to go to waste, but the > response was basically, "Sorry about that". My contact > offered no real hope of a workaround, which is why I > was very pleasantly surprised by Christopher Allen's > recent viewport experiments that show there *are* > resize messages being sent eventually. And, as Joe Hewitt > has shown, one can do continuous polling to determine if > the screen dimensions have changed. These "hacks" may be > our only options at this point. (My conclusion, not > anything suggested by Apple.)
> x Flick-scrolling. This is, as I surmised in a different > thread some time ago, a "meta" feature of Safari that > is meant *exclusively* as a way for the browser to move > the entire window up and down quickly. That's why the > title bar moves. So, the only way to flick-scroll through > a list is to display that entire list on a really tall > page. Flick-scrolling is not, therefore, for manipulating > scrolling divs *within* a web page. Again, I lamented that > I'd been *expecting* users to flick-scroll through items > in one of the "panels" of the iScopes web app, and again, > the response was "Sorry about that". No suggestion to use > iframes or other workarounds.
> x Contrary to what we may have seen in Apple's promotional > videos, there's no way to hide the Safari location bar or > tool bar (yet). (I'd *swear* the guy said "yet" ... but > don't hold them to that.)
> x There's apparently no way to suppress that "darkening" > effect when clicking on a div that takes a mouse event. > (Very unsightly when your buttons aren't rectangular > and/or don't extend to the boundaries of the clickable > div.) I was told that they'd "look into it", but don't > expect anything anytime soon.
> x They're working to put together documentation and > guidelines and sample code (for "cool effects") for all > of us, but I was given no idea of the time frame on that.
> I think that's all I have at this point. Feel free to ask for > clarification, although I don't know if I can offer any more clarity. > Our primary focus in the conversation was getting my *specific* app > working properly. Many of the things I list above came from tangential > comments related to what we were discussing. I didn't think it an > appropriate use of my contact's time to pump him for details on every > open question about iPhone web app development. (I certainly don't > want to wear out my welcome with Apple; as you might imagine, I value > it highly.)
> I was not contacted by Apple, even though two of my apps (Digg and > Chat) got considerable press coverage, so they must have been aware of > them. I hope this is a sign that they will be releasing a native > iChat app in the near future and either deemed it unnecessary to get > my chat app working or didn't want to dodge my inevitable questions > about the need for my app.
> -d
> On Jul 2, 2:05 am, DayLateDon <dayl...@gmail.com> wrote:
> > Hello ...
> > Apple contacted a(n unknown-to-me) number of iPhone web app developers > > on Thursday, offering advice on how to make their apps work properly > > on iPhone in time for launch Friday. (Let me say publicly: That > > gesture was *greatly* appreciated!) I was contacted by a member of the > > iPhone/Safari/WebKit team in order to improve the "iScopes" app I > > created for Astrology.com:
> > (If you stop at just "/iphone", you'll get a landing page that's > > missing an iPhone-specific optimization (namely, the viewport meta tag > > we've all come to know and love), which is rather funny considering > > the heading. :) That page should be updated "soon".)
> > I've been released from the Non-Disclosure Agreement covering the > > conversation, so I'll share some of the things from it. Consider this > > information second-hand and hardly definitive. I don't speak for > > Apple, and it's entirely possible that I misinterpreted some things > > that were said. (In particular, I mention a few times that my contact > > didn't offer workarounds for this or that limitation. That doesn't > > necessarily mean that there *aren't* decent workarounds, perhaps even > > "easy" ones; my contact may simply be unaware of them or unwilling to > > go into them or whatever.)
> > x iPhone Safari isn't the same as Safari 3.0. They > > "forked" a while ago. If you don't have iPhone, > > they recommend testing apps in Safari 2.x and > > 3.0 on your Mac (or, presumably, PC). On iPhone, > > an app will tend to perform somewhere between > > the two. (Note that iPhone-Safari has a great deal > > more CSS3 support than Safari 2 (though not quite > > as much as in Safari 3). So, your app might look > > *terrible* in Safari 2 --mine does-- but still > > render nicely in iPhone.)
> > x For animations, they recommend using 'setTimeout's > > with wait parameter set to 0:
> > function startAnimation() > > { > > // set up animation global variables, etc.
> > setTimeout( "stepAnimation()", 0 ); > > }
> > function stepAnimation() > > { > > // do something
> > The contact considers 'setTimeout's better than > > 'setInterval's, although that might just be his > > personal preference. (Still, he recommended changing all > > my 'setInterval's to 'setTimeout's during our debugging > > session.)
> > Note that, on a Mac, animations set up this way will zip > > along in a flash, making debugging tricky. However, on > > iPhone, they're *much* slower.
> > x The first tip given was about that viewport meta tag
> > <meta name="viewport" content="width=320" />
> > My contact didn't say anything about scaling parameters, > > however. (I didn't know about them at the time, so > > didn't ask. Perhaps I should now. :)
> > x iPhone-Safari doesn't send any specific messages when > > flipping to landscape mode.
> > Naturally, I lamented greatly about how my landscape- > > specific stylesheet was going to go to waste, but the > > response was basically, "Sorry about that". My contact > > offered no real hope of a workaround, which is why I > > was very pleasantly surprised by Christopher Allen's > > recent viewport experiments that show there *are* > > resize messages being sent eventually. And, as Joe Hewitt > > has shown, one can do continuous polling to determine if > > the screen dimensions have changed. These "hacks" may be > > our only options at this point. (My conclusion, not > > anything suggested by Apple.)
> > x Flick-scrolling. This is, as I surmised in a different > > thread some time ago, a "meta" feature of Safari that > > is meant *exclusively* as a way for the browser to move > > the entire window up and down quickly. That's why the > > title bar moves. So, the only way to flick-scroll through > > a list is to display that entire list on a really tall > > page. Flick-scrolling is not, therefore, for manipulating > > scrolling divs *within* a web page. Again, I lamented that > > I'd been *expecting* users to flick-scroll through items > > in one of the "panels" of the iScopes web app, and again, > > the response was "Sorry about that". No suggestion to use > > iframes or other workarounds.
> > x Contrary to what we may have seen in Apple's promotional > > videos, there's no way to hide the Safari location bar or > > tool bar (yet). (I'd *swear* the guy said "yet" ... but > > don't hold them to that.)
> > x There's apparently no way to suppress that "darkening" > > effect when clicking on a div that takes a mouse event. > > (Very unsightly when your buttons aren't rectangular > > and/or don't extend to the boundaries of the clickable > > div.) I was told that they'd "look into it", but don't > > expect anything anytime soon.
> > x They're working to put together documentation and > > guidelines and sample code (for "cool effects") for all > > of us, but I was given no idea of the time frame on that.
> > I think that's all I have at this point. Feel free to ask for > > clarification, although I don't know if I can offer any more clarity. > > Our primary focus in the conversation was getting my *specific* app > > working properly. Many of the things I list above came from tangential > > comments related to what we were discussing. I didn't think it an > > appropriate use of my contact's time to pump him for details on every > > open question about iPhone web app development. (I certainly don't > > want to wear out my welcome with Apple; as you might imagine, I value > > it highly.)
I gotta say though, if Apple wants to embrace the web development community and web standards, they're certainly off to a HORRIBLE start. All this NDA stuff is a bunch of nonsense. If they were really serious about web apps being the primary way to develop third- party apps for the iPhone, they should have publicly released guidelines on how to develop for the iPhone on the day of Job's Keynote. So now here we are days after the release of the iPhone and still no public guidelines? ... and come to find out Apple is picking and choosing which developers they give additional information to?
Memo to Apple: that's not the way the web standards community works. We share information and we work from the same standards. We embrace technologies that are freely accessible to everyone and we reject technologies that are part of a walled garden, "it's who you know and how much you're willing to pay", mentality.
I'm really hoping that these are just some initial missteps. But its certainly not a good sign of where Apple is headed. Its in their best interest to have the maximum number of developers interested in developing for the iPhone. They'll make a hell of a lot more money that way than they will by trying to sell more tickets to the WWDC where they dole out secret information.
On Jul 1, 11:05 pm, DayLateDon <dayl...@gmail.com> wrote:
> Apple contacted a(n unknown-to-me) number of iPhone web app developers > on Thursday, offering advice on how to make their apps work properly > on iPhone in time for launch Friday. (Let me say publicly: That > gesture was *greatly* appreciated!) I was contacted by a member of the > iPhone/Safari/WebKit team in order to improve the "iScopes" app I > created for Astrology.com:
> (If you stop at just "/iphone", you'll get a landing page that's > missing an iPhone-specific optimization (namely, the viewport meta tag > we've all come to know and love), which is rather funny considering > the heading. :) That page should be updated "soon".)
> I've been released from the Non-Disclosure Agreement covering the > conversation, so I'll share some of the things from it. Consider this > information second-hand and hardly definitive. I don't speak for > Apple, and it's entirely possible that I misinterpreted some things > that were said. (In particular, I mention a few times that my contact > didn't offer workarounds for this or that limitation. That doesn't > necessarily mean that there *aren't* decent workarounds, perhaps even > "easy" ones; my contact may simply be unaware of them or unwilling to > go into them or whatever.)
> x iPhone Safari isn't the same as Safari 3.0. They > "forked" a while ago. If you don't have iPhone, > they recommend testing apps in Safari 2.x and > 3.0 on your Mac (or, presumably, PC). On iPhone, > an app will tend to perform somewhere between > the two. (Note that iPhone-Safari has a great deal > more CSS3 support than Safari 2 (though not quite > as much as in Safari 3). So, your app might look > *terrible* in Safari 2 --mine does-- but still > render nicely in iPhone.)
> x For animations, they recommend using 'setTimeout's > with wait parameter set to 0:
> function startAnimation() > { > // set up animation global variables, etc.
> The contact considers 'setTimeout's better than > 'setInterval's, although that might just be his > personal preference. (Still, he recommended changing all > my 'setInterval's to 'setTimeout's during our debugging > session.)
> Note that, on a Mac, animations set up this way will zip > along in a flash, making debugging tricky. However, on > iPhone, they're *much* slower.
> x The first tip given was about that viewport meta tag
> <meta name="viewport" content="width=320" />
> My contact didn't say anything about scaling parameters, > however. (I didn't know about them at the time, so > didn't ask. Perhaps I should now. :)
> x iPhone-Safari doesn't send any specific messages when > flipping to landscape mode.
> Naturally, I lamented greatly about how my landscape- > specific stylesheet was going to go to waste, but the > response was basically, "Sorry about that". My contact > offered no real hope of a workaround, which is why I > was very pleasantly surprised by Christopher Allen's > recent viewport experiments that show there *are* > resize messages being sent eventually. And, as Joe Hewitt > has shown, one can do continuous polling to determine if > the screen dimensions have changed. These "hacks" may be > our only options at this point. (My conclusion, not > anything suggested by Apple.)
> x Flick-scrolling. This is, as I surmised in a different > thread some time ago, a "meta" feature of Safari that > is meant *exclusively* as a way for the browser to move > the entire window up and down quickly. That's why the > title bar moves. So, the only way to flick-scroll through > a list is to display that entire list on a really tall > page. Flick-scrolling is not, therefore, for manipulating > scrolling divs *within* a web page. Again, I lamented that > I'd been *expecting* users to flick-scroll through items > in one of the "panels" of the iScopes web app, and again, > the response was "Sorry about that". No suggestion to use > iframes or other workarounds.
> x Contrary to what we may have seen in Apple's promotional > videos, there's no way to hide the Safari location bar or > tool bar (yet). (I'd *swear* the guy said "yet" ... but > don't hold them to that.)
> x There's apparently no way to suppress that "darkening" > effect when clicking on a div that takes a mouse event. > (Very unsightly when your buttons aren't rectangular > and/or don't extend to the boundaries of the clickable > div.) I was told that they'd "look into it", but don't > expect anything anytime soon.
> x They're working to put together documentation and > guidelines and sample code (for "cool effects") for all > of us, but I was given no idea of the time frame on that.
> I think that's all I have at this point. Feel free to ask for > clarification, although I don't know if I can offer any more clarity. > Our primary focus in the conversation was getting my *specific* app > working properly. Many of the things I list above came from tangential > comments related to what we were discussing. I didn't think it an > appropriate use of my contact's time to pump him for details on every > open question about iPhone web app development. (I certainly don't > want to wear out my welcome with Apple; as you might imagine, I value > it highly.)
Well, let's be fair. The only reason Apple announced the iPhone in January at all is because they had to submit to the FCC's certification process or whatever it is. If it weren't for that, we all would have heard about the product the day it was available in stores.
The remarkable thing about Safari on the iPhone is that it works as well as it does. Which is really amazingly well. Let's not lose sight of that as we focus on the imperfections.
> I gotta say though, if Apple wants to embrace the web development > community and web standards, they're certainly off to a HORRIBLE > start. All this NDA stuff is a bunch of nonsense. If they were > really serious about web apps being the primary way to develop third- > party apps for the iPhone, they should have publicly released > guidelines on how to develop for the iPhone on the day of Job's > Keynote. So now here we are days after the release of the iPhone and > still no public guidelines? ... and come to find out Apple is picking > and choosing which developers they give additional information to?
> Memo to Apple: that's not the way the web standards community works. > We share information and we work from the same standards. We embrace > technologies that are freely accessible to everyone and we reject > technologies that are part of a walled garden, "it's who you know and > how much you're willing to pay", mentality.
> I'm really hoping that these are just some initial missteps. But its > certainly not a good sign of where Apple is headed. Its in their best > interest to have the maximum number of developers interested in > developing for the iPhone. They'll make a hell of a lot more money > that way than they will by trying to sell more tickets to the WWDC > where they dole out secret information.
>> Apple contacted a(n unknown-to-me) number of iPhone web app >> developers >> on Thursday, offering advice on how to make their apps work properly >> on iPhone in time for launch Friday. (Let me say publicly: That >> gesture was *greatly* appreciated!) I was contacted by a member of >> the >> iPhone/Safari/WebKit team in order to improve the "iScopes" app I >> created for Astrology.com:
>> (If you stop at just "/iphone", you'll get a landing page that's >> missing an iPhone-specific optimization (namely, the viewport meta >> tag >> we've all come to know and love), which is rather funny considering >> the heading. :) That page should be updated "soon".)
>> I've been released from the Non-Disclosure Agreement covering the >> conversation, so I'll share some of the things from it. Consider this >> information second-hand and hardly definitive. I don't speak for >> Apple, and it's entirely possible that I misinterpreted some things >> that were said. (In particular, I mention a few times that my contact >> didn't offer workarounds for this or that limitation. That doesn't >> necessarily mean that there *aren't* decent workarounds, perhaps even >> "easy" ones; my contact may simply be unaware of them or unwilling to >> go into them or whatever.)
>> x iPhone Safari isn't the same as Safari 3.0. They >> "forked" a while ago. If you don't have iPhone, >> they recommend testing apps in Safari 2.x and >> 3.0 on your Mac (or, presumably, PC). On iPhone, >> an app will tend to perform somewhere between >> the two. (Note that iPhone-Safari has a great deal >> more CSS3 support than Safari 2 (though not quite >> as much as in Safari 3). So, your app might look >> *terrible* in Safari 2 --mine does-- but still >> render nicely in iPhone.)
>> x For animations, they recommend using 'setTimeout's >> with wait parameter set to 0:
>> function startAnimation() >> { >> // set up animation global variables, etc.
>> setTimeout( "stepAnimation()", 0 ); >> }
>> function stepAnimation() >> { >> // do something
>> The contact considers 'setTimeout's better than >> 'setInterval's, although that might just be his >> personal preference. (Still, he recommended changing all >> my 'setInterval's to 'setTimeout's during our debugging >> session.)
>> Note that, on a Mac, animations set up this way will zip >> along in a flash, making debugging tricky. However, on >> iPhone, they're *much* slower.
>> x The first tip given was about that viewport meta tag
>> <meta name="viewport" content="width=320" />
>> My contact didn't say anything about scaling parameters, >> however. (I didn't know about them at the time, so >> didn't ask. Perhaps I should now. :)
>> x iPhone-Safari doesn't send any specific messages when >> flipping to landscape mode.
>> Naturally, I lamented greatly about how my landscape- >> specific stylesheet was going to go to waste, but the >> response was basically, "Sorry about that". My contact >> offered no real hope of a workaround, which is why I >> was very pleasantly surprised by Christopher Allen's >> recent viewport experiments that show there *are* >> resize messages being sent eventually. And, as Joe Hewitt >> has shown, one can do continuous polling to determine if >> the screen dimensions have changed. These "hacks" may be >> our only options at this point. (My conclusion, not >> anything suggested by Apple.)
>> x Flick-scrolling. This is, as I surmised in a different >> thread some time ago, a "meta" feature of Safari that >> is meant *exclusively* as a way for the browser to move >> the entire window up and down quickly. That's why the >> title bar moves. So, the only way to flick-scroll through >> a list is to display that entire list on a really tall >> page. Flick-scrolling is not, therefore, for manipulating >> scrolling divs *within* a web page. Again, I lamented that >> I'd been *expecting* users to flick-scroll through items >> in one of the "panels" of the iScopes web app, and again, >> the response was "Sorry about that". No suggestion to use >> iframes or other workarounds.
>> x Contrary to what we may have seen in Apple's promotional >> videos, there's no way to hide the Safari location bar or >> tool bar (yet). (I'd *swear* the guy said "yet" ... but >> don't hold them to that.)
>> x There's apparently no way to suppress that "darkening" >> effect when clicking on a div that takes a mouse event. >> (Very unsightly when your buttons aren't rectangular >> and/or don't extend to the boundaries of the clickable >> div.) I was told that they'd "look into it", but don't >> expect anything anytime soon.
>> x They're working to put together documentation and >> guidelines and sample code (for "cool effects") for all >> of us, but I was given no idea of the time frame on that.
>> I think that's all I have at this point. Feel free to ask for >> clarification, although I don't know if I can offer any more clarity. >> Our primary focus in the conversation was getting my *specific* app >> working properly. Many of the things I list above came from >> tangential >> comments related to what we were discussing. I didn't think it an >> appropriate use of my contact's time to pump him for details on every >> open question about iPhone web app development. (I certainly don't >> want to wear out my welcome with Apple; as you might imagine, I value >> it highly.)
Safari 3 is still in beta, and of course the two _application versions_ of Safari for iPhone/Mac have diverged. Remember, the app is just the UI and Bookmarking stuff, etc.
I'm guessing WebKit is still the meat behind every Safari version, and that when Safari 3 is GM (around when Leopard ships), iPhone will get a software update. It doesn't make any sense for Apple to have two different versions of the engine, rendering in different ways, while still claiming they're the same app.
|
