You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Patrick Mueller <pm...@gmail.com> on 2012/03/12 14:58:14 UTC
platform 'errgen'
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
Re: platform 'errgen'
Posted by Viras <vi...@users.sourceforge.net>.
This is really a nice idea. Currently I stick to cordova-qt exactly for
that reason (the Qt-Simulator is really fast and lets you emulate all
this).
However as you mentioned I strongly vote for a platform which also
supports returning static data instead of errors. This in fact could
then later on evolve to a real simulator application for cordova based
applications (by e.g. offering a popup-window which allows to tweak the
return values of the API calls).
Am 2012-03-12 14:58, schrieb Patrick Mueller:
> 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.
--
GOFG - Get On Fat Guy
http://www.gofg.at/ - powered by Cordova
Re: platform 'errgen'
Posted by Roland Avelino <la...@yahoo.com.ph>.
>
> So, although `errgen` can work on a desktop, the goal of the `errgen`
> platform is NOT that it is `Cordova for the desktop`; that's something
> else. This would just be something you could happen to use on a desktop.
> It would obviously also work on a mobile device.
>
I might have misunderstood the purpose of the port in the grand sense.
Anyway, it is a good idea for instrumentation and tooling then. :)
Regards.
On Tue, Mar 13, 2012 at 12:54 AM, Patrick Mueller <pm...@gmail.com> wrote:
> On Mon, Mar 12, 2012 at 11:19, Roland Avelino <la...@gmail.com>
> wrote:
>
> > 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.
> >
>
> So, although `errgen` can work on a desktop, the goal of the `errgen`
> platform is NOT that it is `Cordova for the desktop`; that's something
> else. This would just be something you could happen to use on a desktop.
> It would obviously also work on a mobile device.
>
>
> > 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?
> >
>
> 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.?
> >
>
> I guess I sort of see that there are many possibilities for `platforms`
> here, all specialized to do different things. It wasn't really my
> intention to build a Cordova platform that ONLY EVER GENERATED ERRORS. It
> was just a tactical decision to make the implementation easy. But after I
> did it, I happened to think - "Ya know, it might actually be useful to test
> your app on a 'platform' that only ever generated errors".
>
> Having 'Desktop' versions of Cordova clearly make sense to someone, since
> some of that work was done back in the "old PhoneGap days". I don't think
> the "use native versions of accelerometer/geo/etc" is really any different
> here than on the mobile platforms though - of course, for production, you
> want to use the native versions as much as possible and not even have
> Cordova code in the code path.
>
> --
> Patrick Mueller
> http://muellerware.org
>
Re: platform 'errgen'
Posted by Patrick Mueller <pm...@gmail.com>.
On Mon, Mar 12, 2012 at 11:19, Roland Avelino <la...@gmail.com> wrote:
> 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.
>
So, although `errgen` can work on a desktop, the goal of the `errgen`
platform is NOT that it is `Cordova for the desktop`; that's something
else. This would just be something you could happen to use on a desktop.
It would obviously also work on a mobile device.
> 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?
>
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.?
>
I guess I sort of see that there are many possibilities for `platforms`
here, all specialized to do different things. It wasn't really my
intention to build a Cordova platform that ONLY EVER GENERATED ERRORS. It
was just a tactical decision to make the implementation easy. But after I
did it, I happened to think - "Ya know, it might actually be useful to test
your app on a 'platform' that only ever generated errors".
Having 'Desktop' versions of Cordova clearly make sense to someone, since
some of that work was done back in the "old PhoneGap days". I don't think
the "use native versions of accelerometer/geo/etc" is really any different
here than on the mobile platforms though - of course, for production, you
want to use the native versions as much as possible and not even have
Cordova code in the code path.
--
Patrick Mueller
http://muellerware.org
Re: platform 'errgen'
Posted by gt...@gmail.com.
One of the hopes for cordova-js is to build out an instrumented platform that will plug into ripple (ripple.tinyhippos.com)
Having our code structured this way allows us to build an emulation / testing platform to plug into ripple/webinspector/winre/etc.
The main goal is to keep the bridge between native and UI small and tight so but with enough control and flexibility for enhanced tooling.
That being said, yes Pat ... I am very interested in this branch ;)
Sent on the TELUS Mobility network with BlackBerry
-----Original Message-----
From: Roland Avelino <la...@gmail.com>
Date: Mon, 12 Mar 2012 23:19:51
To: <ca...@incubator.apache.org>
Reply-To: callback-dev@incubator.apache.org
Subject: Re: platform 'errgen'
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 <pm...@gmail.com> 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
>
Re: platform 'errgen'
Posted by gt...@gmail.com.
Btw you can find the code for ripple here:
http://github.com/blackberry/Ripple-UI
Sent on the TELUS Mobility network with BlackBerry
-----Original Message-----
From: gtanner@gmail.com
Date: Mon, 12 Mar 2012 15:29:35
To: <ca...@incubator.apache.org>
Reply-To: gtanner@gmail.com
Subject: Re: platform 'errgen'
One of the hopes for cordova-js is to build out an instrumented platform that will plug into ripple (ripple.tinyhippos.com)
Having our code structured this way allows us to build an emulation / testing platform to plug into ripple/webinspector/winre/etc.
The main goal is to keep the bridge between native and UI small and tight so but with enough control and flexibility for enhanced tooling.
That being said, yes Pat ... I am very interested in this branch ;)
Sent on the TELUS Mobility network with BlackBerry
-----Original Message-----
From: Roland Avelino <la...@gmail.com>
Date: Mon, 12 Mar 2012 23:19:51
To: <ca...@incubator.apache.org>
Reply-To: callback-dev@incubator.apache.org
Subject: Re: platform 'errgen'
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 <pm...@gmail.com> 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
>
Re: platform 'errgen'
Posted by Roland Avelino <la...@gmail.com>.
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 <pm...@gmail.com> 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
>
Re: platform 'errgen'
Posted by Brian LeRoux <b...@brian.io>.
Love it --- will make a good base for more tooling and automations.
On Mon, Mar 12, 2012 at 12:00 PM, Filip Maj <fi...@adobe.com> wrote:
> Yes I like it. To reiterate what you said, if only to be able to quickly
> and easily test how your application performs when only errors are
> returned seems quite useful.
>
> On 3/12/12 6:58 AM, "Patrick Mueller" <pm...@gmail.com> 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/1e512d8fecdea91cf39
>>dcb40013d154fbbe6637b
>>
>>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
>
Re: platform 'errgen'
Posted by Filip Maj <fi...@adobe.com>.
Yes I like it. To reiterate what you said, if only to be able to quickly
and easily test how your application performs when only errors are
returned seems quite useful.
On 3/12/12 6:58 AM, "Patrick Mueller" <pm...@gmail.com> 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/1e512d8fecdea91cf39
>dcb40013d154fbbe6637b
>
>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