Re: storage
I'm trying to not sound like a broken record but I still do not hear an actual use cases that is unique to IndexedDB. I understand that you like it, I do too, and the browsers will support it eventually in Cordova so effort spent there is not really a demonstrable win (to me) unless I hear a use case for it not currently possible (if not more appropriate) for reading and writing plain old text, JSON, or Blobs. IndexedDB is a structured key/value store. Files have names (keys) and values. IndexedDB provides a non blocking async read/write. So does our File API. Transactional support is not built into our File API so that might be something you'd want if reads/writes could conflict. On Sun, Jan 5, 2014 at 10:02 AM, venkata kiran surapaneni svkir...@gmail.com wrote: +1 to Axel. Cordova is incomplete without providing support for indexeddb and websql. I think most of the apps require local database. There are some frameworks which provide different level of implementations. But those implementations are usually designed for browsers and then enhanced for mobile support and so has several limitations like not working when the application is switched to background. Cordova should have a uniform wrapper on top of indexeddb and websql to actually allow developers to create a cross platform apps, which is what Cordova promises.
Re: storage
The key win I think is simply having a consistent implementation. CanIUse reports that indexedDB is available on Android 4.4+ and every other of our supported platforms, with a very notable exception of Mobile Safari. Ultimately this is a plugin, and Parashuram is working on it, so I am sure he would appreciate help. To echo what Brian says, it is all currently possible, maybe just not as consistently as some would like, but ultimately Cordova is really just the bridge, the tools, and the container, so I don't think it is fair to call it incomplete ... and pull requests are always welcome. @purplecabbage risingj.com On Mon, Jan 6, 2014 at 9:43 AM, Brian LeRoux b...@brian.io wrote: I'm trying to not sound like a broken record but I still do not hear an actual use cases that is unique to IndexedDB. I understand that you like it, I do too, and the browsers will support it eventually in Cordova so effort spent there is not really a demonstrable win (to me) unless I hear a use case for it not currently possible (if not more appropriate) for reading and writing plain old text, JSON, or Blobs. IndexedDB is a structured key/value store. Files have names (keys) and values. IndexedDB provides a non blocking async read/write. So does our File API. Transactional support is not built into our File API so that might be something you'd want if reads/writes could conflict. On Sun, Jan 5, 2014 at 10:02 AM, venkata kiran surapaneni svkir...@gmail.com wrote: +1 to Axel. Cordova is incomplete without providing support for indexeddb and websql. I think most of the apps require local database. There are some frameworks which provide different level of implementations. But those implementations are usually designed for browsers and then enhanced for mobile support and so has several limitations like not working when the application is switched to background. Cordova should have a uniform wrapper on top of indexeddb and websql to actually allow developers to create a cross platform apps, which is what Cordova promises.
Re: Plugin Version Control Workflow
I've wanted to add Cordova plugin dependencies to the app's top-level config.xml for a long time, but it's never reached the top of my priorities. I think with that support, we can avoid checking in ./plugins/ and ./platforms altogether for 99% of app developers. If it doesn't solve anyone's use case, I'd love to hear about it. Braden On Tue, Dec 31, 2013 at 2:03 PM, Ross Gerbasi rgerb...@gmail.com wrote: CB-4624 is exactly what I am looking for. I am not sure if it should be config.xml or some other config file, it probably doesn't matter much when it comes down to it. Is there any rules currently in place, like CLI doesn't touch config.xml? On Tue, Dec 31, 2013 at 12:27 PM, Andrew Grieve agri...@chromium.org wrote: I think https://issues.apache.org/jira/browse/CB-4624 is the relevant issue here. Please add comments to it if it's not spec'ed or good enough. Also related is https://issues.apache.org/jira/browse/CB-5006 - meant to address local repos of plugins. On Tue, Dec 31, 2013 at 3:02 AM, Andrey Kurdumov kant2...@googlemail.com wrote: Hi all, Would be very helpful if you change formatting of the plugins manifest files (android.json, ios.json). Currently it is print all JSON string to the big single line, which difficult to merge when needed.
Re: IDE tweaks for CLI
The unfortunate part is that Eclipse and Xcode are also (more or less) the build systems for iOS and Android. You can build from CLI, and even deploy from the CLI if the stars align and you have your ruby slippers on the correct feet, but in practice most people are launching from IDEs. That makes it tempting to use them to edit the files in the project, when in fact one shouldn't be editing any of those files by hand, native or web. I'm glad to see some progress being made; this is easily the biggest user training problem faced by the CLI workflow. Braden On Thu, Jan 2, 2014 at 10:32 PM, Tommy Williams to...@devgeeks.org wrote: I'm with you, Brian... CLI for CLI, project scripts for IDEs. Anything else will just lead to madness.. On 03/01/2014 12:21 pm, Brian LeRoux b...@brian.io wrote: idk, if ppl want to use the cli I would reccomend using a text editor and our build chain if they want to use IDE's then they should not use the cli and just use the project scripts (at least, this was the intent of the design as I originally saw it) not sure I see much benefit to making the cli ultra configurable On Thu, Jan 2, 2014 at 4:10 PM, Andrew Grieve agri...@chromium.org wrote: We've had a bunch of users confused by Xcode and Eclipse showing only the output www/ and not the www/ that they are supposed to edit. There's bugs tracking addressing this for: iOS: https://issues.apache.org/jira/browse/CB-5397 Android: https://issues.apache.org/jira/browse/CB-5715 I've now taken a stab at addressing both of them through adding in references to the root www/, merges/ and config.xml for CLI projects (using a separate project template for normal vs CLI projects). For Xcode, the build still works fine if you delete the reference to the output www/, but I've left it in by default. For Eclipse, there's no such option. If anyone wants to give it a whirl provide feedback, that'd be great! Andrew
Re: IDE tweaks for CLI
I'm sorry, what problems do you really have with the CLI for building/deploying? I have none nor see any issues that require slippers. ;) When I train people about Cordova based dev I always teach them the CLI and to use a text editor. Most are using Sublime (not Xcode) and many are rolling into a Grunt workflow (not Ant!). I suspect the majority of people using IDE's are actually our committers and not the web community user base. On Mon, Jan 6, 2014 at 11:11 AM, Braden Shepherdson bra...@chromium.orgwrote: The unfortunate part is that Eclipse and Xcode are also (more or less) the build systems for iOS and Android. You can build from CLI, and even deploy from the CLI if the stars align and you have your ruby slippers on the correct feet, but in practice most people are launching from IDEs. That makes it tempting to use them to edit the files in the project, when in fact one shouldn't be editing any of those files by hand, native or web. I'm glad to see some progress being made; this is easily the biggest user training problem faced by the CLI workflow. Braden On Thu, Jan 2, 2014 at 10:32 PM, Tommy Williams to...@devgeeks.org wrote: I'm with you, Brian... CLI for CLI, project scripts for IDEs. Anything else will just lead to madness.. On 03/01/2014 12:21 pm, Brian LeRoux b...@brian.io wrote: idk, if ppl want to use the cli I would reccomend using a text editor and our build chain if they want to use IDE's then they should not use the cli and just use the project scripts (at least, this was the intent of the design as I originally saw it) not sure I see much benefit to making the cli ultra configurable On Thu, Jan 2, 2014 at 4:10 PM, Andrew Grieve agri...@chromium.org wrote: We've had a bunch of users confused by Xcode and Eclipse showing only the output www/ and not the www/ that they are supposed to edit. There's bugs tracking addressing this for: iOS: https://issues.apache.org/jira/browse/CB-5397 Android: https://issues.apache.org/jira/browse/CB-5715 I've now taken a stab at addressing both of them through adding in references to the root www/, merges/ and config.xml for CLI projects (using a separate project template for normal vs CLI projects). For Xcode, the build still works fine if you delete the reference to the output www/, but I've left it in by default. For Eclipse, there's no such option. If anyone wants to give it a whirl provide feedback, that'd be great! Andrew
Re: Moving www/config.xml - config.xml (within CLI)
1) Wouldn't it make more sense to default to the root config.xml if both are present? If you create a new project and import an old www project using a new CLI (--source or --link), you would get both configuration files (one at the root created by the template, and one inside your imported www). Wouldn't you expect to use the new config file in this case, perhaps with a warning to delete the old one? Not a big deal I guess if you have a warning in either case. 2) Do we want to rename config.xml to app.xml (or something else) to finally kill the confusion between platform config.xml vs project config.xml? On Fri, Jan 3, 2014 at 1:52 PM, Andrew Grieve agri...@chromium.org wrote: Looks like there's already a JIRA for this: https://issues.apache.org/jira/browse/CB-4910 On Thu, Jan 2, 2014 at 10:35 AM, Andrew Grieve agri...@chromium.org wrote: I'll make a JIRA issue on Tuesday and paste the link to it here. On Thu, Jan 2, 2014 at 10:32 AM, Ross Gerbasi rgerb...@gmail.com wrote: Did this make it to jira? I also think its a good idea to pull config.xml out of the www root. Anyway to track this one? On Mon, Dec 30, 2013 at 1:51 PM, Dick Van den Brink d_vandenbr...@outlook.com wrote: I think it is a a good idea! So a +1 Sent from my Windows Phone From: Axel Nennkermailto:ignisvul...@gmail.com Sent: 12/30/2013 20:47 To: devmailto:dev@cordova.apache.org Subject: Re: Moving www/config.xml - config.xml (within CLI) I support this proposal. When I started work on CB-2606 https://issues.apache.org/jira/browse/CB-2606I noticed that the element icon src=icon.png... / suggests that icons are put next to config.xml as well. When config.xml is in the project root it becomes more natural to put icons in project root/res/icons/platform/icon.png -Axel ps: I need opinions on my current implementation of CB-2606. https://github.com/AxelNennker/cordova-cli Please chime in to the email thread with the subject Started Implementing CB-2606 Add support for icon in config.xml 2013/12/30 Andrew Grieve agri...@chromium.org I thought this was previously discussed, but I can't find any JIRA issues or old emails about it. Proposal: For CLI projects: - Use www/config.xml if it exists - Otherwise use ./config.xml - Change the project template to use ./config.xml by default Reasons: - Paths in config.xml are relative to project root - Prevents a copy of config.xml ended up in platforms/*/www - Manifests are generally found at the top-level of projects. Sound good? If so I'll make an issue and work on this. Since it's holidays, will wait until next week Tuesday (Jan 7) to proceed. Andrew
Re: Moving www/config.xml - config.xml (within CLI)
1) Good point. Makes sense to me. 2) I think this is a tougher call. In on context, it does make more sense as app.xml, since config.xml is the thing you're generating as an output. OTOH, there are a lot of tutorials blog posts that say put FOO in your config.xml, and so renaming it would be confusing in this context. On Mon, Jan 6, 2014 at 11:30 AM, Michal Mocny mmo...@chromium.org wrote: 1) Wouldn't it make more sense to default to the root config.xml if both are present? If you create a new project and import an old www project using a new CLI (--source or --link), you would get both configuration files (one at the root created by the template, and one inside your imported www). Wouldn't you expect to use the new config file in this case, perhaps with a warning to delete the old one? Not a big deal I guess if you have a warning in either case. 2) Do we want to rename config.xml to app.xml (or something else) to finally kill the confusion between platform config.xml vs project config.xml? On Fri, Jan 3, 2014 at 1:52 PM, Andrew Grieve agri...@chromium.orgwrote: Looks like there's already a JIRA for this: https://issues.apache.org/jira/browse/CB-4910 On Thu, Jan 2, 2014 at 10:35 AM, Andrew Grieve agri...@chromium.org wrote: I'll make a JIRA issue on Tuesday and paste the link to it here. On Thu, Jan 2, 2014 at 10:32 AM, Ross Gerbasi rgerb...@gmail.com wrote: Did this make it to jira? I also think its a good idea to pull config.xml out of the www root. Anyway to track this one? On Mon, Dec 30, 2013 at 1:51 PM, Dick Van den Brink d_vandenbr...@outlook.com wrote: I think it is a a good idea! So a +1 Sent from my Windows Phone From: Axel Nennkermailto:ignisvul...@gmail.com Sent: 12/30/2013 20:47 To: devmailto:dev@cordova.apache.org Subject: Re: Moving www/config.xml - config.xml (within CLI) I support this proposal. When I started work on CB-2606 https://issues.apache.org/jira/browse/CB-2606I noticed that the element icon src=icon.png... / suggests that icons are put next to config.xml as well. When config.xml is in the project root it becomes more natural to put icons in project root/res/icons/platform/icon.png -Axel ps: I need opinions on my current implementation of CB-2606. https://github.com/AxelNennker/cordova-cli Please chime in to the email thread with the subject Started Implementing CB-2606 Add support for icon in config.xml 2013/12/30 Andrew Grieve agri...@chromium.org I thought this was previously discussed, but I can't find any JIRA issues or old emails about it. Proposal: For CLI projects: - Use www/config.xml if it exists - Otherwise use ./config.xml - Change the project template to use ./config.xml by default Reasons: - Paths in config.xml are relative to project root - Prevents a copy of config.xml ended up in platforms/*/www - Manifests are generally found at the top-level of projects. Sound good? If so I'll make an issue and work on this. Since it's holidays, will wait until next week Tuesday (Jan 7) to proceed. Andrew
Re: Moving .cordova/config.json - cordova.json
If we don't add a config.json by default, we need a new strategy for looking up paths for the root. I don't like naming the top-level config config.xml, but after some thoughts on it, I don't think we should rename it just right now. There are a lot of changes that would need to go along with that rename for it to make any sense. I also agree with Brian that what we really need is to step back and consider an entirely better solution rather than something incremental. Perhaps this is good subject matter for the next hangout / meet-up. -Michal On Fri, Jan 3, 2014 at 2:43 PM, Brian LeRoux b...@brian.io wrote: probably a good idea for the moment / at some we will have a config file reckoning! On Fri, Jan 3, 2014 at 11:34 AM, Andrew Grieve agri...@chromium.org wrote: Okay, yeah, reading that back to myself and it seems like a bad idea (config.xml-app.xml). Probably would just add to confusion. So, top-level config.xml and top-level cordova.json. Maybe I could add to this that we don't create a cordova.json by default, since 99% most people shouldn't need it. On Fri, Jan 3, 2014 at 2:31 PM, Brian LeRoux b...@brian.io wrote: actually, let me put this another way: I support .cordova/config.json - cordova.json but I am not really interested in changing the name of ./www/config.xml to ./www/app.xml ...feels to me we could consolidate this entire sitation with a single well crafted configuration file (at the top level). ideally we have more convention than configuration. feels like we have too many footguns to ease our personal dev workflows as is than consideration for people actually building apps. On Fri, Jan 3, 2014 at 11:25 AM, Brian LeRoux b...@brian.io wrote: Sorry, I completely do not understand this at all. The proposal is to change the name of config.xml to ease confusions and add a new top level config file? On Fri, Jan 3, 2014 at 11:15 AM, Andrew Grieve agri...@chromium.org wrote: Just spoke with Ian and I now understand his point about cordova.json being for build environment, whereas config.xml is for application things. So, do think it'd be bad to have a cordova.json and a config.xml right next to each other. How about: config.xml - app.xml - This will (hopefully) ease confusion about CLI's config.xml vs. platforms/ config.xml files. - E.g. we're adding icon splashscreen support to CLI's config.xml, but not for non-CLI config.xml files - E.g. app.xml and plugin.xml is where you make edits, config.xml is what's read at runtime. .cordova/config.json - cordova.json Also - JIRA for this is https://issues.apache.org/jira/browse/CB-4910 On Thu, Jan 2, 2014 at 4:10 PM, Brian LeRoux b...@brian.io wrote: I understood and read it too Gorkem. I was (poorly) suggesting we look at the issue of configuration in a complete view. Due to backwards compatibility we will be adding a new file and the code to support the old file will be around a while. We can probably roll a whole lot more into a single file. What Im not sure about is what should and should not be. On Thu, Jan 2, 2014 at 12:31 PM, Gorkem Ercan gorkem.er...@gmail.com wrote: Reducing the number of configuration files is actually the goal here. The abstraction is not a new one. It already exists and it is part of the $PROJECT/.cordova/config.json. I am suggesting to move it to $HOME/.cordova/config.json so that we no longer need the $PROJECT/.cordova/config.json and have only the cordova.xml to carry project specific properties. -- Gorkem On Thu, Jan 02, 2014 at 12:16:57PM -0800, Brian LeRoux wrote: Considering http://wiki.apache.org/cordova/ConfigurationFilesI'm not sure we want more config either. Perhaps we need to think more comprehensively rather than proposing more abstractions. On Thu, Jan 2, 2014 at 11:15 AM, Gorkem Ercan gorkem.er...@gmail.com wrote: I think what I will describe here is more that what CLI provides today. An engine/lib has a version, id and a uri. On most cases, you only care about the id and uri and assume that the tools that you work with already knows how to resolve the id and version to a location. In the case of CLI an engine with id: cordova and version:3.1.0 should be resolved to ~/.cordova/lib/ios/cordova/3.1.0 . If we have a uri defined that actually means we want to overwrite the default location for the engine. I think this redirection should be per
Re: IDE tweaks for CLI
I'm glad to hear people are having success with IDE-less workflows. I'm a vim guy through and through, and wish I didn't have to waste disk space or memory on Xcode or Eclipse. I need them for native debugging, I suppose. I have had a patchy history of trying to deploy to simulators and devices using the CLI commands, but it may be something about my setup (eg. my HTC One frequently drops out of the ADB devices list even though it's still plugged in) or that I have only used it occasionally across many CLI versions and my own patches and so on. If it's working for everyday users (I know it's working for our CI) then that's great. Braden On Mon, Jan 6, 2014 at 2:26 PM, Brian LeRoux b...@brian.io wrote: I'm sorry, what problems do you really have with the CLI for building/deploying? I have none nor see any issues that require slippers. ;) When I train people about Cordova based dev I always teach them the CLI and to use a text editor. Most are using Sublime (not Xcode) and many are rolling into a Grunt workflow (not Ant!). I suspect the majority of people using IDE's are actually our committers and not the web community user base. On Mon, Jan 6, 2014 at 11:11 AM, Braden Shepherdson bra...@chromium.org wrote: The unfortunate part is that Eclipse and Xcode are also (more or less) the build systems for iOS and Android. You can build from CLI, and even deploy from the CLI if the stars align and you have your ruby slippers on the correct feet, but in practice most people are launching from IDEs. That makes it tempting to use them to edit the files in the project, when in fact one shouldn't be editing any of those files by hand, native or web. I'm glad to see some progress being made; this is easily the biggest user training problem faced by the CLI workflow. Braden On Thu, Jan 2, 2014 at 10:32 PM, Tommy Williams to...@devgeeks.org wrote: I'm with you, Brian... CLI for CLI, project scripts for IDEs. Anything else will just lead to madness.. On 03/01/2014 12:21 pm, Brian LeRoux b...@brian.io wrote: idk, if ppl want to use the cli I would reccomend using a text editor and our build chain if they want to use IDE's then they should not use the cli and just use the project scripts (at least, this was the intent of the design as I originally saw it) not sure I see much benefit to making the cli ultra configurable On Thu, Jan 2, 2014 at 4:10 PM, Andrew Grieve agri...@chromium.org wrote: We've had a bunch of users confused by Xcode and Eclipse showing only the output www/ and not the www/ that they are supposed to edit. There's bugs tracking addressing this for: iOS: https://issues.apache.org/jira/browse/CB-5397 Android: https://issues.apache.org/jira/browse/CB-5715 I've now taken a stab at addressing both of them through adding in references to the root www/, merges/ and config.xml for CLI projects (using a separate project template for normal vs CLI projects). For Xcode, the build still works fine if you delete the reference to the output www/, but I've left it in by default. For Eclipse, there's no such option. If anyone wants to give it a whirl provide feedback, that'd be great! Andrew
Re: Moving .cordova/config.json - cordova.json
ya agreed, we should aim to do something early Feb once everyone is back into the the flow On Mon, Jan 6, 2014 at 11:59 AM, Michal Mocny mmo...@chromium.org wrote: If we don't add a config.json by default, we need a new strategy for looking up paths for the root. I don't like naming the top-level config config.xml, but after some thoughts on it, I don't think we should rename it just right now. There are a lot of changes that would need to go along with that rename for it to make any sense. I also agree with Brian that what we really need is to step back and consider an entirely better solution rather than something incremental. Perhaps this is good subject matter for the next hangout / meet-up. -Michal On Fri, Jan 3, 2014 at 2:43 PM, Brian LeRoux b...@brian.io wrote: probably a good idea for the moment / at some we will have a config file reckoning! On Fri, Jan 3, 2014 at 11:34 AM, Andrew Grieve agri...@chromium.org wrote: Okay, yeah, reading that back to myself and it seems like a bad idea (config.xml-app.xml). Probably would just add to confusion. So, top-level config.xml and top-level cordova.json. Maybe I could add to this that we don't create a cordova.json by default, since 99% most people shouldn't need it. On Fri, Jan 3, 2014 at 2:31 PM, Brian LeRoux b...@brian.io wrote: actually, let me put this another way: I support .cordova/config.json - cordova.json but I am not really interested in changing the name of ./www/config.xml to ./www/app.xml ...feels to me we could consolidate this entire sitation with a single well crafted configuration file (at the top level). ideally we have more convention than configuration. feels like we have too many footguns to ease our personal dev workflows as is than consideration for people actually building apps. On Fri, Jan 3, 2014 at 11:25 AM, Brian LeRoux b...@brian.io wrote: Sorry, I completely do not understand this at all. The proposal is to change the name of config.xml to ease confusions and add a new top level config file? On Fri, Jan 3, 2014 at 11:15 AM, Andrew Grieve agri...@chromium.org wrote: Just spoke with Ian and I now understand his point about cordova.json being for build environment, whereas config.xml is for application things. So, do think it'd be bad to have a cordova.json and a config.xml right next to each other. How about: config.xml - app.xml - This will (hopefully) ease confusion about CLI's config.xml vs. platforms/ config.xml files. - E.g. we're adding icon splashscreen support to CLI's config.xml, but not for non-CLI config.xml files - E.g. app.xml and plugin.xml is where you make edits, config.xml is what's read at runtime. .cordova/config.json - cordova.json Also - JIRA for this is https://issues.apache.org/jira/browse/CB-4910 On Thu, Jan 2, 2014 at 4:10 PM, Brian LeRoux b...@brian.io wrote: I understood and read it too Gorkem. I was (poorly) suggesting we look at the issue of configuration in a complete view. Due to backwards compatibility we will be adding a new file and the code to support the old file will be around a while. We can probably roll a whole lot more into a single file. What Im not sure about is what should and should not be. On Thu, Jan 2, 2014 at 12:31 PM, Gorkem Ercan gorkem.er...@gmail.com wrote: Reducing the number of configuration files is actually the goal here. The abstraction is not a new one. It already exists and it is part of the $PROJECT/.cordova/config.json. I am suggesting to move it to $HOME/.cordova/config.json so that we no longer need the $PROJECT/.cordova/config.json and have only the cordova.xml to carry project specific properties. -- Gorkem On Thu, Jan 02, 2014 at 12:16:57PM -0800, Brian LeRoux wrote: Considering http://wiki.apache.org/cordova/ConfigurationFilesI'm not sure we want more config either. Perhaps we need to think more comprehensively rather than proposing more abstractions. On Thu, Jan 2, 2014 at 11:15 AM, Gorkem Ercan gorkem.er...@gmail.com wrote: I think what I will describe here is more that what CLI provides today. An engine/lib has a version, id and a uri. On most cases, you only care about the id and uri and assume that the tools that you work with already knows how to resolve the id and version to a
Re: IDE tweaks for CLI
We've quibbled over this before. Regardless of your preference or philosophy, at least some users are choosing/expecting to use IDE's and then complaining about it. I'm all for removing the barriers to all-CLI all the time (I'm also a vim guy), but these changes significantly appease confusion for some subset of our users, don't break anything, don't add noticeable overhead, and have developer support.. so why wouldn't we endorse the improvements? -Michal On Mon, Jan 6, 2014 at 2:26 PM, Brian LeRoux b...@brian.io wrote: I'm sorry, what problems do you really have with the CLI for building/deploying? I have none nor see any issues that require slippers. ;) When I train people about Cordova based dev I always teach them the CLI and to use a text editor. Most are using Sublime (not Xcode) and many are rolling into a Grunt workflow (not Ant!). I suspect the majority of people using IDE's are actually our committers and not the web community user base. On Mon, Jan 6, 2014 at 11:11 AM, Braden Shepherdson bra...@chromium.org wrote: The unfortunate part is that Eclipse and Xcode are also (more or less) the build systems for iOS and Android. You can build from CLI, and even deploy from the CLI if the stars align and you have your ruby slippers on the correct feet, but in practice most people are launching from IDEs. That makes it tempting to use them to edit the files in the project, when in fact one shouldn't be editing any of those files by hand, native or web. I'm glad to see some progress being made; this is easily the biggest user training problem faced by the CLI workflow. Braden On Thu, Jan 2, 2014 at 10:32 PM, Tommy Williams to...@devgeeks.org wrote: I'm with you, Brian... CLI for CLI, project scripts for IDEs. Anything else will just lead to madness.. On 03/01/2014 12:21 pm, Brian LeRoux b...@brian.io wrote: idk, if ppl want to use the cli I would reccomend using a text editor and our build chain if they want to use IDE's then they should not use the cli and just use the project scripts (at least, this was the intent of the design as I originally saw it) not sure I see much benefit to making the cli ultra configurable On Thu, Jan 2, 2014 at 4:10 PM, Andrew Grieve agri...@chromium.org wrote: We've had a bunch of users confused by Xcode and Eclipse showing only the output www/ and not the www/ that they are supposed to edit. There's bugs tracking addressing this for: iOS: https://issues.apache.org/jira/browse/CB-5397 Android: https://issues.apache.org/jira/browse/CB-5715 I've now taken a stab at addressing both of them through adding in references to the root www/, merges/ and config.xml for CLI projects (using a separate project template for normal vs CLI projects). For Xcode, the build still works fine if you delete the reference to the output www/, but I've left it in by default. For Eclipse, there's no such option. If anyone wants to give it a whirl provide feedback, that'd be great! Andrew
Re: Moving www/config.xml - config.xml (within CLI)
After discussing this and reading the other thread (on config.json movement), I agree this is not the time for the rename. On Mon, Jan 6, 2014 at 2:58 PM, Andrew Grieve agri...@chromium.org wrote: 1) Good point. Makes sense to me. 2) I think this is a tougher call. In on context, it does make more sense as app.xml, since config.xml is the thing you're generating as an output. OTOH, there are a lot of tutorials blog posts that say put FOO in your config.xml, and so renaming it would be confusing in this context. On Mon, Jan 6, 2014 at 11:30 AM, Michal Mocny mmo...@chromium.org wrote: 1) Wouldn't it make more sense to default to the root config.xml if both are present? If you create a new project and import an old www project using a new CLI (--source or --link), you would get both configuration files (one at the root created by the template, and one inside your imported www). Wouldn't you expect to use the new config file in this case, perhaps with a warning to delete the old one? Not a big deal I guess if you have a warning in either case. 2) Do we want to rename config.xml to app.xml (or something else) to finally kill the confusion between platform config.xml vs project config.xml? On Fri, Jan 3, 2014 at 1:52 PM, Andrew Grieve agri...@chromium.orgwrote: Looks like there's already a JIRA for this: https://issues.apache.org/jira/browse/CB-4910 On Thu, Jan 2, 2014 at 10:35 AM, Andrew Grieve agri...@chromium.org wrote: I'll make a JIRA issue on Tuesday and paste the link to it here. On Thu, Jan 2, 2014 at 10:32 AM, Ross Gerbasi rgerb...@gmail.com wrote: Did this make it to jira? I also think its a good idea to pull config.xml out of the www root. Anyway to track this one? On Mon, Dec 30, 2013 at 1:51 PM, Dick Van den Brink d_vandenbr...@outlook.com wrote: I think it is a a good idea! So a +1 Sent from my Windows Phone From: Axel Nennkermailto:ignisvul...@gmail.com Sent: 12/30/2013 20:47 To: devmailto:dev@cordova.apache.org Subject: Re: Moving www/config.xml - config.xml (within CLI) I support this proposal. When I started work on CB-2606 https://issues.apache.org/jira/browse/CB-2606I noticed that the element icon src=icon.png... / suggests that icons are put next to config.xml as well. When config.xml is in the project root it becomes more natural to put icons in project root/res/icons/platform/icon.png -Axel ps: I need opinions on my current implementation of CB-2606. https://github.com/AxelNennker/cordova-cli Please chime in to the email thread with the subject Started Implementing CB-2606 Add support for icon in config.xml 2013/12/30 Andrew Grieve agri...@chromium.org I thought this was previously discussed, but I can't find any JIRA issues or old emails about it. Proposal: For CLI projects: - Use www/config.xml if it exists - Otherwise use ./config.xml - Change the project template to use ./config.xml by default Reasons: - Paths in config.xml are relative to project root - Prevents a copy of config.xml ended up in platforms/*/www - Manifests are generally found at the top-level of projects. Sound good? If so I'll make an issue and work on this. Since it's holidays, will wait until next week Tuesday (Jan 7) to proceed. Andrew
Re: IDE tweaks for CLI
On Mon, Jan 6, 2014 at 12:03 PM, Braden Shepherdson bra...@chromium.org wrote: I have had a patchy history of trying to deploy to simulators and devices using the CLI commands, but it may be something about my setup (eg. my HTC One frequently drops out of the ADB devices list even though it's still plugged in) or that I have only used it occasionally across many CLI versions and my own patches and so on. If it's working for everyday users (I know it's working for our CI) then that's great. This may be OT, but this sounds like a hardware problem. Does the USB Bus have enough power to support these devices? Is the MicroUSB cable connected properly? Seriously, MicroUSB is terrible since the ports will eventually wear out, and the plugs bend if you put any stress on them (i.e. Device Wall).
Re: IDE tweaks for CLI
(More OT: I've gone through my fourth damaged microUSB cable on this last road trip. They bend so easily in the car.) On Mon, Jan 6, 2014 at 3:17 PM, Joe Bowser bows...@gmail.com wrote: On Mon, Jan 6, 2014 at 12:03 PM, Braden Shepherdson bra...@chromium.org wrote: I have had a patchy history of trying to deploy to simulators and devices using the CLI commands, but it may be something about my setup (eg. my HTC One frequently drops out of the ADB devices list even though it's still plugged in) or that I have only used it occasionally across many CLI versions and my own patches and so on. If it's working for everyday users (I know it's working for our CI) then that's great. This may be OT, but this sounds like a hardware problem. Does the USB Bus have enough power to support these devices? Is the MicroUSB cable connected properly? Seriously, MicroUSB is terrible since the ports will eventually wear out, and the plugs bend if you put any stress on them (i.e. Device Wall).
Introductory Developer Email
Hello fellow Cordova Devs, I have been using PhoneGap / Cordova for about the last few years and love that the project is ever evolving. I would like to help contribute to the Cordova project as well to help give back some of what was freely given to myself. Some of my hobbies include mobile development (im guessing you already knew hybrid apps), coding in Ruby and Javascript, process automation, and speaking / mentoring others. I hope to be chatting with many of you and contributing on issues that I myself find or that others may have an urgent priority for. Thanks, and may we build a better future. -- Clear thoughts produce clear results. Josh Bavari Application Developer Phone: 405-509-9448 Cell: 405-812-0496 Email: jbav...@gmail.com
Re: Introductory Developer Email
Right on, welcome to the fray Josh. On Mon, Jan 6, 2014 at 3:31 PM, Anis KADRI anis.ka...@gmail.com wrote: Welcome Josh! On Mon, Jan 6, 2014 at 9:20 AM, Josh Bavari jbav...@gmail.com wrote: Hello fellow Cordova Devs, I have been using PhoneGap / Cordova for about the last few years and love that the project is ever evolving. I would like to help contribute to the Cordova project as well to help give back some of what was freely given to myself. Some of my hobbies include mobile development (im guessing you already knew hybrid apps), coding in Ruby and Javascript, process automation, and speaking / mentoring others. I hope to be chatting with many of you and contributing on issues that I myself find or that others may have an urgent priority for. Thanks, and may we build a better future. -- Clear thoughts produce clear results. Josh Bavari Application Developer Phone: 405-509-9448 Cell: 405-812-0496 Email: jbav...@gmail.com
Re: Plugin Version Control Workflow
About plugin and platform version control. I heard a lot about that, and confused why you think that everybody would like to remove ./plugins and ./platforms folders from source control. I do agree that this is most likely the case for the simple applications and for the maybe 99% of current Cordova users, but I don't believe that this is truly important for the Cordova as the ecosystem for the cross-platform of the mobile development. Let me explain why I think that keep ./platforms and ./plugins under source control very important. I would base my reasoning on my current project needs. I currently develop 2 similar products for different clients from the same domain. I understand that in future I will have another clients from same problem domain which would like to have similar applications, just with different design. So I take the route of having 1 product line and customization of that product line for each client, depends on their needs. This is client facing application, so I would like to cover as much mobile platforms as possible with minimum amount of efforts. Currently I support only Android and iOS platforms, but envision that my clients will expand to the Windows Phone soon, and maybe I will force them to support Tizen in next year if that platform would be world-wide popular. I position my self as a) heavy Cordova user b) middle/low platform specific development. (I have to go deep in each platform, but that's not priority for me as Cordova users) I maintain 3 Git branches. 1 branch for core product and 2 branches for each client. In each branch I keep, platform specific code for the application (cordova-platform-ios/android code), Cordova plugins code + plugins developed specifically to this application. I definitely sure that I will need to add some functionality to the core platforms, either iOS or Android which will benefit the my application. I would try to push to the core Cordova as much as I can, but possible that not all contribution would be useful for the Cordova. Either way I plan for update to next version of Cordova (3.4, or 3.5 whenether). To keep my changes, which I add to current version of Cordova (3.3) and make update to 3.4 and later easier I keep all code in the source control to make all my future merges easier. Same rules apply to the plugins,maybe I add some code/fixes to plugins, or not don't matter - I have to plan for that. I would like to contribute to Cordova everything what will benefit the community to meet my selfish goals: I want to make my upgrade path as straightforward as possible, for platform code and for plugins code. Maybe I was too verbose, but that was just to explain that I plan to align my long-term goals with Cordova's long-term goals. I try to gave more explanation, so you guys could plan not only for people which create projects which are working on the specific version of Cordova, but also for the guys which want to nurture their product together with Cordova. I plainly don't see: a) how I could work on my product not keeping ./platforms and ./plugins directories in the source control, and b) why I should don't use Cordova CLI to update contents of my ./platforms and ./plugins folders. I think that these tool has a good fit for basic housekeeping of the files/plugins. Don't want to manually fiddle with content of plugins for each platform and use plugman/cordova executables to do the job. Hopefully I was enough verbose to explain why I have needs what I have now, and not too verbose so you flood in details. To summarize my input is: 1. Keep tools that way, that it could work either when ./plugins, ./platforms in source control, or when these folders not in the VCS. 2. Take into account that people may want to customize Cordova distribution and have path to future upgrades. 3. I want to take responsibility for some burden which this way could potentially create for you guys, Andrey Kurdyumov. 2014/1/7 Braden Shepherdson bra...@chromium.org I've wanted to add Cordova plugin dependencies to the app's top-level config.xml for a long time, but it's never reached the top of my priorities. I think with that support, we can avoid checking in ./plugins/ and ./platforms altogether for 99% of app developers. If it doesn't solve anyone's use case, I'd love to hear about it. Braden On Tue, Dec 31, 2013 at 2:03 PM, Ross Gerbasi rgerb...@gmail.com wrote: CB-4624 is exactly what I am looking for. I am not sure if it should be config.xml or some other config file, it probably doesn't matter much when it comes down to it. Is there any rules currently in place, like CLI doesn't touch config.xml? On Tue, Dec 31, 2013 at 12:27 PM, Andrew Grieve agri...@chromium.org wrote: I think https://issues.apache.org/jira/browse/CB-4624 is the relevant issue here. Please add comments to it if it's not spec'ed or good enough. Also related is https://issues.apache.org/jira/browse/CB-5006 - meant to address local repos
Re: Plugin Version Control Workflow
Hi Andrey, I have worked on two small, simple Cordova applications, but we still at times had to modify platform specific code. Not much, but some (AppDelegate.m for the iOS app, and the DroidGap subclass for Android--this is a 2.9.x project for now). Here's my solutions to your issues. * if you need to modify native plugin code, you should fork the repo and manage your changes via a git project, not in your project. If you use a recent enough version of Cordova, you can even pull plugins off git branches ( see https://issues.apache.org/jira/browse/CB-4981 ) so you could have different versions of your apps for different clients pull different branches of the same plugin. * if you need to modify code under platforms, use an after_platform_add hook, and keep your customized platform files elsewhere in your project tree. This way, you aren't version controlling everything, just what you've had to change. Of course, when the Cordova platform changes underneath you (perhaps a new method is added to AppDelegate.m, and the version you have in source control overwrites that), you need to check these files carefully. But when you version control everything and you upgrade, you have to merge in your custom changes into the new Cordova code in the same careful manner, plus you are carrying around everything else under platforms. Of course, I'm a big believer in the CLI, having everyone use the entire CLI toolchain, and treating everything under platforms and plugins as derived code that you can replace at any time. If this isn't how you develop (if you prefer the 'native project dev' workflow, for example), then this may not work for you. Thanks. Dan PS Can you explain how keeping all the code in source control makes your merges as you move from Cordova version to Cordova version easier? To me, that would seem to make them more difficult. On Monday, January 6, 2014 5:38 PM, Andrey Kurdumov kant2...@googlemail.com wrote: About plugin and platform version control. I heard a lot about that, and confused why you think that everybody would like to remove ./plugins and ./platforms folders from source control. I do agree that this is most likely the case for the simple applications and for the maybe 99% of current Cordova users, but I don't believe that this is truly important for the Cordova as the ecosystem for the cross-platform of the mobile development. Let me explain why I think that keep ./platforms and ./plugins under source control very important. I would base my reasoning on my current project needs. I currently develop 2 similar products for different clients from the same domain. I understand that in future I will have another clients from same problem domain which would like to have similar applications, just with different design. So I take the route of having 1 product line and customization of that product line for each client, depends on their needs. This is client facing application, so I would like to cover as much mobile platforms as possible with minimum amount of efforts. Currently I support only Android and iOS platforms, but envision that my clients will expand to the Windows Phone soon, and maybe I will force them to support Tizen in next year if that platform would be world-wide popular. I position my self as a) heavy Cordova user b) middle/low platform specific development. (I have to go deep in each platform, but that's not priority for me as Cordova users) I maintain 3 Git branches. 1 branch for core product and 2 branches for each client. In each branch I keep, platform specific code for the application (cordova-platform-ios/android code), Cordova plugins code + plugins developed specifically to this application. I definitely sure that I will need to add some functionality to the core platforms, either iOS or Android which will benefit the my application. I would try to push to the core Cordova as much as I can, but possible that not all contribution would be useful for the Cordova. Either way I plan for update to next version of Cordova (3.4, or 3.5 whenether). To keep my changes, which I add to current version of Cordova (3.3) and make update to 3.4 and later easier I keep all code in the source control to make all my future merges easier. Same rules apply to the plugins,maybe I add some code/fixes to plugins, or not don't matter - I have to plan for that. I would like to contribute to Cordova everything what will benefit the community to meet my selfish goals: I want to make my upgrade path as straightforward as possible, for platform code and for plugins code. Maybe I was too verbose, but that was just to explain that I plan to align my long-term goals with Cordova's long-term goals. I try to gave more explanation, so you guys could plan not only for people which create projects which are working on the specific version of Cordova, but also for the guys which want to nurture their product together with Cordova. I plainly don't see: a) how I
Camera Usage Causes Memory Warnings
Hi, I'm hoping to get some help with the camera usage causing memory warnings and an eventual crashing of the application. I've filed a bug with details here: https://issues.apache.org/jira/browse/CB-5732
Re: Plugin Version Control Workflow
Hey Andrey, Much like you said 99% of the users will want to ignore platforms and plugins from version control. Making this work properly would not stop someone from including them if they wanted to. If your workflow is better including those folders you would have no problem doing so. Ideally though if you can keep your custom code off in plugins, even if they are not public plugins, would be ideal. Also as Dan mentioned you can look into hooks to help modify platforms as needed. Again though if you find checking everything in easier thats cool but the CLI should be setup in a way that we do not need to. On Mon, Jan 6, 2014 at 6:59 PM, Dan Moore moore...@yahoo.com wrote: Hi Andrey, I have worked on two small, simple Cordova applications, but we still at times had to modify platform specific code. Not much, but some (AppDelegate.m for the iOS app, and the DroidGap subclass for Android--this is a 2.9.x project for now). Here's my solutions to your issues. * if you need to modify native plugin code, you should fork the repo and manage your changes via a git project, not in your project. If you use a recent enough version of Cordova, you can even pull plugins off git branches ( see https://issues.apache.org/jira/browse/CB-4981 ) so you could have different versions of your apps for different clients pull different branches of the same plugin. * if you need to modify code under platforms, use an after_platform_add hook, and keep your customized platform files elsewhere in your project tree. This way, you aren't version controlling everything, just what you've had to change. Of course, when the Cordova platform changes underneath you (perhaps a new method is added to AppDelegate.m, and the version you have in source control overwrites that), you need to check these files carefully. But when you version control everything and you upgrade, you have to merge in your custom changes into the new Cordova code in the same careful manner, plus you are carrying around everything else under platforms. Of course, I'm a big believer in the CLI, having everyone use the entire CLI toolchain, and treating everything under platforms and plugins as derived code that you can replace at any time. If this isn't how you develop (if you prefer the 'native project dev' workflow, for example), then this may not work for you. Thanks. Dan PS Can you explain how keeping all the code in source control makes your merges as you move from Cordova version to Cordova version easier? To me, that would seem to make them more difficult. On Monday, January 6, 2014 5:38 PM, Andrey Kurdumov kant2...@googlemail.com wrote: About plugin and platform version control. I heard a lot about that, and confused why you think that everybody would like to remove ./plugins and ./platforms folders from source control. I do agree that this is most likely the case for the simple applications and for the maybe 99% of current Cordova users, but I don't believe that this is truly important for the Cordova as the ecosystem for the cross-platform of the mobile development. Let me explain why I think that keep ./platforms and ./plugins under source control very important. I would base my reasoning on my current project needs. I currently develop 2 similar products for different clients from the same domain. I understand that in future I will have another clients from same problem domain which would like to have similar applications, just with different design. So I take the route of having 1 product line and customization of that product line for each client, depends on their needs. This is client facing application, so I would like to cover as much mobile platforms as possible with minimum amount of efforts. Currently I support only Android and iOS platforms, but envision that my clients will expand to the Windows Phone soon, and maybe I will force them to support Tizen in next year if that platform would be world-wide popular. I position my self as a) heavy Cordova user b) middle/low platform specific development. (I have to go deep in each platform, but that's not priority for me as Cordova users) I maintain 3 Git branches. 1 branch for core product and 2 branches for each client. In each branch I keep, platform specific code for the application (cordova-platform-ios/android code), Cordova plugins code + plugins developed specifically to this application. I definitely sure that I will need to add some functionality to the core platforms, either iOS or Android which will benefit the my application. I would try to push to the core Cordova as much as I can, but possible that not all contribution would be useful for the Cordova. Either way I plan for update to next version of Cordova (3.4, or 3.5 whenether). To keep my changes, which I add to current version of Cordova (3.3) and make update to 3.4 and later easier I keep all code in the source control to make all my future
Re: Introductory Developer Email
Awesome! Welcome to the team! On Mon, Jan 6, 2014 at 3:40 PM, Brian LeRoux b...@brian.io wrote: Right on, welcome to the fray Josh. On Mon, Jan 6, 2014 at 3:31 PM, Anis KADRI anis.ka...@gmail.com wrote: Welcome Josh! On Mon, Jan 6, 2014 at 9:20 AM, Josh Bavari jbav...@gmail.com wrote: Hello fellow Cordova Devs, I have been using PhoneGap / Cordova for about the last few years and love that the project is ever evolving. I would like to help contribute to the Cordova project as well to help give back some of what was freely given to myself. Some of my hobbies include mobile development (im guessing you already knew hybrid apps), coding in Ruby and Javascript, process automation, and speaking / mentoring others. I hope to be chatting with many of you and contributing on issues that I myself find or that others may have an urgent priority for. Thanks, and may we build a better future. -- Clear thoughts produce clear results. Josh Bavari Application Developer Phone: 405-509-9448 Cell: 405-812-0496 Email: jbav...@gmail.com
