[android-developers] Re: Best practices for creating multiple app versions from a single codebase?
I think for many situations the SDK's library project mechanism solves the originally posted problem (without additional plug-ins, scripts, or the ant learning curve)... http://developer.android.com/intl/fr/guide/developing/eclipse-adt.html#libraryProject There is an ongoing thread in this group with more details: http://groups.google.com/group/android-developers/browse_thread/thread/b4a5d751346655b On May 22, 12:48 pm, Michael nicholls...@googlemail.com wrote: Hi Bob, I too would be very interested to hear how you have your build process setup. Ideally I would like to develop and debug with Eclipse, commit my code and then like you say, checkout a pristine copy and do production builds of paid and free versions with a script. If you get time to write it up, I think a number of us would be extremely greatfull. Cheers, Mike On May 7, 4:25 pm, Bob Kerns r...@acm.org wrote: I don't recommend doing production builds directly in your Eclipse environment. Export a copy, and modify that. In fact, I strongly urge checking out a pristine copy from revision control for real production builds. I derive my build numbers from the Eclipse revision I'm building. I inject that into the AndroidManifest.xml via an XSLT ant task. I've been meaning to write up my build practices for a while; I keep holding off for certain refinements, but I really should get to it soon, since it's a recurring issue for people. On May 4, 4:42 pm, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: Since you talk about a generated ant file tt sounds like you're project was created using the android tool instead of Eclipse. Is this correct? I spent most of today trying to get a non-eclipse project going and had some success up until debugging. I really wanted to use NetBeans but it looks like Eclipse is doing quite a bit under the hood for you when it comes to debugging. If you're using an Ant script for the main build, how are you using Eclipse with it? I wrote something to inc the version number and Eclipse really doesn't like the AndroidManifest.xml file touched. Leigh On 5/4/2010 4:36 PM, Alex (PS3 Friends) wrote: My solution was to create two different starter classes with different packages. One for the paid version and the other for the free version. Since the package name is used to identify the application in the market. You can use this to customize the app, by setting properties in the different start classes. I modified the generated Ant file to switch between the paid/free versions. I created a task that uses regular expression replacements, identifying sections and replacing the starting class name depending on what I am deploying in the manifest. You can even modify the XML layouts using this method. Essentially pre-processing prior to compilation. The R class is the only issue, you need to make sure you include an * import for both packages otherwise it won't work, and you will have to modify code each time. Also, Eclipse gets upset when you change things underneath it after compiling the R class, you need to delete the generated source directory. This is the best solution I have come up with so far, it's not great but it works for me and it is scripted. Alex On May 4, 3:01 pm, Tomáš Hubálektom.huba...@gmail.com wrote: I'm thinking about the same thing. I believe thathttp://code.google.com/p/maven-android-plugin/couldbe a solution. Maven is very powerful tool for building (we are using it for JEE projects) so I'm sure that it will support also multiple APKs from one source code base. But I didn't looked into details yet. Tom On 4 kvě, 20:37, E.Peld...@gmail.com wrote: Are there any viable approaches for creating multiple .APKs out of a single codebase? The apps may share the same code, but they could have different manifest files, different resources, or different external libraries (for example in an app with both free and paid versions, the free version could have a library for display ads). Ideally, this would be a single Eclipse project, with a way to specify which app to build/debug, and possibly a command line way to batch build everything. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email
Re: [android-developers] Re: Best practices for creating multiple app versions from a single codebase?
I just use an ANT script which reads some propeties and repackages classes, updates AndroidManifest.xml, updates some Java final variables, etc during the build depending on if it is full/pay or free/demo -Original message- From: jk-bk-vk jeffakna...@gmail.com To: Android Developers android-developers@googlegroups.com Sent: 2010 May, Sun, 23 15:55:09 GMT+00:00 Subject: [android-developers] Re: Best practices for creating multiple app versions from a single codebase? I think for many situations the SDK's library project mechanism solves the originally posted problem (without additional plug-ins, scripts, or the ant learning curve)... http://developer.android.com/intl/fr/guide/developing/eclipse-adt.html#libraryProject There is an ongoing thread in this group with more details: http://groups.google.com/group/android-developers/browse_thread/thread/b4a5d751346655b On May 22, 12:48 pm, Michael nicholls...@googlemail.com wrote: Hi Bob, I too would be very interested to hear how you have your build process setup. Ideally I would like to develop and debug with Eclipse, commit my code and then like you say, checkout a pristine copy and do production builds of paid and free versions with a script. If you get time to write it up, I think a number of us would be extremely greatfull. Cheers, Mike On May 7, 4:25 pm, Bob Kerns r...@acm.org wrote: I don't recommend doing production builds directly in your Eclipse environment. Export a copy, and modify that. In fact, I strongly urge checking out a pristine copy from revision control for real production builds. I derive my build numbers from the Eclipse revision I'm building. I inject that into the AndroidManifest.xml via an XSLT ant task. I've been meaning to write up my build practices for a while; I keep holding off for certain refinements, but I really should get to it soon, since it's a recurring issue for people. On May 4, 4:42 pm, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: Since you talk about a generated ant file tt sounds like you're project was created using the android tool instead of Eclipse. Is this correct? I spent most of today trying to get a non-eclipse project going and had some success up until debugging. I really wanted to use NetBeans but it looks like Eclipse is doing quite a bit under the hood for you when it comes to debugging. If you're using an Ant script for the main build, how are you using Eclipse with it? I wrote something to inc the version number and Eclipse really doesn't like the AndroidManifest.xml file touched. Leigh On 5/4/2010 4:36 PM, Alex (PS3 Friends) wrote: My solution was to create two different starter classes with different packages. One for the paid version and the other for the free version. Since the package name is used to identify the application in the market. You can use this to customize the app, by setting properties in the different start classes. I modified the generated Ant file to switch between the paid/free versions. I created a task that uses regular expression replacements, identifying sections and replacing the starting class name depending on what I am deploying in the manifest. You can even modify the XML layouts using this method. Essentially pre-processing prior to compilation. The R class is the only issue, you need to make sure you include an * import for both packages otherwise it won't work, and you will have to modify code each time. Also, Eclipse gets upset when you change things underneath it after compiling the R class, you need to delete the generated source directory. This is the best solution I have come up with so far, it's not great but it works for me and it is scripted. Alex On May 4, 3:01 pm, Tomáš Hubálektom.huba...@gmail.com wrote: I'm thinking about the same thing. I believe thathttp://code.google.com/p/maven-android-plugin/couldbe a solution. Maven is very powerful tool for building (we are using it for JEE projects) so I'm sure that it will support also multiple APKs from one source code base. But I didn't looked into details yet. Tom On 4 kvě, 20:37, E.Peld...@gmail.com wrote: Are there any viable approaches for creating multiple .APKs out of a single codebase? The apps may share the same code, but they could have different manifest files, different resources, or different external libraries (for example in an app with both free and paid versions, the free version could have a library for display ads). Ideally, this would be a single Eclipse project, with a way to specify which app to build/debug, and possibly a command line way to batch build everything. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email
[android-developers] Re: Best practices for creating multiple app versions from a single codebase?
Hi Bob, I too would be very interested to hear how you have your build process setup. Ideally I would like to develop and debug with Eclipse, commit my code and then like you say, checkout a pristine copy and do production builds of paid and free versions with a script. If you get time to write it up, I think a number of us would be extremely greatfull. Cheers, Mike On May 7, 4:25 pm, Bob Kerns r...@acm.org wrote: I don't recommend doing production builds directly in your Eclipse environment. Export a copy, and modify that. In fact, I strongly urge checking out a pristine copy from revision control for real production builds. I derive my build numbers from the Eclipse revision I'm building. I inject that into the AndroidManifest.xml via an XSLT ant task. I've been meaning to write up my build practices for a while; I keep holding off for certain refinements, but I really should get to it soon, since it's a recurring issue for people. On May 4, 4:42 pm, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: Since you talk about a generated ant file tt sounds like you're project was created using the android tool instead of Eclipse. Is this correct? I spent most of today trying to get a non-eclipse project going and had some success up until debugging. I really wanted to use NetBeans but it looks like Eclipse is doing quite a bit under the hood for you when it comes to debugging. If you're using an Ant script for the main build, how are you using Eclipse with it? I wrote something to inc the version number and Eclipse really doesn't like the AndroidManifest.xml file touched. Leigh On 5/4/2010 4:36 PM, Alex (PS3 Friends) wrote: My solution was to create two different starter classes with different packages. One for the paid version and the other for the free version. Since the package name is used to identify the application in the market. You can use this to customize the app, by setting properties in the different start classes. I modified the generated Ant file to switch between the paid/free versions. I created a task that uses regular expression replacements, identifying sections and replacing the starting class name depending on what I am deploying in the manifest. You can even modify the XML layouts using this method. Essentially pre-processing prior to compilation. The R class is the only issue, you need to make sure you include an * import for both packages otherwise it won't work, and you will have to modify code each time. Also, Eclipse gets upset when you change things underneath it after compiling the R class, you need to delete the generated source directory. This is the best solution I have come up with so far, it's not great but it works for me and it is scripted. Alex On May 4, 3:01 pm, Tomáš Hubálektom.huba...@gmail.com wrote: I'm thinking about the same thing. I believe thathttp://code.google.com/p/maven-android-plugin/couldbe a solution. Maven is very powerful tool for building (we are using it for JEE projects) so I'm sure that it will support also multiple APKs from one source code base. But I didn't looked into details yet. Tom On 4 kvě, 20:37, E.Peld...@gmail.com wrote: Are there any viable approaches for creating multiple .APKs out of a single codebase? The apps may share the same code, but they could have different manifest files, different resources, or different external libraries (for example in an app with both free and paid versions, the free version could have a library for display ads). Ideally, this would be a single Eclipse project, with a way to specify which app to build/debug, and possibly a command line way to batch build everything. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- Leigh McRaewww.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group
[android-developers] Re: Best practices for creating multiple app versions from a single codebase?
Here's how I did it, not sure if it is the best practice or the most efficient one. 1. Create an Android project from Eclipse, this will be used solely for developing paid version. 2. Create an ant script to copy the entire paid version to a separate directory that becomes the free version. 3. Use custom ant tasks like TextRewrite to replace package name, app name, etc from paid to free version. 4. Use a preprocessor ant task (I used prebop) to additionally inject ads code (or cripple features) into free version. 5. After all the injections, transformations, you can either build the free version from ant, or from Eclipse (Same goes for the paid version). Of course it's not as simple as it seems, even while developing for the paid version, I still need to make some classes aware of whether it is free or paid (e.g. DatabaseAdapter related). On May 7, 11:03 am, Greg Donald gdon...@gmail.com wrote: On Fri, May 7, 2010 at 12:13 PM, Alex (PS3 Friends) kludg...@gmail.com wrote: it also makes it easier to move from one machine to another if need be Just curious.. what problems have you ran into developing acrossmultiplemachines? I develop on both Win7 and Ubuntu Linux using git and I have zero issues related to moving back and forth between them. I have a .gitignore file that looks like this: *.apk .metadata .swp */bin/* */gen/* Works really well for me. -- Greg Donald destiney.com | gregdonald.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Best practices for creating multiple app versions from a single codebase?
I don't recommend doing production builds directly in your Eclipse environment. Export a copy, and modify that. In fact, I strongly urge checking out a pristine copy from revision control for real production builds. I derive my build numbers from the Eclipse revision I'm building. I inject that into the AndroidManifest.xml via an XSLT ant task. I've been meaning to write up my build practices for a while; I keep holding off for certain refinements, but I really should get to it soon, since it's a recurring issue for people. On May 4, 4:42 pm, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: Since you talk about a generated ant file tt sounds like you're project was created using the android tool instead of Eclipse. Is this correct? I spent most of today trying to get a non-eclipse project going and had some success up until debugging. I really wanted to use NetBeans but it looks like Eclipse is doing quite a bit under the hood for you when it comes to debugging. If you're using an Ant script for the main build, how are you using Eclipse with it? I wrote something to inc the version number and Eclipse really doesn't like the AndroidManifest.xml file touched. Leigh On 5/4/2010 4:36 PM, Alex (PS3 Friends) wrote: My solution was to create two different starter classes with different packages. One for the paid version and the other for the free version. Since the package name is used to identify the application in the market. You can use this to customize the app, by setting properties in the different start classes. I modified the generated Ant file to switch between the paid/free versions. I created a task that uses regular expression replacements, identifying sections and replacing the starting class name depending on what I am deploying in the manifest. You can even modify the XML layouts using this method. Essentially pre-processing prior to compilation. The R class is the only issue, you need to make sure you include an * import for both packages otherwise it won't work, and you will have to modify code each time. Also, Eclipse gets upset when you change things underneath it after compiling the R class, you need to delete the generated source directory. This is the best solution I have come up with so far, it's not great but it works for me and it is scripted. Alex On May 4, 3:01 pm, Tomáš Hubálektom.huba...@gmail.com wrote: I'm thinking about the same thing. I believe thathttp://code.google.com/p/maven-android-plugin/couldbe a solution. Maven is very powerful tool for building (we are using it for JEE projects) so I'm sure that it will support also multiple APKs from one source code base. But I didn't looked into details yet. Tom On 4 kvě, 20:37, E.Peld...@gmail.com wrote: Are there any viable approaches for creating multiple .APKs out of a single codebase? The apps may share the same code, but they could have different manifest files, different resources, or different external libraries (for example in an app with both free and paid versions, the free version could have a library for display ads). Ideally, this would be a single Eclipse project, with a way to specify which app to build/debug, and possibly a command line way to batch build everything. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- Leigh McRaewww.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Best practices for creating multiple app versions from a single codebase?
Hi, Bob. A description of best build practices would be pure gold to me. I'm nearing an application release (this month I hope) but have not yet ventured beyond building it with Eclipse. - Greg On May 7, 11:25 am, Bob Kerns r...@acm.org wrote: I don't recommend doing production builds directly in your Eclipse environment. Export a copy, and modify that. In fact, I strongly urge checking out a pristine copy from revision control for real production builds. I derive my build numbers from the Eclipse revision I'm building. I inject that into the AndroidManifest.xml via an XSLT ant task. I've been meaning to write up my build practices for a while; I keep holding off for certain refinements, but I really should get to it soon, since it's a recurring issue for people. On May 4, 4:42 pm, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: Since you talk about a generated ant file tt sounds like you're project was created using the android tool instead of Eclipse. Is this correct? I spent most of today trying to get a non-eclipse project going and had some success up until debugging. I really wanted to use NetBeans but it looks like Eclipse is doing quite a bit under the hood for you when it comes to debugging. If you're using an Ant script for the main build, how are you using Eclipse with it? I wrote something to inc the version number and Eclipse really doesn't like the AndroidManifest.xml file touched. Leigh On 5/4/2010 4:36 PM, Alex (PS3 Friends) wrote: My solution was to create two different starter classes with different packages. One for the paid version and the other for the free version. Since the package name is used to identify the application in the market. You can use this to customize the app, by setting properties in the different start classes. I modified the generated Ant file to switch between the paid/free versions. I created a task that uses regular expression replacements, identifying sections and replacing the starting class name depending on what I am deploying in the manifest. You can even modify the XML layouts using this method. Essentially pre-processing prior to compilation. The R class is the only issue, you need to make sure you include an * import for both packages otherwise it won't work, and you will have to modify code each time. Also, Eclipse gets upset when you change things underneath it after compiling the R class, you need to delete the generated source directory. This is the best solution I have come up with so far, it's not great but it works for me and it is scripted. Alex On May 4, 3:01 pm, Tomáš Hubálektom.huba...@gmail.com wrote: I'm thinking about the same thing. I believe thathttp://code.google.com/p/maven-android-plugin/couldbe a solution. Maven is very powerful tool for building (we are using it for JEE projects) so I'm sure that it will support also multiple APKs from one source code base. But I didn't looked into details yet. Tom On 4 kvě, 20:37, E.Peld...@gmail.com wrote: Are there any viable approaches for creating multiple .APKs out of a single codebase? The apps may share the same code, but they could have different manifest files, different resources, or different external libraries (for example in an app with both free and paid versions, the free version could have a library for display ads). Ideally, this would be a single Eclipse project, with a way to specify which app to build/debug, and possibly a command line way to batch build everything. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- Leigh McRaewww.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to
[android-developers] Re: Best practices for creating multiple app versions from a single codebase?
I agree with Bob on this, you should be able to build your system for release outside of Eclipse entirely, there should be no dependencies at all with that environment. A good way to set this up is to use a Continuous Integration Server like Hudson to do this. There are even Hudson plugins that allow you to tag releases in CVS and do some nice things. The nice thing about this, you will end up with a clean environment that Bob was talking about, and it also makes it easier to move from one machine to another if need be and helps you document and clean up your build. Alex On May 7, 12:08 pm, greg sep...@eduneer.com wrote: Hi, Bob. A description of best build practices would be pure gold to me. I'm nearing an application release (this month I hope) but have not yet ventured beyond building it with Eclipse. - Greg On May 7, 11:25 am, Bob Kerns r...@acm.org wrote: I don't recommend doing production builds directly in your Eclipse environment. Export a copy, and modify that. In fact, I strongly urge checking out a pristine copy from revision control for real production builds. I derive my build numbers from the Eclipse revision I'm building. I inject that into the AndroidManifest.xml via an XSLT ant task. I've been meaning to write up my build practices for a while; I keep holding off for certain refinements, but I really should get to it soon, since it's a recurring issue for people. On May 4, 4:42 pm, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: Since you talk about a generated ant file tt sounds like you're project was created using the android tool instead of Eclipse. Is this correct? I spent most of today trying to get a non-eclipse project going and had some success up until debugging. I really wanted to use NetBeans but it looks like Eclipse is doing quite a bit under the hood for you when it comes to debugging. If you're using an Ant script for the main build, how are you using Eclipse with it? I wrote something to inc the version number and Eclipse really doesn't like the AndroidManifest.xml file touched. Leigh On 5/4/2010 4:36 PM, Alex (PS3 Friends) wrote: My solution was to create two different starter classes with different packages. One for the paid version and the other for the free version. Since the package name is used to identify the application in the market. You can use this to customize the app, by setting properties in the different start classes. I modified the generated Ant file to switch between the paid/free versions. I created a task that uses regular expression replacements, identifying sections and replacing the starting class name depending on what I am deploying in the manifest. You can even modify the XML layouts using this method. Essentially pre-processing prior to compilation. The R class is the only issue, you need to make sure you include an * import for both packages otherwise it won't work, and you will have to modify code each time. Also, Eclipse gets upset when you change things underneath it after compiling the R class, you need to delete the generated source directory. This is the best solution I have come up with so far, it's not great but it works for me and it is scripted. Alex On May 4, 3:01 pm, Tomáš Hubálektom.huba...@gmail.com wrote: I'm thinking about the same thing. I believe thathttp://code.google.com/p/maven-android-plugin/couldbe a solution. Maven is very powerful tool for building (we are using it for JEE projects) so I'm sure that it will support also multiple APKs from one source code base. But I didn't looked into details yet. Tom On 4 kvě, 20:37, E.Peld...@gmail.com wrote: Are there any viable approaches for creating multiple .APKs out of a single codebase? The apps may share the same code, but they could have different manifest files, different resources, or different external libraries (for example in an app with both free and paid versions, the free version could have a library for display ads). Ideally, this would be a single Eclipse project, with a way to specify which app to build/debug, and possibly a command line way to batch build everything. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to
Re: [android-developers] Re: Best practices for creating multiple app versions from a single codebase?
On Fri, May 7, 2010 at 12:13 PM, Alex (PS3 Friends) kludg...@gmail.com wrote: it also makes it easier to move from one machine to another if need be Just curious.. what problems have you ran into developing across multiple machines? I develop on both Win7 and Ubuntu Linux using git and I have zero issues related to moving back and forth between them. I have a .gitignore file that looks like this: *.apk .metadata .swp */bin/* */gen/* Works really well for me. -- Greg Donald destiney.com | gregdonald.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Best practices for creating multiple app versions from a single codebase?
I am using the Eclipse tool also, I feel your pain with not being able to use Netbeans as natively as Eclipse, Eclipse is a great tool, just really used to Netbeans. It has been a while but I believe I created the project using the Eclipse tool. You can then create the ant script using the Android tool, and modify that and use that directly. I might have generated a test project and copied over the ant script. Sorry I can't remember the details, I only had to do it once and it has a been awhile. I just know the solution to the problem that E.P had with versioning, is easily solved with Ant. When you do modify anything outside of Eclipse, sometimes you need to delete the gen dir and Clean the project which should trigger a rebuild. That usually works. Alex On May 4, 7:42 pm, Leigh McRae leigh.mc...@lonedwarfgames.com wrote: Since you talk about a generated ant file tt sounds like you're project was created using the android tool instead of Eclipse. Is this correct? I spent most of today trying to get a non-eclipse project going and had some success up until debugging. I really wanted to use NetBeans but it looks like Eclipse is doing quite a bit under the hood for you when it comes to debugging. If you're using an Ant script for the main build, how are you using Eclipse with it? I wrote something to inc the version number and Eclipse really doesn't like the AndroidManifest.xml file touched. Leigh On 5/4/2010 4:36 PM, Alex (PS3 Friends) wrote: My solution was to create two different starter classes with different packages. One for the paid version and the other for the free version. Since the package name is used to identify the application in the market. You can use this to customize the app, by setting properties in the different start classes. I modified the generated Ant file to switch between the paid/free versions. I created a task that uses regular expression replacements, identifying sections and replacing the starting class name depending on what I am deploying in the manifest. You can even modify the XML layouts using this method. Essentially pre-processing prior to compilation. The R class is the only issue, you need to make sure you include an * import for both packages otherwise it won't work, and you will have to modify code each time. Also, Eclipse gets upset when you change things underneath it after compiling the R class, you need to delete the generated source directory. This is the best solution I have come up with so far, it's not great but it works for me and it is scripted. Alex On May 4, 3:01 pm, Tomáš Hubálektom.huba...@gmail.com wrote: I'm thinking about the same thing. I believe thathttp://code.google.com/p/maven-android-plugin/couldbe a solution. Maven is very powerful tool for building (we are using it for JEE projects) so I'm sure that it will support also multiple APKs from one source code base. But I didn't looked into details yet. Tom On 4 kvě, 20:37, E.Peld...@gmail.com wrote: Are there any viable approaches for creating multiple .APKs out of a single codebase? The apps may share the same code, but they could have different manifest files, different resources, or different external libraries (for example in an app with both free and paid versions, the free version could have a library for display ads). Ideally, this would be a single Eclipse project, with a way to specify which app to build/debug, and possibly a command line way to batch build everything. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- Leigh McRaewww.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to
Re: [android-developers] Re: Best practices for creating multiple app versions from a single codebase?
Thanks. I am surprised there isn't built in support for auto build numbers as it's very useful. Leigh On 5/5/2010 9:41 AM, Alex (PS3 Friends) wrote: I am using the Eclipse tool also, I feel your pain with not being able to use Netbeans as natively as Eclipse, Eclipse is a great tool, just really used to Netbeans. It has been a while but I believe I created the project using the Eclipse tool. You can then create the ant script using the Android tool, and modify that and use that directly. I might have generated a test project and copied over the ant script. Sorry I can't remember the details, I only had to do it once and it has a been awhile. I just know the solution to the problem that E.P had with versioning, is easily solved with Ant. When you do modify anything outside of Eclipse, sometimes you need to delete the gen dir and Clean the project which should trigger a rebuild. That usually works. Alex On May 4, 7:42 pm, Leigh McRaeleigh.mc...@lonedwarfgames.com wrote: Since you talk about a generated ant file tt sounds like you're project was created using the android tool instead of Eclipse. Is this correct? I spent most of today trying to get a non-eclipse project going and had some success up until debugging. I really wanted to use NetBeans but it looks like Eclipse is doing quite a bit under the hood for you when it comes to debugging. If you're using an Ant script for the main build, how are you using Eclipse with it? I wrote something to inc the version number and Eclipse really doesn't like the AndroidManifest.xml file touched. Leigh On 5/4/2010 4:36 PM, Alex (PS3 Friends) wrote: My solution was to create two different starter classes with different packages. One for the paid version and the other for the free version. Since the package name is used to identify the application in the market. You can use this to customize the app, by setting properties in the different start classes. I modified the generated Ant file to switch between the paid/free versions. I created a task that uses regular expression replacements, identifying sections and replacing the starting class name depending on what I am deploying in the manifest. You can even modify the XML layouts using this method. Essentially pre-processing prior to compilation. The R class is the only issue, you need to make sure you include an * import for both packages otherwise it won't work, and you will have to modify code each time. Also, Eclipse gets upset when you change things underneath it after compiling the R class, you need to delete the generated source directory. This is the best solution I have come up with so far, it's not great but it works for me and it is scripted. Alex On May 4, 3:01 pm, Tomáš Hubálektom.huba...@gmail.comwrote: I'm thinking about the same thing. I believe thathttp://code.google.com/p/maven-android-plugin/couldbe a solution. Maven is very powerful tool for building (we are using it for JEE projects) so I'm sure that it will support also multiple APKs from one source code base. But I didn't looked into details yet. Tom On 4 kvě, 20:37, E.Peld...@gmail.comwrote: Are there any viable approaches for creating multiple .APKs out of a single codebase? The apps may share the same code, but they could have different manifest files, different resources, or different external libraries (for example in an app with both free and paid versions, the free version could have a library for display ads). Ideally, this would be a single Eclipse project, with a way to specify which app to build/debug, and possibly a command line way to batch build everything. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- Leigh McRaewww.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Best practices for creating multiple app versions from a single codebase?
I'm thinking about the same thing. I believe that http://code.google.com/p/maven-android-plugin/ could be a solution. Maven is very powerful tool for building (we are using it for JEE projects) so I'm sure that it will support also multiple APKs from one source code base. But I didn't looked into details yet. Tom On 4 kvě, 20:37, E.P eld...@gmail.com wrote: Are there any viable approaches for creating multiple .APKs out of a single codebase? The apps may share the same code, but they could have different manifest files, different resources, or different external libraries (for example in an app with both free and paid versions, the free version could have a library for display ads). Ideally, this would be a single Eclipse project, with a way to specify which app to build/debug, and possibly a command line way to batch build everything. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Best practices for creating multiple app versions from a single codebase?
My solution was to create two different starter classes with different packages. One for the paid version and the other for the free version. Since the package name is used to identify the application in the market. You can use this to customize the app, by setting properties in the different start classes. I modified the generated Ant file to switch between the paid/free versions. I created a task that uses regular expression replacements, identifying sections and replacing the starting class name depending on what I am deploying in the manifest. You can even modify the XML layouts using this method. Essentially pre-processing prior to compilation. The R class is the only issue, you need to make sure you include an * import for both packages otherwise it won't work, and you will have to modify code each time. Also, Eclipse gets upset when you change things underneath it after compiling the R class, you need to delete the generated source directory. This is the best solution I have come up with so far, it's not great but it works for me and it is scripted. Alex On May 4, 3:01 pm, Tomáš Hubálek tom.huba...@gmail.com wrote: I'm thinking about the same thing. I believe thathttp://code.google.com/p/maven-android-plugin/could be a solution. Maven is very powerful tool for building (we are using it for JEE projects) so I'm sure that it will support also multiple APKs from one source code base. But I didn't looked into details yet. Tom On 4 kvě, 20:37, E.P eld...@gmail.com wrote: Are there any viable approaches for creating multiple .APKs out of a single codebase? The apps may share the same code, but they could have different manifest files, different resources, or different external libraries (for example in an app with both free and paid versions, the free version could have a library for display ads). Ideally, this would be a single Eclipse project, with a way to specify which app to build/debug, and possibly a command line way to batch build everything. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Best practices for creating multiple app versions from a single codebase?
Since you talk about a generated ant file tt sounds like you're project was created using the android tool instead of Eclipse. Is this correct? I spent most of today trying to get a non-eclipse project going and had some success up until debugging. I really wanted to use NetBeans but it looks like Eclipse is doing quite a bit under the hood for you when it comes to debugging. If you're using an Ant script for the main build, how are you using Eclipse with it? I wrote something to inc the version number and Eclipse really doesn't like the AndroidManifest.xml file touched. Leigh On 5/4/2010 4:36 PM, Alex (PS3 Friends) wrote: My solution was to create two different starter classes with different packages. One for the paid version and the other for the free version. Since the package name is used to identify the application in the market. You can use this to customize the app, by setting properties in the different start classes. I modified the generated Ant file to switch between the paid/free versions. I created a task that uses regular expression replacements, identifying sections and replacing the starting class name depending on what I am deploying in the manifest. You can even modify the XML layouts using this method. Essentially pre-processing prior to compilation. The R class is the only issue, you need to make sure you include an * import for both packages otherwise it won't work, and you will have to modify code each time. Also, Eclipse gets upset when you change things underneath it after compiling the R class, you need to delete the generated source directory. This is the best solution I have come up with so far, it's not great but it works for me and it is scripted. Alex On May 4, 3:01 pm, Tomáš Hubálektom.huba...@gmail.com wrote: I'm thinking about the same thing. I believe thathttp://code.google.com/p/maven-android-plugin/could be a solution. Maven is very powerful tool for building (we are using it for JEE projects) so I'm sure that it will support also multiple APKs from one source code base. But I didn't looked into details yet. Tom On 4 kvě, 20:37, E.Peld...@gmail.com wrote: Are there any viable approaches for creating multiple .APKs out of a single codebase? The apps may share the same code, but they could have different manifest files, different resources, or different external libraries (for example in an app with both free and paid versions, the free version could have a library for display ads). Ideally, this would be a single Eclipse project, with a way to specify which app to build/debug, and possibly a command line way to batch build everything. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- Leigh McRae www.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
