incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon MacDonald <simon.macdon...@gmail.com>
Subject Re: Is navigator.app an API we want to support?
Date Tue, 31 Jan 2012 19:59:00 GMT
I did a quick look at Android and we could duck punch window.close() so
that it does a navigator.app.exitApp(). That could be a good solution if we
can determine what if any affect it will have on jQuery apps. As much as we
all love to hate on jQuery a lot of our users are leveraging their jQuery
experience to build mobile apps with Cordova and we don't want to totally
screw them over. Also, in a multi page app if window.close is executed does
this mean the entire app should close?

The other Android specific methods:

*loadUrl/cancelLoadUrl* - we can probably get rid of them now as we load
everything in a single web view. I believe they were more useful when we
had multiple instance of DroidGap in the same app. Bryce, can you comment
on this?

*overrideBackButton* - Imma gonna take this out right now. This is a legacy
piece of code. The proper way of doing this is to register an event
listener for the "backbuttton" event.

Simon Mac Donald
http://hi.im/simonmacdonald


On Tue, Jan 31, 2012 at 2:29 PM, Filip Maj <fil@adobe.com> wrote:

> Bryce suggested leaving window.close alone due to how some frameworks
> (*COUGH* jQuery) hoist into the history and whatnot. Not sure this is a
> real issue - Bryce can you provide an example where piggybacking off of
> window.close would mess stuff up? Plus, I don't want random web frameworks
> dictating how we build our APIs. That's not how this works...
>
> Also I like the idea of reviewing what we have in app right now. Currently
> we have, for stuff that is common across BB and Android:
>
> - exitApp
> - clearCache
> - clearHistory
> - backHistory
> - event stuff (pause/resume/hardware buttons). Don't think this is
> applicable though...
>
> Android only:
>
> - loadUrl
> - cancelLoadUrl
> - overrideBackButton
>
> I think if we can stay away from the history api extensions we're all
> gonna be better off. Worst case if history is not implemented properly on
> some platforms, again, I would consider monkeypatching the `history`
> methods with some native stubs to fill in an API that web devs expect to
> "just work."
>
> LoadURL/CancelLoadURL - again, my opinion about these is the same as
> history. Using "web" approaches such as setting `window.location` and
> using `window.open` (if you wanted to open in the stock browser or a new
> phonegap window instance, for example) are better, more intuitive
> approaches.
>
> exitApp -> window.close
>
> clearCache is interesting. The BB WebWorks container *can* do some
> caching, so WebWorks actually provides an API to clear the cache.
> Presumably Android has some native equivalent for this. This is probably
> the one method in `navigator.app` that is somewhat useful and has no web
> equivalent.
>
> My $0.02.
>
> On 12-01-30 7:02 PM, "Brian LeRoux" <b@brian.io> wrote:
>
> >I like window.close Fil --- exactly how we should look at PhoneGap
> >APIs. If its not a spec, or something we can polyfil, then it should
> >be a plugin.
> >
> >Think this is something we need to document in the wiki?
> >
> >On Mon, Jan 30, 2012 at 5:28 PM, Filip Maj <fil@adobe.com> wrote:
> >> Apparently discussion triggered by a JIRA issue filed, and now further
> >>discussion is happening in that thread:
> >>
> >> https://issues.apache.org/jira/browse/CB-206
> >>
> >> Chime in if you like :)
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message