Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of alunny@gmail.com designates
 209.85.213.175 as permitted sender)
MIME-Version: 1.0
Reply-To: alunny@gmail.com
In-Reply-To: 
 <CADVgkyNrEASooAdtBMJTud4uT84B9xqOUD2gxoq95Ym-PtKWaw@mail.gmail.com>
References: 
 <CAE6O_-YUy89+hSQO+8g=1BZNm=tC+m_2ksd8xAqB17aWic6BLQ@mail.gmail.com>
	<CBDABB43.6740%fil@adobe.com>
	<CAE6O_-bjd1WBTukiTJY-gSXFYTKMKY96zh=Ko7nGJpFL0obYcA@mail.gmail.com>
	<CAPihERRnzcL0FKH2xchGxjFv=O5891762yDwq2Z_ZJmHyNeC=w@mail.gmail.com>
	<CAM1AYQD2fHjrEoiEHMUK3SC=YHLjz6ib6rWnqCA461O1EexBdQ@mail.gmail.com>
	<CAMT1KGPZi5cPPybo74gc01KxUPviwOTd8iimU=d+rQUr1LnKwg@mail.gmail.com>
	<CAPihERQoaneEqPk+EUAfHqCG92KrDYeKYYO06itsTqYvmEjZBw@mail.gmail.com>
	<CADVgkyNrEASooAdtBMJTud4uT84B9xqOUD2gxoq95Ym-PtKWaw@mail.gmail.com>
Date: Fri, 18 May 2012 10:56:18 -0700
Message-ID: 
 <CAPihERS3XVenXDtdWm6aFTTdnKb+BSUp+u5ea36xe1pcm=f2Sg@mail.gmail.com>
Subject: Re: API function: Open url in system web browser
From: Andrew Lunny <alunny@gmail.com>
To: Brian LeRoux <b@brian.io>
Cc: callback-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=20cf305e262bf270db04c0534470

--20cf305e262bf270db04c0534470
Content-Type: text/plain; charset=ISO-8859-1

On 18 May 2012 10:48, Brian LeRoux <b@brian.io> wrote:

> Agree we could use both those thins but before we solve w/ a new
> nonstandard api: what doesn't work about target _blank again?
>

* not cross-platform, and will never work on Android 2
* doesn't really work on iOS - iOS can't access the value of the target
attribute, so it's just checking whether "target" is set. Shaz has more
details in the JIRA issue referenced above
* only ever works for anchor tags - doesn't handle launching the browser on
any other event


