Chromelessness in Engage 0.3

[Sambhavi Chandrashekar]

Hi Colin,

Thank you for your reply last evening. My main question was indeed about the
chromelessness in Engage and how I was getting caught without being able to
go back. I was starting new sessions of FE on the iPhone every time and
wasn't sure if the earlier sessions actually ended or were still running
somewhere and draining the battery. I was hesitant to spam the list about it
because things are still under development. I did write about some other
issues to the list.

Thanks.

Sam

On Wed, Feb 3, 2010 at 11:20 AM, Colin Clark <colinbdclark at gmail.com> wrote:

> 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
>
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20100203/d709806f/attachment.html>