Re: Merge plugin dev branchs into master
Yes, updating the wiki would be helpful. I'd like to submit a fix but since I don't follow this list all this time, I'm not sure if I should be working off of dev or master. Based on the above thread I think dev? thanks, -becky On Thu, Aug 29, 2013 at 11:48 AM, Andrew Grieve agri...@chromium.orgwrote: Steve, did you do this? I didn't notice a JIRA issue or blog post. On Fri, Aug 16, 2013 at 10:59 AM, Andrew Grieve agri...@chromium.org wrote: Thought of another step! Generate a changelog, and turn it into a blog post so that people will know about the update :) On Thu, Aug 15, 2013 at 4:59 PM, Steven Gill stevengil...@gmail.com wrote: Thanks for the feedback Andrew! Sounds good to me. I am going to go through these steps today. On Thu, Aug 15, 2013 at 12:07 PM, Andrew Grieve agri...@chromium.org wrote: Great! I agree it's time someone take a stab at this! On Thu, Aug 15, 2013 at 3:00 PM, Steven Gill stevengil...@gmail.com wrote: I want to try and flush out the process for merging the dev branches for the core plugins into master and get it onto the wiki. Currently the dev branches have some readme changes, namespace changes and package changes for android. I don't believe any of these changes should be breaking changes. Process 1. Create issue on jira for running mobile spec tests on all platforms using dev branch of plugins 2. Test on all platforms 3. Merge in change into master 4. Publish to plugins.cordova.io? Do we really need to test the plugins on all the platforms for changes that won't affect them at all? I think no. And we should only test plugins that have changes to them (in this case all of them). Should add in bumping of the version number. I think one thing to add to the process is to create mobilespec with the existing versions of plugins, then `cordova plugin rm` them all, then `cordova plugin add` the new ones using a URL that points to the dev branch. aka, test out the upgrade process.
Re: A few comments on Working With 3.0
Regarding cordova-ios, I cloned a cordova-ios into a new directory via the coho clone script in the wiki. I assumed that would get me the latest but I'll update and see what happens. I'm not sure what installing the packages with dependencies means? I ran npm install -g. I'm no node expert, what should I have done? It would at least be good to document the coho dependencies in the readme. Regarding grunt vs grunt-cli - I did run sudo npm install -g grunt-cli and it got installed but still wasn't accessible from cordova-js? thanks, -becky On Thu, Aug 15, 2013 at 9:33 AM, Braden Shepherdson bra...@chromium.orgwrote: It sounds like you're installed npm packages with dependencies (coho, cordova-js) and not running npm install. That command will install all their dependencies locally. In particular that's what's wrong with grunt-cli vs. grunt: the intended flow is that you install grunt-cli globally, and that gives you a grunt command. That command is a thin wrapper the looks up your directory structure until it finds a node_modules/grunt, and then runs that locally installed grunt version. Braden On Wed, Aug 14, 2013 at 6:50 PM, James Jong wjamesj...@gmail.com wrote: Becky, I would update your cordova-ios project. There was a recent change to remove it (CB-4281). -James Jong On Aug 14, 2013, at 5:33 PM, Becky Gibson gibson.be...@gmail.com wrote: OK, I think the linker problem is because CDVEcho.m is included twice. I see it in plugins dir under org.apache.cordova.test.echo/src/ios/ and in platforms/ios/cordovalib/classes/. I'm guessing this has something to do with the dependencies for mobilespec? thanks, -becky On Wed, Aug 14, 2013 at 5:05 PM, Becky Gibson gibson.be...@gmail.com wrote: I found a few bugs in iOS media capture and media that I would like to fix. I need to get set up for 3.0 so I followed the instructions here: http://wiki.apache.org/cordova/WorkingWithThree. Since I didn't have any 3.0 clones I started by cloning. Here are a few issues that I ran into that did not seem to be documented: - In order for the coho clone command to work I needed to install optimist, shelljs and request. I tried to install optimist globally but that didn't work so I ended up installing all of these locally in my cordova-coho directory to get things working. - I had to blindly cut and paste the coho clone from the WorkingWithThree wiki page since I couldn't find any documentation for the clone command. - I edited .cordova/config.json as indicated in the instructions but then running the cordova platform add command kept giving me a syntax error: unexpected string. I went back to the default config.json and the platform add command worked correctly. - Since I was starting from scratch I had to also clone cordova-js - I followed the instructions for the cordova-js readme and installed grunt via: sudo npm install -g grunt-cli When I tried to run grunt to build cordova-js I got the message that it should be installed locally: Fatal error: Unable to find local grunt. Based on the original instructions I installed grunt-cli locally - that didn't work so I installed grunt locally. - I could build the platform js files but got the following error: Running _test task starting node-based tests Warning: can't run tests in node: run grunt btest instead, or install jsdom via: npm install Use --force to continue. Since I didn't care about the tests (at this point I didn't worry about the error - however I'm still not sure what I should be installing). I opened the created mobilespec project in xcode but the build failed when linking. I did make the mistake of opening it in xcode 5 (beta 5) before trying it in 4.6 so my project settings may have been messed up by xcode 5. I'll tackle that tomorrow but I wanted to get the installation information documented before I forgot. -becky
Re: A few comments on Working With 3.0
FYI I'm guessing that the cordova-mobile-spec\dependencies-plugin\plugin.xml file is what is causing the problems with the xcode project since it still lists org.apache.test.echo as a dependency. I guess my point in the first post was to point out the difficulties in following the WorkingWithThree instructions in hopes of helping other folks who might want to contribute. I DID run npm install moduleName from the directory that had the dependency to get a local copy. My question was really whether or not we intended for the modules to be installed locally rather than globally. Looking at .gitignore I guess the intention is for local install since node_modules is listed. On Thu, Aug 15, 2013 at 11:24 AM, Andrew Grieve agri...@chromium.orgwrote: https://npmjs.org/doc/faq.html is a good resource for understanding node's local vs global dependencies. Agree coho's README needs updating. It's completely out of date! On Thu, Aug 15, 2013 at 11:20 AM, Andrew Grieve agri...@chromium.org wrote: yeah, sounds like mainly it's that you missed typing npm install within cordova-js and within cordova-coho (and within cordova-cli if you want to use a local version of that). For iOS (and android), the WorkingWithThree steps exist in a script within cordova-mobile-spec (createmobilespec.sh). For coho - use coho --help for documentation. On Thu, Aug 15, 2013 at 9:33 AM, Braden Shepherdson bra...@chromium.org wrote: It sounds like you're installed npm packages with dependencies (coho, cordova-js) and not running npm install. That command will install all their dependencies locally. In particular that's what's wrong with grunt-cli vs. grunt: the intended flow is that you install grunt-cli globally, and that gives you a grunt command. That command is a thin wrapper the looks up your directory structure until it finds a node_modules/grunt, and then runs that locally installed grunt version. Braden On Wed, Aug 14, 2013 at 6:50 PM, James Jong wjamesj...@gmail.com wrote: Becky, I would update your cordova-ios project. There was a recent change to remove it (CB-4281). -James Jong On Aug 14, 2013, at 5:33 PM, Becky Gibson gibson.be...@gmail.com wrote: OK, I think the linker problem is because CDVEcho.m is included twice. I see it in plugins dir under org.apache.cordova.test.echo/src/ios/ and in platforms/ios/cordovalib/classes/. I'm guessing this has something to do with the dependencies for mobilespec? thanks, -becky On Wed, Aug 14, 2013 at 5:05 PM, Becky Gibson gibson.be...@gmail.com wrote: I found a few bugs in iOS media capture and media that I would like to fix. I need to get set up for 3.0 so I followed the instructions here: http://wiki.apache.org/cordova/WorkingWithThree. Since I didn't have any 3.0 clones I started by cloning. Here are a few issues that I ran into that did not seem to be documented: - In order for the coho clone command to work I needed to install optimist, shelljs and request. I tried to install optimist globally but that didn't work so I ended up installing all of these locally in my cordova-coho directory to get things working. - I had to blindly cut and paste the coho clone from the WorkingWithThree wiki page since I couldn't find any documentation for the clone command. - I edited .cordova/config.json as indicated in the instructions but then running the cordova platform add command kept giving me a syntax error: unexpected string. I went back to the default config.json and the platform add command worked correctly. - Since I was starting from scratch I had to also clone cordova-js - I followed the instructions for the cordova-js readme and installed grunt via: sudo npm install -g grunt-cli When I tried to run grunt to build cordova-js I got the message that it should be installed locally: Fatal error: Unable to find local grunt. Based on the original instructions I installed grunt-cli locally - that didn't work so I installed grunt locally. - I could build the platform js files but got the following error: Running _test task starting node-based tests Warning: can't run tests in node: run grunt btest instead, or install jsdom via: npm install Use --force to continue. Since I didn't care about the tests (at this point I didn't worry about the error - however I'm still not sure what I should be installing). I opened the created mobilespec project in xcode but the build failed when linking. I did make the mistake of opening it in xcode 5 (beta 5) before trying it in 4.6 so my project settings may have been messed up by xcode 5. I'll tackle that tomorrow but I wanted to get
A few comments on Working With 3.0
I found a few bugs in iOS media capture and media that I would like to fix. I need to get set up for 3.0 so I followed the instructions here: http://wiki.apache.org/cordova/WorkingWithThree. Since I didn't have any 3.0 clones I started by cloning. Here are a few issues that I ran into that did not seem to be documented: - In order for the coho clone command to work I needed to install optimist, shelljs and request. I tried to install optimist globally but that didn't work so I ended up installing all of these locally in my cordova-coho directory to get things working. - I had to blindly cut and paste the coho clone from the WorkingWithThree wiki page since I couldn't find any documentation for the clone command. - I edited .cordova/config.json as indicated in the instructions but then running the cordova platform add command kept giving me a syntax error: unexpected string. I went back to the default config.json and the platform add command worked correctly. - Since I was starting from scratch I had to also clone cordova-js - I followed the instructions for the cordova-js readme and installed grunt via: sudo npm install -g grunt-cli When I tried to run grunt to build cordova-js I got the message that it should be installed locally: Fatal error: Unable to find local grunt. Based on the original instructions I installed grunt-cli locally - that didn't work so I installed grunt locally. - I could build the platform js files but got the following error: Running _test task starting node-based tests Warning: can't run tests in node: run grunt btest instead, or install jsdom via: npm install Use --force to continue. Since I didn't care about the tests (at this point I didn't worry about the error - however I'm still not sure what I should be installing). I opened the created mobilespec project in xcode but the build failed when linking. I did make the mistake of opening it in xcode 5 (beta 5) before trying it in 4.6 so my project settings may have been messed up by xcode 5. I'll tackle that tomorrow but I wanted to get the installation information documented before I forgot. -becky
Re: A few comments on Working With 3.0
OK, I think the linker problem is because CDVEcho.m is included twice. I see it in plugins dir under org.apache.cordova.test.echo/src/ios/ and in platforms/ios/cordovalib/classes/. I'm guessing this has something to do with the dependencies for mobilespec? thanks, -becky On Wed, Aug 14, 2013 at 5:05 PM, Becky Gibson gibson.be...@gmail.comwrote: I found a few bugs in iOS media capture and media that I would like to fix. I need to get set up for 3.0 so I followed the instructions here: http://wiki.apache.org/cordova/WorkingWithThree. Since I didn't have any 3.0 clones I started by cloning. Here are a few issues that I ran into that did not seem to be documented: - In order for the coho clone command to work I needed to install optimist, shelljs and request. I tried to install optimist globally but that didn't work so I ended up installing all of these locally in my cordova-coho directory to get things working. - I had to blindly cut and paste the coho clone from the WorkingWithThree wiki page since I couldn't find any documentation for the clone command. - I edited .cordova/config.json as indicated in the instructions but then running the cordova platform add command kept giving me a syntax error: unexpected string. I went back to the default config.json and the platform add command worked correctly. - Since I was starting from scratch I had to also clone cordova-js - I followed the instructions for the cordova-js readme and installed grunt via: sudo npm install -g grunt-cli When I tried to run grunt to build cordova-js I got the message that it should be installed locally: Fatal error: Unable to find local grunt. Based on the original instructions I installed grunt-cli locally - that didn't work so I installed grunt locally. - I could build the platform js files but got the following error: Running _test task starting node-based tests Warning: can't run tests in node: run grunt btest instead, or install jsdom via: npm install Use --force to continue. Since I didn't care about the tests (at this point I didn't worry about the error - however I'm still not sure what I should be installing). I opened the created mobilespec project in xcode but the build failed when linking. I did make the mistake of opening it in xcode 5 (beta 5) before trying it in 4.6 so my project settings may have been messed up by xcode 5. I'll tackle that tomorrow but I wanted to get the installation information documented before I forgot. -becky
Setting up Cordova Dev environment
So, I've been away from Cordova development for several months. I thought I might look into fixing a few iOS bugs. - I updated my cordova-ios repo and used the create script to create a new test project as this seemed to be still available. I know cli is available but I didn't see options for working from the repos (like the --shared option in the cordova-ios script lets me do). - I ran the project in the simulator and saw the familiar logo and device is ready. Yeah! - Now I want to run mobile-spec to make sure everything works before I start changing code. I plopped the mobile-spec files into my www directory. The app builds but certainly doesn't run the tests properly. - So, I figure that I need to build cordova.js. And I suddenly realize the world is completely different! There are all these new repos - cordova-plugin-*. I'm wondering if there is an easy way to create all of these repos and keep them all updated? Does anyone have any scripts to share? If I am going to be a good Cordova developer I assume I should have a repo for each of the native plugins and build and run them if I make any Cordova infrastructure changes. Is there any documentation for the best way to do this? I got a little overwhelmed at having to create and pull 19 new cordova-plugin-* repos? I guess that is what I get for not keeping up with the mailing list! I did search the wiki for any clues but didn't see any magic to help me manage all of the new repos - any quick advice to share or docs or particular email exchanges that would help me get back up to speed? thanks, -becky
Re: camera saveToPhotoAlbum intent
Yeah, saveToPhotoAlbum was an iOS only option for awhile. It got lost for a bit during the unified JS push last year but I added it back in April, 2012.The photo was only saved to the photo album when this variable is set but it did result in two copies of the file in order to have a URL to return to the caller. I guess when we added some of the other options for resizing and resaving we didn't take the saveToPhotoAlbum option into account. It shouldn't be too hard to reconcile the options. However, at the time this was added there wasn't a way to return a URL to the photoAlbum so we had to create the additional copy. I haven't looked to see if we can get the URI to the album now or not - I don't think so. -becky On Fri, Apr 5, 2013 at 1:30 PM, Shazron shaz...@gmail.com wrote: Bah iOS landscape mode on Gmail app is too small - hit Send accidentally when scrolling. Becky can elaborate (I think she implemented this) but I think it was needed at the time. On Friday, April 5, 2013, Shazron wrote: Like the Transformers, I think there is more than meets the eye. On Friday, April 5, 2013, James Jong wrote: I have been looking at Lorin's iOS image metadata writer that was recently merged in 2.6.x and noticed that the exif metadata was missing from the saved photos. After troubleshooting some w Lorin, I discovered that the image saved to the photo album is the image before scaling and writing of the exif metadata. This results in 2 different images which was confusing to me. Is this correct intent? This refers to iOS code but my question is intended for the Camera API. Do other platforms that support this follow the same behavior? ref code in camera https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/CDVCamera.m#L275 -James Jong
Re: Updated W3C Contacts api
Hi, Josh, Yes, I've worked in W3C working groups - I know the risks of implementing too early in the process! However, when we wanted to add an API for contacts into PhoneGap we needed a place to start so we used the W3C working draft available at the time. We realized that it would likely change but at least gave us a starting point. We been trying to keep track of the W3C updates and changes so we can decide when to update the Cordova version. When we implemented an earlier Contacts API working draft for Cordova we added a remove functionality to provide the ability to delete a contact. It just seemed to make sense that if add is being provided that there should also be a way to remove a contact as well. Since not all of the platforms provide a native view for accessing the contacts (similar to camera access) we decided to implement full functionality of create, find and remove. On Thu, Mar 14, 2013 at 11:25 AM, Josh Soref jso...@blackberry.com wrote: Becky wrote: The basic contacts object is pretty much the same but there have been several enhancements. Most notably the find method is actual useful enough to perform an efficient search! There is a result object defined as well as events to indicate when a procedure is completed. And remove has been officially added. 1. Please don't treat a working draft as official, it's a working draft. Things before Last Call are really unofficial. 2. Can you please explain which use cases you have for `remove`? - 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: Contacts, and when/how/who removes anything and why
Well, I know that people do use find a lot and are frequently tripped up by it. They get confused over the fact that the fields array is the list of fields that are returned AND are searched. Most people expect all of the contact information returned and they think that the fields are just the fields that will be searched. We did modify the api a bit to add a * in fields to indicate to return all fields. However, with the field parameter overloaded it does make the search less efficient. At any rate, I can certainly post to the Phonegap google group asking for feedback on the use of remove and request the use cases. Or, you can join and post directly yourself. It's up to you. As I'm not active in the W3C currently, I doubt I could get approval and funding to attend any F2F :-( FYI - I did work actively on WAI/WCAG and some on WAI/PF. On Thu, Mar 14, 2013 at 4:39 PM, Josh Soref jso...@blackberry.com wrote: Becky wrote: Yes, I've worked in W3C working groups I'm glad you do, I'm concerned about messaging - that others might not understand what it means. I've seen various groups really fail to understand such a detail. - I know the risks of implementing too early in the process! However, when we wanted to add an API for contacts into PhoneGap we needed a place to start so we used the W3C working draft available at the time. We realized that it would likely change but at least gave us a starting point. We been trying to keep track of the W3C updates and changes so we can decide when to update the Cordova version. Right, and appreciated. When we implemented an earlier Contacts API working draft for Cordova we added a remove functionality to provide the ability to delete a contact. It just seemed to make sense that if add is being provided that there should also be a way to remove a contact as well. So, this symmetry is interesting. One thing I don't think Cordova (or pretty much most other projects have) is any metrics showing how often/much use a given API has. Does Cordova/PhoneGap know if remove() is used and if so by whom and if by whom, why? I know of a few rather rare instances where it might theoretically be possible for someone to want to have a remove, but I think they're either theoretical or indicate a need for something drastically different (which is the reason why I was working on a Pick-Contact API). Since not all of the platforms provide a native view for accessing the contacts (similar to camera access) we decided to implement full functionality of create, find and remove. Camera access doesn't usually let one delete a picture, does it? (I understand that Gallery access would.) p.s., sysapps is having a F2F soon, I hope you're planning to attend :). - 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: Who's who at cordova
I added a profile on people.phonegap.com and updated the link on the cordova/who page. If someone could star my phonegap people page I would appreciate it. -b On Wed, Mar 13, 2013 at 11:23 AM, Michal Mocny mmo...@chromium.org wrote: I think this is a good start, please fill in whoever I've missed. http://wiki.apache.org/cordova/who We can add more detail about each individual, but for now I just link to the phonegap page which already has a lot of good stuff. If your name doesn't have a link, I encourage you to make one! On Tue, Mar 12, 2013 at 5:58 PM, Benn Mapes benn.ma...@gmail.com wrote: +1 On Tue, Mar 12, 2013 at 1:30 PM, Marcel Kinard cmarc...@gmail.com wrote: +1 On Mar 12, 2013, at 2:31 PM, Michal Mocny mmo...@google.com wrote: I'de like to make a wiki page with a brief bio of all cordova contributors (a who's who, if you will). This helps new contributors, and frankly, helps me with my terrible memory keep track of the less vocal members. Is anyone apposed to this for any reason? -Michal
Re: Updated W3C Contacts api
A bit more detail. I was curious about some items in the Contact Manager API so I dove into the mail archives for the System Applications Working group who published this working draft. It seems that this is a parallel effort to the Device API working group which published the initial contacts api and is still updating the Pick Contacts Intent (it was just updated on March 11, 2013!). At least the two groups plan to unify the Contacts objects a bit. I sure hope they unify the find() implementation and use the one from the Contacts Manager API. IMHO it is much more reasonable and usable. I was thinking of creating an iOS branch to implement the Contacts Manager API as a test case but it is probably too soon to commit any coding time to this. -becky On Tue, Mar 12, 2013 at 5:19 PM, Brian LeRoux b...@brian.io wrote: awesome, thx for this becky On Tue, Mar 12, 2013 at 2:10 PM, Becky Gibson gibson.be...@gmail.com wrote: Contacts Manager API Draft Published 07 March 2013 | Archive http://www.w3.org/News/2013#entry-9748 The System Applications Working Group has published the First Public Working Draft of Contacts Manager API. This specification defines a System Level API which offers a simple interface to manage user's contacts stored in the system's address book. A typical use case of the Contacts API is the implementation of an application to manage said address book. Learn more about the Ubiquitous Web Applications Activity. http://www.w3.org/2012/sysapps/ http://www.w3.org/TR/2013/WD-contacts-manager-api-20130307/ http://www.w3.org/2007/uwa/ The basic contacts object is pretty much the same but there have been several enhancements. Most notably the find method is actual useful enough to perform an efficient search! There is a result object defined as well as events to indicate when a procedure is completed. And remove has been officially added. Since this is a new draft I don't think we should rush to implement it but at least there are some useful changes. I'll update the Core API Audit entry in the wiki.
Re: prompt dialog for the Notification API?
+1 I think it would be worthwhile to add this. We just need confirmation from the other platforms that this feature is available. On Mon, Mar 11, 2013 at 5:04 PM, James Jong wjamesj...@gmail.com wrote: I was looking at the Notification API and noticed that we have existing support for alert and confirm dialogs but do not have one for prompt. I think it would good to add this missing function to the Notification API. It seems a natural fit alongside the alert and confirm methods. To mirror the current dialogs in the Notification API, the js method would look something like: navigator.notification.prompt(message, promptCallback, [title], [buttonLabels]) message: Dialog message to display (String) promptCallback: Callback to invoke with index of button pressed (1 or 2). (Function) title: Dialog title (String) (Optional, Default: Prompt) buttonLabels: Comma separated string with button labels (String) (Optional, Default: OK,Cancel) The goal would be to have this across all our supported platforms. I would like to create a JIRA item and have sub-tasks for each platform. I plan on contributing the code for iOS and Android. I also will update mobile-spec tests and write the API documentation. My questions are: (1) Is this a reasonable addition to the Notification API? (2a) If so, can we initially have support for a few platforms and add more as we go along? (2b) Can we go ahead and publicly document the API or wait until we have support across the platforms? If we agree this is good to have, here's the summary of tasks I plan to proceed with: create a JIRA issue with sub-tasks for each platform contribute the code for iOS and Android add prompt tests to mobile-spec create the prompt API documentation Thoughts or comments? -James Jong
Re: Issues with CLI
Fil, perhaps I over explained! Regarding my question about the directory: 1) Although I could easily figure it out from the note about changing ownership of the cordova directory, it would help to state up front the directory where cordova will be installed. All I really want is to state that cordova will be installed in usr/local/lib/node_modules/cordova if the user has installed node in the default directory. FWIW I had already dealt with the permissions issue in previous cordova-cli tries and that wasn't the point. Just want to provide node newbies with the directory name where cordova will be installed. And regarding the create commane, yes, I did see the create command in the Global Commands section, but my point was that the explanation of create doesn't tell me that I must add cordova in front of it. That might be obvious to others but I was busy looking for create.sh in the directory structure. -b On Wed, Mar 6, 2013 at 12:59 PM, Brian LeRoux b...@brian.io wrote: I love the theory of a global cli that is so well designed that we never have to change it and everything 'just works' across versions. I suspect we may want this to bake as the 'official way' for some time before we attmpt it. On Wed, Mar 6, 2013 at 9:46 AM, Patrick Mueller pmue...@gmail.com wrote: On Wed, Mar 6, 2013 at 12:37 PM, Don Coleman don.cole...@gmail.com wrote: I'd like to see cordova-cli get the phonegap version from config.xml like phonegap build. preference name=phonegap-version value=2.3.0 / It would be nice to semver this, so I could do something like preference name=phonegap-version value=2.3.x / making it easy (presumably) to upgrade to point releases (somehow). -- Patrick Mueller http://muellerware.org
Issues with CLI
I played around a bit with cordova-cli and have a few comments and questions. I think a bit more detail in the instructions would resolve most of my issues. I think I am a fairly good test subject with respect to Android since I am not familiar with the SDK and don't use it much. I also haven't used npm and am not familiar with the file layout so I couldn't (easily) rely on poking through the cordova-cli files to answer my questions. Also, defining the audience for cli and the cli documentation might make some of these issues moot. 1. Although I could easily figure it out from the note about changing ownership of the cordova directory, it would help to state up front the directory where cordova will be installed. 2. What version of Cordova is being installed - next, master or can I specify a specific version as a parameter to npm? 3. After installation I was a bit surprised to see that I was good to go for Blackberry Webworks development until I realized that it is all Web technology! 4. There should probably be some links about how to get set up for iOS, Android, and BB development. We certainly don't need to explain the nuances of iOS certificates and provisioning profiles but we do need to point newbies to a link (provided we are targeting iOS/Android/BB development newbies). I got hung up on needing to setup my Android tablet for development before I could run from the command line and had to spend a bit more time jogging my memory about basic Android setup. 5. Why is it just cordova.js in each of the platform repos rather than including the version number as we normally do? I blindly copied the mobile-spec into my www directory and since it relies on its own cordova.js to set up the version number the back button in the tests no longer worked. This is a minor point since I could easily modify mobile-spec to use a different technique. However, I suspect the technique used in mobile-spec may be commonly used by multi-platform app developers. It also might be useful to keep the platform name of the cordova file in the platform specific directories just to make it clear which is which. 6. OK, it may seem dumb but it took me awhile to find the create command. I had to scroll through all of the documentation to the samples to see that it is cordova create. 7. I haven't tried any plugins yet. my two cents, -becky
Re: git frustration!
I was trying to follow #2 and didn't want the merge commit in the next branch. So, I took a deep breath and slogged through.I cherry-picked each commit, rebased to squash them together, merged into next and pushed to next. Then I could checkout master, merge next, and then push master. I can live with the merge commits into master but I wanted to keep the original author's commit info when I merged the fix into next. git taxes my brain and my patience! Thanks for the help! On Thu, Feb 21, 2013 at 1:57 PM, Michal Mocny mmo...@chromium.org wrote: I had that same concern at some point, but I've just learned to live with them. In the end, unless they are abused (such as doing work on master and having merge commit with each pull), merge commits can be useful and give insights, so shouldn't necessarily be avoided at all costs. On Thu, Feb 21, 2013 at 1:27 PM, Andrew Grieve agri...@chromium.org wrote: You get a merge commit any time you try to merge in a branch that is not fast-forward (the internet can explain this better than I can). You have two options to not have a merge commit: 1. Cherry-pick both commits, one after the other 2. Create a local branch based off of the remote one, rebase it, and then merge it The work-flow for #2 is on the committer's wiki page (replace master with next for your case): git checkout master git pull apache git checkout topic_branch git checkout -b to_be_merged git rebase master -i ... git checkout master git merge --ff-only to_be_merged git push apache master git branch -d to_be_merged git branch -D topic_branch git push apache :topic_branch Having a merge commit is a bit annoying IMO, but you do end up in the same state if you use them, and there are fewer git commands to type. On Thu, Feb 21, 2013 at 12:02 PM, Becky Gibson gibson.be...@gmail.com wrote: I am trying to merge a fix from someone else into my branch that I created off of the apache/next branch: git checkout next git pull apache next git checkout -b cb2411 git remote add foo address git fetch foo git merge foo/branchName Why does git want to create a new commit when I do the merge? It immediately prompts for a commit message and gives me a generic message about merging? The only way I can get the code into my branch is to use cherry-pick but since the branch has two commits this results in two separate commits? Is my only choice to rebase interactive and squash those commits? I'm just trying to keep the original author. This is a fairly simple commit and should not require any merging. I'm happy to read more docs about git but to be honest, most of it makes my eyes glaze over! thanks, -becky
Re: Tag 2.5.0rc1?
Just an FYI - I ran mobile-spec yesterday (using an older version) and I only had one failure so maybe the issue is with the tests themselves. On Wed, Feb 20, 2013 at 11:11 AM, Shazron shaz...@gmail.com wrote: On iOS just touch and hold, drag then copy :) On Wednesday, February 20, 2013, Michal Mocny wrote: Shaz how did you generate that text file output? Did you open remote inspector and copy console output manually? On Wed, Feb 20, 2013 at 3:33 AM, Shazron shaz...@gmail.comjavascript:; wrote: Tried mob-spec on an iPhone 3GS running 6.0.1 (to rule out any errors due to the new 6.1.2 update) - same number of errors as the previous two devices. On Wed, Feb 20, 2013 at 12:23 AM, Shazron shaz...@gmail.com javascript:; wrote: I tagged iOS 2.5.0rc1 but there are 22 mobile-spec failures (21 related to filetransfer). I'll examine them tomorrow and fix for a re-tag. The mobile-spec failures are attached as a text file. Tested on an iPhone 5 with iOS 6.1.2 and iPhone 4 with iOS 5.1.1, exact same failures. On Tue, Feb 19, 2013 at 3:16 PM, Herm Wong kingoftheo...@hotmail.comjavascript:; wrote: webOS has been tagged 2.5.0rc1. From: shaz...@gmail.com javascript:; Date: Tue, 19 Feb 2013 14:46:08 -0800 Subject: Re: Tag 2.5.0rc1? To: dev@cordova.apache.org javascript:; Will do the same EOD today for Eye-Oh-Ess, wrapping things up. On Tue, Feb 19, 2013 at 11:55 AM, Joe Bowser bows...@gmail.com javascript:; wrote: Gone through the same process with Fil. If we fail, we fail together On Tue, Feb 19, 2013 at 11:50 AM, Filip Maj f...@adobe.com javascript:; wrote: I've creatd the JIRA issues for 2.5.0rc1 tagging. Also created a new next branch under the javascript and tagged 2.5.0rc1 from that branch.. Hope I did it right :s On 2/19/13 11:32 AM, Brian LeRoux b...@brian.iojavascript:; wrote: Sounds about right. Lets aim to get this thing tagged/bagged today. On Tue, Feb 19, 2013 at 11:23 AM, Filip Maj f...@adobe.com javascript:; wrote: I fear change! But let's do it. On 2/19/13 11:19 AM, Joe Bowser bows...@gmail.com javascript:; wrote: So, how does this work? Do we create the next branch now and throw things in that?
Re: Tag 2.5.0rc1?
This morning I did git pull apache next for mobile-spec and got this: Updating 3e3d075..842e603 Fast-forward VERSION | 2 +- autotest/tests/file.tests.js | 14 ++ autotest/tests/filetransfer.tests.js | 27 +-- cordova.js | 2 +- index.html | 1 + misc/index.html | 3 ++- misc/page2.html | 27 ++- splashscreen/index.html | 47 +++ 8 files changed, 105 insertions(+), 18 deletions(-) create mode 100644 splashscreen/index.html Does that help? On Wed, Feb 20, 2013 at 11:27 AM, Shazron shaz...@gmail.com wrote: That was my suspicion but i have no data on this yet. Which mob-spec version? I can verify. On Wednesday, February 20, 2013, Becky Gibson wrote: Just an FYI - I ran mobile-spec yesterday (using an older version) and I only had one failure so maybe the issue is with the tests themselves. On Wed, Feb 20, 2013 at 11:11 AM, Shazron shaz...@gmail.com javascript:; wrote: On iOS just touch and hold, drag then copy :) On Wednesday, February 20, 2013, Michal Mocny wrote: Shaz how did you generate that text file output? Did you open remote inspector and copy console output manually? On Wed, Feb 20, 2013 at 3:33 AM, Shazron shaz...@gmail.com javascript:; javascript:; wrote: Tried mob-spec on an iPhone 3GS running 6.0.1 (to rule out any errors due to the new 6.1.2 update) - same number of errors as the previous two devices. On Wed, Feb 20, 2013 at 12:23 AM, Shazron shaz...@gmail.com javascript:; javascript:; wrote: I tagged iOS 2.5.0rc1 but there are 22 mobile-spec failures (21 related to filetransfer). I'll examine them tomorrow and fix for a re-tag. The mobile-spec failures are attached as a text file. Tested on an iPhone 5 with iOS 6.1.2 and iPhone 4 with iOS 5.1.1, exact same failures. On Tue, Feb 19, 2013 at 3:16 PM, Herm Wong kingoftheo...@hotmail.com javascript:;javascript:; wrote: webOS has been tagged 2.5.0rc1. From: shaz...@gmail.com javascript:; javascript:; Date: Tue, 19 Feb 2013 14:46:08 -0800 Subject: Re: Tag 2.5.0rc1? To: dev@cordova.apache.org javascript:; javascript:; Will do the same EOD today for Eye-Oh-Ess, wrapping things up. On Tue, Feb 19, 2013 at 11:55 AM, Joe Bowser bows...@gmail.comjavascript:; javascript:; wrote: Gone through the same process with Fil. If we fail, we fail together On Tue, Feb 19, 2013 at 11:50 AM, Filip Maj f...@adobe.com javascript:; javascript:; wrote: I've creatd the JIRA issues for 2.5.0rc1 tagging. Also created a new next branch under the javascript and tagged 2.5.0rc1 from that branch.. Hope I did it right :s On 2/19/13 11:32 AM, Brian LeRoux b...@brian.io javascript:; javascript:; wrote: Sounds about right. Lets aim to get this thing tagged/bagged today. On Tue, Feb 19, 2013 at 11:23 AM, Filip Maj f...@adobe.comjavascript:; javascript:; wrote: I fear change! But let's do it. On 2/19/13 11:19 AM, Joe Bowser bows...@gmail.com javascript:; javascript:; wrote: So, how does this work? Do we create the next branch now and throw things in that?
Re: too long to package a release?
Can someone please provide a git cordova release process for dummies
example to make sure I do the release commits and merges properly (the
committerWorkflow example didn't help me as I didn't understand the
topic_branch and to_be_merged distinction)
At any rate, can I do a git checkout apache next into my master branch?
Then I can checkout my working_branch, rebase master (which contains the
next code) checkout master, merge my fix and push apache next.
git checkout apache next
git checkout working_branch_with_fix
git rebase master
git checkout master
git merge working_branch_with_fix
git push apache next
and then repeat this for apache master with the possibility of needing to
use -ff when I merge. Am I on the right track?
humbled by git,
-becky
On Fri, Feb 8, 2013 at 5:22 PM, Marcel Kinard cmarc...@gmail.com wrote:
Nice! Thanks, Andrew!
-- Marcel Kinard
On Feb 7, 2013, at 2:59 PM, Andrew Grieve agri...@chromium.org wrote:
The doc's not up-to-date, but I think we ended on consensus for the code
version. I've taken a stab at updating the wiki pages:
http://wiki.apache.org/cordova/CordovaAndGit -- Added the idea of
having
both a master and a next branch
http://wiki.apache.org/cordova/CommitterWorkflow -- Added Jesse's
version
of the which branch - in code
http://wiki.apache.org/cordova/CuttingReleases -- Changed tagging
instructions to refer to the next branch
On Thu, Feb 7, 2013 at 1:26 PM, Marcel Kinard cmarc...@gmail.com
wrote:
With 2.5 starting, it appears time to poke this thread.
- Is the Google doc refreshed with the latest consensus?
- If so, should the Google doc be transferred to a wiki page?
- Have the necessary branches been created?
- Are we all in the boat, and understand how to row this beast?
-- Marcel Kinard
On Jan 24, 2013, at 5:14 PM, Jesse purplecabb...@gmail.com wrote:
Nice Shaz, but I was hoping it was a github style network visualization
that included a few versions worth of merges.
Who wants to draw that?
On Thu, Jan 24, 2013 at 2:05 PM, Shazron shaz...@gmail.com wrote:
Inline image got mangled, here it is linked: http://cl.ly/MOrD
On Thu, Jan 24, 2013 at 1:39 PM, Shazron shaz...@gmail.com wrote:
Thanks for the pseudocode Andrew, seems simpler to understand ;)
Jesse's
re-factor makes it even easier. Here's my contrib for those more
visually
inclined:
[image: Inline image 2]
On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve agri...@chromium.org
wrote:
Nice! even simpler. :)
On Thu, Jan 24, 2013 at 3:44 PM, Jesse purplecabb...@gmail.com
wrote:
Thanks for clarifying Andrew. et al, I guess I was
mis-understanding
some
of the earlier discussion around naming stuff.
So everything is going to master all the time, and we only care
about
'next' if we are inReleaseMode and it is a bug fix?
if(inReleaseMode isBugFix) {
commitToBranch('next');
mergeBranch('next').into('master');
}
else {
commitToBranch('master');
}
On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve
agri...@chromium.org
wrote:
Just to clarify - there should be *no* using of the git
cherry-picking
command, only git merge.
Jesse - not sure what you're referring to with branch must be
named
x.
The latest revision of the proposal has only two branches: master
and
next.
Do you mean you don't like the name next?
Maybe the proposal will seem simpler if put in the form of code :)
if (!inReleaseMode) {
commitToBranch('master');
} else {
if (isBugFix) {
commitToBranch('next');
mergeBranch('next').into('master');
} else {
commitToBranch('master');
}
}
On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson
bra...@chromium.org
wrote:
Most of the time the flow will be unchanged: push to master.
Tagging
things
we already know how to do; that doesn't change.
The only new flow for most people is cherrypicking bug fixes from
master
to
next, which we can give examples of. Plus that could remain the
responsibility of the main platform maintainers, who are doing
the
tagging.
Braden
On Thu, Jan 24, 2013 at 2:56 PM, Jesse purplecabb...@gmail.com
wrote:
On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson
bra...@chromium.org
wrote:
The founding goal we're trying to accomplish here is that we
don't
want
everyone sitting on changes to be in the next version while we
use
master
to prep a release.
I don't think having one branch for prepping the release and
another
for
main development is a lot of bureaucracy.
It is not, the 'branch must be named x' is mainly where I have
concerns.
Really I just want things simple.
On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen
purplecabb...@gmail.com
wrote:
I have been quietly listening on this thread, but thought I
should
at
least share my opinion.
I don't think adding
Re: Tag 2.5.0rc1?
For added data, I also fail using the tagged cordova-js (04e4ceafdcd59cdd937e873cc9006766c1e5940a) built locally. On Wed, Feb 20, 2013 at 12:40 PM, Shazron shaz...@gmail.com wrote: I just generated the js from cordova-js on tag 2.5.0rc1 (hash 04e4ceafdcd59cdd937e873cc9006766c1e5940a) and I get the same results as I've always had :/ On Wed, Feb 20, 2013 at 9:34 AM, Andrew Grieve agri...@chromium.org wrote: Using the JS built from cordova-js it's working fine... On Wed, Feb 20, 2013 at 12:32 PM, Shazron shaz...@gmail.com wrote: Could be the symbol mapping. Using Safari 6 iPhone Simulator debugging -- window.FileTransfer is not defined, but I can do a cordova.require(cordova/plugin/FileTransfer). On Wed, Feb 20, 2013 at 9:27 AM, Shazron shaz...@gmail.com wrote: Don't know what's wrong - with mob-spec 3e3d075 on iOS 2.5.0rc1 it still all fails. Trying iOS 2.4.0 (with latest mob-spec), it all passes. I suspect its in the cordova-js, not mob-spec On Wed, Feb 20, 2013 at 9:17 AM, Shazron shaz...@gmail.com wrote: Andrew, I re-verified and re-downloaded 2.5.0rc1 of iOS and 2.5.0rc1 of mobile-spec, created a new project - I get the same results as I had (both in Simulator and device as well). On Wed, Feb 20, 2013 at 8:46 AM, Andrew Grieve agri...@chromium.org wrote: Just tried the tests and they are all passing for me (on simulator) On Wed, Feb 20, 2013 at 11:38 AM, Becky Gibson gibson.be...@gmail.com wrote: This morning I did git pull apache next for mobile-spec and got this: Updating 3e3d075..842e603 Fast-forward VERSION | 2 +- autotest/tests/file.tests.js | 14 ++ autotest/tests/filetransfer.tests.js | 27 +-- cordova.js | 2 +- index.html | 1 + misc/index.html | 3 ++- misc/page2.html | 27 ++- splashscreen/index.html | 47 +++ 8 files changed, 105 insertions(+), 18 deletions(-) create mode 100644 splashscreen/index.html Does that help? On Wed, Feb 20, 2013 at 11:27 AM, Shazron shaz...@gmail.com wrote: That was my suspicion but i have no data on this yet. Which mob-spec version? I can verify. On Wednesday, February 20, 2013, Becky Gibson wrote: Just an FYI - I ran mobile-spec yesterday (using an older version) and I only had one failure so maybe the issue is with the tests themselves. On Wed, Feb 20, 2013 at 11:11 AM, Shazron shaz...@gmail.com javascript:; wrote: On iOS just touch and hold, drag then copy :) On Wednesday, February 20, 2013, Michal Mocny wrote: Shaz how did you generate that text file output? Did you open remote inspector and copy console output manually? On Wed, Feb 20, 2013 at 3:33 AM, Shazron shaz...@gmail.com javascript:; javascript:; wrote: Tried mob-spec on an iPhone 3GS running 6.0.1 (to rule out any errors due to the new 6.1.2 update) - same number of errors as the previous two devices. On Wed, Feb 20, 2013 at 12:23 AM, Shazron shaz...@gmail.com javascript:; javascript:; wrote: I tagged iOS 2.5.0rc1 but there are 22 mobile-spec failures (21 related to filetransfer). I'll examine them tomorrow and fix for a re-tag. The mobile-spec failures are attached as a text file. Tested on an iPhone 5 with iOS 6.1.2 and iPhone 4 with iOS 5.1.1, exact same failures. On Tue, Feb 19, 2013 at 3:16 PM, Herm Wong kingoftheo...@hotmail.com javascript:;javascript:; wrote: webOS has been tagged 2.5.0rc1. From: shaz...@gmail.com javascript:; javascript:; Date: Tue, 19 Feb 2013 14:46:08 -0800 Subject: Re: Tag 2.5.0rc1? To: dev@cordova.apache.org javascript:; javascript:; Will do the same EOD today for Eye-Oh-Ess, wrapping things up. On Tue, Feb 19, 2013 at 11:55 AM, Joe Bowser bows...@gmail.comjavascript:; javascript:; wrote: Gone through the same process with Fil. If we fail, we fail together On Tue, Feb 19, 2013 at 11:50 AM, Filip Maj f
Re: too long to package a release?
Thank you, Michael! I do usually go a git push --dry-run to check that I
am pushing what I expect but I'll try the diff as well.
On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny mmo...@chromium.org wrote:
So there is also http://wiki.apache.org/cordova/CuttingReleases which may
be useful (esp Taggin section).
As far as the confusion with the two branch names: topic_branch is your
local working branch for a bugfix/feature, and to_be_merged is really
temporary_new_name_for_a_branch_to_do_rebase_in. I usually skip that
step and take the risk or rebasing in topic_branch (aside: this may
negatively affect diffs if you push updates for a review-edit-re-review
cycle -- but this isn't an issue for cordova).
Do not checkout 'next' into your master branch. Update your local branches
to include the remote next branch (with 'git pull apache' with no branch)
then you can switch to the next branch locally, apply your patch there, and
push to that remote branch directly. Later, merge that commit into master
locally, and push that.
Do not push to apache next from your local master, or else you will push
all the changes.
I agree, this is a little confusing, but after a few practice runs it
should be easy to figure out. You should probably also check what would be
pushed with 'git diff apache/[target-branch]' or tag on --stat to that to
just see that files that would signal a quick uh-oh.
I'll work to update the wiki later today, and likely others will have more
tips on how to make sure we don't make mistakes.
-Michal
On Wed, Feb 20, 2013 at 12:42 PM, Becky Gibson gibson.be...@gmail.com
wrote:
Can someone please provide a git cordova release process for dummies
example to make sure I do the release commits and merges properly (the
committerWorkflow example didn't help me as I didn't understand the
topic_branch and to_be_merged distinction)
At any rate, can I do a git checkout apache next into my master branch?
Then I can checkout my working_branch, rebase master (which contains
the
next code) checkout master, merge my fix and push apache next.
git checkout apache next
git checkout working_branch_with_fix
git rebase master
git checkout master
git merge working_branch_with_fix
git push apache next
and then repeat this for apache master with the possibility of needing to
use -ff when I merge. Am I on the right track?
humbled by git,
-becky
On Fri, Feb 8, 2013 at 5:22 PM, Marcel Kinard cmarc...@gmail.com
wrote:
Nice! Thanks, Andrew!
-- Marcel Kinard
On Feb 7, 2013, at 2:59 PM, Andrew Grieve agri...@chromium.org
wrote:
The doc's not up-to-date, but I think we ended on consensus for the
code
version. I've taken a stab at updating the wiki pages:
http://wiki.apache.org/cordova/CordovaAndGit -- Added the idea of
having
both a master and a next branch
http://wiki.apache.org/cordova/CommitterWorkflow -- Added Jesse's
version
of the which branch - in code
http://wiki.apache.org/cordova/CuttingReleases -- Changed tagging
instructions to refer to the next branch
On Thu, Feb 7, 2013 at 1:26 PM, Marcel Kinard cmarc...@gmail.com
wrote:
With 2.5 starting, it appears time to poke this thread.
- Is the Google doc refreshed with the latest consensus?
- If so, should the Google doc be transferred to a wiki page?
- Have the necessary branches been created?
- Are we all in the boat, and understand how to row this beast?
-- Marcel Kinard
On Jan 24, 2013, at 5:14 PM, Jesse purplecabb...@gmail.com wrote:
Nice Shaz, but I was hoping it was a github style network
visualization
that included a few versions worth of merges.
Who wants to draw that?
On Thu, Jan 24, 2013 at 2:05 PM, Shazron shaz...@gmail.com
wrote:
Inline image got mangled, here it is linked: http://cl.ly/MOrD
On Thu, Jan 24, 2013 at 1:39 PM, Shazron shaz...@gmail.com
wrote:
Thanks for the pseudocode Andrew, seems simpler to understand ;)
Jesse's
re-factor makes it even easier. Here's my contrib for those more
visually
inclined:
[image: Inline image 2]
On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve
agri...@chromium.org
wrote:
Nice! even simpler. :)
On Thu, Jan 24, 2013 at 3:44 PM, Jesse purplecabb...@gmail.com
wrote:
Thanks for clarifying Andrew. et al, I guess I was
mis-understanding
some
of the earlier discussion around naming stuff.
So everything is going to master all the time, and we only care
about
'next' if we are inReleaseMode and it is a bug fix?
if(inReleaseMode isBugFix) {
commitToBranch('next');
mergeBranch('next').into('master');
}
else {
commitToBranch('master');
}
On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve
agri...@chromium.org
Re: [iOS] Call for testing
Interesting. I ran this once and it worked (I had to use sudo). Then, I realized that I might have my xcode-selects variable set wrong since I recently downloaded Xcode 4.6 via the iOS downloads page rather than via the AppStore. I put Xcode 4.6 into a subdirectory: /Applications/Xcode46/Xcode.app rather than right in the Applications folder. I realized that I should have also updated my xcode-select variable. I did that: sudo /usr/bin/xcode-select -switch /Applications/Xcode46/Xcode.app/Contents/Developer Then when I run sudo npm install -g cordova again, iOS fails: WARNING: Your system does not meet requirements to create iosprojects. See error output below. Xcode is not installed. Cannot add iOS platform. SKIPPING ios bootstrap. So, I would guess it has to do with the xcode-selects value. Also, FWIW running the suggested sudo chown -R yourusername /usr/local/lib/node_modules/cordova command and it didn't work for me. I haven't investigate that yet. -becky On Fri, Feb 8, 2013 at 3:59 PM, Filip Maj f...@adobe.com wrote: Hey everyone, I've had a couple of reports of people using the cordova-cli tools and having issues installing. Apparently the post-install script (bootstrap) complains that Xcode is not installed on the system. Both users were running Xcode 4.6. I've since upgraded my Xcode and done both a fresh install as well as an upgrade from old cli tools to new, and cannot reproduce (the bootstrap works; I get SUCCESS: min reqs for iOS met). Could other contributors on the ML here, who have Xcode at least 4.5.2 installed, give it a shot and see if the installation goes through? To install, have node installed and run: npm install -g cordova (you may need to put sudo in front of that if your node is installed globally) Near the end of the installation process you should see something like: cordova@2.4.4 install /usr/local/lib/node_modules/cordova node bootstrap.js ./bin/notice SUCCESS: Minimum requirements for blackberry met. BOOTSTRAPPING blackberry... SUCCESS: Minimum requirements for ios met. BOOTSTRAPPING ios... SUCCESS: ios ready to rock! SUCCESS: blackberry ready to rock! SUCCESS: Minimum requirements for android met. BOOTSTRAPPING android... SUCCESS: android ready to rock! If you do notice issues, please file any details on the following JIRA issue I have set up to track details: https://issues.apache.org/jira/browse/CB-2404 Thanks in advance! Fil
Re: Creating repos for core plugins
Well, we still need an API/plugin for playing audio. The w3c spec is pretty involved. In the past Simon has suggested we try to unify around HTML audio. At any rate I don't think we can just get rid of it. Sent from my iPhone On Feb 6, 2013, at 2:52 PM, Andrew Grieve agri...@chromium.org wrote: +1 On Wed, Feb 6, 2013 at 2:41 PM, Brian LeRoux b...@brian.io wrote: So instead of revisiting it just let it die and kick up a new one for web audio? On Wed, Feb 6, 2013 at 11:23 AM, Andrew Grieve agri...@chromium.org wrote: So... back to cordova-plugin-media then? On Wed, Feb 6, 2013 at 1:59 PM, Brian LeRoux b...@brian.io wrote: exactly! And plugins, I think, will end up being independently versioned so if ppl want old and busted they can have it. =P On Wed, Feb 6, 2013 at 10:48 AM, Andrew Grieve agri...@chromium.org wrote: SGTM. First step towards deprecation is turning it into a plugin so that people can not install it :) On Wed, Feb 6, 2013 at 1:41 PM, Brian LeRoux b...@brian.io wrote: I was thinkin we'd just deprecate the media spec altogether for a starter/subset of the web audio api (perhaps polyfil the audio element while we're at it). should we kick up a thread about that? (Added file transfer to the non-spec plugins.) On Wed, Feb 6, 2013 at 10:22 AM, Filip Maj f...@adobe.com wrote: Totally makes sense to separate them. File is spec-based, FileTransfer is not. On 2/6/13 10:16 AM, Andrew Grieve agri...@chromium.org wrote: I thought FileTransfer was a part of File. Maybe it makes sense to separate them though? On Wed, Feb 6, 2013 at 12:00 PM, Becky Gibson gibson.be...@gmail.comwrote: Yes, I shouldn't have confused the issue about audio and media! I guess I just get annoyed when I go to mobile spec and it is labelled as audio :-) We can leave it as cordova-plugin-media so it matches the JS api name. Although, I think we are creating the same type of confusion if we rename capture to media-capture but I don't have a strong opinion on that. Plus, I see we are doing that for acceleration and compass as well. I guess now is as good a time as any to match the W3C names! Also, where is FileTransfer? On Wed, Feb 6, 2013 at 11:12 AM, Andrew Grieve agri...@chromium.org wrote: Great! I like the spec-based names. I think I have the opposite thought as Becky. Our current media plugin doesn't follow the WebAudio spec at all. How about we call it cordova-media for now since that's what it's called in our docs, and then if we ever implement WebAudio, then we'll have the name available for that. Maybe we should even put it the spec-less category (unless there's some older spec that it was based off of?) On Tue, Feb 5, 2013 at 5:14 PM, Brian LeRoux b...@brian.io wrote: Just kicked up a quick wiki page to help vett this. I'm thinking we try to stay as close to the spec names as possible. http://wiki.apache.org/cordova/Core%20Plugin%20Name%20Proposal On Tue, Feb 5, 2013 at 11:40 AM, Becky Gibson gibson.be...@gmail.com wrote: My only comment would be about media. Currently it just supports audio so perhaps codova-plugin-audio makes more sense and we can leave media open for the rewrite. Although, I do realize the api is labelled media so perhaps it would be too confusing to change the repo name. Just a thought. On Tue, Feb 5, 2013 at 1:38 PM, Andrew Grieve agri...@chromium.org wrote: Before I go ahead with this, let's agree upon the repo names / which plugins to include. Here's the proposed list: Repos to create: cordova-plugin-accelerometer cordova-plugin-battery cordova-plugin-camera cordova-plugin-capture cordova-plugin-compass cordova-plugin-contacts cordova-plugin-device cordova-plugin-file cordova-plugin-geolocation cordova-plugin-globalization cordova-plugin-logger cordova-plugin-media cordova-plugin-networkstatus cordova-plugin-notification cordova-plugin-splashscreen cordova-plugin-inappbrowser Note that I have device and network status in this list. Plugins that delay ondeviceready just add themselves to channel.deviceReadyChannelsArray. Plugins *not* getting their own Repo: blackberry/plugin/java/app android/plugin/android/app android/plugin/android/storage errgen/plugin/errgen ios/plugin/ios/console (seems like this should be merged into the logger plugin) windowsphone/plugin/windowsphone/DOMStorage windowsphone/plugin/windowsphone/XHRPatch windowsphone/plugin/windowsphone/console iOS's CDVLocalStorage.m On Tue, Feb 5, 2013 at 9:34 AM, Andrew Grieve agri...@chromium.org wrote: Great! Sounds like an agreement :). I'll file an INFRA to get them created. On Mon, Feb 4, 2013 at 9:44 PM, Shazron shaz...@gmail.com wrote: +1 on separate repos. It's the sane choice. On Mon, Feb 4, 2013 at 11:53 PM, Jesse purplecabb...@gmail.com wrote: +1, I agree
[jira] [Commented] (CB-285) Add property returning root path of PhoneGap files
[ https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571647#comment-13571647 ] Becky Gibson commented on CB-285: - For iOS I'm not sure that I understand why you want to change the PERSISTENT directory out of application-home/Documents into application-home/Library/CdvPersistent? The iOS documentation that you reference explicitly states for Application_Home/Library/, You should not use this directory for user data files. I could see adding a USERDATA setting if you want to make a distinction between user data and app data, although then we are deviating from the W3C spec. I'm also not sure I understand the need for a way to retrieve the application-home directory - why would an app want to write here? I can see why the user might want the APP_ASSETS in order to obtain a full path to the www directory but I think that would be confusing in the File APIs since this is read only. Generally by convention in the core plugins file names with w/o a full path are treated as coming from te www directory. At least this is what media does and we could standardize any other core plugins that do not use this convention. While we are thinking about directory names and locations, I am looking at fixing CB-571 where iOS requires the file to exist before recording. If the user just passes in a file name, I was going to create and store the recording in the application-home/Documents directory since it is user generated and should be backed up. I'm not sure how this flies in the face of your proposed conventions for the File api - I guess the dev could get to these recorded files later using the proposed APP_HOME and appending /Documents to access the directory? Or are you proposing that recorded files would also go in the application-home/Library/CdvPersistent dir??? Add property returning root path of PhoneGap files -- Key: CB-285 URL: https://issues.apache.org/jira/browse/CB-285 Project: Apache Cordova Issue Type: Improvement Components: CordovaJS Affects Versions: 1.4.0 Environment: Both PhoneGap SDK and PhoneGap Build Reporter: Ashley Gullen Assignee: Andrew Grieve Labels: features There needs to be a property in PhoneGap that returns the root path to the general files added to the PhoneGap project (i.e. the directory index.html is in). For example, if I add 'music.mp3' to my project, in Android it will be located in: /android_asset/www/music.mp3 On iOS after being built with PhoneGap Build it will be located in some path like this: /var/mobile/Applications/app_ID/name.app/www/music.mp3 However, there does not appear to be a programmatic way to determine both app_ID and name.app. This has two side effects: 1. Paths to audio for Media must be hard-coded separately depending on the platform, which is inconvenient. 2. Paths to audio for Media cannot be known if developing a framework that uses PhoneGap. Since a framework does not know the App ID or name in advance, it's impossible for the framework to determine the correct path. This is actively blocking audio from working on iOS in PhoneGap projects exported by Construct 2 (www.scirra.com), a HTML5 game creator. Also, it seems like kind of an important function to make available anyway, since hard-coding paths for each platform is a pain. This PhoneGap Support thread led to this issue: http://phonegap.tenderapp.com/discussions/questions/208-android_asset-equivalent-for-ios -- 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: Adding new LocalFileSystem constants.
I commented in the ticket: https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571437#comment-13571647 On Tue, Feb 5, 2013 at 1:53 PM, Andrew Grieve agri...@chromium.org wrote: Thanks for the input Bryan! Good ref's for storage locations: Android: http://developer.android.com/guide/topics/data/data-storage.html ): iOS: http://developer.apple.com/library/ios/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemOverview/FileSystemOverview.html Shared files: On Android, they go on /sdcard/Pictures, /sdcard/Music, etc. On iOS, Photos Videos are shared via the AssetLibrary framework and music through the MusicPlayer framework. Neither one is provides a filesystem-like interface. Would SHARED be different from EXTERNAL_ROOT? Maybe SHARED would be a better name for it? On Tue, Feb 5, 2013 at 1:31 PM, Bryan Higgins br...@bryanhiggins.net wrote: Hi Andrew, I really like this proposal. It's something we'd likely pick up for BlackBerry WebWorks. Right now we have a separate API call which removes the sandbox and exposes the full file system via PERSISTENT. We provide constants for paths to things like application root, sd card and shared directories. Sandboxed file systems are rooted in a subdirectory of the application. That approach (plus our use of local:/// protocol) has caused some confusion with developers. I think the list of android constants would work well for BB10, perhaps with the addition of SHARED. I'm not too familiar with iOS and Android file systems. Is there a single directory which contains shared documents, music, etc? Thanks, Bryan On Tue, Feb 5, 2013 at 11:52 AM, Andrew Grieve agri...@chromium.org wrote: FYI - Still looking for feedback here! -- Forwarded message -- From: Andrew Grieve (JIRA) j...@apache.org Date: Tue, Feb 5, 2013 at 11:38 AM Subject: [jira] [Commented] (CB-285) Add property returning root path of PhoneGap files To: callback-...@incubator.apache.org [ https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571437#comment-13571437 ] Andrew Grieve commented on CB-285: -- I like the idea of switching PERSISTENT to be internal-only. The W3C spec intends this area to be sandboxed to the app, so shouldn't be on the sdcard. I think we need more than just an APP constant though, as there are many places where an app might want to put things. For iOS, You'd minimally want: 1. Application bundle, 2. Application_Home The other locations are all subdirectories of Application_Home, so not a big deal if we don't have constants for them For Android, You'd minimally want: 1. Assets directory (seems like a parallel to iOS Application Bundle) 2. Application data on internal storage (/data/data/$PACKAGE_NAME/files) 3. Application cache on internal storage (/data/data/$PACKAGE_NAME/cache) 4. External root: (/sdcard) We could maybe combine #2 and #3 into a single one that gave you /data/data/$PACKAGE_NAME, and document that Android wants files in the files and cache directories. The Ideal iOS constants: 1. PERSISTENT changes from Application_Home/Documents -- Application_Home/Library/CdvPersistentStorage 2. TEMPORARY changes from Application_Home/tmp -- Application_Home/tmp/CdvTemporaryStorage 3. APP_ASSETS -- Application bundle 4. APP_DATA -- Application_Home The main reason for changing #1 is that iCloud treats Documents directory specially The main reason for adding subdirs under Library/tmp is that it keeps the storage areas separate from the rest of the app (apps that have native components won't interfere with the webview's storage area). The ideal Android constants: 1. PERSISTENT -- /data/data/$PACKAGE_NAME/files/CdvPersistentStorage 2. TEMPORARY -- /data/data/$PACKAGE_NAME/cache/CdvTemporaryStorage 3. APP_ASSETS -- assets directory 4. APP_DATA -- /data/data/$PACKAGE_NAME 5. EXTERNAL_APP_DATA -- /sdcard/Android/data/$PACKAGE_NAME 6. EXTERNAL_ROOT -- /sdcard I even think there would be merit in adding more constants (e.g. DOCUMENTS, android resources) going forward, but one step at a time... == Transitioning to these new constants == TEMPORARY: Use the new path right away. No need to transition since the files there are temporary anyways. PERSISTENT (iOS): - If new location directory exists, use that. - Else, if any files exist in the legacy location, use the legacy location - Else, use the new path. PERSISTENT (Android): - PERSISTENT is currently /sdcard, so files will always exist :( In both
Re: Creating repos for core plugins
My only comment would be about media. Currently it just supports audio so perhaps codova-plugin-audio makes more sense and we can leave media open for the rewrite. Although, I do realize the api is labelled media so perhaps it would be too confusing to change the repo name. Just a thought. On Tue, Feb 5, 2013 at 1:38 PM, Andrew Grieve agri...@chromium.org wrote: Before I go ahead with this, let's agree upon the repo names / which plugins to include. Here's the proposed list: Repos to create: cordova-plugin-accelerometer cordova-plugin-battery cordova-plugin-camera cordova-plugin-capture cordova-plugin-compass cordova-plugin-contacts cordova-plugin-device cordova-plugin-file cordova-plugin-geolocation cordova-plugin-globalization cordova-plugin-logger cordova-plugin-media cordova-plugin-networkstatus cordova-plugin-notification cordova-plugin-splashscreen cordova-plugin-inappbrowser Note that I have device and network status in this list. Plugins that delay ondeviceready just add themselves to channel.deviceReadyChannelsArray. Plugins *not* getting their own Repo: blackberry/plugin/java/app android/plugin/android/app android/plugin/android/storage errgen/plugin/errgen ios/plugin/ios/console (seems like this should be merged into the logger plugin) windowsphone/plugin/windowsphone/DOMStorage windowsphone/plugin/windowsphone/XHRPatch windowsphone/plugin/windowsphone/console iOS's CDVLocalStorage.m On Tue, Feb 5, 2013 at 9:34 AM, Andrew Grieve agri...@chromium.org wrote: Great! Sounds like an agreement :). I'll file an INFRA to get them created. On Mon, Feb 4, 2013 at 9:44 PM, Shazron shaz...@gmail.com wrote: +1 on separate repos. It's the sane choice. On Mon, Feb 4, 2013 at 11:53 PM, Jesse purplecabb...@gmail.com wrote: +1, I agree on the separate repositories. I still contend that nothing should need to be 'built' and there should be NO dependencies on the plugins from cordova-js, ( aside from device.js + network.js which are both required pre device ready, and I think should remain in the cordova-js repo ) On Mon, Feb 4, 2013 at 2:46 PM, Anis KADRI anis.ka...@gmail.com wrote: +1 for separate repositories. Should take a bit longer than normal to package a release but not too long especially if the repos are pulled from a local source (ie no network overhead). I'd be ok to ship a set of default plugins and give the ability for people to build their 'own' Cordova. On Mon, Feb 4, 2013 at 2:11 PM, Brian LeRoux b...@brian.io wrote: I'm in favor of discreet plugin repos. It shouldn't effect a release if we automate install/remove and add to the Coho tool... though perhaps this is a naive assumption. On Mon, Feb 4, 2013 at 1:44 PM, Andrew Grieve agri...@chromium.org wrote: Thought it'd be worth having a discussion around whether we want a separate repo for each core plugin or not. As far as I can see, we can either have all core plugins in one repo, or have each in it's own and call them: cordova-plugin-file cordova-plugin-network cordova-plugin-media etc... I think my preference would be to have them as their own repos so that it will be easier to add/remove lists of plugins to the which ones are core list. It will also let us version them separately (if we want to do this). The downside is that it may take longer to perform a release? Would we even bundle the plugins with releases anyways though? -- @purplecabbage risingj.com
[jira] [Commented] (CB-285) Add property returning root path of PhoneGap files
[ https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571785#comment-13571785 ] Becky Gibson commented on CB-285: - OK, I can live with not using the Documents directory for PERSISTENT, although I think we should give devs a way to access it if they DO want to put user data in the documents dir - I guess access to application-home would give them that option. I don't know enough about Android to know if this works there or not! For the media object they can pass in documents://filename to store a recording there. I like your idea of requiring a full path name (or documents://) for the file name of the recording. However, one of the biggest complaints in CB-571 is the difference between iOS and Android. Currently iOS requires that the file exist (which is what I am changing) and Android does not. Android accepts just a filename and then stores it in: new File(/data/data/ + handler.cordova.getActivity().getPackageName() + /cache/ + file). Thus, the reason CB-571 has been open so long! I'll put this media specific stuff in that ticket for further conversation. Add property returning root path of PhoneGap files -- Key: CB-285 URL: https://issues.apache.org/jira/browse/CB-285 Project: Apache Cordova Issue Type: Improvement Components: CordovaJS Affects Versions: 1.4.0 Environment: Both PhoneGap SDK and PhoneGap Build Reporter: Ashley Gullen Assignee: Andrew Grieve Labels: features There needs to be a property in PhoneGap that returns the root path to the general files added to the PhoneGap project (i.e. the directory index.html is in). For example, if I add 'music.mp3' to my project, in Android it will be located in: /android_asset/www/music.mp3 On iOS after being built with PhoneGap Build it will be located in some path like this: /var/mobile/Applications/app_ID/name.app/www/music.mp3 However, there does not appear to be a programmatic way to determine both app_ID and name.app. This has two side effects: 1. Paths to audio for Media must be hard-coded separately depending on the platform, which is inconvenient. 2. Paths to audio for Media cannot be known if developing a framework that uses PhoneGap. Since a framework does not know the App ID or name in advance, it's impossible for the framework to determine the correct path. This is actively blocking audio from working on iOS in PhoneGap projects exported by Construct 2 (www.scirra.com), a HTML5 game creator. Also, it seems like kind of an important function to make available anyway, since hard-coding paths for each platform is a pain. This PhoneGap Support thread led to this issue: http://phonegap.tenderapp.com/discussions/questions/208-android_asset-equivalent-for-ios -- 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-1452) Media position incorrect after being set beyond duration
[ https://issues.apache.org/jira/browse/CB-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Becky Gibson updated CB-1452: - Fix Version/s: (was: 2.4.0) 2.5.0 Media position incorrect after being set beyond duration Key: CB-1452 URL: https://issues.apache.org/jira/browse/CB-1452 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 2.0.0 Reporter: Becky Gibson Assignee: Shazron Abdullah Priority: Minor Fix For: 2.5.0 While playing a media file, set the position to be greater than the duration of the file using the media.seekTo() api. This will properly stop the playing of the media. However, the media.position is set to the value beyond the duration. The media can not be played again until media.stop is called. This can be reproduced in the mobile spec manual audio test: 1) enter a value of 8 into the SeekBy/SeekTo input 2) press play to start the audio playing 3) press SeekBy button 4) press SeekBy button again to make new position greater than the 18 second duration. The media will stop playing 5) press the play button to play the media again - it will not play. You must first press stop to officially stop the media before it will play again. I'm not sure this is worth fixing since media will be overhauled. The fix is to set the currentTime to 0 in the mediaDidStopPlaying method. I also think that we should return a position of 0 from the seekToAudio method if the seekTo position is greater than the duration but I'm not sure what the other platforms are doing in this case. The other alternative is to return the requested position from seekToAudio (even if it is beyond the duration) and to set the MEDIA_POSITION to 0 from the mediaDidStopPlaying method. -- 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] [Assigned] (CB-571) Check that audio file recording to using Media.startRecord is of type .wav
[
https://issues.apache.org/jira/browse/CB-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Becky Gibson reassigned CB-571:
---
Assignee: Becky Gibson (was: Shazron Abdullah)
Check that audio file recording to using Media.startRecord is of type .wav
--
Key: CB-571
URL: https://issues.apache.org/jira/browse/CB-571
Project: Apache Cordova
Issue Type: Improvement
Components: iOS
Affects Versions: 1.6.1
Environment: iOS
Reporter: Ram Kulkarni
Assignee: Becky Gibson
Priority: Minor
Labels: ios, media
Fix For: 2.4.0
As we document in {{startRecord}} on our [docs
page|http://docs.phonegap.com/en/1.6.1/cordova_media_media.md.html#media.startRecord],
when recording audio in iOS, you need to make sure the file exists and that
it is of type .wav.
It would be nice if the {{startRecordingAudio}} method in CDVSound.m checked
that the requested file to record to is of the right type, and throw an error
if it is not.
--
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-571) Check that audio file recording to using Media.startRecord is of type .wav
[
https://issues.apache.org/jira/browse/CB-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Becky Gibson updated CB-571:
Fix Version/s: (was: 2.4.0)
2.5.0
Check that audio file recording to using Media.startRecord is of type .wav
--
Key: CB-571
URL: https://issues.apache.org/jira/browse/CB-571
Project: Apache Cordova
Issue Type: Improvement
Components: iOS
Affects Versions: 1.6.1
Environment: iOS
Reporter: Ram Kulkarni
Assignee: Becky Gibson
Priority: Minor
Labels: ios, media
Fix For: 2.5.0
As we document in {{startRecord}} on our [docs
page|http://docs.phonegap.com/en/1.6.1/cordova_media_media.md.html#media.startRecord],
when recording audio in iOS, you need to make sure the file exists and that
it is of type .wav.
It would be nice if the {{startRecordingAudio}} method in CDVSound.m checked
that the requested file to record to is of the right type, and throw an error
if it is not.
--
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] [Assigned] (CB-1452) Media position incorrect after being set beyond duration
[ https://issues.apache.org/jira/browse/CB-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Becky Gibson reassigned CB-1452: Assignee: Becky Gibson (was: Shazron Abdullah) Media position incorrect after being set beyond duration Key: CB-1452 URL: https://issues.apache.org/jira/browse/CB-1452 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 2.0.0 Reporter: Becky Gibson Assignee: Becky Gibson Priority: Minor Fix For: 2.5.0 While playing a media file, set the position to be greater than the duration of the file using the media.seekTo() api. This will properly stop the playing of the media. However, the media.position is set to the value beyond the duration. The media can not be played again until media.stop is called. This can be reproduced in the mobile spec manual audio test: 1) enter a value of 8 into the SeekBy/SeekTo input 2) press play to start the audio playing 3) press SeekBy button 4) press SeekBy button again to make new position greater than the 18 second duration. The media will stop playing 5) press the play button to play the media again - it will not play. You must first press stop to officially stop the media before it will play again. I'm not sure this is worth fixing since media will be overhauled. The fix is to set the currentTime to 0 in the mediaDidStopPlaying method. I also think that we should return a position of 0 from the seekToAudio method if the seekTo position is greater than the duration but I'm not sure what the other platforms are doing in this case. The other alternative is to return the requested position from seekToAudio (even if it is beyond the duration) and to set the MEDIA_POSITION to 0 from the mediaDidStopPlaying method. -- 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: ship 2.4 monday
Thanks, Andrew. I'm still having problems with the FileTransfer mobile spec tests. Based on what I see in the fileTransfer.tests.js file, I set my whitelist to the following in config.xml: access origin=http://www.google.com; / access origin=http://www.apache.org; subdomains=false/ access origin=https://www.apache.org; / access origin=http://cordova-filetransfer.jitsu.com; / access origin=http://whatheaders.com; / The goole reference is for the inAppBrowser tests. With this whitelist I get two failures both relating to unknown host testing: File Transfer download method should handle unknown host - the uploadWin success method is being called when it should not be. This is trying to download from http://foobar.apache.org/index.html;; which should be rejected because of the subdomains=false in the apache.org white list settings. I also get File Transfer upload method should handle unknown host error as well with the same error that 'uploadWin' should not have been called. Interestingly the whitelist error is caught but is returned in the success callback as the response. Now, if I remove the change to fix CB-2235 ( https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=commit;h=db22768362823bf6f84cbaead6c03dd1764f60b2) all of the FileTransfer tests pass. FWIW if I leave the whitelist wide open, I still get the FileTransfer download method should handle unknown host error that uploadWin is getting called - which probably makes sense since the subdomain to apache is allowed. However, I do not get the upload method should handle unknown host error which I think I should get!! Thus, 1) either my whitelist is incorrect 2) the fix is incorrect 3) the tests are incorrect 4) I am totally lost! (reading jasmine tests is not one of my strong suits) I am not an http headers guru so it will take me awhile to fully grok the file transfer code to determine the problem. -becky On Wed, Jan 30, 2013 at 10:23 AM, Andrew Grieve agri...@chromium.orgwrote: Okay, tagged JS, iOS, Android. https://dl.dropbox.com/u/6648754/cordova-2.4.0rc2/cordova-2.4.0rc2-src.zip https://dl.dropbox.com/u/6648754/cordova-2.4.0rc2/cordova-2.4.0rc2/cordova-js.zip https://dl.dropbox.com/u/6648754/cordova-2.4.0rc2/cordova-2.4.0rc2/cordova-ios.zip https://dl.dropbox.com/u/6648754/cordova-2.4.0rc2/cordova-2.4.0rc2/cordova-android.zip On Tue, Jan 29, 2013 at 10:35 PM, fabian boulegue fboule...@me.com wrote: Agree _ Fabian Boulegue tea inc. CEO - Founder Meierbrede 9 33100 Paderborn Mobile Am 29.01.2013 um 23:43 schrieb Shazron shaz...@gmail.com: Ah I get it now (Andrew's list of significant iOS commits) I suppose we could internally tag an rc2 (not public release) and test the heck out of it. Those iOS changes are critical bug fixes since rc1. On Tue, Jan 29, 2013 at 2:37 PM, Andrew Grieve agri...@chromium.org wrote: Okay, that wasn't entirely clear... I think we'd get pretty far by just tagging testing iOS Android, since most of the changes since rc1 relate to those two platforms. Agree? Given that we don't test before cutting an rc1, I think we should generally expect that we'll need to do an rc2 before shipping a release. On Tue, Jan 29, 2013 at 3:49 PM, Brian LeRoux b...@brian.io wrote: Andrew: sounds great. I'll talk to Shaz about doing a thoruough review of those commits/changes. Lets stay on course for 2.4 Monday. http://www.youtube.com/watch?v=NnP5iDKwuwk (Hopefully with a better outcome.---^) On Tue, Jan 29, 2013 at 2:41 PM, Andrew Grieve agri...@chromium.org wrote: I can tag JS iOS Android @ rc2 today. On Tue, Jan 29, 2013 at 3:33 PM, Becky Gibson gibson.be...@gmail.com wrote: would be nice if we could tag a cordova-js so we are all working off the same version On Tue, Jan 29, 2013 at 2:29 PM, fabian boulegue fboule...@me.com wrote: Even if its no change on official repo maybe we should test it in a small group...? _ Fabian Boulegue tea inc. CEO - Founder Meierbrede 9 33100 Paderborn Mobile Am 29.01.2013 um 20:27 schrieb Filip Maj f...@adobe.com: The reason we aimed for Monday is because we have various committers in transit atm and tagging is difficult today + tomorrow. On 1/29/13 11:20 AM, Steven Gill stevengil...@gmail.com wrote: Could we just tag iOS rc2 today and still aim to release 2.4.0 on Monday? People interested in testing could just work off the source. -Steve On Tue, Jan 29, 2013 at 11:14 AM, Andrew Grieve agri...@chromium.orgwrote: Changes of note: [CB-2235] Fixed file transfer whitelisting for iOS6. [CB-2290] iOS: 'CDVJSON.h' file not found when adding a plugin Fixed InAppBrowser becoming subject to the opener's whitelist Fixed InAppBrowser
Re: ship 2.4 monday
would be nice if we could tag a cordova-js so we are all working off the same version On Tue, Jan 29, 2013 at 2:29 PM, fabian boulegue fboule...@me.com wrote: Even if its no change on official repo maybe we should test it in a small group...? _ Fabian Boulegue tea inc. CEO - Founder Meierbrede 9 33100 Paderborn Mobile Am 29.01.2013 um 20:27 schrieb Filip Maj f...@adobe.com: The reason we aimed for Monday is because we have various committers in transit atm and tagging is difficult today + tomorrow. On 1/29/13 11:20 AM, Steven Gill stevengil...@gmail.com wrote: Could we just tag iOS rc2 today and still aim to release 2.4.0 on Monday? People interested in testing could just work off the source. -Steve On Tue, Jan 29, 2013 at 11:14 AM, Andrew Grieve agri...@chromium.orgwrote: Changes of note: [CB-2235] Fixed file transfer whitelisting for iOS6. [CB-2290] iOS: 'CDVJSON.h' file not found when adding a plugin Fixed InAppBrowser becoming subject to the opener's whitelist Fixed InAppBrowser not working on iOS5 On Android, I don't see any changes since the tag that warrant an rc2. On Tue, Jan 29, 2013 at 1:57 PM, Filip Maj f...@adobe.com wrote: I'll defer to Andrew's opinion as he has been hands-on with the iOS repo recently (at least more than I have). On 1/29/13 10:52 AM, fabian boulegue fboule...@me.com wrote: Well If we could commit a r2 soon I could let it been tested here, about the known issues. So we would stay on time. _ Fabian Boulegue tea inc. CEO - Founder Meierbrede 9 33100 Paderborn Mobile Am 29.01.2013 um 19:45 schrieb Filip Maj f...@adobe.com: I'm uncertain and worried that we'd slip to mid-Feb before releasing 2.4.0. On 1/29/13 10:38 AM, Andrew Grieve agri...@chromium.org wrote: There have been several fixes to iOS since rc1. I think this would warrant an rc2. On Tue, Jan 29, 2013 at 12:49 PM, Filip Maj f...@adobe.com wrote: We will go straight from 2.4.0rc1 to 2.4.0, unless contributors and committers think there are some unresolved issues left over from, or new ones introduced in, 2.4.0rc1 . On 1/29/13 9:39 AM, fabian boulegue fboule...@me.com wrote: So any update on release for r2? Am Jan 29, 2013 um 6:24 PM schrieb Giorgio Natili g.nat...@gnstudio.com : +1 On 1/28/13 8:11 PM, Brian LeRoux b...@brian.io wrote: remember: silence is assent!
[jira] [Resolved] (CB-2209) ARC issues in Contact
[ https://issues.apache.org/jira/browse/CB-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Becky Gibson resolved CB-2209. -- Resolution: Fixed Should be properly fixed this time: https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=commit;h=97e7c2c1f9736ed4be48a1278cf5ead57ad50d4b ARC issues in Contact -- Key: CB-2209 URL: https://issues.apache.org/jira/browse/CB-2209 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 2.3.0 Reporter: Becky Gibson Assignee: Becky Gibson Fix For: 2.4.0 Changing the __unsafe_unretained stack variables in contact.m to __weak exposes issues with the ARC conversion. See: https://groups.google.com/forum/?fromgroups=#!topic/phonegap/D9-7rmVojI4 -- 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: Testing 2.4.0rc1 on iOS - 2 possible failures
Actually, the FileTransfer error is different on the iPad running 5.1. The
same test is failing but the error is:
FileTransfer download method should handle unknown host.
Expected false to be true, downloadWin should not have been called. Got
args: []'.
I see the File Transfer errors using the tagged cordova-2.4.0rc1 or my own
built one. I'm not sure what I could have that is different? I guess I'll
wait for 2.4.0rc2 to see if my FileTransfer errors magically go away.
happy testing!
On Fri, Jan 25, 2013 at 3:51 PM, Max Woghiren m...@google.com wrote:
I'm not seeing the FileTransfer error on an iPad2 / iOS 6.0. I am seeing
the File error though.
On Fri, Jan 25, 2013 at 3:46 PM, Shazron shaz...@gmail.com wrote:
Thanks Becky,
http://ci.cordova.io/ confirms the blobConstructor error on iPad3,1
running
iOS 5.1
I don't have my other test devices here, they are back in SF, I'll be
able
to test further on Monday.
On Fri, Jan 25, 2013 at 12:36 PM, Becky Gibson gibson.be...@gmail.com
wrote:
I am getting one or two failures in the automatic tests on iOS. I
pulled
the lasted cordova-js, cordova-ios and cordova-mobile-spec. I built
the
cordova-2.4.0rc1.js file and am testing with that.
Using Xcode 4.5.2 I tested with the following 3 devices:
iPad running iOS 5.1.1
IPad 3 running iOS 6.01
iPhone 4S running iOS 6.01
FileTranser download method should handle unknown host:
Expected false to be true, downloadWin should not have been called.
Got
args: (0:{isFile:true, isDirectory:false, name:index.html,
fullPath:/var/mobile/Applications/uuid/Documents/index.html,
filesystem:null}}'.
Using Xcode 4.5.2 with an original iPad running iOS 5.1.1 in addition
to
the FileTransfer error I get a File error:
Automatic File tests:
File API Read method should be able to read native blob objects.
TypeError: [object BlobConstructor]' is not a constructor.
I also tested an iPad 2 running beta 6.1 using beta Xcode 4.5.2 and I
got
the same FileTransfer error.
I haven't looked into these errors, yet. Marcel does not see the
FileTransfer error so I will also test with the tagged version of
cordova-js rather than my version built from the master tip.
-becky
Re: Testing 2.4.0rc1 on iOS - 2 possible failures
My whitelist is at the default - wide open (access origin=* /)
That is an issue we need to discuss as some tests (manual inAppBrowser
tests come to mind) require specific whitelist settings.
On Fri, Jan 25, 2013 at 4:07 PM, Max Woghiren m...@google.com wrote:
What does your apache.org whitelist tag look like in your config.xml?
On Fri, Jan 25, 2013 at 4:01 PM, Becky Gibson gibson.be...@gmail.com
wrote:
Actually, the FileTransfer error is different on the iPad running 5.1.
The
same test is failing but the error is:
FileTransfer download method should handle unknown host.
Expected false to be true, downloadWin should not have been called. Got
args: []'.
I see the File Transfer errors using the tagged cordova-2.4.0rc1 or my
own
built one. I'm not sure what I could have that is different? I guess
I'll
wait for 2.4.0rc2 to see if my FileTransfer errors magically go away.
happy testing!
On Fri, Jan 25, 2013 at 3:51 PM, Max Woghiren m...@google.com wrote:
I'm not seeing the FileTransfer error on an iPad2 / iOS 6.0. I am
seeing
the File error though.
On Fri, Jan 25, 2013 at 3:46 PM, Shazron shaz...@gmail.com wrote:
Thanks Becky,
http://ci.cordova.io/ confirms the blobConstructor error on iPad3,1
running
iOS 5.1
I don't have my other test devices here, they are back in SF, I'll be
able
to test further on Monday.
On Fri, Jan 25, 2013 at 12:36 PM, Becky Gibson
gibson.be...@gmail.com
wrote:
I am getting one or two failures in the automatic tests on iOS. I
pulled
the lasted cordova-js, cordova-ios and cordova-mobile-spec. I
built
the
cordova-2.4.0rc1.js file and am testing with that.
Using Xcode 4.5.2 I tested with the following 3 devices:
iPad running iOS 5.1.1
IPad 3 running iOS 6.01
iPhone 4S running iOS 6.01
FileTranser download method should handle unknown host:
Expected false to be true, downloadWin should not have been
called.
Got
args: (0:{isFile:true, isDirectory:false,
name:index.html,
fullPath:/var/mobile/Applications/uuid/Documents/index.html,
filesystem:null}}'.
Using Xcode 4.5.2 with an original iPad running iOS 5.1.1 in
addition
to
the FileTransfer error I get a File error:
Automatic File tests:
File API Read method should be able to read native blob objects.
TypeError: [object BlobConstructor]' is not a constructor.
I also tested an iPad 2 running beta 6.1 using beta Xcode 4.5.2
and I
got
the same FileTransfer error.
I haven't looked into these errors, yet. Marcel does not see the
FileTransfer error so I will also test with the tagged version of
cordova-js rather than my version built from the master tip.
-becky
Re: No more activities from Cordova
Please note that this mailing list is for the discussion of the development of the Cordova API only. There is a Google group for discussing PhoneGap issues: https://groups.google.com/forum/?fromgroups=#!forum/phonegap. If you think you have found a bug please file it at http://issues.cordova.io with as many details as possible. thanks On Tue, Jan 22, 2013 at 10:57 AM, fabian boulegue fboule...@me.com wrote: Hi, i m building my first project with Cordova. I use it for iOS (6), i builded a app with inAppBrowser as well then some Notifications. From time to time, if i switched the pages and used some of the Browser and Notifications it comes to a point where no more activities by Cordova can be handle. If i then click on the Notification button nothing happens (also no console output) anyone a idea whats wrong (normally on first try all of the functions work great.) Would be great if someone could help, would also share my html and js if needed. Thanks Fabian
Review of Contacts API against W3C
I thought I would check the state of our Contacts API against the latest
W3C draft. At this point I don't think there are enough changes to warrant
modifying the Cordova APIs except maybe for search. We might consider
making search work better but I think at this point we are better off
waiting for the W3C to solidify the spec and decide what is happening with
Web Intents.
Here are the differences I noted in my review:
Current W3C Document just provides a Pick Intent. We can ignore the Web
Intent based changes for now and focus on the Contact objects and
behaviors. The only option now is pick which is just find. There is no
api for creating contacts but we can keep what we have implemented with
Contacts.create and Contacts.find.
Most of the Contact objects are the same. However the input to the pick
operation has changed. Instead of two parameters of fields and
ContactFindOptions, there is now the ContactIntentExtras Dictionary (
http://www.w3.org/TR/contacts-api/#idl-def-ContactIntentExtras) that
combines the previous options:
ContactIntentExtras {
DomString search,
Unsigned longlimit, // nullable
DomString[] fields
}
Thus, what used to be the find string in ContactFindOptions is now the
loosely defined search string and the boolean multiple is once again a
numeric limit. The interesting change is the definition for search:
search of type DOMString, nullable
A string which provides a hint to the contact service to facilitate
contacts selection by the user. The exact manner in which this hint is
exploited is entirely up to the contact service.
This gives us much more flexibility in implementing find. Previously, in
the December, 2010 draft, find was defined as the item to search for within
the specified fields (where fields were the field types that were returned
in the found contact(s)). We could add some rules to the search string to
allow people to search in specific fields rather than all of the returned
fields. We could use a simple format like:
searchTerm1, searchTerm2: searchField1, searchField2, … searchField#
This would allow limiting the search term(s) to one of more fields rather
than the entire fields array of items to be returned. Thus, to have all
name, address and phone number details returned for all contacts containing
Smith in the familyName field you could provide the following
ContentIntentExtras:
{search: Smith: name.familyName, limit: NULL, fields: [addresses,
name, phoneNumbers]}
Since the previous draft from June, 2011, does not spell out all the find
details, we could also implement something similar to this now using the
current ContactFindOptions.filter field.
In addition, the ContactError object has been modified to just contain a
DomString with the error message rather than previously defined error code.
Re: Getting Started (Android) feedback
I know I'm late to the party but I have some concerns about the idea of providing only command line instructions. I'm not sure what the plans are for detailed instructions but I'm not sure our current user base is going to be comfortable using the instructions currently in the readme in the cordova-cli repo. Don't get me wrong, I understand that the repo is for developers but I think we need to take a closer look at the current cordova user base and make a decision about what type of developer we want to support and how we want to support them. Then we can craft the correct type of useful documentation. Based on what I see in the PhoneGap group, many users are very naive and have limited hard-core development skills. Many are not familiar with IDE's let alone using the command line! Maybe that is not the user base we want to encourage? Perhaps we should be pushing those users to products built upon Cordova like IBM's Worklight or Adobe's Dreamweaver integration or others? We really should be considering our audience as we make changes that affect the installation and use of Cordova. I believe the goal of Cordova is to make building Mobile apps easier and we certainly have been pushing that idea at conferences. And we do tell people that you just need HTML and Web skills. Yes, it is difficult to keep the documentation up to date when there are so many changes but it should be considered as part of making and scheduling changes. In addition, I think that we may need to continue to provide some level of detail about installing prerequisites. For the IDEs there are generally fairly good installation documents available from other sources and we shouldn't try to replicate them. For iOS we can point to the instructions provided by Apple. For Eclipse we can hopefully find some third party instuctions or point to something at eclipse.org. Many of our users need this level of hand holding. However, point at nodejs.org and telling someone to install node could be daunting for some users - the nodejs site is really geared for developers, not end users! Ok, I'm rambling. The point I'm trying to make is I think we need to determine who the user base for Cordova really is, clearly spell that out in the wiki or home page and taylor our documentation and installation towards that user base. On Sun, Jan 20, 2013 at 9:12 AM, Andrew Grieve agri...@chromium.org wrote: Looking at the two guides right now, two things struck me as different: 1. Andrew's walks you through *how* to install all of the required tools, we just say which tools to install 2. Andrew's instructions go through the old way of setting up a project, which is now out of date. But! Once going through them, you get a pretty good idea of how Cordova works because he points out what all of the pieces do. E.g. the jar is the native side, the www is your code, the manifest is where your permissions go. As for #1, I think the short version we have in our guide is sufficient, and I don't like the idea of having it explained out more thoroughly step-by-step, because it's then more of a pain to keep up-to-date. I can see us doing more in the area of #2 though. E.g. have a separate guide that goes through all of the parts of an Android Cordova app, and points out which ones you may want to touch at some point. I also agree that it might make things more clear to separate out IDE instructions from the core command-line instructions. I don't think we should remove them though, since the IDE is the harder thing to figure out usually :P. Perhaps to tie in these external tutorials, we add a note at the bottom saying that if you still need help, to search for external tutorials / youtube walkthroughs / link to the user forums? We could also mention which versions of Cordova have had changes in steps, so that they don't follow old tutorials like the one that was pointed out. On Sat, Jan 19, 2013 at 12:42 PM, Shazron shaz...@gmail.com wrote: Just at a glance, I suppose his tutorial has more screenshots and steps. We could take the good and extract the incorrect and fix those I suppose. As for command line, that is definitely where we are going and if we remove Eclipse instructions (which third-party bloggers can fill the gap) we should point them to the alternative instructions. Which brings me to the next question -- should all platforms remove IDE specific instructions? There are some things in iOS currently that we can't do command line (at least with the current tools), for example deploy to device. On Sat, Jan 19, 2013 at 9:11 AM, Joe Bowser bows...@gmail.com wrote: Andrew Trice's tutorial is out of date and is technically wrong. The Android target for a project should always be set to the latest. I would agree with Don about not having Eclipse in our instructions, except that I don't have that much confidence in the command line tools on Windows to do that.
Re: Media APIs - some research and discussion
Interesting. The latest Editor's draft of the Web Intents spec ( https://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview-respec.html) is dated today. However, looking at the page source that could be an auto-generated date?? The Pick Content Intent editor's draft has a date of Jan. 18, 2013 ( http://w3c-test.org/dap/contacts/). Go Figure! On Mon, Jan 21, 2013 at 10:39 AM, Andrew Grieve agri...@chromium.orgwrote: Yeah, I believe that's the case as well. I'm not sure what the replacement is though :( On Mon, Jan 21, 2013 at 9:01 AM, Brian LeRoux b...@brian.io wrote: I think that spec is defunct and the functionality was removed from Chrome recently. =.( On Sun, Jan 20, 2013 at 10:29 PM, Simon MacDonald simon.macdon...@gmail.com wrote: Just reading everything over and looking at the way things are going it seems like we should get the Web Intents API implemented. Looks like there is already a shim implemented here: https://github.com/PaulKinlan/WebIntents with an APL license. Simon Mac Donald http://hi.im/simonmacdonald On Fri, Jan 18, 2013 at 4:20 PM, Becky Gibson gibson.be...@gmail.com wrote: I was looking at the open issues for iOS and found some related to capture/camera and media so I decided to see what the state of the latest W3C APIs are for these things. It wasn't a pleasant journey! There seem to be three apis that cover our camera/capture and media. Note that the referenced URLs are to the latest published draft although many have updated editor's drafts. - Pick Media Intent ( http://www.w3.org/TR/gallery/) Pick stored Media (images, audio, video) from various sources. - HTML Media Capture (http://www.w3.org/TR/html-media-capture/) - HTML form extension to allow user access to capture media from the device's via still camera, video, microphone via the File upload control. Appears to have replaced the Media Capture API ( http://www.w3.org/TR/2010/WD-capture-api-20100401/) since all links on that page to Latest Published Draft and Latest Editor's Draft refer the the HTML Media Capture spec and there is no longer any reference to the Media Capture API on the Device API working group page ( http://www.w3.org/2009/dap/) - Media Capture and Streams (http://www.w3.org/2009/dap/) Access to multi media streams (video camera, microphone, stored media) from a device. Thus, it seems that the Pick Media Intent would replace the Camera apis for selecting existing images and video. It would add the ability to pick from existing audio. Perhaps it is time to dive into the Web Intents spec and consider implementation HTML Media Capture allows capturing media but it is tied to the input element. It also provides for uploading the captured data. This seems to have replaced the Media Capture API that we implemented. I'm not sure how we can incorporate this into Cordova as there are no real apis, just attributes on the input element for the browser to implement and provide the UI. Although this seems to be the only W3C mechanism for accessing the still camera to capture an image! The Media Capture and Streams could replace our Media and Capture Video apis, but this is much more complicated. It also, in my opinion, doesn't seem all that well baked at the moment with a fair amount of open issues for defining some of the constants. Thus, I was a bit overwhelmed at how to address some of the Media and camera issues! I did discuss this briefly with Simon and was relieved that he was considering the HTML apis for media as our solution for Media ( http://www.position-absolute.com/articles/introduction-to-the-html5-audio-tag-javascript-manipulation/ ). Perhaps the best way to tackle our media is to normalize our media apis around the HTML Media apis. The point of this email? To capture my foray into the W3C Capture Apis and perhaps start a discussion on the next steps for Camera, Capture and Media apis. My next foray is into the changes to Contacts - this is now a Web Intent as well.
Re: mobile spec pass rate sizable drop on android
I can reliably reproduce that issue but only in the manual tests. I do have a local branch to fix it - the fix is pretty straightforward. I didn't do it when I filed the issue because we keep talking abt over hauling media. -becky Sent from my iPad On Jan 21, 2013, at 5:58 PM, Shazron shaz...@gmail.com wrote: I tested with the cordova-js 2.4.0rc1, and all tests pass. There is one intermittent failure though, relating to Media.position, which doesn't seem a blocker to me (see attached screenshot). Might be related to: https://issues.apache.org/jira/browse/CB-1452 On Mon, Jan 21, 2013 at 1:04 PM, Shazron shaz...@gmail.com wrote: I updated the cordova-js on iOS with cordova-js commit 1aa3643deaa9f14970806277d5f651f3cd78caa9 (the latest as of this email) and I got all the automatic tests to pass. I'll be doing more tests before I would consider a tag, probably later today. On Mon, Jan 21, 2013 at 10:07 AM, Filip Maj f...@adobe.com wrote: Hey everyone, Working over the weekend on the ci dashboard I noticed that the pass rate on android for mobile-spec dropped from ~95% to ~85%. It looks like the majority of failures are due to new tests for the File slice stuff that was added recently, perhaps also related to the Blob stuff. If you head to ci.cordova.io and click on the outer pie chart pieces (representing individual devices) you'll see a list of failures on particular devices. It looks like some of this stuff is failing on iOS too (there's a Blob constructor failure), but there is only one failure on iOS vs. 35+ on Android. Additionally, this is just on two platforms. Not sure what the situation is on BlackBerry, WP, and our other supported platforms, but I'm assuming no work was done on the new APIs for these platforms. Andrew/Michal/Braden you guys were working on this stuff, ya? Are we going to ship incomplete slice and blob implementations for 2.4.0rc1? I don't care if we do, but I do care about cross-platform parity for new features being shipped, and I'm concerned there is no plan for that with this new File API addition.
[jira] [Created] (CB-2229) whitelist docs state all domains are blocked by default - this is false
Becky Gibson created CB-2229: Summary: whitelist docs state all domains are blocked by default - this is false Key: CB-2229 URL: https://issues.apache.org/jira/browse/CB-2229 Project: Apache Cordova Issue Type: Bug Components: Docs Affects Versions: 2.3.0, 2.2.0 Reporter: Becky Gibson Assignee: Michael Brooks Fix For: 2.4.0 The Domain Whitelist Guide for 2.2 and 2.3 states: The default security policy is to block all network access. This is incorrect. In 2.2 it WAS true for iOS but not for Android nor BlackBerry. Both Android and BlackBerry do not block any domains in 2.2. In 2.3 Android, BlackBerry, and iOS do NOT block any domains. I didn't check all of the other platforms although in 2.3 the doc states that on Bada, Symbian, WebOS and Windows Phone, By default, all domains are accessible. -- 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: too long to package a release?
Am I correct in assuming US pacific time zone? Sent from my iPad On Jan 15, 2013, at 4:36 AM, Brian LeRoux b...@brian.io wrote: Works for me, however, to accommodate EU community we must to consider times unholy. This is Apache Way from what I understand. I created a form to help us pick a time to talk. http://goo.gl/h9d1a On Mon, Jan 14, 2013 at 7:06 PM, Michal Mocny mmo...@chromium.org wrote: Okay gentlemen, I think there have been countless good points made from all parties, but also some bike-shedding. Perhaps it is time to schedule some face-time to better articulate some of the finer points, and to help come to some consensus? -Michal On Mon, Jan 14, 2013 at 9:40 PM, Marcel Kinard cmarc...@gmail.com wrote: Sorry if this got asked before, but does a feature branch get deleted after it is merged? Just wondering about branch clutter over a long period, or if this is just the same as a topic branch using today's committer workflow. On 1/14/2013 5:34 PM, Brian LeRoux wrote: You work on a Feature branch. It gets rolled into Dev as needed so others can merge / collaborate on said feature. When it feels right instead of merging a large set of potentially breaking commits to Unstable the dev working on said feature just merges that feature. This would require more responsibility for the committer to keep track of their feature branches which I could see as being more overhead.
[jira] [Created] (CB-2209) ARC issues in Contact
Becky Gibson created CB-2209: Summary: ARC issues in Contact Key: CB-2209 URL: https://issues.apache.org/jira/browse/CB-2209 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 2.3.0 Reporter: Becky Gibson Assignee: Becky Gibson Fix For: 2.4.0 Changing the __unsafe_unretained stack variables in contact.m to __weak exposes issues with the ARC conversion. See: https://groups.google.com/forum/?fromgroups=#!topic/phonegap/D9-7rmVojI4 -- 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: Slicing files on iOS and Android
I put this in when we implemented the File APIs as it was the only way that I could get international /multi-byte characters to be supported. The implementation was way before iOS 5 so maybe the embedded browser or iOS internals have changed. -becky On Thu, Jan 10, 2013 at 11:26 AM, Braden Shepherdson bra...@chromium.orgwrote: Yes, that's one of the tests in mobile-spec, and it works fine without the escaping. On Thu, Jan 10, 2013 at 11:24 AM, Marcel Kinard cmarc...@gmail.com wrote: Can it pass non-ascii / multi-byte characters correctly without the escaping? On 1/10/2013 10:55 AM, Braden Shepherdson wrote: Becky, do you know why this escaping was originally put in place? From our investigations it is unnecessary on iOS 5.0, 5.1 and 6, so we can drop it, and the iOS-specific readAsText implementation. If no one can remember why it was there (its existence predates the porting to Apache repos, so I can't see the commit that added it) and it seems to pass all the tests, then I vote to remove this extra complexity. Braden
Re: Slicing files on iOS and Android
FYI - the W3C versions of the File API's was done back in April of 2011. Inquiring minds can see the history in my repo: https://github.com/becka11y/phonegap-iphone/blob/master/PhoneGapLib/Classes/File.m On Thu, Jan 10, 2013 at 12:12 PM, Becky Gibson gibson.be...@gmail.comwrote: I put this in when we implemented the File APIs as it was the only way that I could get international /multi-byte characters to be supported. The implementation was way before iOS 5 so maybe the embedded browser or iOS internals have changed. -becky On Thu, Jan 10, 2013 at 11:26 AM, Braden Shepherdson bra...@chromium.orgwrote: Yes, that's one of the tests in mobile-spec, and it works fine without the escaping. On Thu, Jan 10, 2013 at 11:24 AM, Marcel Kinard cmarc...@gmail.com wrote: Can it pass non-ascii / multi-byte characters correctly without the escaping? On 1/10/2013 10:55 AM, Braden Shepherdson wrote: Becky, do you know why this escaping was originally put in place? From our investigations it is unnecessary on iOS 5.0, 5.1 and 6, so we can drop it, and the iOS-specific readAsText implementation. If no one can remember why it was there (its existence predates the porting to Apache repos, so I can't see the commit that added it) and it seems to pass all the tests, then I vote to remove this extra complexity. Braden
Re: Slicing files on iOS and Android
The reason for encoding on iOS was to support international characters. The response from read as text is decoded in the iOS specific version of readAsText at https://github.com/apache/cordova-js/blob/master/lib/ios/plugin/ios/FileReader.js line 65. I wouldn't suspect that the all of the mobilespec file tests would pass with the encoding removed since there are tests to check for extended characters? Becky Sent from my iPad On Jan 7, 2013, at 6:30 PM, Braden Shepherdson bra...@chromium.org wrote: I've recently been implementing support for Blob.slice() for FileReader files (sort of). With real native File and Blob objects, they actually hold the binary data. Cordova File objects are just records passed to FileReaders. Regardless, the API for File.slice() is identical: it takes a start and optional end position, and returns a new File. Asking FileReader to fetch that new file will return just the specified segment of the file. Some examples are in order. Suppose the file we're reading contains the text: All that is gold does not glitter, not all those who wander are lost. Then f.slice(4, 8) would result in that f.slice(9) would be is gold does not glitter, not all those who wander are lost. f.slice(-5, -1) would be lost This is implemented on Android and iOS for both reading text and reading data URLs. It's straightforward to implement on other platforms, and I encourage maintainers of other platforms to add this. I'll be updating the docs tomorrow, including the following quirk on iOS. That quirk is that iOS encodes the response to readAsText using %-escapes, so that spaces become %20 and so on. This breaks a handful of spec tests including mine. It seems very puzzling, since a quick test with that encoding removed shows that all the specs are now passing. I didn't commit that, I just wanted to see if the bridge code would die horribly or something. This has been in the codebase as far back as Github's history goes (the name change to Cordova), so I was unable to discover the original reason for it. Shaz, Andrew, any idea what's going on here? Is this a relic of an old bridge that can be removed? I'm not sure whether this is a breaking change for iOS, since Android and presumably other platforms do not do this. Braden
Re: Correct spelling for Blackberry?
Sorry about the duplicate bug - I should have either have pulled master and rebuilt or checked the already filed tickets! On Wed, Jan 2, 2013 at 2:49 PM, Tim Kim timki...@gmail.com wrote: Ok cool :) On 2 January 2013 11:45, Becky Gibson gibson.be...@gmail.com wrote: Whatever works! I always forget how the docs magic works until I have to make a change. Thanks. On Wed, Jan 2, 2013 at 2:37 PM, Tim Kim timki...@gmail.com wrote: Oh - I created one already and fixed it. Do we actually need to rename the directory? I thought we just needed the list of headers in this file docs/en/edge/guide/getting-started/index.md needed to match the new spelling change. On 2 January 2013 11:29, Becky Gibson gibson.be...@gmail.com wrote: Ok, thanks, I've created a ticket in for the docs: https://issues.apache.org/jira/browse/CB-2106 -becky On Wed, Jan 2, 2013 at 2:26 PM, Ken Wallis kwal...@rim.com wrote: Confirmed, 'BlackBerry' -- Ken Wallis Product Manager – BlackBerry WebWorks Research In Motion (905) 629-4746 x14369 From: Filip Maj [f...@adobe.com] Sent: Wednesday, January 02, 2013 2:21 PM To: dev@cordova.apache.org Subject: Re: Correct spelling for Blackberry? I believe it is 'BlackBerry' ( ) On 1/2/13 11:17 AM, Becky Gibson gibson.be...@gmail.com wrote: Note that this commit, https://github.com/apache/cordova-docs/commit/7b1c42c4dd5aafb6e132830ed803 c3f161830656, to cordova-docs breaks the link to the blackberry file on the Getting Started page because it changes the case of the second b in BlackBerry. I didn't fix it because I'm not sure what the correct spelling is. -becky - 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. -- Timothy Kim -- Timothy Kim
Correct spelling for Blackberry?
Note that this commit, https://github.com/apache/cordova-docs/commit/7b1c42c4dd5aafb6e132830ed803c3f161830656, to cordova-docs breaks the link to the blackberry file on the Getting Started page because it changes the case of the second b in BlackBerry. I didn't fix it because I'm not sure what the correct spelling is. -becky
Re: Correct spelling for Blackberry?
Whatever works! I always forget how the docs magic works until I have to make a change. Thanks. On Wed, Jan 2, 2013 at 2:37 PM, Tim Kim timki...@gmail.com wrote: Oh - I created one already and fixed it. Do we actually need to rename the directory? I thought we just needed the list of headers in this file docs/en/edge/guide/getting-started/index.md needed to match the new spelling change. On 2 January 2013 11:29, Becky Gibson gibson.be...@gmail.com wrote: Ok, thanks, I've created a ticket in for the docs: https://issues.apache.org/jira/browse/CB-2106 -becky On Wed, Jan 2, 2013 at 2:26 PM, Ken Wallis kwal...@rim.com wrote: Confirmed, 'BlackBerry' -- Ken Wallis Product Manager – BlackBerry WebWorks Research In Motion (905) 629-4746 x14369 From: Filip Maj [f...@adobe.com] Sent: Wednesday, January 02, 2013 2:21 PM To: dev@cordova.apache.org Subject: Re: Correct spelling for Blackberry? I believe it is 'BlackBerry' ( ) On 1/2/13 11:17 AM, Becky Gibson gibson.be...@gmail.com wrote: Note that this commit, https://github.com/apache/cordova-docs/commit/7b1c42c4dd5aafb6e132830ed803 c3f161830656, to cordova-docs breaks the link to the blackberry file on the Getting Started page because it changes the case of the second b in BlackBerry. I didn't fix it because I'm not sure what the correct spelling is. -becky - 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. -- Timothy Kim
[jira] [Created] (CB-2109) update audio tests for changes to device properties
Becky Gibson created CB-2109: Summary: update audio tests for changes to device properties Key: CB-2109 URL: https://issues.apache.org/jira/browse/CB-2109 Project: Apache Cordova Issue Type: Bug Components: mobile-spec Affects Versions: 2.3.0 Reporter: Becky Gibson Assignee: Becky Gibson Fix For: 2.3.0 The manual audio test used device.platform to determine if running on blackberry or iOS in order to create the file for recording. The return value for device.platform has changed from iPad or iPhone to iOS so the test file must be updated. Not sure if BlackBerry needs to be updated as well? -- 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] [Commented] (CB-2109) update audio tests for changes to device properties
[ https://issues.apache.org/jira/browse/CB-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13542519#comment-13542519 ] Becky Gibson commented on CB-2109: -- Blackberry doesn't use device object so it should be fine. update audio tests for changes to device properties --- Key: CB-2109 URL: https://issues.apache.org/jira/browse/CB-2109 Project: Apache Cordova Issue Type: Bug Components: mobile-spec Affects Versions: 2.3.0 Reporter: Becky Gibson Assignee: Becky Gibson Fix For: 2.3.0 The manual audio test used device.platform to determine if running on blackberry or iOS in order to create the file for recording. The return value for device.platform has changed from iPad or iPhone to iOS so the test file must be updated. Not sure if BlackBerry needs to be updated as well? -- 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] [Resolved] (CB-2109) update audio tests for changes to device properties
[ https://issues.apache.org/jira/browse/CB-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Becky Gibson resolved CB-2109. -- Resolution: Fixed fixed with https://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=commit;h=dbd91a50eb990ae177deed22aa32707550b09679 update audio tests for changes to device properties --- Key: CB-2109 URL: https://issues.apache.org/jira/browse/CB-2109 Project: Apache Cordova Issue Type: Bug Components: mobile-spec Affects Versions: 2.3.0 Reporter: Becky Gibson Assignee: Becky Gibson Fix For: 2.3.0 The manual audio test used device.platform to determine if running on blackberry or iOS in order to create the file for recording. The return value for device.platform has changed from iPad or iPhone to iOS so the test file must be updated. Not sure if BlackBerry needs to be updated as well? -- 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: Issues with Mobile-spec on iOS
That might be it as I was testing the Misc Content Load another Apache Cordova Page in my mix of testing. Will play with that further tomorrow. thanks! On Wed, Jan 2, 2013 at 6:03 PM, Shazron shaz...@gmail.com wrote: The deviceready thing might be this issue: https://issues.apache.org/jira/browse/CB-2094 On Wed, Jan 2, 2013 at 2:59 PM, Becky Gibson gibson.be...@gmail.com wrote: I have been testing 2.3rc2 on my iPhone 4s and running into strange problems in mobile-spec. All of the automatic tests pass (although I do see an error about contacts not cleaning up in the log that I have to investigate). I seem to be able to run the manual tests, but then some of the tests stop working. I can hit back to get out of the test page and back to the menu but loading a new test page and pressing one of the buttons on to actually run a test will do nothing. And, sometimes if I go back to run the automatic tests again the page is blank except for the back link. In some ways it seems that deviceReady is not firing some of the time but I think most manual test pages have a timeout for that and display an alert. I'm not seeing an alert. At first I thought it might be some specific test that was jamming up the system but I haven't found a repeatable case. I thought it might be location because that wasn't working for me - but now it seems to be working. To try and duplicate run the automatic tests and then start running the manual tests. After a few tests, the manual ones seem to stop working. Notifications vibrate is a quick test to see if it has failed. I hope it is just gremlins on my device but I'm hoping someone else can take a look. I'll create a new project and test some more tomorrow. Note that I fixed a bug (CB-2109) in the manual audio test so be sure to pull master before running. -becky
Re: iOS Getting Started docs pull request
Thanks for the comments, Giorgio. I incorporated the first two. I didn't make changes to the JS example as I would rather not teach JavaScript best practices in the Getting Started guide. I just used the original simple example because I think this is what most people are familiar with. I have no objections if you want to modify this - although probably eaiser to wait until it is merged. -becky On Sun, Dec 30, 2012 at 6:56 AM, Giorgio Natili g.nat...@gnstudio.comwrote: Hi Becky, I added few comments... Giorgio On 12/29/12 10:26 PM, Becky Gibson gibson.be...@gmail.com wrote: This is a pretty big change so I'd appreciate another set of eyes on it before I commit: https://github.com/apache/cordova-docs/pull/2 thanks, -becky
iOS Getting Started docs pull request
This is a pretty big change so I'd appreciate another set of eyes on it before I commit: https://github.com/apache/cordova-docs/pull/2 thanks, -becky
Re: Updating Getting Started documents
Ok, thanks for the feedback. I'll work on updating for 2.3 and converting it to markdown over the holidays and post a pull request to give folks a chance to review. -becky On Thu, Dec 20, 2012 at 4:27 PM, Marcel Kinard cmarc...@gmail.com wrote: Some possibilities to bounce around: - collapse your detailed info into the existing Getting Started guides. Then there is a single guide per platform and the info isn't spread out across multiple places (even though it may be unevenly detailed across platforms). This implies markdown and cordova-docs. - rename the existing Getting Started guides into QuickStart guides, and your doc becomes a new longer Getting Started. Host it in cordova-docs, and it gets published to the docs site. This implies markdown and cordova-docs. - your doc becomes the long version of Getting Started. Could be hosted on apache.org, could be any format you want such as pdf. On 12/20/2012 3:37 PM, Becky Gibson wrote: I have an updated Getting Started document for iOS that has received favorable reviews. However, it is 11 pages long and fairly detailed. Personally, I like the detail. If it is structured well, users can skip anything they don't need. Does anyone think your detail is not useful or complicating? I'm not sure if we want to include that on the documentation site. I was thinking that we could leave the basic getting started on the documentation site with a link to the more involved document. Personally, I like having all the documentation in basically one place. Less fragmentation, easier to navigate, easier to keep consistent. Are there different audiences or circumstances in which having 2 forms of getting-started is valuable? My thought was to attach the more involved pdf to a page in the wiki but this doesn't keep it in source control. Is that an issue? Because docs assume a point-in-time reference to the functioning code (describing how it works), to me it makes sense to put the docs in one of the existing git repos. Then the docs and code are always sync'd. 1) should we include more involved documentation in the Getting started section of docs.phonegap.com? (I could possibly work on updating the Android version as well) Getting the same level of detail on other platforms would be goodness. Better educated users, smoother startup for them. 2) If we do want the more involved docs but not on the docs site, where should it live? I'd suggest defaulting to the docs site. Is there a reason it should be somewhere else? 3) what format - pdf, pages, doc? I'd suggest it depends on where the readable content it is hosted, and what kind of control you want on edits. Bottom line, I think Shaz's reply is spot on. Convert to markdown and put in cordova-docs. So then should your content be collapsed or separate from the existing Getting Started? I'd suggest collapsed. -- Marcel Kinard
Updating Getting Started documents
I have an updated Getting Started document for iOS that has received favorable reviews. However, it is 11 pages long and fairly detailed. I'm not sure if we want to include that on the documentation site. I was thinking that we could leave the basic getting started on the documentation site with a link to the more involved document. My thought was to attach the more involved pdf to a page in the wiki but this doesn't keep it in source control. Is that an issue? I used pages to write the doc and could export it to a Word format if necessary and commit it to source control. I'm interested to know what folks think as I will likely be able to work on this over the Holidays. The basic questions are: 1) should we include more involved documentation in the Getting started section of docs.phonegap.com? (I could possibly work on updating the Android version as well) 2) If we do want the more involved docs but not on the docs site, where should it live? 3) what format - pdf, pages, doc? 4) where should it be commited - cordova-docs, cordova-platform thanks, -becky
Re: mobile-spec failures on iOS 6.0.0
So, I thought the encoding was necessary for internationalization and any
special characters in the file data (for example a URL)? Do all of the other
file tests still run with this change? We're there any changes to the file
tests themselves? I try to take a look this afternoon.
- Becky
Sent from my iPad
On Dec 13, 2012, at 2:15 PM, Marcel Kinard cmarc...@gmail.com wrote:
Yup, I see that file-transfer.jitsu.com is returning a page saying:
An error has occurred:
{code:ECONNREFUSED,errno:ECONNREFUSED,syscall:connect}
Something is obviously dead there. So yeah, ignore those test failures as
an infrastructure problem.
Your File API failures look like the ones I was getting. If I modify
readAsText: from
messageAsString:[pNStrBuff
stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]
to
messageAsString:[NSString stringWithString:pNStrBuff]
then those failures disappear. So I'm still puzzled if it is really
supposed to be URL encoding the result message.
BTW, I noticed in your screenshot that your testsuite has 95 tests. Mine
has 238. Are we using the same version of mobile-spec?
-- Marcel
Re: incubator repos no more - remove the prefix in your git urls
Any idea how long this should take - it has been 3 days? thanks, -becky On Fri, Nov 23, 2012 at 5:52 AM, Jukka Zitting jukka.zitt...@gmail.comwrote: Hi, On Thu, Nov 22, 2012 at 8:33 PM, Simon MacDonald simon.macdon...@gmail.com wrote: Do we need to fix the mirrors at: https://github.com/apache I updated the mirrors at git.apache.org, and Github should pick up the changes shortly. Can we make sure pull requests to the new repo's on GitHub end up in our mailing list? I'll make sure the settings are correct once the mirrors show up on GitHub. BR, Jukka Zitting
Re: Updated iOS Getting Started Docs
Thanks, Shaz! I've updated and posted here: https://dl.dropbox.com/u/21698358/GSCordova22iOS.pdf -becky On Tue, Nov 20, 2012 at 7:01 PM, Shazron shaz...@gmail.com wrote: Thanks Becky! Looks great. Some comments: 1. Requirements -- we are moving this to a separate section in the docs, with the GS Guide referring to it. Your section here can be the basis for that new section. 2. Download Cordova. All urls should point to http://docs.cordova.ioinstead of http://docs.phonegap.com . When the time comes, that .io will re-direct to an Apache server instead of Adobe's. I know you mention this, but I think we should not mention PhoneGap in the Apache docs? Right now the downloads are: http://incubator.apache.org/cordova/#download but once we get the TLP server location up we would have an updated URL On Tue, Nov 20, 2012 at 12:53 PM, Becky Gibson gibson.be...@gmail.com wrote: Hmm, attachment must have been stripped by mail system? It's there in my sent folder. Here is a Dropbox link: https://www.dropbox.com/s/du3cujg8l408ptq/GSCordova22iOSApache.pdf Becky Sent from my iPad On Nov 20, 2012, at 2:20 PM, Shazron shaz...@gmail.com wrote: Ditto - it's all open source, open discussion - feel free :) Thanks for doing this, would like to read it once you post it. On Tue, Nov 20, 2012 at 10:59 AM, Filip Maj f...@adobe.com wrote: I don't have a problem with posting to google group. Also, there is no attachment :) On 11/20/12 7:40 AM, Becky Gibson gibson.be...@gmail.com wrote: I am taking a technical writing class and needed to produce a 5-10 page technical document. I elected to re-write the Getting Started for iOS Guide (attached). I wrote the document based on a new Mac and/or Xcode user. It may be more detailed than we want to publish with Cordova. I'd appreciate feedback on the document and would like to post if publicly for feedback via the PhoneGap google group if that does not pose any problems. I searched through the Apple Trademark info (http://www.apple.com/legal/trademark/guidelinesfor3rdparties.html) and believe I have given proper attribution within the document. However, the attribution varies when the document is distributed outside of the US. I used the United States references but I'm not sure what the Apache policy is? I also included a copyright notice at the end of the file with the Apache license. I did set it to copyright 2012 Becky Gibson but can remove my name if that is a problem. I'd appreciate any feedback on the document by November 28. Also, is something we would consider as part of the Cordova Docs? If so, what format or HTML template should I use (it would be tedious to convert this to markdown but probably not impossible). Please let me know about any concerns posting to the google group. thanks, -becky
Updated iOS Getting Started Docs
I am taking a technical writing class and needed to produce a 5-10 page technical document. I elected to re-write the Getting Started for iOS Guide (attached). I wrote the document based on a new Mac and/or Xcode user. It may be more detailed than we want to publish with Cordova. I'd appreciate feedback on the document and would like to post if publicly for feedback via the PhoneGap google group if that does not pose any problems. I searched through the Apple Trademark info ( http://www.apple.com/legal/trademark/guidelinesfor3rdparties.html) and believe I have given proper attribution within the document. However, the attribution varies when the document is distributed outside of the US. I used the United States references but I'm not sure what the Apache policy is? I also included a copyright notice at the end of the file with the Apache license. I did set it to copyright 2012 Becky Gibson but can remove my name if that is a problem. I'd appreciate any feedback on the document by November 28. Also, is something we would consider as part of the Cordova Docs? If so, what format or HTML template should I use (it would be tedious to convert this to markdown but probably not impossible). Please let me know about any concerns posting to the google group. thanks, -becky
Re: Updated iOS Getting Started Docs
Hmm, attachment must have been stripped by mail system? It's there in my sent folder. Here is a Dropbox link: https://www.dropbox.com/s/du3cujg8l408ptq/GSCordova22iOSApache.pdf Becky Sent from my iPad On Nov 20, 2012, at 2:20 PM, Shazron shaz...@gmail.com wrote: Ditto - it's all open source, open discussion - feel free :) Thanks for doing this, would like to read it once you post it. On Tue, Nov 20, 2012 at 10:59 AM, Filip Maj f...@adobe.com wrote: I don't have a problem with posting to google group. Also, there is no attachment :) On 11/20/12 7:40 AM, Becky Gibson gibson.be...@gmail.com wrote: I am taking a technical writing class and needed to produce a 5-10 page technical document. I elected to re-write the Getting Started for iOS Guide (attached). I wrote the document based on a new Mac and/or Xcode user. It may be more detailed than we want to publish with Cordova. I'd appreciate feedback on the document and would like to post if publicly for feedback via the PhoneGap google group if that does not pose any problems. I searched through the Apple Trademark info (http://www.apple.com/legal/trademark/guidelinesfor3rdparties.html) and believe I have given proper attribution within the document. However, the attribution varies when the document is distributed outside of the US. I used the United States references but I'm not sure what the Apache policy is? I also included a copyright notice at the end of the file with the Apache license. I did set it to copyright 2012 Becky Gibson but can remove my name if that is a problem. I'd appreciate any feedback on the document by November 28. Also, is something we would consider as part of the Cordova Docs? If so, what format or HTML template should I use (it would be tedious to convert this to markdown but probably not impossible). Please let me know about any concerns posting to the google group. thanks, -becky
Re: 2.3.0 major new features
Ok, this doesn't seem to be a little thing and it concerns me:
-iOS don't synthesize variables via properties since it causes them to not
show up in the debugger. With ARC, it is now just as convenient to use
fields as it is properties for private members anyways.
Can you explain this a bit better? Apple recommends using properties why
would be deviate from that? I haven't seen any issues debugging, can you
elaborate? Some example code would help to make sure we are all using the
same terms.
thanks,
-becky
On Tue, Nov 6, 2012 at 11:54 PM, Andrew Grieve agri...@chromium.org wrote:
Here's my list of things I want to see done / plan on doing:
Bigger things:
-Make the cordova/scripts sane for iOS and Android (CB-1668)
-iOS: Work on moving symbols that we don't want to be in our public API out
of header files (or into _private.h header files)
-Android: Work on making symbols private / package-private that we don't
want to be in our public API.
-Create a Google cordova plugin to provide OAuth2 for Google APIs via
gtm-oauth2 on iOS and AccountManager on Android.
Littler things:
-iOS don't synthesize variables via properties since it causes them to not
show up in the debugger. With ARC, it is now just as convenient to use
fields as it is properties for private members anyways.
-Create a helper function to reduce exec() param checking in the JS. e.g.
Instead of a bunch of if() blocks with throws / errBack calls, we'd have:
function(win, fail, num, str, func, opt_numOrString, opt_str) {
// n = number
// s = string
// f = function
// * = anything goes
// S = string or null or undefined (likewise, N and F)
checkedExec('nsf*S', win,fail,'Service', 'action',
[num,str,func,opt_numOrString, opt_str]);
}
Also note that both of Shaz's items would appear on this list if he hadn't
pointed them out already :)
On Tue, Nov 6, 2012 at 3:21 PM, Simon MacDonald
simon.macdon...@gmail.comwrote:
Sure, we've only been delaying it for about a year now, what's another
month.
Passive aggressiveness FTW!
Simon Mac Donald
http://hi.im/simonmacdonald
On Tue, Nov 6, 2012 at 3:17 PM, Shazron shaz...@gmail.com wrote:
I agree it's a mess. Seeing stuff on the iOS 2.3.0 plate perhaps we can
slate it for 2.4.0 -- but we can plan what needs to be done now I
suppose.
On Tue, Nov 6, 2012 at 6:42 AM, Simon MacDonald
simon.macdon...@gmail.comwrote:
The InAppBrowser would be great to have in 2.3.0.
Can we do a review of the Media API as well? It's a mess. Maybe we
can
just
fix the inconsistencies this release and look at a true Audio API
for a
future release.
Simon Mac Donald
http://hi.im/simonmacdonald
On Mon, Nov 5, 2012 at 7:16 PM, Shazron shaz...@gmail.com wrote:
I'd like to implement InAppBrowser in 2.3.0?
https://issues.apache.org/jira/browse/CB-1506
Also I'd like to migrate the Cordova.plist to config.xml for iOS:
https://issues.apache.org/jira/browse/CB-1108
