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.macdon...@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 <alu...@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 <shaz...@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 <f...@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" <shaz...@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
>>> >
>>>
