cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frederico Galvão <frederico.gal...@pontoget.com.br>
Subject Re: [Discuss] Ripple as a platform
Date Fri, 08 Aug 2014 23:34:25 GMT
I think one of Julian's last sentences sum it up well for me: "They see
Ripple like an instruction level simulator that is fast but not
cycle-accurate: limited accuracy but useful nevertheless.".

That, with what Ray said, is what I think Ripple should be or do: give me a
fast, instantaneously reloadable, uniform way to run the non-native part of
my cordova application.


- Being able to test the html+css+js part of my application without any
walls (compilation, packaging, assembly, installation, initialization,
remote debugging) is a MUST.
- Being able to change some settings of the emulated device is a MUST:
current ripple-emulator already does that through the mentioned device
dropdown, but it's limited and sometimes buggy. I'd rather be able to just
use the emulation tools from Chrome or Firefox themselves, which are
amazing at this point.
- Being able to have the official plugins simply "not break" in a ripple
environment is a very very good PLUS.
- Enabling third party plugin developers to offer mocks or real emulation
of their plugin's behaviour is a good PLUS.
- Being able to test platform specific parts or behaviours of my
application (merges, specific plugin APIs, specific cordova stuff) is a
nice PLUS, but I've never ran into a situation where I needed this and I
couldn't get the same results by running ripple in a different browser
(need iOS? run in Safari. need WP8? run in IE10. need android 2.3? well...
it's time to move on ;).

Therefore, if I have a vote, I'll vote that Ripple become a single platform
sibling to the other ones already existing.

Having it as many platforms (being through standalone platforms "prepare
ripple-ios" or through an option to the current ones "prepare ios
--ripple") is not a bad thing feature wise, but it's much more complex to
implement and to use, and I can also see beforehand many issues arising
with plugins or any other code running in ripple expecting it to emulate
that platform beyond what ripple can actually do. [Uncanny valley]


2014-08-08 13:43 GMT-03:00 Ray Camden <raycamde@adobe.com>:

> (Julian also posted to the Ripple list, so for folks subscribed there,
> pardon my cut and paste.)
>
> The underlying idea of the prototype, as I see it, is to use the
> plugin.xml format to describe additional files that would be used for
> emulation of that plugin.  The prototype CLI treats ripple as a platform
> that is a peer to the other platforms, such as android, windows8, ios and
> so on.  The idea is to use the CLI "cordova prepare ripple" command to
> create sources that are suitable for use with Ripple.
>
> This would be nice, but I worry how many plugin authors will bother to
> write in support. Maybe they will as a "competitive advantage", but, I
> worry. ;) Of course, Ripple has long had a concept of, "If I don't know how
> to respond to a call, just give me some JSON crap", so as long as that
> works we're good.
>
>
>
> The question this raises for me is whether Ripple is best thought of as
> one platform or as a set of platforms, one for each real platform.  In
> other words, instead of preparing and emulating "ripple" code, maybe Ripple
> should emulate "ripple-ios" code when emulating an iOS device,
> "ripple-android" code when emulating an android device and so on.  The
> Ripple Cordova 3 support Gord Tanner added follows this model.
>
> Remember that the current usage is to allow users to select any device
> *after* they have started Ripple. So they fire it up, it defaults to the
> last device, and then they can switch the device via a drop down. It isn't
> presented as a platform, but rather a drop down of devices.
>
> I'm not saying it has to *stay* that way, just providing context to how it
> works now.
>
> As a user, I think I just want to launch Ripple and not a particular
> platform.
>
>
>
> One can imagine a different prototype CLI that uses the same extended
> plugin syntax but makes different CLI changes.  Instead of ripple being
> another user-visible platform, it could just be a command line switch, as
> in "cordova prepare windows8 --emulate ripple".  This would tell the CLI to
> include the contribution of both the windows8 and ripple platforms in the
> output.
>
> If we switch from having device drop downs to platform drop downs, that
> would be ok, but I'd still like to be able to switch in the UI.
>
> It's obviously simpler to treat ripple as one platform.  The downside is
> that it makes it impossible to emulate platform-specific source differences.
>
> Keep in mind that I think the *primary* use of Ripple, and folks, feel
> free to disagree with me, is to test the *non* hardware specific stuff. As
> I used to say when I presented on PhoneGap, I'm not so concerned about the
> Camera API. I know that crap works. Instead, I want to focus on the non-PG
> stuff, like some random remote API. I want to be able to quickly test it
> and just mock the device stuff like Camera, GPS, etc.
>
> When it comes to random plugins, like bluetooth for example, I'm ok with
> ignoring it or - in the future with plugins supporting a "do this for
> Ripple mode", just defaulting to a sane value.
>
> For example, imagine the bar code scanner. I'd be happy with - when
> running under Ripple, it simply returned a hard coded value for the scan.
>
> Or, even better, if it popped open a dialog:
>
> * Click here for a default value
> * Type here to enter your own value
> * Click here to fake a failed scane
>
>
>
> Platform-specific source differences can arise in two ways.  The "contact
> list" plugin for example provides functions that only exist on iOS.  These
> functions are defined in a JavaScript file you only get when you prepare
> for ios. Platform-specific source differences can also arise from the
> "merges" folder.  This allows an application developer to supply different
> files on different platforms. If Ripple is multiple platforms, then the
> user can test with the sources that would actually be used on the selected
> device.  If Ripple is one platform, then the user must test with one code
> base for all devices.  The plugin author decides what the ripple sources
> will be for the plugin, and the application author decides what that will
> be for the merges.
>
> And again, I worry about what authors will do this. You are asking the
> author now to provide mock services for multiple platforms, which may be
> asking a lot. Then again, maybe they will do it.
>
> I think the ideal solution would be:
> As a plugin author, I can write one JS file that will be used by Ripple. I
> put my mock crap in there. Inside my JS I can sniff the current emulated
> device and IF I CHOOSE, do crap like, "particular feature X isn't available
> on iOS".
>
> This lets the author provide a quick mock for ripple and later, when s/he
> has time, provide a better mock (or let someone else do it).
>
> At Intel we discussed the one-versus-many question but no clear consensus
> has emerged. I think it boils down to an interesting philosophical question
> about what Ripple is or should be trying to be.
>
> This goes back to what I said above, about how *I* see Ripple being
> useful: Let me ignore/mock the PG stuff and focus on UI and other stuff
> like APIs, etc.
>
>
> ________________________________________
>
>


-- 

*Frederico Galvão*

Diretor de Tecnologia

PontoGet Inovação Web


( +55(62) 8131-5720

* www.pontoget.com.br <http://www.pontoget.com/>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message