I have built an application that I want to use as the foundation for a few other variants. The variants will come from assets / resource files and a unique AndroidManifest.xml. However, I want to be able to leave all the application code alone (modifying the package of all my classes, etc). I'm having a hard time figuring out how to do so.
My first thought was to simply have my main application in its own package, and then specify the specific application package in the manifest. However, this gives me issues with the generated R.java class, since it is generated to be in the main application's package.
Anyone have any thoughts on how to accomplish this? To have a code baseline, and the application variants happen in resources/assets and the manifest?
You can look at the new Android library project system, which is designed at least in part for your scenario. However, this appears to require Eclipse, which you may or may not be using.
You can also look at the Android Parcel Project for ideas, though that is more designed for reusable components than your specific use case.
Related
Currently I am working on an application aimed to small local businesses, which serves as a template for other applications (other stores). The base application allows local stores to send notifications to their customers, depending on the business context, notifications can be to report promotions, inform a client that he can pick up his order at the store, notices of new products in the store, etc ... What I do is work on the template for each client and then customize the appearance of the application in the background but the functionality is the same for everyone. My problem is that every time we have more businesses interested in the application and the problem arises when I find bugs or want further improvements, and to update the code in each of the applications can be hell (open each project, add the lines code, recompile, etc ...), and also publish new applications involves a great job because I have to change namespaces whole project, change the authority of the content provider, update references to the namespace associated with the template, etc. ...
Is there any way that I provide update and / or add portions of code in the original template and the changes are automatically reflected in all projects generated from the template?
I have understood Apache Ant can help with the compiling process of large project with many dependencies, but could be useful in the context of my problem?
The solution that I can think of right now is to create a project library and then put everything common to projects, including resources and Activities. The problem is that for example the application Content Provider could not go there because I need to have a single authority in the Manifiest defined for each application.
In advance thank you very much for taking the time to read my message. Any help or advice is welcome. Thank you again.
My question is there any way that I provide update and / or add portions of code in the original template and the changes are automatically reflected in all projects generated from the template?
Make the core code be an Android library project, and use that library project in all the customer apps.
The solution that I can think of right now is to create a project library and then put everything common to projects, including resources and Activities.
Correct.
The problem is that for example the application Content Provider could not go there because I need to have a single authority in the Manifiest defined for each application.
Your ContentProvider implementation can go in the library project. Your customer-specific project will need the <provider> element in the manifest, with a unique authority, pointing to the ContentProvider class from the library.
I have a single android app with a custom logo, some custom json service endpoints, occasional custom text, and possibly a custom color scheme.
For my client this particular app will need to be rebranded and distributed as an entirely different app about 5-10 times over. So I'm looking for way to reuse the most amount of code - the activities and services will be identical except for the custom things I mentioned.
First off, how can I share projects in the sense that one project will hold all code (including activities), and the others just modify a few values. I can't think of a smart way to share both service code and activity code with the occasional value thrown in via properties.
Do android layout/string resource files have the ability to pull from properties? Can activities be bundled inside a jar and shared with other projects?
You can use Android library project to share the common code. Start by reading this article
You do not have to have different java namespaces, they can be common for all projects. All you need is to replace resources and modify manifest to contain different namespace for each application. There is no problem with several applications having the same name of classes inside. Unless you want to rebrand it all the way user could not find it is actually the same code, of course.
Since it's popular to have both a free and a paid version in the android market of the same app, I had decided to do the same. Initially I just duplicated the complete codebase and adapted some code here and there (added ads, built in some limitations etc) since there was no option to do library projects at that time, but that left me with two projects that are horrific to manage fixes to bugs as I need to do those twice.
Since r14 we can use library projects with resources, so that would be a great solution to this particular problem as far as I can tell. Therefore I've read up on library projects and conciderations, and I'm curious to know what the minimum amount of files needed in the projects of the different versions are. My questions therefore are;
Could I have all of the code in the shared project, and have bare bone project with basically just a manifest?
If so, should I? is this the optimal way conceptually? (so apart from the fact that it depends on my code base)
How should I deal with library package naming, are there specific rules?
Are there tools about that can compare code from two different projects and perhaps merge them auto-magically or auto-manually, and which one is preferred?
If I understand your problem correctly, you want to create multiple Android apps that are similar to one another (i.e., have a lot of the same source code), but which are different in particular (minor) ways, and you want each of these apps to have a distinct package, so that it can be separately uploaded and distributed on an app store such as Google Play. A Project Library is an excellent facility for accomplishing those goals.
I'm assuming that the differences between your various versions are minor, involving things like resources and the app name and package, and a switch that turns on certain features for a paid version while leaving them off for a free version.
Even if that is not the case, by using polymorphism in the ways described below, your various apps could differ in significant ways and still share a common Project Library.
A Project Library can be defined in Eclipse in the same way as any Android project can be defined, but it is marked as a Project Library (by checking the "Is Library" box near the bottom of the Android page of the library's Project Properties dialog) and cannot be compiled and run on its own. Instead, it is intended to be included by reference in one or more other projects which are actual apps (by adding a reference to it on the Android page of each such app's Project Properties dialog). These apps will use the Project Library, and thus will share its code and capabilities.
Each such referencing app will have its own manifest file (where their respective, different packages can be declared), and they can also define their own classes (including classes derived from the Activity and/or Application classes of the Project Library), so that these classes can be specialized polymorphically for each app that uses the Project Library (e.g., by overriding methods or by providing definitions for methods that are defined as abstract within the Project Library's Activity- or Application-derived classes), although you can also use those Library classes without modification (provided that they are not abstract) by simply referencing them within the manifest file (e.g., in an activity or application tag) of each app that uses the Library, just as you would reference Activity or Application-derived classes defined within the app itself.
If you decided to use this approach, then you would put your main source files in a Project Library, and would create a separate project for each app you want to produce, each of which would reference the Project Library. The manifest file of the Project Library would be overridden by the manifest of whatever project is being created using that Library (actually, I think that the Project Library's own manifest is completely ignored, not just overridden, but nonetheless it is useful to create a manifest for the Library, so that you can manually template - copy and edit - the manifest of each project that uses it from the Library's own manifest).
I have used this approach to create multiple android apps that share some of the same capabilities, and it has worked very well for me.
Regarding package naming, any old package name will work for a library project, but of course it makes sense to use the same prefix for the Library Project's package as you use for your various individual (e.g., free vs. paid) apps that use it, with something like ".library" as the last part of the name, while the various apps could have endings like ".myappfree" and ".myapppaid". Naturally, you would want to use your reverse domain name convention for the library's package prefix to prevent conflicts, just as you would for a package name of a released app.
In Windows, a nice, open-source tool for comparing code bases is WinMerge:
http://winmerge.org/
If I were in your position, however, I would only use this tool to manually identify differences, and would not attempt to use it to automate the refactoring of your code into a Library Project. That would be best done under your own (manual) control.
Finally, as an alternative, you might consider using a single app that is free and that has your free app's capabilities by default, with an option to upgrade to your full app's capabilities (delivered within the same APK) via an in-app payment, rather than having separate free and paid apps. In-app payments have improved a great deal in the past several months (with the release of version 3 of IAB), and although there are still some glitches, they have become a more practical alternative to the free/full dichotomy than they were at first.
Yes, you can have a project that is basically just a manifest specifying app name, name space, icon etc, with all the actual code and 99% of the resources in the library project.
Yes, I think you should use this approach. It's very common to use library projects to deal with the Free/Paid app problem.
I've not had any problems with naming, though you should be careful with any resources in separate projects to avoid using the same names.
I'm not aware of any tools, and if it were me I'd want to do it manually to be sure I'm merging what needs merging and keeping separate what needs to be separate. you've one significant refactor to do, but once all the duplication is removed I'm sure it'll be much easier.
I have an app that, for release, needs building as two apps. The app will self-reconfigure based on the app's namespace, so I just need to build two versions, each with its own slightly different namespace.
I obviously want to avoid changing source code package names, and would like to change the name space in one place so building either version is quick and easy.
Can I simply change the package name in the <manifest> tag in the Android manifest, making sure my references are fully qualified? Are there any gotchas with doing this?
Have two separate application projects, with separate package names, and have the common functionality - the bulk of your code - in a shared library project.
I'm building a suite of applications, meaning that I have a single set of code that gets customized via a single change of an API key. This means that all of the applications have the same activities, same behaviors, but different icons, package names, and application names depending on the client I am building for.
Unfortunately, I haven't figured out a clean way to do this. Because the package name is what the Android Marketplace uses, I've been changing it to com.nilobject.productname.clientname. However, this changes the package for all of the activities to no longer be in the package of the application, since they live in "com.nilobject.productname." Additionally, the autogenerated "R" moves, so all of the references to R in com.nilobject.productname break.
Has anyone else dealt with this problem? I'm using Eclipse for development. Should I just refactor the activities with each build to be in the same package? Is there a system for this that I don't know about?
Thanks for any ideas and help!
I've been down this road with 3 different projects. One app needed "regular" and "pro" versions, another needed a versions of the same app for each of the US States, and another project involved delivering the same app to 3 different clients with each having slightly different graphics and colors.
Anyway, this is the approach that has worked best for me, and I've used it in all 3 of the multi-target projects I've been working on...
http://developer.android.com/guide/developing/eclipse-adt.html#libraryProject