Hi Patrick, This is what I would like to see as well with PhoneGap in the future, to support the desktop platform as a form of a mobile platform since there still exists a large number of devices in the netbook/ultrabook form.
Does Cordova really need to remove the native-ness functionality and opt for the framework to _just_ work in a desktop browser? Perhaps, we could support/opt to utilise HTML5 features like Geolocation/Storage (which already exists in Cordova). But, how will we support browsers that do not provide the HTML5 features, through poly-fills? So instead of: > build a platform that doesn't require ANY native code, so that you could > use it in > the browser. Since the Cordova 'APIs' have to do >something< I decided I'd > have them all return errors. Is there a future for Cordova to support the Desktop platform with most of it's Mobile _native_ features supported, e.g., Geolocation, Storage, etc.? Regards, Lan On Mon, Mar 12, 2012 at 9:58 PM, Patrick Mueller <[email protected]> wrote: > About two weeks ago, I spent the morning working on a new 'platform' for > Cordova, using the cordova-js framework. The original goal was to build a > platform that doesn't require ANY native code, so that you could use it in > the browser. Since the Cordova 'APIs' have to do >something< I decided I'd > have them all return errors. I called the platform 'errgen', and here's a > commit to a fork of mine with the code (and various drive-by fixes as > well): > > > > https://github.com/pmuellr/incubator-cordova-js/commit/1e512d8fecdea91cf39dcb40013d154fbbe6637b > > Seems to me like there's a couple of interesting things here: > > - building a platform like this shows you what sort of internal frameworky > things a platform has to do to get itself up and running; eg. a platform > has to arrange to call > `require('cordova/channel').onCordovaInfoReady.fire()` when `DeviceInfo` is > ready. > > - having a platform that doesn't require any natives means you can load it > in a desktop (or mobile) browser to see if you have any structural issues, > and use desktop tooling like (real) Web Inspector to debug some bits. > > - having a platform that returns errors every time you do something would > be a good way to test that your application actually handles errors > correctly. > > Any interest in continuing this work? There's some meta-work that needs to > be done; eg. decide how to handle "repeat-fire" APIs (eg, > `accelerometer.watchAcceleration()`) > > I could also see perhaps having a platform just like 'errgen', but always > returns the same static-y 'success' bits all the time. > > -- > Patrick Mueller > http://muellerware.org >
