07-29-2011 03:06 PM
Welcome one and all to the Ripple Open source project. Ripple is a cross-platform, web application emulation environment.
Please check out our github projects here:
http://github.com/blackberry/Ripple-Framework
This is the container that hosts the web-based UI and provides system services and interactions with the emulated application.
http://github.com/blackberry/Ripple-UI
This is the web-based UI which you interact with and is hosted in the Ripple - Framework.
We are really excited about the potential of this tool and approach to mobile web application development, and look forward to the community's thoughts and involvement.
Thanks!
08-01-2011 10:03 AM
Neat, the switch to Qt is a dramatic shift. Are the projects at https://github.com/tinyhippos being retired in favour of these new projects?
08-01-2011 01:01 PM
08-30-2011 04:26 AM
Thanks for opening up this wonderful project ![]()
What is the current architecture? I have seen IPC in the source codes and I am wondering how IPC is used in your Ripple Framework. And how the device API will be provided for the emulated application? Will you re-use the ripple.js framework in the Ripple-UI?
What are the features that would not have been possible in the Chrome extension architecture? Are you considering using QtWebKit bridge to access the native QObject?
08-31-2011 04:06 PM
Hi Haitao, thanks very much for your interest in Ripple!
Ripple will be moving to a stand-alone application within a QT Container that will allow us to host a "browser within a browser"; There will be one instance of QtWebKit that will run the Ripple UI, and another to run the WebWorks app itself. This will compartmentalize the WebWorks app itself and allow us to do things the current Google Chrome extension approach will not, such as emulating the WebWorks concept of whitelisting for all resources, cross-origin calls, true mobile rendering experience (eg. touch events, scrolling behaviour, different browser capabilities, etc.). This is where the IPC communication comes in, to allow the communication between the Ripple UI instance of QtWebKit and the application instance.
The current architecture is slightly different from our end goal architecture I described above, which we will evolve to over time. In the short term, the Ripple-Framework project/repository provides a QT container and QtWebKit view for the Ripple-UI project to be hosted in. Ripple-UI will then create an iFrame to host the WebWorks application, so the Ripple UI and the WebWorks app will be in the same QtWebKit instance. This is quite close to what Ripple does today in the Chrome extension approach, so we were able to leverage very quickly the current Ripple-UI codebase.
I hope this addresses your questions.
Thanks!
09-01-2011 10:27 PM
Hi Ken, thanks very much for your sharing of your end goal architecture and current architecture!
I am not very clear of the device simulation mechanism of your end goal architecture. Currently Ripple UI framework provides the UI control panel, emulation bridge and the emulation environment (in an iframe with simulated device API). Do you mean you will run the UI control panel in the QtWebKit, use IPC as an emulation bridge, and run the emulated app in the BlackBerry WebKit? Will the device still be simulated by Ripple javascript library?
If the device simulation mechanism of the end goal architecture is like this, maybe you might find Qt simulator project (http://doc.qt.nokia.com/qtsimulator-1.2/index.html) helpful. Currently they already have a simulator control panel and IPC mechanism, and the Qt application runs with a simulated Qt mobility. If the BlackBerry WebKit could interact with the simulator panel, it is an implementation alternative of the end goal architecture.
Will you set up IRC channel and mailing list for Ripple framework and Ripple UI? I'd like to contribute to those projects, do you have a CLA (contributor license agreement)?
Thanks
-Haitao
09-16-2011 10:45 AM
Hi Haitao. You have mostly got the architecture right, except that the emulated application will actually run in a separate instance of QtWebKit. There are a few reason for that, one being that we will be supporting emulation for multiple devices, not just BlackBerry devices, so undertaking the desktop port of our own BlackBerry webkit is of less importance. And QTWebKit has some nice interfaces for configuring how it operates that will allow us to configure it to mimic different platform capabilities.
Interesting, we definitely need to take a look at the qt simulator project.
Yes, we do have a CLA. you can find more information on getting involved in our BlackBerry Open source projects here:
http://blackberry.github.com/howToContribute.html
Mailing lists are certainly something we are considering. We are evolving the supporting tools/processes for our open source projects, and taking it step by step. So far we have been relying on GitHub features, and our existing BlackBerry forum infrastructure, but as things get moving with greater speed, we will be looking to see if we need to augment our supporting tools. For now, this forum, and the GitHub wiki/issues features are the best ways to get involved.
Thanks!
01-11-2012 02:28 AM
Hi,
I am looking to automate what we are doing on the Ripple emulator with Selenium. So we would be ideally be passing the commands from selenium to Ripple. Is this possible with the new Qt?If yes, what web driver do I need to use to get the two talking to each other i.e. Can I use the chrome webdriver to go ahead and start automating using Selenium?
11-26-2012 04:53 AM
Hi,
I currently use your chrome extension. Should I continue to use it or download your app?
Will you still continue to emulate for Android and iOS devices?
Many thanks
Jeremy
12-04-2012 09:05 AM - edited 12-04-2012 09:20 AM