On Mon Apr 21 03:39 PM, Sergey Grebnov (Akvelon) wrote:
> module.exports = function(platform, projectDir, pluginDir, cmdLine) {
> console.log('hook.js: ' + platform);
> console.log('hook.js: ' + projectDir);
> console.log('hook.js: ' + pluginDir);
> console.log('hook.js: ' + cmdLine
On Fri Apr 18 11:35 AM, Sergey Grebnov (Akvelon) wrote:
> Sound like most of us prefer module.export. Cool, will update the code today
> and let you know once this is done.
>
> Since we will be moving to cordova-lib the next action item here could be
> creating uniform hooks with shared code for
On Tue Apr 15 09:36 AM, Andrew Grieve wrote:
> I think everyone is on board with the idea that modules should be used to
> enable
> sharing code, and for code organization.
>
> Two problems that are happening in practice:
> - Multiple pull requests (plugman and CLI) to make a change
> - Code dupl
On Thu Apr 10 01:35 PM, Michal Mocny wrote:
>
> List of hangouts scheduled:
> https://wiki.apache.org/cordova/Google%20Hangout%20Discussion%20Notes
> Agenda for this next one: https://wiki.apache.org/cordova/Agenda20140415
>
Awesome, I'll join in
Cheers,
Jon
On Wed Apr 9 08:40 PM, Brian LeRoux wrote:
>
> The cons are wrong. You can import plugins and indeed you can test plugins.
> The statement that we shouldn't need to compile/transpile is not correct if we
> want to evolve things. Its the only path we have that will keep things
> backwards
> compat
On Tue Apr 8 03:50 PM, Andrew Grieve wrote:
>
> The question of whether we *need* them is not a good way to phrase it I think.
> Rather:
> Pros?
- Cordova doesn't pick a style of writing modules/plugins
- More control over how plugin loading works
Prefer this approach for now, might be a better
On Tue Apr 1 07:27 AM, Anis KADRI wrote:
> I've been working on an alternative build system for cordova-js over the last
> little
> while and I finally have something to share.
>
Personally like this direction
>
> Some random thoughts for the future:
> - clobbers/merges/runs should be useless.
On Thu Apr 3 09:20 AM, Bryan Higgins wrote:
> My point is only that we should be consistent. If the platform element is
> used for
> preference, then why introduce an attribute which does the same thing for
> icon?
>
> Also, I've seen platform=, cdv:platform= and gap:platform= within the pull
>
On Thu Apr 3 05:06 AM, Axel Nennker wrote:
> It is a shame that CB-2606 is unresolved this long. We should have something
> rolled out soon.
>
+1, thoughts on splashscreens or other images?
On Sat Mar 29 03:11 PM, Brian LeRoux wrote:
> I think its a great idea. The platforms have a standard interface [1] for
> which the
> higher level CLI Node module depends. We could remove our logic for
> versioning/caching and leave that to npm. We distribute via npm already for
> the
> CLI so th
On Fri Mar 28 03:16 PM, Jesse wrote:
> 'process.platform' in node returns win32 for windows ( 32+64 ) 'process.arch'
> returns x64 if it is 64bit
>
>
Interesting didn't know.
In case anyone is curious about this, refers to v8's 'win32' platform / win32
api
https://github.com/joyent/node/blob/0
of their existence.
> > > > > >
> > > > > > my 0.02
> > > > > >
> > > > > > -a
> > > > > >
> > > > > >
> > > > > > On Sat, Mar 15, 2014 at 3:54 PM, Carlos Santana <
> > > csantan...@gmail.com
> > > > >
On Tue Mar 18 04:20 PM, Andrew Grieve wrote:
> No idea :P. Stumbled upon it when I was doing a recent CLI refactoring.
>
>
+1 for the change but we'd have to drop the widget namespace, no?
https://github.com/apache/cordova-cli/commit/45e80ac1b2c73a18155e74ac286067a4299742d8#diff-6e0c580ec9d220fc
On Fri Mar 14 11:36 PM, Carlos Santana wrote:
> I have being thinking on this sort of problem also.
>
> I think using npm to store none node code is perfectly fine use case.
>
> I vote to leverage npm as the building block and then build cordova functions
> on
> top of it.
>
+1 where possible
On Thu Mar 13 11:38 AM, Andrew Grieve wrote:
> I think it would be beneficial if we could release updates to platforms
> independent from others. Why?
> - Far easier to do one-off platform releases (e.g. quick turn-around on a
> security
> update, quick turn around on iOS is broken on the latest X
On Fri Mar 14 10:56 AM, Lisa Seacat DeLuca wrote:
> Bas, good catch.
>
> Still seeing the same error though when I use a : instead of ;
>
> C:\workspaces\lisa\test2>plugman install --platform android --project
> C:\workspaces\lisa\test2\www --plugin C:\workspaces\lisa\TestPlugin
> Installin
On Fri Mar 14 10:02 AM, Braden Shepherdson wrote:
> To be clear, you're suggesting that we have templates in the form of
> plugins? I'm
> not sure that's what we really want. At least, if we
> install them like regular plugins
> then there are several values that
> need to be changed, including the
; > plugin means devs can go to its plugin page to find its docs.
> > >
> > > I think just having default plugins would achieve the "everyone will
> > > probably want it" concern. But having it show up in "cordova plugin ls"
> > > will help d
On Mon Mar 10 04:07 PM, Jesse wrote:
> More on the concept of rolling into a platform ...
> My distinction is that there are some things that every platform should
> consider a
> baseline of browser functionality, and if the OS SDKs do not provide it out
> of the
> box, then we should. Some examp
> Import 'plaforms/android' into Eclipse:
> https://onedrive.live.com/?gologin=1&mkt=en-
> US#cid=295047487FC4F731&id=295047487FC4F731%215602&v=3
>
> Broken... but "cordova run" works... Is using eclipse still a 'core' thing?
> It's a "still want to use an IDE" thing. My preference is a cordova th
On Mon Mar 10 02:52 PM, Brian LeRoux wrote:
> While I wholeheartedly agree plugins, clean separation of concerns, discreet
> repos, all have big benefits if every single developer installs a plugin on
> day 1 that
> is specific to a particular platform I feel that might be a good indication
> the
On Mon Mar 10 12:51 PM, Michal Mocny wrote:
>
> I think we can solve that problem using a plethora of better
> alternatives, including
> install scripts (perhaps with a generator
> like yeoman, perhaps my just pasting
> snippets in tutorials), by
> supporting plugin dependencies for platforms, or
On Thu Mar 6 01:57 PM, Sergey Grebnov (Akvelon) wrote:
> Can we think about scripts as just a new plugin module? - Similar to
> js-module or
> config-file and which must be processed special way (by
> execution).
>
> src="src/windows8/SQLitePCL.Ext.dll" custom="true"/> src="src/add_win8_toastC
On Thu Mar 6 11:41 AM, Michal Mocny wrote:
> On Thu, Mar 6, 2014 at 11:16 AM, Jonathan Bond-Caron <
> jbo...@gdesolutions.com> wrote:
>
> > On Wed Mar 5 04:13 PM, Michal Mocny wrote:
> > > For cli workflow: hooks (including plugin hooks) can access
> > > co
On Wed Mar 5 04:13 PM, Michal Mocny wrote:
> For cli workflow: hooks (including plugin hooks) can access config.xml
> 's for things like the sqllite compile example (recompile only if
> settings changed would be nice), and access at runtime for the
> console example.
>
> For old workflow, perhaps
On Wed Mar 5 02:54 PM, Jesse wrote:
> I am a no to passing arguments, the use-case is really about doing some
> extra
> tasks for the current environment.
>
Not necessarily:
https://github.com/apache/cordova-plugin-console/blob/master/www/logger.js#L48
cordova plugin add cordova-plugin-console -
On Wed Mar 5 12:00 PM, Marcel Kinard wrote:
> In that case (i.e., "npm test") the user is explicitly invoking the
> script. If we are
> talking about hooks that run automatically on
> "cordova plugin add", then it is
> implicit. How about if the cli
> prompted the user when a hook request is presen
On Sat Mar 1 01:39 PM, Sergey Grebnov (Akvelon) wrote:
>
>
>
> preinstall.js is called before plugman.raw.install(platform, platformRoot,
> path.basename(dir), pluginsDir, options) and could be used to check system
> requirements, download/compile required libraries, etc
>
> afterinstall.js is
On Mon Mar 3 12:45 PM, Brian LeRoux wrote:
> sure, but that is most certainly a user space instrumentation and done
> very easily
> with a hook
>
> do ALL apps need that instrumentation? probably not
>
Fair enough, don't have a strong opinion about it.
Is the list of installed plugins & versio
On Sat Mar 1 02:19 PM, Brian LeRoux wrote:
> No, no, I'm suggesting this is a user space problem. Easily solved by
> the user.
> (Certainly the first/only time I've heard a desire for this
> feature.)
Here's a very common use case:
- error occurs
- send application info to a central server
Usu
On Fri Feb 28 04:06 PM, Michal Mocny wrote:
> Now that I look a bit deeper, that plugin I only returns
> specifically,
> not the entire contents of config.xml (name is not a
> ).
>
> It also does not currently implement a way to inspect all preferences,
> just has a
> way to get the value for a s
On Fri Feb 28 10:18 AM, Martin Bektchiev wrote:
> My first idea was to allow the installation of such interdependent plugins,
> but
> then I saw that once added they cannot be uninstalled due to the cylce in the
> graph. That's why I decided to stay consistent with uninstall and not allow
> it.
>
On Fri Feb 28 08:09 AM, Andrew Grieve wrote:
> Thanks Martin! Looks good! I've merged it in :)
>
>
Should just keep track of what's pending to be installed, why throw an
exception?
On Wed Feb 26 09:24 AM, Gert-Jan Braas wrote:
> >> expect(s).toHaveBeenCalledWith(temp,
> >> path.join('src', 'plugins', 'dummyplugin', 'DummyPlugin.js'));
> >> done();
> >> });
> >> });
> >> });
> >>
> >
> > Jasmine
On Tue Feb 25 03:24 AM, Gert-Jan Braas wrote:
> I've added some testing for firefoxos in plugman, but am a bit stuck on
> the
> uninstall handler.
>
> test:
> describe('of elements', function() {
> it('should remove stuff by calling common.removeFile',
> function(done) {
>
On Fri Feb 21 09:43 AM, Axel Nennker wrote:
>
> I would like to avoid to invent new elements or attributes. I think my plan
> works
> and would like to know what the group thinks about it.
>
The "icon problem" is you can have different icons of the same size for
different platforms.
The cordo
On Wed Feb 12 02:12 PM, Tim Kim wrote:
>
>
> Yep, Braden is correct. That is totally a bug. Filed here:
> https://issues.apache.org/jira/browse/CB-6023
>
Thoughts on?
Vs.
I'm trying to look at how this can apply to 'runtimes'. E.g.
Vs.
?
On Fri Feb 21 09:14 AM, Jonathan Bond-Caron wrote:
> On Thu Feb 20 04:07 AM, Axel Nennker wrote:
> > How about this strategy:
> >
>
> Would this work:
> ref="icons" src="icon.jpg" width="96" height="96" /
On Thu Feb 20 04:07 AM, Axel Nennker wrote:
> How about this strategy:
>
> project_dir/config.xml
> - no new elements in config.xml like cdv:icon
> - no new attributes in icon element in config.xml like cdv:platform or
> gap:platform
> - do not invent stuff we have to support for the rest of our l
On Sat Feb 15 01:56 PM, Dick Van den Brink wrote:
> I like the idea of json config files but how to handle cases where a element
> can
> occur multiple times? With only one element, it would generate an object, but
> with multiple elements it would change into an array. This might make the code
>
On Mon Feb 17 05:27 PM, Brian LeRoux wrote:
> almost certain we could align down to a single configuration for
> everything safely
> extending package.json (and treating
> ./platform/whatever/[...]/www/config.xml
> as compile targets
>
Sounds right, package.json is the top level config?
On Mon Feb 17 04:13 PM, Jesse wrote:
> If this only refers to the cli project level config, then I withdraw my
> objection.
>
config.json or config.xml would be top-level in the cli project
> However, consistency creates clarity.
>
> Maybe taking a step back, why do we have different config.xml
On Mon Feb 17 11:07 AM, Marcel Kinard wrote:
> Just curious, what drives your preference for XML over json?
>
It fits more naturally with some 'native' tools (e.g. android & windows 8).
IDE's have better support for it.
If you're developing only with css,js,html -> json makes more sense
If you'
On Mon Feb 17 10:41 AM, Marcel Kinard wrote:
>
> On Feb 15, 2014, at 1:34 PM, Jonathan Bond-Caron
> wrote:
>
> > So the idea here is:
> > - config.xml, config.json
> > - plugin.xml, plugin.json
> >
> > Would both be supported, with json being looked
On Fri Feb 14 02:30 PM, Marcel Kinard wrote:
>
> On Feb 13, 2014, at 10:04 AM, Jonathan Bond-Caron
> wrote:
>
> > IBM most likely would prefer XML for the XSD & tooling...
>
> Not necessarily. Schema validation is nice, but XML for the sake of XML
> doesn't
On Thu Feb 13 10:49 AM, Braden Shepherdson wrote:
>
> except for the persistent question of what we're gaining with all these
> changes.
> Like the JSON config files idea, I'd be happy if we were already in that
> world. But
> the transition is sufficiently painful that switching doesn't feel wo
On Thu Feb 13 09:37 AM, Andrew Grieve wrote:
> Jonathan - I'm a fan of your "rough work" :)
>
Thanks, lots of credit to Braden & Mark around the plugman 'project' idea
Note about xml vs. json config, Cordova could support both. Upstream
distributions could choose to focus on config as XML, json
On Wed Feb 12 10:22 PM, Andrew Grieve wrote:
> > b) More a personal preference for:
> > > version=">=3.3.0" platform="android"/>
> >
> > I can patch the code so that:
> > > name="cordova-{$supported_platform} " version=">=3.3.0" />
> >
> >
> - Agree that the first example is more intuitive.
> -
On Wed Feb 12 05:00 PM, Andrew Grieve wrote:
> So... I'd like to:
> A: Remove xmlns="http://www.w3.org/ns/widgets"; from our config.xml
> template
> B: Change xmlns:cdv="http://cordova.apache.org/ns/1.0"; -> xmlns="
> http://cordova.apache.org/ns/1.0";
> C: Revert the commit that enforces the name
On Wed Feb 12 03:56 PM, Braden Shepherdson wrote:
> Do the check the same file? I thought they were different. They might
> check the
> same path in different platforms, but that script can
> return different things. I
> would consider that a bug as well.
>
> I don't see anything to be gained from
On Tue Feb 11 11:05 AM, Braden Shepherdson wrote:
> The intention is that it allows plugins to specify that they require at least
> a certain
> version of the native code for each platform. This would be for things like
> added
> a new transport type to the bridge, as when we added binary data tr
I'm a bit confused about 'engines'
To my surprise, "cordova-plugman" actually returns node's version:
https://github.com/apache/cordova-plugman/blob/master/src/util/default-engines.js
Some questions:
- Should "cordova-plugman" be renamed to "node"?
- Are there many plugins tha
> > https://labs.mwrinfosecurity.com/blog/2013/09/24/webview-addjavascript
> > interface-remote-code-execution/
> >
> > > I don't know enough about the reasons for the different bridges to
> > > know whether this is a good idea or not.
> > >
> >
> > This is why we can't have nice things!
> >
>
> O
On Wed Jan 29 10:19 AM, Braden Shepherdson wrote:
> I use CoffeeScript all the time in my own hackery. In Cordova, though,
> big
> -1 to alternative languages. Let's keep it straight Javascript.
>
Also -1 on CoffeeScript / alternative syntax.
TypeScript though is the new version of JavaScript, E
Video call full?
Great to see some faces,
Cheers,
Jon
> -Original Message-
> From: John M. Wargo [mailto:jwarg...@gmail.com]
> Sent: January 29, 2014 12:36 PM
> To: dev@cordova.apache.org
> Subject: Re: Hangout?
>
> Me too. I dropped off because I didn't' want to eat up a slot.
>
> On 1
Great stuff :)
> -Original Message-
> From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
> Grieve
> Sent: Tuesday, January 28, 2014 12:18 PM
> To: dev
> Subject: Re: Chrome Apps via Cordova
>
> http://blog.chromium.org/2014/01/run-chrome-apps-on-mobile-using-
> apach
A bit of context, I've been digging more into adding -force or -f to forcefully
remove plugins (supported by plugman & cli)
As I was bouncing in between cli & plugman code, I felt an itch on some issues:
- In cli, options is passed as an array to the 'subcommands' which is
confusing as
On Sun Dec 8 06:13 PM, Brian LeRoux wrote:
> I like it but one small nit: we already use the term 'engine' to
> describe a
> downstream in plugins. Propose we call it 'renderer'.
>
>
Would 'runtime' be better? Renderer might be too specific. A different
'runtime' could mean same HTML5 renderin
On Wed Dec 4 11:55 PM, Hu, Ningxin wrote:
> > -Original Message-
> > From: Jonathan Bond-Caron [mailto:jbo...@gdesolutions.com]
> > Sent: Wednesday, December 04, 2013 11:47 PM
> > To: dev@cordova.apache.org
> > Subject: RE: Cordova and Crosswalk
> >
&g
On Tue Dec 3 08:40 AM, Hu, Ningxin wrote:
> Your thoughts about the integration?
> Is it possible to support Crosswalk runtime as a platform in Cordova
> upstream?
>
> [2]: https://github.com/crosswalk-project/crosswalk-cordova-android
It looks really awesome, can't wait to try it out.
I have so
On Fri Nov 15 11:29 AM, Braden Shepherdson wrote:
> I propose three things:
> 1. Punt all discussion of overhauling configuration files to the new year.
> 2. Drop my proposals above, as well as the summary Anis posted of last night's
> discussion.
> 3. Solve the immediate use-case of AppHarness wan
On Fri Nov 15 09:28 AM, Josh Soref wrote:
> Jonathan wrote:
> > You should add:
>
> I'll add it to the wiki if no one beats me to it.
>
> Please feel free to edit this page or any other. If you don't have the wiki
> edit bit,
> just send an email here with your account name and someone will give
On Thu Nov 14 06:12 PM, Josh Soref wrote:
> I've converted that into a wiki page:
> https://wiki.apache.org/cordova/ConfigurationFiles
> -
Awesome, thanks for this. You should add:
$PROJECT/platforms//www/cordova_plugins.js
- Me
On Thu Nov 14 01:44 PM, Andrew Grieve wrote:
> I'm going to attempt to summarize in point form:
>
> Goal:
> - Make available the list of installed plugins and their versions to native
> side & JS
> side.
> - Needed by App Harness to know whether an app is compatible with its
> bundled set of pl
On Thu Nov 7 11:40 AM, Braden Shepherdson wrote:
> The CLI tests are bad. I propose making them better.
>
> I propose letting the tests actually run filesystem and related calls,
> instead of
> always mocking them out. In the simplest form, that means running them on the
> real filesystem. If tha
On Wed Nov 6 01:54 AM, Darryl Pogue wrote:
> On 5 November 2013 13:37, Braden Shepherdson
> wrote:
> >
> > Why is any development here happening outside of Cordova? Most apps
> > are going to depend on Cordova APIs too deeply to get all that far
> > with the early steps in your outline.
> >
> > Br
On Mon Nov 4 11:00 AM, Josh Soref wrote:
> https://issues.apache.org/jira/browse/CB-2062
>
> > Any thoughts on adding html5 as a platform?
>
> Fil mentioned Ripple. While not endorsing it, have you tried it?
>
> Ripple is more or less what you want. It's a JavaScript shim to which you can
> depl
I submitted this ticket a while back:
https://issues.apache.org/jira/browse/CB-2062
For rapid development, I find browsers (chrome, ie10, safari, firefox) are
becoming good environments for testing applications.
The workflow I'd like to use is test on browser then deploy to a physical
device for
On Thu Oct 31 10:37 PM, Joe Bowser wrote:
>
> My main fear was that only Google devices would get KitKat WebView and that
> AOSP would get nothing, similar to how AOSP apparently doesn't have a Gallery
> or a default SMS client anymore. There are rumours that AOSP no longer has a
> dialer, but th
On Wed Oct 23 10:29 AM, Lisa Seacat DeLuca wrote:
> * Hockey teams (probably some issues with trademarks)
Love this idea :)
No trademark issue as long as there's no use of logos, printing of t-shirts
etc...:
http://tsdr.uspto.gov/#caseNumber=74109221&caseType=SERIAL_NO&searchType=statusSea
On Tue Oct 8 11:19 AM, Jacob Robbins wrote:
>
> This made me wonder, has there been discussion of integrating a full
> mobile
> browser codebase into Cordova and using that instead of the
> native webview?
> Mozilla sort of went this way with XUL where you
> could take their HTML engine
> and use
On Thu Sep 26 11:32 AM, Carlos Santana wrote:
> Branden,
>"On Android, it's really easy to load XML files from res/xml/foo.xml, so
> that's
> where we put it."
>
> Easy for who?
> I think is difficult for web developer to not find it in www/config.xml and
> start
> searching for it
>
But c
On Thu Sep 26 10:18 AM, Braden Shepherdson wrote:
> I am strongly opposed to splitting into one file per platform. We want to
> support
> tags in config.xml, which will allow platform-specific content
> within
> the single config.xml.
>
+1, a single configuration file not in the www/ folder
On Wed Sep 4 04:38 PM, Andrew Grieve wrote:
>
> You can always use --quiet if you pipe our command and have it not output.
> Am I missing something about your use-case?
>
> We have a practical problem right now in that we get a lot of bad bug reports
> where we need to tell users to re-run with -
On Tue Sep 3 01:09 PM, Brian LeRoux wrote:
> Or you could create cordova-plugin-core, cordova-plugin-chromeos, and
> cordova-plugin-phonegap repos, with a plugin.xml that have the
> dependencies
> you describe to achieve the same result.
>
> As the other guys mentoin, there's many ways to do this
On Mon Sep 2 07:34 PM, Brian LeRoux wrote:
> Here's a shot. Ideal flow tomorrow might be to generate a plugin called, lets
> say,
> "Echo" that matches something we'd find in our docs, automate add/remove
> with some sort of watch command. That way ppl are writing to the plugin spec
> from the beg
Setting up the mobile spec app was tedious since I didn't know the dependencies.
I wrote a small patch that allows to pull a plugin from a git subdirectory
e.g. cordova plugin add
https://github.com/jbondc/cordova-labs?subdir=cordova-deps-mobile-spec
https://issues.apache.org/jira/browse/CB-4715
> Is there any reason why the 'module name' isn't the plugin id (when loading
> JavaScript):
> https://github.com/apache/cordova-plugman/blob/master/src/prepare.js#L149
>
In case it helps someone, plugins can have multiple js-module declarations:
This name is appended to the
On Sun Aug 18 10:25 PM, Ian Clelland wrote:
>
> https://issues.apache.org/jira/browse/CB-4609
>
> Is this preventing any plugins from working at all, or is it just
> something about your new plugin?
It seems like two issues in 3.0 release:
1) Issue with Windows path
2) Plugin loading works
I participated at a #hackmtl event in Montreal and thought it would be a good
opportunity to try building a 'Cordova Gesture' plugin:
https://github.com/jbondc/cordova-plugin-gesture
My first time using 3.0.0 went very smoothly, the simple command line tools are
great.
Unfortunately I didn't co
I'm developing an app for iOS, Android, Windows 8, and noticed the getPicture()
api is very inconsistent on the errorCallback:
https://issues.apache.org/jira/browse/CB-4071
http://docs.phonegap.com/en/2.9.0/cordova_camera_camera.md.html#camera.getPicture
Would the api in 3.0 return a CaptureError
Jonathan Bond-Caron created CB-2062:
---
Summary: HTML5 platform
Key: CB-2062
URL: https://issues.apache.org/jira/browse/CB-2062
Project: Apache Cordova
Issue Type: New Feature
[
https://issues.apache.org/jira/browse/CB-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13532252#comment-13532252
]
Jonathan Bond-Caron commented on CB-753:
Small clarification, the purpos
[
https://issues.apache.org/jira/browse/CB-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13532247#comment-13532247
]
Jonathan Bond-Caron commented on CB-753:
Thanks, some more thoughts:
I image
[
https://issues.apache.org/jira/browse/CB-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531157#comment-13531157
]
Jonathan Bond-Caron commented on CB-753:
Agree that it would be nice for Cordov
- Are there any plans to have an 'HTML5' platform/release?
I use the Cordova 'Android JavaScript' to do testing in the browser. Chrome
and Safari work nicely since they are both based on WebKit.
What I'd like really like is to use HTML5 features like
getUserMedia() to
Ya calling invalidate() right after onDraw() is wrong.
My experience is only with ICS on JB, but invalidate() will only affect
native/java (e.g. an android rectangle EditText on top of an HTML input).
It has no impact on the HTML/CSS webkit engine.
It's actually the other way around, the webkit
On Tue Nov 6 01:41 PM, Joe Bowser wrote:
> Hey
>
> Apparently the pause and resume bug still exists, and I think it's
> caused by the pause and resume timers not being executed properly.
> I'm looking at the Private API to see what this actually does so I can
> try and write a JUnit test for thi
88 matches
Mail list logo