>
> On Fri, May 18, 2012 at 7:32 PM, Andrew Lunny <alunny@gmail.com> wrote:
> > Yes, a cross-platform loadUrl with some tweaks would be the right fix.
> The
> > catch I remember with loadUrl on Android was that whitelisted URLs would
> > always open in the webview - I was probably missing the openExternal
> option.
> >
> > Putting ChildBrowser in core is one long-term fix - I think a better one
> is
> > to have a cross-platform, WebIntents style system for calling external
> > services. Both are beyond the scope of this problem though, and probably
> > warrant separate threads.
> >
> > On 18 May 2012 06:47, Bryce Curtis <curtis.bryce@gmail.com> wrote:
> >
> >> Android has loadUrl on the App plugin that will load url into a
> >> browser or same webview - depending upon a parameter.  Maybe we can
> >> tweak it and use as a basis for other platforms.
> >>
> >>  /**
> >>   * Load the url into the webview or into new browser instance.
> >>   *
> >>   * @param url           The URL to load
> >>   * @param props         Properties that can be passed in to the
> activity:
> >>   *      wait: int                           => wait msec before loading
> >> URL
> >>   *      loadingDialog: "Title,Message"      => display a native loading
> >> dialog
> >>   *      loadUrlTimeoutValue: int            => time in msec to wait
> >> before triggering a timeout error
> >>   *      clearHistory: boolean              => clear webview history
> >> (default=false)
> >>   *      openExternal: boolean              => open in a new browser
> >> (default=false)
> >>   *
> >>   * Example:
> >>   *      navigator.app.loadUrl("http://server/myapp/index.html",
> >> {wait:2000, loadingDialog:"Wait,Loading App", loadUrlTimeoutValue:
> >> 60000});
> >>   */
> >>  loadUrl:function(url, props) {
> >>    exec(null, null, "App", "loadUrl", [url, props]);
> >>  },
> >>
> >>
> >> On Fri, May 18, 2012 at 7:39 AM, Simon MacDonald
> >> <simon.macdonald@gmail.com> wrote:
> >> > Maybe it's time to pull the ChildBrowser into the core Cordova API? It
> >> > is currently available on Android/BB/iOS (not sure about WP7). This
> >> > seems like the logical place to put any new API. Specifically on
> >> > Android the ChildBrowser gives you two main methods:
> >> >
> >> > showWebPage - communicates with your main app by sending location
> change
> >> events.
> >> > openExternal - Fires up the native Android browser
> >> >
> >> > Simon Mac Donald
> >> > http://hi.im/simonmacdonald
> >> >
> >> >
> >> > On Thu, May 17, 2012 at 6:12 PM, Andrew Lunny <alunny@gmail.com>
> wrote:
> >> >> Why would a new API be overkill for something tons of apps and users
> >> >> need? Here are some representative threads from PG Build about users
> >> >> wanting this kind of API:
> >> >>
> >> >>
> >>
> http://community.phonegap.com/nitobi/topics/external_links_outside_webview
> >> >>
> >>
> http://community.phonegap.com/nitobi/topics/iframes_open_in_safari_in_ios
> >> >>
> >>
> http://community.phonegap.com/nitobi/topics/why_app_opens_in_external_widow
> >> >>
> >>
> http://community.phonegap.com/nitobi/topics/opening_native_browser_programmatically_with_phonegap_build
> >> >>
> >>
> http://community.phonegap.com/nitobi/topics/js_opening_links_methods_and_config_xml_access_tag
> >> >>
> >> >> I realize a few of those were started by the same user, but there are
> >> lots
> >> >> of me-toos and responses.
> >> >>
> >> >> -1 on clobbering window.open. window.open takes 3 parameters, two of
> >> which
> >> >> are invalid for this use case, and lacks a callback parameter (for
> >> example,
> >> >> if the user is prompted with a choice of browsers on an Android
> device
> >> and
> >> >> declines to open the link entirely).
> >> >>
> >> >> On 17 May 2012 14:27, Shazron <shazron@gmail.com> wrote:
> >> >>
> >> >>> iOS doesn't differentiate what the target attribute value is (thus
> >> >>> ambiguous in Objective-C what the intent is).
> >> >>>
> >> >>> Good idea - we could clobber window.open, sure - and we add the
> native
> >> >>> bits to support this.
> >> >>>
> >> >>> On Thu, May 17, 2012 at 2:27 PM, Filip Maj <fil@adobe.com> wrote:
> >> >>> > So target="_blank" is no good to use for this.
> >> >>> >
> >> >>> > A "new" API seems overkill for me.
> >> >>> >
> >> >>> > What about clobbering window.open ?
> >> >>> >
> >> >>> > On 5/17/12 2:19 PM, "Shazron" <shazron@gmail.com> wrote:
> >> >>> >
> >> >>> >>Punted this too much, need all of your input on this.
> >> >>> >>
> >> >>> >>Summary:
> >> >>> >>We need an API function on all platforms to always open a url in
> the
> >> >>> >>system web browser, right now each platform does its own thing,
> and
> >> on
> >> >>> >>iOS it is very wonky, relying on a something that is ambiguous
> >> >>> >>(navigation type value) through the target attribute of an anchor
> >> tag.
> >> >>> >>Basically, I agree with Andrew's proposal here:
> >> >>> >>
> >> >>>
> >>
> https://issues.apache.org/jira/browse/CB-362?focusedCommentId=13247777&pag
> >> >>>
> >> >>>
> >>
> >>e=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment
> >> >>> >>-13247777
> >> >>> >>
> >> >>> >>
> >> >>> >>JIRA issue:
> >> >>> >>https://issues.apache.org/jira/browse/CB-362
> >> >>> >>
> >> >>> >>See the matrix in the PG Build blog post:
> >> >>> >>https://build.phonegap.com/blog/access-tags
> >> >>> >
> >> >>>
> >>
>

--20cf305e262bf270db04c0534470--