This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
In the latest trunk build: 1. Install the PhoneGap module from the Update Center 2. Register a server (GlassFish or Tomcat) 3. Create a Ant-based Web project 4. Go to Project Properties -> Run 5. You can now select the target browser: Chrome, Firefox, Embedded browser, ... It would be nice if I could also choose Android Device, Android Emulator, iPhone Device and iPhone Simulator, like I can in HTML5 projects.
cordova.platforms module already provides an API for opening url on mobile device (Device.openUrl). There are several option how to implement this feature 1. cordova.platforms module can implement "top level" browser which will be available everywhere in the ide. On the other hand we probably don't want mobile browser to be the default for NB IDE. 2. cordova.platforms already have an API. Javaee module can use it 3. JavaEE can define it's own API and cordova.platforms module can implement it
> 1. ... On the other hand we probably don't want mobile browser to be the default for NB IDE. Agreed. > 2. cordova.platforms already have an API. Javaee module can use it I don't think javaee should depend on cordova.platforms - cordova.platforms is quite specific and should be only loosely coupled with the rest of the IDE. javaee does not depend directly on FireFox or Opera or Chrome, so it should not depend on cordova.platforms either. > 3. JavaEE can define it's own API and cordova.platforms module can implement it Yes, I think we will need something like this, but this API will need to be deeper than JavaEE, because the same thing applies to PHP. Also, cordova.platforms will be in webcommon cluster, so the API should be in webcommon or lower down. Right now there is module web.browser.api (in ide cluster), where lots of common browser-relates stuff is placed, so that would be a possibility. In the longer run, I think it would be more clean to place this API (and maybe some other things from web.browser.api) to another (new?) module in webcommon cluster, because all these things are specific to web applications, so they should not be present in the code that's present in non-web distributions (Java SE and C++).
+1 on everything what Petr said.
Implemented for web and php projects