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.
Related
There is a core ERP mobile application for Android. A customer has requested additional features that will require more screens (and Activities) and extra functionality.
Is there a way I can add sort of an extension to the core mobile application in order to intergrate the extra features or should I code on top of the code of the core application?
I am interested in finding a neat solution focused on extendability since different clients might ask for different additional features. How would you deal with such an issue? Any tips on the structure of such a project would also be welcome.
Would it make a difference if the extra features need to use the same db as the core application?
Thank you in advance for your help.
The answer to your question lies in the Open/Closed principle introduced by Bertrand Meyer. Open/Closed Principle is a very simple Object Oriented Design principle which states that
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"
From your question its clear that you have identified the core functionalities in your application. So rather than Modifying this core functionalities and making it more specific, I would recommend, on the basis of the Open/Closed principle, that you should freeze your code features and write your customer specific functionalities over it without corrupting the core.
Now to answer your question on what kind of structure you may follow. I would recommend that you create a library project of your core functionalities and make different client specific projects that would include your core functionalities as a library project.
It won't make a difference if your application is using the same db as your core application provided all your applications uses it, else it should not be in your core application in the first place.
Hope this explanation help you.
Update:
My friend pointed out that I may not have understood the question right. So rather than correcting my old post(...which may be useful for others) I am updating it.
So if I understand it right, you have an ERP project which you may not have coded. The right approach, according to me,still would be that you build over this existing code. Rather than making changes on this project, include it as a library because if the project is downloaded from a reliable source, you will have the benefit of getting the updated version as and when it is available.
This is kind of a design philosophy question. Here are a couple choices that might give you ideas:
You could look into making your core application code/features into a custom library. Then your new core application is just a simple wrapper that includes the custom library. Your additional features for a specific customer could then be a different app that also references the core library but will include additional features. There are lots of tutorials on how to turn your app into a custom library. You would end up with different apps that target different a customers. (A tip that took a while for me to uncover is that if you have a resource name in your custom library you can "override" it by using the same name in the app that includes the library. Another tip is that you need to essentially duplicate the manifest of the library in the app by listing all the activities in the library that would be used by the app.) I haven't tried this but it might be that your additional features are each libraries that are included in different apps.
You could have an key the user inputs that will unlock certain features. You could save this as a shared preference so that they don't need to keep entering the key. This approach has the benefit that you can "reuse" features for other clients without any more implementation other than determining which client gets what feature. The majority of users just wouldn't have a key to unlock anything.
Both these solutions should use the same db since they would be calling the same core classes, etc.
Another possible solution is to create a Library Project. Put your core ERP app code inside the library Project, and then create different project for different customers. Each one of these projects will also use the same library project.
Your core library project could expose an api to dynamically register new features (Such as a menu that can expose new menu items).
i'll try to better explain my question.
We are are developing a business application for a target customer.
This application has some function very specific for the customer but the core should be re-used for other customer.
For istance the log-in activity would be the same for all customers, but customer A could see activity A and customer B could see activity B and so on...what part of the app to show is managed from the data returned by log in.
I'd like to have only ona project in order to better mantain it....but here my question:
i create the application for customer A, with common activities and custom activities.
I put this application with package name com.mybigapplication and with apk name mybigapplication.apk in the play store.
Customer A download install and use it.
Now I have customer B, I take the same project, I'll add the custom activities for customer B and I'd like to put the app in the play store.
Here my problem if i put the app with same package and apk name the customer A will update the app without any reason...
How can I do ?
Is there a way to manage this problems ?
Please notice that I haven't already put anything in the store.
Best regards
The way to go is putting the common code in an Android Library project, that the specialized apps for customer A and customer B will depend on. So you will have 3 projects in Eclipse:
common (Library)
customerA (Android)
customerB (Android)
An Android application is uniquely identified by the package attribute in AndroidManifest.xml. The two android projects can (actually must) have different package attribute in their manifest, that's how upgrading one app will not affect the other.
For more details on library projects, see the docs:
http://developer.android.com/tools/projects/index.html#LibraryProjects
This article may also be helpful:
http://blog.donnfelker.com/2010/08/05/howto-android-full-and-lite-versions/
A trivial solution would be to create 2 separate projects with different package names.
Then write a shell script or something that just periodically copies all the source files from the directory of project A to project B.
You have to be careful not to copy stuff that might mess up configurations etc. You'll have to manually adjust those. for example, the manifest file can't be copied directly; You'll have to manually add any activities, Services etc in Project A to Project B's manifest too.
Another option is to create an Android library project with the shared code and just include it in both the projects. Here's a tutorial on this.
I have an android application for one client, and he wants to make a 99% similar app for different country.
Almost everything is the same, only a few bitmaps would need to be replaced, address of API server will change, language file will change, but the code should stay the same, BUT I will need a different package name.
What is a simple way to make a clone of the app that will allow me to make code changes to one version, merge them with the new version (or versions), but keep the package name?
Or should I have everything in one project folder and then write and run some script that will change package names and swap content files? My iOS friend will probably need a few different #defines, but what should I do here, so I can maintain both versions in the future?
declare your original project as library, then create 2 new projects each for one language and let them include original project as library
then you can go ahead and just override bitmaps and constants you need.
this way, if you need any changes in core functionality, you just change your library project, and changes will propagate to both of extending projects
read more about library projects here:
https://developer.android.com/tools/projects/index.html#LibraryProjects
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.