Build an app that does the following Test: 1. Tests the WebAPIs supported by WebRT, and shows whether the API call passed or failed (Success/Failure) 2. Displays the results, here is an example http://dl.dropbox.com/u/171684/webrt-feature-test/index.html Showcase: 1. The app should also show typical usage of the APIs. 2. One possibility is to provide a UX for the user to choose a particular API, and the app would show how the API can be used and also link to the documentation/code snippet of the API Two versions of the APP needs to be maintained, one with privileges and one without. Background: Bill W has provided an early implementation of this Kitchen sink app http://dl.dropbox.com/u/171684/webrt-feature-test/index.html src: https://github.com/wfwalker/webrt-feature-test
Summary: Kitchen sink app to test and show platform capabilities → Kitchen sink app to test and show device API support on b2g and Android
Changing whiteboard to nom.
Whiteboard: a4a → a4a?
Bill and Fred to find someone to do this work; there is some prior art out there for reference. P2 for now.
Severity: critical → normal
OS: Mac OS X → Android
Priority: -- → P3
Hardware: x86 → ARM
This is Paul's old "Api" demo: http://paulrouget.com/mwc-demos/apis/
hey there vishy - in order to easily distinguish user stories / themes from development tasks in a bug tree - we've been putting [story] at the front of all bug titles in the "user story" component... is this amenable to you?
FYI (since I've been asked about this a few times): https://github.com/jds2501/webapi-permissions-tests/blob/gh-pages/test-webapi-permissions.zip?raw=true That's my test app I experimented with for testing permissions and various WebAPIs across different privileges.
Summary: Kitchen sink app to test and show device API support on b2g and Android → [story]Kitchen sink app to test and show device API support on b2g and Android
B2G project: http://kofway.github.com/indexb2g.html src: https://github.com/kofway/kofway.github.com Harald's work in support of partner engineering and FxOS simulator http://testno.de/about-device/ src: https://github.com/digitarald/about-device/ tests: https://github.com/digitarald/about-device/blob/master/suite.js Bill's work in support of verifying cross-platform http://dl.dropbox.com/u/171684/webrt-feature-test/index.html src: https://github.com/wfwalker/webrt-feature-test Rob Nyman: http://robnyman.github.com/Firefox-OS-Boilerplate-App/
I'm writing predoc documentation https://etherpad.mozilla.org/kitchen-sink-predoc Please fill the gaps: * is the B2G/Gaia dev part needed? * do we want to build the "collecting server"?
Also there are some diagrams which might explain some stuff a little bit more http://piotr.zalewa.info/downloads/kitchensink-diagram.pdf And a simple list-detail example: http://zalun.github.com/kitchensink_prototype/manifest.webapp
hi there team - This story has no dev bugs blocking it. Which are the development bugs tracking the dev work on kitchen sink? Is this Piotr's work? :-) When you get a quick sec, please set the dev bugs to block the story.
Hmm...there's a point of confusion I think that I'm seeing in the bug tree that I think needs clarity. The Android program probably isn't going to get a lot of value out of kitchen sink app for a *long* time given that many of the APIs the kitchen sink app would show off would hit on b2g areas. We don't even have an ETA on many of the APIs actually. And for ones that already exist on Android, we have existing demos that already target this problem. So I'm not sure if there's really a concrete plan in the Android space here. Or at least that's the impression I pulled out of some of the recent dev-webapi threads. Vishy - Can you shed some light here?
Context btw is here - https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.webapi/TWvyBT8W73s.
Jason agreed. The app will be used to test the APIs on FxOS initially. Once we have support for packaged/privileged apps in Android we can run the app on Android. I think we can clear the A4A? from the whiteboard. we will still be tracking it as part of 832525
Adding the main bugs for packaged app support on Android as dependencies.
(In reply to Mark Finkle (:mfinkle) from comment #13) > Adding the main bugs for packaged app support on Android as dependencies. None of these are really relevant to this bug. The kitchen sink app can be implemented entirely independent right now if Android has packaged app support or not. Read the comments above that talk about this. We should really drop the scope here down to b2g and only revisit this for Android until the many other things are done first. I literally don't expect this kitchen sink app to start being analyzed on Android for a very, very, very, long time. We need a bunch of APIs implemented, packaged apps implemented, and privileged apps implemented. That's a huge scope with many unknowns that I doubt we even know what we're planning to do about a year ahead. I'm morphing the bug to target b2g cause that's the immediate scope to be done.
hey there jason - until vishy aligns with the program team (we met this morning and meet again on Monday) to assign the right product theme, can we leave this story, blocking the theme for now? won't touch the dev bugs of piotrs... understand your point that the dev work is not happening in android. the program team and vishy may very well decide to nom this for a different program, however, i'd like to not lose the bug while that conversation is happening.
(In reply to Caitlin Galimidi from comment #15) > hey there jason - > > until vishy aligns with the program team (we met this morning and meet again > on Monday) to assign the right product theme, can we leave this story, > blocking the theme for now? > > won't touch the dev bugs of piotrs... understand your point that the dev > work is not happening in android. > > the program team and vishy may very well decide to nom this for a different > program, however, i'd like to not lose the bug while that conversation is > happening. I don't think that's relevant anymore given that the bug has been mprphed to b2g since that's the immediate known scope that we know we can complete and track effectively. Split out and file a new bug for Android if it ends up being necessary, although I don't expect we'll know this for quite some time. The two pieces of development really need to be entirely independent of one another - there's similarities of what would be implemented, but there's a good enough inherent unknowns that dictates tracking these entirely separately. Note that this is really up to product to make the call.
gotcha. thx jason.
Vishy & I talked about this in person a sec ago. He made a case I didn't initially think about of why you would track this as a singular entity. In the 1st release of the kitchen sink app we would still allow it to run on Android, but it's purpose would report the "negative," not the positive about API support. This means that early on, the kitchen sink app's purpose on Android is to indicate more along the lines that certain APIs aren't supported, where as B2G show cases them as working. At the same time, we thought it might be better to track this under a different theme than the "APIs" bug this originally linked to. Instead, it should be tracked under a "dev tools" like theme, as this fits where this actually falls under.
Summary: [story]Kitchen sink app to test and show device API support on b2g → [story]Kitchen sink app to test and show device API support on b2g and android
I have change the settings in marketplace, but I was unable to install kitchensink on Nexus4. Firefox Beta said "Install failed" after first attempt Nightly showed an installation modal, but failed as well
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.