Chromelessness in Engage 0.3

[Colin Clark]

Just as a follow up to this thread, I did indeed commit this fix to trunk a few days ago, and it's working nicely and chromelessly on the daily build instance of Engage 0.3.

There's one caveat: we haven't yet implemented our own custom navigation bar and back button, so the only direction is forward for the next few days.

Colin

On 2010-02-01, at 4:30 PM, Colin Clark wrote:

> Hi Justin,
> 
> Wow, you're on to something here! Nice detective work!
> 
> On 2010-01-31, at 7:58 PM, Justin Obara wrote:
>> http://www.coldfusionjedi.com/index.cfm/2008/10/9/Two-iPhone-development-tips-and-jQuery-to-the-rescue
>> 
>> The site mentioned above, talks a bit about these issues, but if you read on down into the comments, there may be some hacks to work around the problem for navigating between pages. Seems like some people have had success keeping the full screen webapp alive outside of safari if you use the link to have javascript change the window.location.href to the desired url.
> 
> The comment on this blog does indeed mention how assigning to window.location won't cause Safari's chrome to appear. I tossed the following more unobtrusive code into the Home screen, and it worked!
> 
> jQuery("a:not([href^=#])").click(function (evt) {
>    window.location=$(this).attr("href");
>    evt.preventDefault();
> });
> 
> There are a couple of consequences to this. For starters, we're assuming that all links that start with # aren't going to cause a page transition. This is probably sensible, but not necessarily safe. I think it's reasonable for Engage 0.3, however.
> 
> The only case this won't address is page transitions that occur as the result of a form submission. For now, we'll probably be fine. Perhaps the Jedi is correct and this won't be a problem anyway.
> 
> We'll probably need to put this code into a JavaScript file that all our components use. Off the top of my head, it seems reasonable to bind it as a live() event so that it will work with all links, regardless of Renderer usage, etc.
> 
> Thoughts, comments, or reasons why we shouldn't go ahead and do this for Engage 0.3?

---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org