Re: InAppBrowser - events
agree, all of this work when completed will be documented as to what is
non-standard which we can then take back to the w3c
On Thu, Nov 22, 2012 at 4:30 AM, Shazron shaz...@gmail.com wrote:
Great! Let's stick with one API, since we have Chrome members on the
Cordova team the choice is obvious :)
On Wed, Nov 21, 2012 at 8:06 PM, Andrew Grieve agri...@chromium.org
wrote:
Looks that way. Given how similar they are, I don't think it matters
which
one we go with (or if we come up with our own event names), but it'd be
good to follow the same pattern of having events and an API like
canGoBack(), goForward(), etc. If they ever move to standardize, then we
can follow suit.
On Wed, Nov 21, 2012 at 7:18 PM, Shazron shaz...@gmail.com wrote:
Mozilla's 'locationchange' is similar to what we have for ChildBrowser,
but
I don't see the equivalent in the Chrome example - I suppose it is
'loadstop'?
I suppose if we were to adopt either, it would go something like this:
var iab = window.open('http://apache.org', '_blank');
// Firefox
iab.addEventListener('locationchange', handleLocationChange);
// Chrome
iab.addEventListener('loadstop', handleLoadStop);
// Firefox
function handleLocationChange(e) {
console.log('location changed to: ' + e.detail);
}
// Chrome
function handleLoadStop(e) {
console.log('location changed to: ' + e.url);
}
On Wed, Nov 21, 2012 at 1:32 PM, Andrew Grieve agri...@chromium.org
wrote:
https://github.com/GoogleChrome/chrome-app-samples/blob/master/browser/browser.js
Re: incubator repos no more - remove the prefix in your git urls
\o/ On Thu, Nov 22, 2012 at 7:27 AM, Jukka Zitting jukka.zitt...@gmail.comwrote: Hi, On Thu, Nov 22, 2012 at 3:26 AM, Shazron shaz...@gmail.com wrote: Also, I don't have edit privlieges on the new repos :/ The cordova group in Apache LDAP was not yet up to speed. Should be fixed now (see below, done with my PMC chair powers from the Incubator). BR, Jukka Zitting jukka@minotaur:~$ modify_committee.pl cordova --add abub,agrieve,anis,becka11y,braden,goya,brianleroux,bcurtis,doc,dkormalev,deedubbu,filmaj,gtanner,hermwong,tranter,purplecabbage,bowserj,jukka,jtyberg,longwei,mwbrooks,mmocny,pmuellr,wildabeast,sgrebnov,shazron,macdonst,steven,timkim,viras,yohei Password for 'jukka' (^D aborts): jukka@minotaur:~$ list_committee.pl cordova abub agrieve anis bcurtis becka11y bowserj braden brianleroux deedubbu dkormalev doc filmaj goya gtanner hermwong jtyberg jukka longwei macdonst mmocny mwbrooks pmuellr purplecabbage sgrebnov shazron steven timkim tranter viras wildabeast yohei jukka@minotaur:~$ modify_unix_group.pl cordova --add abub,agrieve,anis,becka11y,braden,goya,brianleroux,bcurtis,doc,dkormalev,deedubbu,filmaj,gtanner,hermwong,tranter,purplecabbage,bowserj,jukka,jtyberg,longwei,mwbrooks,mmocny,pmuellr,wildabeast,sgrebnov,shazron,macdonst,steven,timkim,viras,yohei Password for 'jukka' (^D aborts): jukka@minotaur:~$ list_unix_group.pl cordova abub agrieve anis bcurtis becka11y bowserj braden brianleroux deedubbu dkormalev doc filmaj goya gtanner hermwong jtyberg jukka longwei macdonst mmocny mwbrooks pmuellr purplecabbage sgrebnov shazron steven timkim tranter viras wildabeast yohei
Re: Type checking in Cordova JS plugins
ya upon further consideration making these TypeException's feels right since, ideally, this error would only be seen by a plugin author and not something a plugin consumer (ideally) On Wed, Nov 21, 2012 at 8:53 PM, Michal Mocny mmo...@chromium.org wrote: On Wed, Nov 21, 2012 at 3:51 PM, Andrew Grieve agri...@chromium.org wrote: Getting back to this - By coercing values, I mean if we're expecting a number, and they pass in the string 3, then we have our helper method change it to a number instead of throwing an exception. This would more closely match what browser APIs do, but is maybe not worth the extra complexity. FWIW I hate API's that do this. I feel it is always correct to teach the user that they are making a mistake. Okay, I'm going to go with throwing a TypeException, because I think it is useful to make a distinction between a failed operation, and passing invalid args. E.g. People's error callbacks will be easier to write if they don't need to check the error code to see if they just messed up the call. I'm going to get a start on this tomorrow, but will restrict the refactoring to just a few plugins at first so that I'm not changing too much before a release cut. On Fri, Nov 16, 2012 at 4:13 AM, Brian LeRoux b...@brian.io wrote: 1. I like the proposal Andrew. We need type checking for sure and making it optional for debugging even better. The light touch you have shown seems good enough for now. I'd rather we did not augment natives...and not so sure what you mean around coercing. 2. Success/error callbacks should be optional, says I. 3. When type errors happen, log return, call errBack, or throw TypeError? I am very unsure about this one. Essentially this args checking is more for our bridge than it is for user space so browser api symmetry less important to me than doing right by the plugin author. It would seem this would indicate an log and error callback. But again, not entirely certain that will yield the most expected behavior. At least w/ throwing a TypeError we fail noisily. =/ On Fri, Nov 16, 2012 at 8:23 AM, Jesse MacFadyen purplecabb...@gmail.com wrote: My answers/opinion 1. Up to the plugin developer 2. Up to the plugin developer 3. Up to the plugin developer However, that does not mean that we can't make the existing APIs handle params a little more consistently. Also, we could expose typeChecking helper methods, although they are pretty easy to come by. Array.isArray() could be polyfil'd or could be cordova.isArray() ... Cheers, Jesse Sent from my iPhone5 On 2012-11-15, at 12:16 PM, Andrew Grieve agri...@google.com wrote: There's very little consistency when it comes to checking params in plugin code. globalization.js https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=blob;f=lib/common/plugin/globalization.js;h=a57062ce8b1e0cc95dde54f8ca600f6ee4876bfd;hb=HEAD : checks every args. logs errors and returns without calling errback, does not allow missing errCB. resolveLocalFileSystemURI.js https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=blob;f=lib/common/plugin/resolveLocalFileSystemURI.js;h=c83b0aac3704c46782c3e19876afb180c32fc081;hb=HEAD : Allows missing successCB and errCB. Sanity checks URL has a colon in it. notification.js https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=blob;f=lib/common/plugin/notification.js;h=fbf9046a0e03bb6647219d7201b23f26f4d47084;hb=HEAD : doesn't check types at all contacts.js https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=blob;f=lib/common/plugin/contacts.js;h=2f5a51a20c8ad14b96c4ef935a28686a9bd87eca;hb=HEAD : Throws TypeError if missing successCB, allows missing errCB compass.js https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=blob;f=lib/common/plugin/compass.js;h=c97c1588bf69d2c94cde64736345a7d8b1dc32fe;hb=HEAD : Logs and returns if callbacks are of wrong type. success required, error optional. So, the things to agree upon are: 1. Should we check types or not? 2. Success / error callbacks : optional or not? 3. When type errors happen, log return, call errBack, or throw TypeError? For some extra inspiration, I played around with what it would look like to at least factor out type checking code. Have a look at the module https://github.com/agrieve/incubator-cordova-js/blob/argscheck/lib/common/argscheck.js and it's tests https://github.com/agrieve/incubator-cordova-js/blob/argscheck/test/test.argscheck.js . Also, here's https://github.com/agrieve/incubator-cordova-js/blob/argscheck/lib/common/plugin/globalization.js what it looks like being used in
Re: Type checking in Cordova JS plugins
On Thu, Nov 22, 2012 at 6:00 AM, Brian LeRoux b...@brian.io wrote: ya upon further consideration making these TypeException's feels right since, ideally, this error would only be seen by a plugin author and not something a plugin consumer (ideally) huh? I thought this was all about informing users when they pass invalid arguments? I'm usually in favor of fail fast - and so throwing an exception when you pass an invalid argument sounds right to me. The problem is that even though it's simple for us to fail fast by throwing an exception, we also need to make sure it's super obvious to the user that a failure has occurred. That's the hard part. Too many places where errors are silently consumed by the runtime. I think a console.log() would be appropriate - along with a thrown exception - lots of folks have access to a console these days. Or maybe we should come up with a new API - reportFailure() or something, which we could have - by default - just log to the console. For platforms that don't have an easily accessible console, they can override this to do something visible for their platform. -- Patrick Mueller http://muellerware.org
RE: [jira] [Updated] (CB-1905) Update JavaScript for webOS
Michael and Herm, I just created a pull request to fix network type codes and to add network online/offline support plus window pause/resume support to cordova-js webOS: https://github.com/apache/incubator-cordova-js/pull/45 Herm: do you want to test? Should we add this to 2.2.3? Markus -Original Message- From: Michael Brooks (JIRA) [mailto:j...@apache.org] Sent: Mittwoch, 21. November 2012 22:22 To: Leutwyler, Markus Subject: [jira] [Updated] (CB-1905) Update JavaScript for webOS [ https://issues.apache.org/jira/browse/CB-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brooks updated CB-1905: --- Affects Version/s: (was: 2.2.0) 2.3.0 Fix Version/s: (was: 2.2.0) 2.3.0 Summary: Update JavaScript for webOS (was: CLONE - CLONE - Update JavaScript for webOS) Update JavaScript for webOS --- Key: CB-1905 URL: https://issues.apache.org/jira/browse/CB-1905 Project: Apache Cordova Issue Type: Sub-task Components: webOS Affects Versions: 2.3.0 Reporter: Michael Brooks Assignee: Markus Leutwyler Fix For: 2.3.0 Update the cordova.js after Cordova-JS has been tagged. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: CB-1889 changes
nvm i just pushed it :) cyu guys Monday On Wed, Nov 21, 2012 at 5:33 PM, Shazron shaz...@gmail.com wrote: Off for the next two days for Thanksgiving weekend. Don't have edit access to the new repos, so I pushed to a branch in mine if an iOS dev wants to integrate: https://github.com/shazron/incubator-cordova-ios/commit/ecbc928368a9dc3eb2a3094f4269451cdfde7159 https://github.com/shazron/incubator-cordova-ios/tree/CB-1889
Re: Type checking in Cordova JS plugins
In the original thread the rational was that things were inconsistent, but the examples were disparate. notification.alert(108); // This is valid and should not fail, and a callback function (win or lose) is not required. resolveLocalFileSystemURI.js // actually, it checks that there are not multiple colons, I wrote this to resolve a specific issue and fixed it in js to patch all platforms at once Backing up to the original questions ; 1. Should we check types or not? - sometimes yes, sometimes no, depends on the case, but this is difficult to achieve generically as a framework and should be left to the plugin developer. 2. Success / error callbacks : optional or not? - optional! Sometimes callback need to be optional, like console.log 3. When type errors happen, log return, call errBack, or throw TypeError? - I think we should always log errors, and provide as much info as possible, however this can only really be done by leading by example. - generally, I think we should be calling the provided error callback if available, so that developers do not have to use both try/catch + callback. Andrew, your type checking code is certainly interesting, however I don't think it belongs in the cordova-js framework. Maybe this should be a standalone tool, in it's own repo ... are you still pushing to add this? Cheers, Jesse Sent from my iPhone, forgive fat fingers. On 2012-11-22, at 6:55 AM, Andrew Grieve agri...@chromium.org wrote: Good point Patrick. I'll go with a console.log + exception. On Thu, Nov 22, 2012 at 9:01 AM, Patrick Mueller pmue...@gmail.com wrote: On Thu, Nov 22, 2012 at 6:00 AM, Brian LeRoux b...@brian.io wrote: ya upon further consideration making these TypeException's feels right since, ideally, this error would only be seen by a plugin author and not something a plugin consumer (ideally) huh? I thought this was all about informing users when they pass invalid arguments? I'm usually in favor of fail fast - and so throwing an exception when you pass an invalid argument sounds right to me. The problem is that even though it's simple for us to fail fast by throwing an exception, we also need to make sure it's super obvious to the user that a failure has occurred. That's the hard part. Too many places where errors are silently consumed by the runtime. I think a console.log() would be appropriate - along with a thrown exception - lots of folks have access to a console these days. Or maybe we should come up with a new API - reportFailure() or something, which we could have - by default - just log to the console. For platforms that don't have an easily accessible console, they can override this to do something visible for their platform. -- Patrick Mueller http://muellerware.org
Re: Type checking in Cordova JS plugins
On Thu, Nov 22, 2012 at 11:40 AM, Jesse MacFadyen purplecabb...@gmail.comwrote: In the original thread the rational was that things were inconsistent, but the examples were disparate. notification.alert(108); // This is valid and should not fail, and a callback function (win or lose) is not required. resolveLocalFileSystemURI.js // actually, it checks that there are not multiple colons, I wrote this to resolve a specific issue and fixed it in js to patch all platforms at once Backing up to the original questions ; 1. Should we check types or not? - sometimes yes, sometimes no, depends on the case, but this is difficult to achieve generically as a framework and should be left to the plugin developer. 2. Success / error callbacks : optional or not? - optional! Sometimes callback need to be optional, like console.log 3. When type errors happen, log return, call errBack, or throw TypeError? - I think we should always log errors, and provide as much info as possible, however this can only really be done by leading by example. - generally, I think we should be calling the provided error callback if available, so that developers do not have to use both try/catch + callback. The idea here is that type errors should not happen, so there's no need for devs to add try/catches. e.g., you don't add a try/catch around calls to browser APIs that guard against you passing in the wrong parameter types. I think of this more like an assertion. The example of the colons is one that my refactoring will not address. I'm going to stick strictly to checking types so that there won't be much code. Andrew, your type checking code is certainly interesting, however I don't think it belongs in the cordova-js framework. Maybe this should be a standalone tool, in it's own repo ... are you still pushing to add this? Yes. Still would like to add this. My motivation here is not to add something new, but rather to delete lines of code within our core plugins. I don't think it makes sense to have it in a separate repo, or else we'll have cordova-js depending on this other repo. Cheers, Jesse Sent from my iPhone, forgive fat fingers. On 2012-11-22, at 6:55 AM, Andrew Grieve agri...@chromium.org wrote: Good point Patrick. I'll go with a console.log + exception. On Thu, Nov 22, 2012 at 9:01 AM, Patrick Mueller pmue...@gmail.com wrote: On Thu, Nov 22, 2012 at 6:00 AM, Brian LeRoux b...@brian.io wrote: ya upon further consideration making these TypeException's feels right since, ideally, this error would only be seen by a plugin author and not something a plugin consumer (ideally) huh? I thought this was all about informing users when they pass invalid arguments? I'm usually in favor of fail fast - and so throwing an exception when you pass an invalid argument sounds right to me. The problem is that even though it's simple for us to fail fast by throwing an exception, we also need to make sure it's super obvious to the user that a failure has occurred. That's the hard part. Too many places where errors are silently consumed by the runtime. I think a console.log() would be appropriate - along with a thrown exception - lots of folks have access to a console these days. Or maybe we should come up with a new API - reportFailure() or something, which we could have - by default - just log to the console. For platforms that don't have an easily accessible console, they can override this to do something visible for their platform. -- Patrick Mueller http://muellerware.org
[jira] [Created] (CB-1931) Contact.find() docs don't match implementation for zero-length array
Andrew Grieve created CB-1931:
-
Summary: Contact.find() docs don't match implementation for
zero-length array
Key: CB-1931
URL: https://issues.apache.org/jira/browse/CB-1931
Project: Apache Cordova
Issue Type: Bug
Components: CordovaJS, Docs
Reporter: Andrew Grieve
Assignee: Filip Maj
Priority: Minor
The docs say:
http://docs.phonegap.com/en/2.2.0/cordova_contacts_contacts.md.html#contacts.find
A zero-length contactFields parameter will result in an array of Contact
objects with only the id property populated.
The code says (in contacts.js):
if (!fields || (utils.isArray(fields) fields.length === 0)) {
errorCB errorCB(new ContactError(ContactError.INVALID_ARGUMENT_ERROR));
}
I peeked at the iOS Contacts impl, and I don't think it looks for the case of
an empty array.
Maybe simplest thing is to just make the docs say that an empty array is
invalid?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: InAppBrowser api questions
Why do we have the Forward and Back buttons on the browser on Android
when Chrome and the Default Browser only have a refresh button? How
does this handle the hardware back button? I think we should do what
the platform does, except that we don't need multi-tab browsing.
On Thu, Nov 22, 2012 at 11:47 AM, Simon MacDonald
simon.macdon...@gmail.com wrote:
Should the implementation of the InAppBrowser on Android mimic the UI of
the iOS app or should it go it's own way?
Currently the Android ChildBrowser has the buttons and location bar on the
top of the screen. Is there any UI pattern we should be following for this
type of in app browsing?
Simon Mac Donald
http://hi.im/simonmacdonald
On Mon, Nov 19, 2012 at 6:24 PM, Shazron shaz...@gmail.com wrote:
I have a pull request for the JavaScript changes, can someone please
review: https://github.com/apache/incubator-cordova-js/pull/43
I have committed my InAppBrowser changes to iOS:
https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-ios.git;a=commit;h=26a6535c
To test this on iOS right now:
cordova.exec(null, null, InAppBrowser, open, [http://google.com;,
_blank, location=yes]);
(don't forget to add InAppBrowser/CDVInAppBrowser to your Cordova.plist).
Note that non-whitelisted URLs cannot be opened in the InAppBrowser yet
because of http://issues.cordova.io/1695 which I am doing next.
Once the js changes are in (at least on ios), you can do:
var mywin = window.open(http://www.google.com;, _blank,
location=no);
mywin.close();
On Thu, Nov 15, 2012 at 3:58 PM, Shazron shaz...@gmail.com wrote:
I updated the spec: http://wiki.apache.org/cordova/InAppBrowser
However, I added the _blank option as well just to be explicit.
On Thu, Nov 15, 2012 at 1:58 AM, Shazron shaz...@gmail.com wrote:
I spent some time playing with how to do this.
1 - Use referer header - Too many situations result in no header, so
this
is out!
2 - Use Cookies - if there were a way to have UIWebViews use separate
cookie jars, this might be feasible. Don't think that's possible.
3 - Use User-Agent - this is already suggested in CB-1695. I also found
this:
http://stackoverflow.com/questions/12180224/unique-tab-id-appended-to-user-agent-string-in-chrome-for-ios
,
which suggests that this is what Chrome for iOS uses to implement
incognito
mode. If they can make it work, then we should be able to as well!
So, this is looking like it's non-trivial but not impossible! As long
as
it's possible, let's implement it :)
Looks like it may be possible in CB-1695 as you mentioned -- so we can
finish InAppBrowser with this one failing case until it is implemented.
I
can look into this further once I finish the InAppBrowser integration.
I don't think the semantics of _parent and _blank really map well to
what
we're doing. My vote is to create a new special value: _system, and
only
this target kicks you out to the system browser.
Also: on the wiki we have:
[F] window.open('http://random-url.com', '_blank'); // native browser
It seems weird to me that the effect of _blank changes based on whether
the
URL is in the whitelist. I'd think this case would also open in the
InAppBrowser.
Summary of what I think:
_self or no target -- open in cordova webview if it's in the
Whitelist,
InAppBrowser otherwise
_system -- open in system browser
anything else -- open in InAppBrowser
Also, I like Simon's idea of using the options in window.open to
specify
whether to show URL bar etc. :)
I agree, we need a new value _system as you suggested, as well as the
other parts of the summary of your changes -- makes more sense, and if
used
in another context -- it will just work as expected. I can make the wiki
changes unless others have more comments.
We can definitely add the window options as well, for sure!
Re: Attempting to add debug token support for building on PlayBook
wow, so yeah that works.
not the best way to do it now ;)
I should be able to automate this in the playbook.xml so our users don't
have to deal with it.
On Thu, Nov 22, 2012 at 2:46 PM, Filip Maj f...@adobe.com wrote:
O HELL YEAH I HAVE. Let me, an Adobe employee, give you, a RIM employee,
the awesome run down of how to fix this. This is gonna be fun and I get to
vent a bit too! :D
1. Locate your debug token.
2. Extract the .bar of the debug token with an archive app
3. There will be a META-INF folder
4. Open up META-INF/MANIFEST.MF
5. In there you will see Package-Author and Package-Author-ID. Note down
those values.
6. Locate your playbook sdk install dir
7. Go to sdk/bbwp/AirAppTemplates/src
8. Edit blackberry-tablet.xml
9. Make sure blackberry-tablet.xml has the following XML elements that
match the values in your MANIFEST.MF file of your debug token:
- publisher should match Package-Author
- author should match Package-Author
- authorId should match Package-Author-Id
10. You may have to add some of these elements if they are missing. Yeah.
Try figuring that out.
I highly recommend RIM fix this as this process is FKN HORSESHIT.
That is all. I'm done :)
On 11/22/12 11:37 AM, Gord Tanner gtan...@gmail.com wrote:
I added debug token support to working on BB10 for cordova and would like
to do the same with playbook but I have the following problem:
Output of cordova build script when running 'ant playbook debug-device'
[exec] Info: Debug token created.
[exec] Info: Sending request: Install and Launch
[exec] Info: Action: Install and Launch
[exec] Info: File size: 2269
[exec] Info: Installing debug.token.gYABgBzNRmtRA7cXnit_yEsmdx4...
[exec] Info: Processing 2269 bytes
[exec] actual_dname::debug.token.gYABgBzNRmtRA7cXnit_yEsmdx4
[exec] actual_id::gYABgBzNRmtRA7cXnit_yEsmdx4
[exec] actual_version::0.0.0.48
[exec] result::success
[exec] Info: Launching debug.token.gYABgBzNRmtRA7cXnit_yEsmdx4...
[exec] result::Invalid
[exec] Info: done
[exec] [INFO] Parsing command line options
[exec] [INFO] Parsing bbwp.properties
[exec] [INFO] Validating WebWorks archive
[exec] [INFO] Parsing config.xml
[exec] [INFO] Populating application source
[exec] [INFO] Compiling WebWorks application
[exec] [INFO] Packaging the bar file
[exec] [INFO] Bar packaging complete
[exec] [INFO] WebWorks application packaging complete
[exec] Info: Sending request: Install and Launch
[exec] Info: Action: Install and Launch
[exec] Info: File size: 510530
[exec] Info: Installing
cordovaExample66daa65d5ab3c8ba4e3a9403c3a28a7.testDev_9403c3a28a75887c750.
..
[exec] Info: Processing 510530 bytes
[exec] actual_dname::
[exec] actual_id::
[exec] actual_version::
[exec] result::failure 881 application author does not match debug
token author
The value in my config.xml author tag is Gord Tanner, which is the same
displayed for the debug token author shown on the playbook.
The ant script I am using is:
!-- install debug token --
+macrodef name=generate-debug-token
+sequential
+exec executable=${blackberry-debugtokenrequest} dir=.
failonerror=true
+arg value=-storepass /
+arg value=${properties.playbook.sigtool.csk.password}
/
+arg value=-deviceID /
+arg value=0x${properties.qnx.device.pin} /
+arg file=${properties.qnx.bbwp.dir}/debugtoken.bar /
+/exec
+
+exec executable=${blackberry-deploy} dir=.
failonerror=true
+arg value=-installApp /
+arg value=-launchApp /
+arg value=-device /
+arg value=${properties.playbook.device.ip} /
+arg value=-password /
+arg value=${properties.playbook.device.password} /
+arg value=-package /
+arg file=${properties.qnx.bbwp.dir}/debugtoken.bar /
+/exec
+/sequential
+/macrodef
Has anyone come across this before?
Re: Fast edit-refresh cycles
I think all the refresh stuff is super cool, I will share how I work, so you can get another perspective. 90% of my code is written on localhost, either running directly in a browser to work out UI stuff. When I need access to actual device APIs, I simply put a redirect in my index.html. This gets me through 99% of my work, after which I can fine tune an individual device or functional piece in XCode, Eclipse, Visual Studio, et al When it comes to inclusion of multiple script tags, I do not see this as a barrier at all. This is the way the internet has always worked, and it ain't broke. I like the explicit declaration of having a script tag, plus you can have multiple pages, with different plugin requirements. Adding an extra build step, + reinventing the internet inside our framework is madness in my opinion. This of course does not preclude use of this technique, however, I feel very strongly that we should NOT be building this into our framework, and forcing developers to use this approach. I think this is definitely something that we should vote on before developing further if the goal is inclusion in cordova. Cheers, Jesse On Thu, Nov 22, 2012 at 2:34 AM, Brian LeRoux b...@brian.io wrote: super interesting. I like where this is going. On Thu, Nov 22, 2012 at 3:42 AM, Andrew Grieve agri...@chromium.org wrote: On Wed, Nov 21, 2012 at 6:37 PM, Filip Maj f...@adobe.com wrote: Dude: awesome! My answers in-line: 2. Manually adding the script tags to include every new plugin is really lame. I propose a unified file, plugins.js or similar, that's always included in the index.html. Every time you add or remove a plugin, the Javascript files for all the plugins are concatenated into this file. There are likely some problems with this approach. Inserting/removing the script tags from the index page is also an option, though it requires more clever scripts. Can you elaborate more on this? I don't understand. Here's the motivating example to explain this: - Our goal for 3.0 is to have cordova be just the bridge, and to have all core plugins in separate repos - Right now, when you pluginstall a plugin, you need to manually edit your .html to add the .js of the plugin in a script tag. - This will be quite annoying to have to add ~10 script tags, (one for each core plugin, plus one for each non-core plugin you have) Here's Braden's idea explained a bit more: - Have a plugin.js file in addition to the cordova.js file - cordova.js to have the platform's bridge init code - plugins.js to contain the concatenation of all plugin .js files - plugins.js to be regenerated whenever a plugin is added / removed - Apps will need to add both .js files to their html, but not need to add a script for every plugin separately. 3. Setting the start page manually on every platform sucks. I think this should be a value in config.xml that gets set on cordova build. Obviously that requires 1. to be fixed, but we'll get there soon. Yes, there is config.xml prior art for this: http://www.w3.org/TR/widgets/#the-content-element-and-its-attributes We should file issues to add support for this. Thanks for forking + contributing to cordova-client, stoked to see more contributors in there! Related: once we migrate to our new git repos we should get a new one set up for cordova-client. -- @purplecabbage risingj.com
Re: Fast edit-refresh cycles
Agree with Jesse. Automatically adding the plugin's .js to html pages inside a www dir can be done by the cordova-client tool anyways. Agree this should go to vote before we proceed. On 11/22/12 12:13 PM, Jesse purplecabb...@gmail.com wrote: I think all the refresh stuff is super cool, I will share how I work, so you can get another perspective. 90% of my code is written on localhost, either running directly in a browser to work out UI stuff. When I need access to actual device APIs, I simply put a redirect in my index.html. This gets me through 99% of my work, after which I can fine tune an individual device or functional piece in XCode, Eclipse, Visual Studio, et al When it comes to inclusion of multiple script tags, I do not see this as a barrier at all. This is the way the internet has always worked, and it ain't broke. I like the explicit declaration of having a script tag, plus you can have multiple pages, with different plugin requirements. Adding an extra build step, + reinventing the internet inside our framework is madness in my opinion. This of course does not preclude use of this technique, however, I feel very strongly that we should NOT be building this into our framework, and forcing developers to use this approach. I think this is definitely something that we should vote on before developing further if the goal is inclusion in cordova. Cheers, Jesse On Thu, Nov 22, 2012 at 2:34 AM, Brian LeRoux b...@brian.io wrote: super interesting. I like where this is going. On Thu, Nov 22, 2012 at 3:42 AM, Andrew Grieve agri...@chromium.org wrote: On Wed, Nov 21, 2012 at 6:37 PM, Filip Maj f...@adobe.com wrote: Dude: awesome! My answers in-line: 2. Manually adding the script tags to include every new plugin is really lame. I propose a unified file, plugins.js or similar, that's always included in the index.html. Every time you add or remove a plugin, the Javascript files for all the plugins are concatenated into this file. There are likely some problems with this approach. Inserting/removing the script tags from the index page is also an option, though it requires more clever scripts. Can you elaborate more on this? I don't understand. Here's the motivating example to explain this: - Our goal for 3.0 is to have cordova be just the bridge, and to have all core plugins in separate repos - Right now, when you pluginstall a plugin, you need to manually edit your .html to add the .js of the plugin in a script tag. - This will be quite annoying to have to add ~10 script tags, (one for each core plugin, plus one for each non-core plugin you have) Here's Braden's idea explained a bit more: - Have a plugin.js file in addition to the cordova.js file - cordova.js to have the platform's bridge init code - plugins.js to contain the concatenation of all plugin .js files - plugins.js to be regenerated whenever a plugin is added / removed - Apps will need to add both .js files to their html, but not need to add a script for every plugin separately. 3. Setting the start page manually on every platform sucks. I think this should be a value in config.xml that gets set on cordova build. Obviously that requires 1. to be fixed, but we'll get there soon. Yes, there is config.xml prior art for this: http://www.w3.org/TR/widgets/#the-content-element-and-its-attributes We should file issues to add support for this. Thanks for forking + contributing to cordova-client, stoked to see more contributors in there! Related: once we migrate to our new git repos we should get a new one set up for cordova-client. -- @purplecabbage risingj.com
Re: Fast edit-refresh cycles
This also is feeding into some of the work we are doing with ripple. Ripple will serve up the app and host it kind of like how we do debug.phonegap.com for in browser testing. Sent from my iPhone On 2012-11-22, at 3:15 PM, Filip Maj f...@adobe.com wrote: Agree with Jesse. Automatically adding the plugin's .js to html pages inside a www dir can be done by the cordova-client tool anyways. Agree this should go to vote before we proceed. On 11/22/12 12:13 PM, Jesse purplecabb...@gmail.com wrote: I think all the refresh stuff is super cool, I will share how I work, so you can get another perspective. 90% of my code is written on localhost, either running directly in a browser to work out UI stuff. When I need access to actual device APIs, I simply put a redirect in my index.html. This gets me through 99% of my work, after which I can fine tune an individual device or functional piece in XCode, Eclipse, Visual Studio, et al When it comes to inclusion of multiple script tags, I do not see this as a barrier at all. This is the way the internet has always worked, and it ain't broke. I like the explicit declaration of having a script tag, plus you can have multiple pages, with different plugin requirements. Adding an extra build step, + reinventing the internet inside our framework is madness in my opinion. This of course does not preclude use of this technique, however, I feel very strongly that we should NOT be building this into our framework, and forcing developers to use this approach. I think this is definitely something that we should vote on before developing further if the goal is inclusion in cordova. Cheers, Jesse On Thu, Nov 22, 2012 at 2:34 AM, Brian LeRoux b...@brian.io wrote: super interesting. I like where this is going. On Thu, Nov 22, 2012 at 3:42 AM, Andrew Grieve agri...@chromium.org wrote: On Wed, Nov 21, 2012 at 6:37 PM, Filip Maj f...@adobe.com wrote: Dude: awesome! My answers in-line: 2. Manually adding the script tags to include every new plugin is really lame. I propose a unified file, plugins.js or similar, that's always included in the index.html. Every time you add or remove a plugin, the Javascript files for all the plugins are concatenated into this file. There are likely some problems with this approach. Inserting/removing the script tags from the index page is also an option, though it requires more clever scripts. Can you elaborate more on this? I don't understand. Here's the motivating example to explain this: - Our goal for 3.0 is to have cordova be just the bridge, and to have all core plugins in separate repos - Right now, when you pluginstall a plugin, you need to manually edit your .html to add the .js of the plugin in a script tag. - This will be quite annoying to have to add ~10 script tags, (one for each core plugin, plus one for each non-core plugin you have) Here's Braden's idea explained a bit more: - Have a plugin.js file in addition to the cordova.js file - cordova.js to have the platform's bridge init code - plugins.js to contain the concatenation of all plugin .js files - plugins.js to be regenerated whenever a plugin is added / removed - Apps will need to add both .js files to their html, but not need to add a script for every plugin separately. 3. Setting the start page manually on every platform sucks. I think this should be a value in config.xml that gets set on cordova build. Obviously that requires 1. to be fixed, but we'll get there soon. Yes, there is config.xml prior art for this: http://www.w3.org/TR/widgets/#the-content-element-and-its-attributes We should file issues to add support for this. Thanks for forking + contributing to cordova-client, stoked to see more contributors in there! Related: once we migrate to our new git repos we should get a new one set up for cordova-client. -- @purplecabbage risingj.com
RE: incubator repos no more - remove the prefix in your git urls
Simon wrote: Do we need to fix the mirrors at: https://github.com/apache I'm waiting for this :) Can we make sure pull requests to the new repo's on GitHub end up in our mailing list? I was hoping you'd have split the pull-list and jira-list out of the discuss-list :) - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
RE: Attempting to add debug token support for building on PlayBook
Gord wrote: not the best way to do it now ;) I should be able to automate this in the playbook.xml so our users don't have to deal with it. The way I'm told is to just remove those items from the PlayBook.xml file entirely and just rely on the packager/debugtoken to magically set them or somehow make it work. (this was advice I got from non-RIM people, to me,...) - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Type checking in Cordova JS plugins
I just checked in argscheck.js and refactored all applicable lower-case plugin/*.js files to use it. It trims 4k off of cordova.ios.js and git tells me: 245 insertions(+), 323 deletions(-) I also found that a couple of our tests were passing invalid arg types :P On Thu, Nov 22, 2012 at 3:48 PM, Andrew Grieve agri...@chromium.org wrote: There's a good amount of code that currently check types on the public API. My goal here is to shrink that code because it seems repetitive. Checking the types passed to exec may be useful in some cases too, but we don't currently do that. Probably, if we wanted to add this in, we'd want something more sophisticated that actually checked JSON schemas instead of just checking for typeof 'object'. On Thu, Nov 22, 2012 at 1:19 PM, Brian LeRoux b...@brian.io wrote: Ok, hold up, I'm missing something---I thought this was for the *bridge protocol validation* not the actual API surface end developers invoke. Ideally the public API would define their own exceptional paths. (Har har.) Example: geolocation api has error callbacks whereas File API has FileError (or some such / on bad connection and just blasting this w/o checking). On Thu, Nov 22, 2012 at 2:01 PM, Patrick Mueller pmue...@gmail.com wrote: On Thu, Nov 22, 2012 at 6:00 AM, Brian LeRoux b...@brian.io wrote: ya upon further consideration making these TypeException's feels right since, ideally, this error would only be seen by a plugin author and not something a plugin consumer (ideally) huh? I thought this was all about informing users when they pass invalid arguments? I'm usually in favor of fail fast - and so throwing an exception when you pass an invalid argument sounds right to me. The problem is that even though it's simple for us to fail fast by throwing an exception, we also need to make sure it's super obvious to the user that a failure has occurred. That's the hard part. Too many places where errors are silently consumed by the runtime. I think a console.log() would be appropriate - along with a thrown exception - lots of folks have access to a console these days. Or maybe we should come up with a new API - reportFailure() or something, which we could have - by default - just log to the console. For platforms that don't have an easily accessible console, they can override this to do something visible for their platform. -- Patrick Mueller http://muellerware.org
[jira] [Commented] (CB-1892) Refactor type-checking code in plugins into a helper method
[
https://issues.apache.org/jira/browse/CB-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13502929#comment-13502929
]
Andrew Grieve commented on CB-1892:
---
argscheck module:
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=1dfa2ac54a41287279e6726d2b748060e1cc44bf
Lower-case .js plugin files:
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=9ba65d4f42cddf0cdc1c1f1b624df201bde0ca18
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=f400233bef00da6d3678d95e4abf745a1f62e07f
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=58990dad50f337fd8c71250398d6586ae2b055ac
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=f81be6623d3429f442a0e214adfe3f66fff32b1f
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=4864283bcc17d37d7d28d85ffed9dc41dd3931f9
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=1fe276bcb9b36ced8be236c40886a6c0dc0a1076
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=ee4a70cce10fadd7a7563eb2941f231c9841d009
So far, 4kb off of cordova.ios.js (from 192 to 188kb)
245 insertions(+), 323 deletions(-)
This is now mostly done, but need to check if it would make sense for any of
the CamelCase.js files to use it.
Refactor type-checking code in plugins into a helper method
---
Key: CB-1892
URL: https://issues.apache.org/jira/browse/CB-1892
Project: Apache Cordova
Issue Type: Improvement
Components: CordovaJS
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
Fix For: 2.3.0
ML Discussion: http://callback.markmail.org/thread/4vgze66wlaaxthsd
The idea is to add a typecheck module along the lines of:
argscheck.checkArgs('noasdf', 'testFunc', arguments);
where n=number, o=object, a=array, s=string, d=date, f=function, *=anything
Side-effects of this change will include:
1. All core plugins will have their callbacks be optional
2. Incorrect types will result in an exception thrown
3. Should reduce the size of cordova.js through removing repetitive code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Fast edit-refresh cycles
On Thu, Nov 22, 2012 at 3:36 PM, Gord Tanner gtan...@gmail.com wrote: This also is feeding into some of the work we are doing with ripple. Ripple will serve up the app and host it kind of like how we do debug.phonegap.com for in browser testing. Sent from my iPhone On 2012-11-22, at 3:15 PM, Filip Maj f...@adobe.com wrote: Agree with Jesse. Automatically adding the plugin's .js to html pages inside a www dir can be done by the cordova-client tool anyways. Agree this should go to vote before we proceed. On 11/22/12 12:13 PM, Jesse purplecabb...@gmail.com wrote: I think all the refresh stuff is super cool, I will share how I work, so you can get another perspective. 90% of my code is written on localhost, either running directly in a browser to work out UI stuff. When I need access to actual device APIs, I simply put a redirect in my index.html. This gets me through 99% of my work, after which I can fine tune an individual device or functional piece in XCode, Eclipse, Visual Studio, et al Awesome! This is the workflow we want to encourage via cordova serve. When it comes to inclusion of multiple script tags, I do not see this as a barrier at all. This is the way the internet has always worked, and it ain't broke. I like the explicit declaration of having a script tag, plus you can have multiple pages, with different plugin requirements. Adding an extra build step, + reinventing the internet inside our framework is madness in my opinion. madness is maybe a bit of an exaggeration :) Our cordova plugin add tool already adds the necessary plugin line to your config.xml / cordova.plist *and* edits your xcode project file to add the native files. Why have the tool take care of these manual steps on the native side, but not the HTML side? It's a pain to have to make manual edits to your .html file every time you add or remove a plugin. I see this more as removing a step rather than adding a step. I'm not set on having a single plugins-concat.js file, but it *is* what we already do for our cordova.js file (we don't list each source file separately in this case). From your response, it's not clear to me if you disagree with the desire to remove this manual step in the plugin install/uninstall process, or if you just disagree with the proposed approach of achieving this through concatenating plugin JS into a single file. You can't have different web-pages with different plugins enabled on the native side, I don't think there would be much benefit to enable this use-case for just the HTML side. Do you have any example of when you'd want this? Votes are fine, but consensus is much better. I don't want to move forward with this until everyone is on board. This of course does not preclude use of this technique, however, I feel very strongly that we should NOT be building this into our framework, and forcing developers to use this approach. I think this is definitely something that we should vote on before developing further if the goal is inclusion in cordova. Cheers, Jesse On Thu, Nov 22, 2012 at 2:34 AM, Brian LeRoux b...@brian.io wrote: super interesting. I like where this is going. On Thu, Nov 22, 2012 at 3:42 AM, Andrew Grieve agri...@chromium.org wrote: On Wed, Nov 21, 2012 at 6:37 PM, Filip Maj f...@adobe.com wrote: Dude: awesome! My answers in-line: 2. Manually adding the script tags to include every new plugin is really lame. I propose a unified file, plugins.js or similar, that's always included in the index.html. Every time you add or remove a plugin, the Javascript files for all the plugins are concatenated into this file. There are likely some problems with this approach. Inserting/removing the script tags from the index page is also an option, though it requires more clever scripts. Can you elaborate more on this? I don't understand. Here's the motivating example to explain this: - Our goal for 3.0 is to have cordova be just the bridge, and to have all core plugins in separate repos - Right now, when you pluginstall a plugin, you need to manually edit your .html to add the .js of the plugin in a script tag. - This will be quite annoying to have to add ~10 script tags, (one for each core plugin, plus one for each non-core plugin you have) Here's Braden's idea explained a bit more: - Have a plugin.js file in addition to the cordova.js file - cordova.js to have the platform's bridge init code - plugins.js to contain the concatenation of all plugin .js files - plugins.js to be regenerated whenever a plugin is added / removed - Apps will need to add both .js files to their html, but not need to add a script for every plugin separately. 3. Setting the start page manually on every platform sucks. I think this should be a value in config.xml that gets set on cordova build. Obviously that requires 1. to be
Re: Type checking in Cordova JS plugins
I don't mean to push ahead with this without your buy-in. What goes in can easily come out. I do want to give you concrete code to look at though, because I think our back-and-forth on this thread has made this change out to be more than it is. On Thu, Nov 22, 2012 at 4:02 PM, Jesse purplecabb...@gmail.com wrote: Nevermind then, guess it's in ... On Thu, Nov 22, 2012 at 12:51 PM, Andrew Grieve agri...@chromium.org wrote: I just checked in argscheck.js and refactored all applicable lower-case plugin/*.js files to use it. It trims 4k off of cordova.ios.js and git tells me: 245 insertions(+), 323 deletions(-) I also found that a couple of our tests were passing invalid arg types :P On Thu, Nov 22, 2012 at 3:48 PM, Andrew Grieve agri...@chromium.org wrote: There's a good amount of code that currently check types on the public API. My goal here is to shrink that code because it seems repetitive. Checking the types passed to exec may be useful in some cases too, but we don't currently do that. Probably, if we wanted to add this in, we'd want something more sophisticated that actually checked JSON schemas instead of just checking for typeof 'object'. On Thu, Nov 22, 2012 at 1:19 PM, Brian LeRoux b...@brian.io wrote: Ok, hold up, I'm missing something---I thought this was for the *bridge protocol validation* not the actual API surface end developers invoke. Ideally the public API would define their own exceptional paths. (Har har.) Example: geolocation api has error callbacks whereas File API has FileError (or some such / on bad connection and just blasting this w/o checking). On Thu, Nov 22, 2012 at 2:01 PM, Patrick Mueller pmue...@gmail.com wrote: On Thu, Nov 22, 2012 at 6:00 AM, Brian LeRoux b...@brian.io wrote: ya upon further consideration making these TypeException's feels right since, ideally, this error would only be seen by a plugin author and not something a plugin consumer (ideally) huh? I thought this was all about informing users when they pass invalid arguments? I'm usually in favor of fail fast - and so throwing an exception when you pass an invalid argument sounds right to me. The problem is that even though it's simple for us to fail fast by throwing an exception, we also need to make sure it's super obvious to the user that a failure has occurred. That's the hard part. Too many places where errors are silently consumed by the runtime. I think a console.log() would be appropriate - along with a thrown exception - lots of folks have access to a console these days. Or maybe we should come up with a new API - reportFailure() or something, which we could have - by default - just log to the console. For platforms that don't have an easily accessible console, they can override this to do something visible for their platform. -- Patrick Mueller http://muellerware.org -- @purplecabbage risingj.com
Re: Android WebView
OK, so what's the downside of constantly forcing the view to be redrawn over and over again? That's the thing that I would be most concerned about. On Thu, Nov 22, 2012 at 1:37 PM, Braden Shepherdson bra...@chromium.org wrote: The first paragraph of his answer is entirely in line with my claim that Android WebView is the new IE6. It's slow, buggy, doesn't follow the standards, and it will be years before we're rid of it. Interesting comments about the invalidation. I haven't seen most of the problems he's been having in a Phonegap app, but I have certainly seen them on the old Android Browser when I was working on mobile web G+. Braden On Thu, Nov 22, 2012 at 3:55 PM, Simon MacDonald simon.macdon...@gmail.comwrote: Hey all, Anything we can use from this SO answer to make the webview faster? http://stackoverflow.com/questions/13500452/android-webview-renders-blank-white-view-doesnt-update-on-css-changes-or-html Simon Mac Donald http://hi.im/simonmacdonald
RE: Android WebView
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 engine (c++) calls viewInvalidate() in c++ when in the DOM cursor/scrolling etc.. events happen, this calls invalidate() in java. The purpose of invalidate() is to force the re-render of *java* components painted on the canvas. -Original Message- From: Joe Bowser [mailto:bows...@gmail.com] Sent: November 22, 2012 4:51 PM To: dev Subject: Re: Android WebView OK, so what's the downside of constantly forcing the view to be redrawn over and over again? That's the thing that I would be most concerned about. On Thu, Nov 22, 2012 at 3:55 PM, Simon MacDonald simon.macdon...@gmail.comwrote: Hey all, Anything we can use from this SO answer to make the webview faster? http://stackoverflow.com/questions/13500452/android-webview-renders- b lank-white-view-doesnt-update-on-css-changes-or-html
Re: Android WebView
I don't think that's necessarily right. Calling invalidate forces the re-render of the canvas with whatever data is sent to it in mPicture as well as whatever the WebView overlays. The fact that you have to call invalidate() after the draw() just to get the up-to-date mPicture is a bug. It would be better to see if mPicture was updated after the draw and to only issue a redraw at that time, but even then there might be issues. I wonder how other browser implementations handle this. On Thu, Nov 22, 2012 at 2:30 PM, Jonathan Bond-Caron jbo...@openmv.com wrote: 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 engine (c++) calls viewInvalidate() in c++ when in the DOM cursor/scrolling etc.. events happen, this calls invalidate() in java. The purpose of invalidate() is to force the re-render of *java* components painted on the canvas. -Original Message- From: Joe Bowser [mailto:bows...@gmail.com] Sent: November 22, 2012 4:51 PM To: dev Subject: Re: Android WebView OK, so what's the downside of constantly forcing the view to be redrawn over and over again? That's the thing that I would be most concerned about. On Thu, Nov 22, 2012 at 3:55 PM, Simon MacDonald simon.macdon...@gmail.comwrote: Hey all, Anything we can use from this SO answer to make the webview faster? http://stackoverflow.com/questions/13500452/android-webview-renders- b lank-white-view-doesnt-update-on-css-changes-or-html
Re: Android WebView
Yeah, a lot of those changes seem risky. The invalidate for sure, but also making every div in your app hw-accelerated will work only for extremely small DOMs, and in the average case cause more harm than good. That said, carefully selecting which elements to apply that to goes a long way. Upping the priority of the renderer thread seems like something we could try out. On Thu, Nov 22, 2012 at 5:54 PM, Joe Bowser bows...@gmail.com wrote: I don't think that's necessarily right. Calling invalidate forces the re-render of the canvas with whatever data is sent to it in mPicture as well as whatever the WebView overlays. The fact that you have to call invalidate() after the draw() just to get the up-to-date mPicture is a bug. It would be better to see if mPicture was updated after the draw and to only issue a redraw at that time, but even then there might be issues. I wonder how other browser implementations handle this. On Thu, Nov 22, 2012 at 2:30 PM, Jonathan Bond-Caron jbo...@openmv.com wrote: 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 engine (c++) calls viewInvalidate() in c++ when in the DOM cursor/scrolling etc.. events happen, this calls invalidate() in java. The purpose of invalidate() is to force the re-render of *java* components painted on the canvas. -Original Message- From: Joe Bowser [mailto:bows...@gmail.com] Sent: November 22, 2012 4:51 PM To: dev Subject: Re: Android WebView OK, so what's the downside of constantly forcing the view to be redrawn over and over again? That's the thing that I would be most concerned about. On Thu, Nov 22, 2012 at 3:55 PM, Simon MacDonald simon.macdon...@gmail.comwrote: Hey all, Anything we can use from this SO answer to make the webview faster? http://stackoverflow.com/questions/13500452/android-webview-renders- b lank-white-view-doesnt-update-on-css-changes-or-html
[jira] [Updated] (CB-200) FileTransfer should support uploading multiple files in one HTTP request
[ https://issues.apache.org/jira/browse/CB-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bowser updated CB-200: -- Fix Version/s: (was: 2.3.0) 2.4.0 Are we going to do this? This issue is almost a year old. FileTransfer should support uploading multiple files in one HTTP request Key: CB-200 URL: https://issues.apache.org/jira/browse/CB-200 Project: Apache Cordova Issue Type: Improvement Components: Android, Bada, BlackBerry, CordovaJS, Docs, iOS, mobile-spec, Qt, webOS, WP7 Affects Versions: 1.3.0 Environment: Windows XP, Android, Lenovo ThinkPad Reporter: Matt Accola Assignee: Simon MacDonald Fix For: 2.4.0 FileTransfer only allows one file to be uploaded at a time. Should allow multiple files to be uploaded at once. This might be necessary if the server-side service requires all files to be submitted at once to ensure any operations on the files are atomic. This question has been asked on the phonegap Google Group, http://groups.google.com/group/phonegap/browse_thread/thread/bdc40098c2954870. (Update: Since this requires a UI change for parity, I've added more components and moved it out of 1.7. This should be added to the Roadmap, so I'm leaving it assigned to myself so I'm reminded to do this - Joe) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CB-1478) FileReader vs XHR bench
[ https://issues.apache.org/jira/browse/CB-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bowser updated CB-1478: --- Fix Version/s: (was: 2.3.0) Removing the version from this bug. FileReader vs XHR bench --- Key: CB-1478 URL: https://issues.apache.org/jira/browse/CB-1478 Project: Apache Cordova Issue Type: Task Components: Android, BlackBerry, iOS, WP7 Affects Versions: 2.2.0 Reporter: Brian LeRoux Assignee: Filip Maj Priority: Minor Labels: ci Attachments: IOBench-debug.apk Long standing rumor that FileReader is/was faster than XHR debunked at PhoneGap Day EU. Before we do anything to optimize our i/o, we need some actual science on which is faster, on which platforms. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: InAppBrowser - events
The more events the better! :) Really though, it would be good if someone
knew of an app that used ChildBrowser for the purposes of OAuth. That seems
like one of the most important use-cases, so we should make sure to have
all of the events that it requires.
On Thu, Nov 22, 2012 at 4:26 PM, Simon MacDonald
simon.macdon...@gmail.comwrote:
Just looking at this again and...
webview.addEventListener('exit', handleExit);
webview.addEventListener('loadstart', handleLoadStart);
would seem to map to our:
onClose
onLocationChanged
methods from the ChildBrowser. At least on Android I fire location changed
event when the page starts to load not when it is finished.
Simon Mac Donald
http://hi.im/simonmacdonald
On Thu, Nov 22, 2012 at 1:53 PM, Simon MacDonald
simon.macdon...@gmail.comwrote:
Is this required for the 2.3.0 release?
Simon Mac Donald
http://hi.im/simonmacdonald
On Wed, Nov 21, 2012 at 11:30 PM, Shazron shaz...@gmail.com wrote:
Great! Let's stick with one API, since we have Chrome members on the
Cordova team the choice is obvious :)
On Wed, Nov 21, 2012 at 8:06 PM, Andrew Grieve agri...@chromium.org
wrote:
Looks that way. Given how similar they are, I don't think it matters
which
one we go with (or if we come up with our own event names), but it'd
be
good to follow the same pattern of having events and an API like
canGoBack(), goForward(), etc. If they ever move to standardize, then
we
can follow suit.
On Wed, Nov 21, 2012 at 7:18 PM, Shazron shaz...@gmail.com wrote:
Mozilla's 'locationchange' is similar to what we have for
ChildBrowser,
but
I don't see the equivalent in the Chrome example - I suppose it is
'loadstop'?
I suppose if we were to adopt either, it would go something like
this:
var iab = window.open('http://apache.org', '_blank');
// Firefox
iab.addEventListener('locationchange', handleLocationChange);
// Chrome
iab.addEventListener('loadstop', handleLoadStop);
// Firefox
function handleLocationChange(e) {
console.log('location changed to: ' + e.detail);
}
// Chrome
function handleLoadStop(e) {
console.log('location changed to: ' + e.url);
}
On Wed, Nov 21, 2012 at 1:32 PM, Andrew Grieve
agri...@chromium.org
wrote:
https://github.com/GoogleChrome/chrome-app-samples/blob/master/browser/browser.js
Re: InAppBrowser - events
At some point Gather used ChildBrowser for Oauth, but I think they might not be
anymore. Max left the list shortly after joining, so I could try and ping him
on IRC if it would help?
On 23/11/2012, at 10:40 AM, Andrew Grieve agri...@chromium.org wrote:
The more events the better! :) Really though, it would be good if someone
knew of an app that used ChildBrowser for the purposes of OAuth. That seems
like one of the most important use-cases, so we should make sure to have
all of the events that it requires.
On Thu, Nov 22, 2012 at 4:26 PM, Simon MacDonald
simon.macdon...@gmail.comwrote:
Just looking at this again and...
webview.addEventListener('exit', handleExit);
webview.addEventListener('loadstart', handleLoadStart);
would seem to map to our:
onClose
onLocationChanged
methods from the ChildBrowser. At least on Android I fire location changed
event when the page starts to load not when it is finished.
Simon Mac Donald
http://hi.im/simonmacdonald
On Thu, Nov 22, 2012 at 1:53 PM, Simon MacDonald
simon.macdon...@gmail.comwrote:
Is this required for the 2.3.0 release?
Simon Mac Donald
http://hi.im/simonmacdonald
On Wed, Nov 21, 2012 at 11:30 PM, Shazron shaz...@gmail.com wrote:
Great! Let's stick with one API, since we have Chrome members on the
Cordova team the choice is obvious :)
On Wed, Nov 21, 2012 at 8:06 PM, Andrew Grieve agri...@chromium.org
wrote:
Looks that way. Given how similar they are, I don't think it matters
which
one we go with (or if we come up with our own event names), but it'd
be
good to follow the same pattern of having events and an API like
canGoBack(), goForward(), etc. If they ever move to standardize, then
we
can follow suit.
On Wed, Nov 21, 2012 at 7:18 PM, Shazron shaz...@gmail.com wrote:
Mozilla's 'locationchange' is similar to what we have for
ChildBrowser,
but
I don't see the equivalent in the Chrome example - I suppose it is
'loadstop'?
I suppose if we were to adopt either, it would go something like
this:
var iab = window.open('http://apache.org', '_blank');
// Firefox
iab.addEventListener('locationchange', handleLocationChange);
// Chrome
iab.addEventListener('loadstop', handleLoadStop);
// Firefox
function handleLocationChange(e) {
console.log('location changed to: ' + e.detail);
}
// Chrome
function handleLoadStop(e) {
console.log('location changed to: ' + e.url);
}
On Wed, Nov 21, 2012 at 1:32 PM, Andrew Grieve
agri...@chromium.org
wrote:
https://github.com/GoogleChrome/chrome-app-samples/blob/master/browser/browser.js
[jira] [Commented] (CB-1856) Offline Event fires twice on Jellybean
[ https://issues.apache.org/jira/browse/CB-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13502974#comment-13502974 ] Joe Bowser commented on CB-1856: After looking at this, it's not coming from the webview at all. For some reason the receiver is being called twice. We can suppress duplicates on the updateConnectionInfo so that switching from WiFi to WiFi doesn't get sent. Offline Event fires twice on Jellybean -- Key: CB-1856 URL: https://issues.apache.org/jira/browse/CB-1856 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.3.0 Environment: Neuxs 7 running Android 4.2 Reporter: Joe Bowser Assignee: Joe Bowser Fix For: 2.3.0 While testing CB-1846, I discovered that the Offline and Online events are being called twice on my Galaxy Nexus and my Nexus 7. The Samsung Galaxy S2 and the Nexus S that I tested are working as expected. We ideally should only fire this event once when we switch WiFi on and off. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
iOS Changes to InAppBrowser
Just pushed a few. Let me know if you have concerns about any of them. 1. I changed the User-Agent from appending a GUID to appending the VC's memory location I was hoping this would let me get rid of the vc header field in the bridge all together, but it turns out that the User-Agent isn't being sent for all requests. (Maybe because they are file:// requests?). Anyways, it still gets rid of having two sets in the URLProtocol, and now the JS gets the value from the UA instead of cordova.iOSVCAddr 2. Added a helper to InvokedCommand for getting arguments. There was a bug in InAppBrowser with NSNull vs nil, which I've run into many times before, so it pushed me over the edge! Makes a lot of sense I think though, to have such a helper method. I'll probably update other plugins to use it instead of checking NSNull themselves 3. I made InAppBrowser's UA the default UA instead of having a GUID appended to it. I don't think a GUID in this case makes a difference since we're not registering them with the URIProtocol, but if you had a use in mind we can just roll back that commit. Andrew
Re: InAppBrowser - events
I'd like to, if everyone agrees. I'd like to wipe out ChildBrowser use if I
can, and this (events) is the only thing I believe that people are still
using ChilBrowser for.
Is this required for the 2.3.0 release?
Simon Mac Donald
http://hi.im/simonmacdonald
On Wed, Nov 21, 2012 at 11:30 PM, Shazron shaz...@gmail.com wrote:
Great! Let's stick with one API, since we have Chrome members on the
Cordova team the choice is obvious :)
On Wed, Nov 21, 2012 at 8:06 PM, Andrew Grieve agri...@chromium.org
wrote:
Looks that way. Given how similar they are, I don't think it matters
which
one we go with (or if we come up with our own event names), but it'd be
good to follow the same pattern of having events and an API like
canGoBack(), goForward(), etc. If they ever move to standardize, then we
can follow suit.
On Wed, Nov 21, 2012 at 7:18 PM, Shazron shaz...@gmail.com wrote:
Mozilla's 'locationchange' is similar to what we have for
ChildBrowser,
but
I don't see the equivalent in the Chrome example - I suppose it is
'loadstop'?
I suppose if we were to adopt either, it would go something like this:
var iab = window.open('http://apache.org', '_blank');
// Firefox
iab.addEventListener('locationchange', handleLocationChange);
// Chrome
iab.addEventListener('loadstop', handleLoadStop);
// Firefox
function handleLocationChange(e) {
console.log('location changed to: ' + e.detail);
}
// Chrome
function handleLoadStop(e) {
console.log('location changed to: ' + e.url);
}
On Wed, Nov 21, 2012 at 1:32 PM, Andrew Grieve agri...@chromium.org
wrote:
https://github.com/GoogleChrome/chrome-app-samples/blob/master/browser/browser.js
Re: InAppBrowser - events
Those events sound good to me.
On Nov 22, 2012 1:27 PM, Simon MacDonald simon.macdon...@gmail.com
wrote:
Just looking at this again and...
webview.addEventListener('exit', handleExit);
webview.addEventListener('loadstart', handleLoadStart);
would seem to map to our:
onClose
onLocationChanged
methods from the ChildBrowser. At least on Android I fire location changed
event when the page starts to load not when it is finished.
Simon Mac Donald
http://hi.im/simonmacdonald
On Thu, Nov 22, 2012 at 1:53 PM, Simon MacDonald
simon.macdon...@gmail.comwrote:
Is this required for the 2.3.0 release?
Simon Mac Donald
http://hi.im/simonmacdonald
On Wed, Nov 21, 2012 at 11:30 PM, Shazron shaz...@gmail.com wrote:
Great! Let's stick with one API, since we have Chrome members on the
Cordova team the choice is obvious :)
On Wed, Nov 21, 2012 at 8:06 PM, Andrew Grieve agri...@chromium.org
wrote:
Looks that way. Given how similar they are, I don't think it matters
which
one we go with (or if we come up with our own event names), but it'd
be
good to follow the same pattern of having events and an API like
canGoBack(), goForward(), etc. If they ever move to standardize, then
we
can follow suit.
On Wed, Nov 21, 2012 at 7:18 PM, Shazron shaz...@gmail.com wrote:
Mozilla's 'locationchange' is similar to what we have for
ChildBrowser,
but
I don't see the equivalent in the Chrome example - I suppose it is
'loadstop'?
I suppose if we were to adopt either, it would go something like
this:
var iab = window.open('http://apache.org', '_blank');
// Firefox
iab.addEventListener('locationchange', handleLocationChange);
// Chrome
iab.addEventListener('loadstop', handleLoadStop);
// Firefox
function handleLocationChange(e) {
console.log('location changed to: ' + e.detail);
}
// Chrome
function handleLoadStop(e) {
console.log('location changed to: ' + e.url);
}
On Wed, Nov 21, 2012 at 1:32 PM, Andrew Grieve
agri...@chromium.org
wrote:
https://github.com/GoogleChrome/chrome-app-samples/blob/master/browser/browser.js
