I am working on some application that has different type of users namely a mechanic and a customer.
Now I have two solutions
1 To make separate applications for both
Pro:
Modular application,manageable and lesser size .
Con:
Code redundancy like login pages for both apps.
2 To make a single application for both.
Pro:
One application caters so overhead saved.
Con:
Lot of thinking and flexible arch. In place is needed.
I am kinda confused ,if someone can guide me with this.It'll be great.
Some sort of examples and links would be superb.
Diagrams would also do.
I guess the most reasonable option would be to have:
A Library Project with the common parts (anything you want to reuse, basically), and
Two Application Projects for the distinct applications.
That way you can reuse the common parts (no duplication) and still keep the specific parts separate.
See Managing Projects in the Android documentation, this precise scenario is listed as one of the main use cases for library projects:
If you are developing multiple related applications that use some of
the same components, you move the redundant components out of their
respective application projects and create a single, reuseable set of
the same components in a library project.
Related
I'm trying to understand the concept of modules on Android. I've read this article on the official documentation, but I'm a bit confused. Here is stated:
An Android Application Module is the container for your application's source code, resource files, and application level settings, such as the module-level build file, resource files, and Android Manifest file. The application module contents are eventually built into the .apk file that gets installed on a device.
and that's pretty much all the documentation I've found on this. I still don't understand in which cases would make sense to create different modules. I know that it may be vary from case to case, but ideally what would be the minimum logical size of a module?
A practical example
I'm building an app with a drawer view. Each button of the drawer will open a fragment which will have some logic to it. Would it make sense to make a module that contains only a fragment and a few java classes with no activities in it?
I'd really like to know which are the best practices on this.
Thank you.
Perhaps the best argument for breaking code and resources into modules is reusability. If not for multiple dependents of such a module, why would you need to separate this code out into a module at all? If you only ever have one application, there's not much need to have this code broken out into a module.
As soon as you have multiple applications sharing the same code, then I think a module is justified. A module could be many things. It could be a base application that contains the bulk of the code. It could contain the "Model" aspect of your application, or maybe an API or networking layer. It could be a container for proprietary algorithms. It could be some generalized code that you're planning to open-source. Who knows?
Consider it from the opposite angle. What's the risk of doing this now if you don't really need to? Maybe mental overhead? Having to think about and maintain this module may be more trouble than its worth if you don't have a good reason to do it in the first place.
What is the cost of deferring this decision? Is there any compelling reason why this code couldn't be refactored out of the main application into a module at some later point?
Something as small as a single Fragment for a single UI component sounds like something that doesn't need to be in its own module.
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).
This is more of a fundamental question I suppose. I currently have in the market one app that I have separated in two projects. One project (with it's unique package name, obviously) does not have Google Ads and is not free. The other project has Google Ads and it's free.
Both projects are exactly the same. Same functionalities.
When I want to add a new functionality, I have to work on both projects, making then the release of my app slower, since I am basically control-c/control-v what I did in one project onto another. And sometimes I just forget something, so I have to fix the issues...
So, basically, I am wondering if there's a better way I have to manage that?
Maybe creating a rather intelligent script that will build the application depending on what I want (i.e: if it's ad based version, should use the AndroidManifest that declares the AdMob Activity)
Or maybe create a library? But I don't think this approach would work.
Looking forward for inputs.
Regards,
Felipe Caldas
Yes, a library project is exactly what you want. Put all the functionality in a library, and have two very thin shells for each of your app types that make calls into the library. As you noticed, duplicating the code is error prone and at best just extra work you shouldn't have to do.
See: Managing Projects for details. That page even mentions your exact scenario:
If you are creating an application that exists in both free and paid
versions. You move the part of the application that is common to both
versions into a library project. The two dependent projects, with
their different package names, will reference the library project and
provide only the difference between the two application versions.
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.
Im going to develop a very large scale android project, which has thousands of classes and resources. Im planning to separate application in to modules and develop them separately as library projects. Later combine them together. (Application may contain 5 - 6 modules, so planning to create 5 - 6 library projects and combine them)
Is this approach ok? or android experts, please suggest a way to maintain and develop such a big project?
Edit:
Libraries hold shared code for multiple applications -> Yes agreed 100% true
But this project is like combination of several projects.
Its like this:
Home Screen Dashboard has 8 buttons which represents 8 modules
you click on one button - > it opens up an activity and it has its own thousands of fragments, layouts, drawables etc, which is independent from other modules
so likewise i have non interdependent use cases which can be separated easily, and 4 - 5 developers are going to be involved this project, so if I can separate in to several library projects, i can simply allocate developers easily based on modules(library projects)
So one approach is to create one project and create package structure by modules
com.name.something.Module1
under this package i have
com.name.something.Module1.activity
com.name.something.Module1.util
com.name.something.Module1.widget
com.name.something.Module1.data
com.name.something.Module1.dao
and module 2
com.name.something.Module2
com.name.something.Module2.activity
com.name.something.Module2.util
com.name.something.Module2.widget
etc.
so this is first approach but each module has thousands of classes and resources, layout xml files etc.
The other approach is to separate modules as library projects.
I dont know how large scale projects maintain their codebase, like facebook, twitter etc.
Please advise.
Libraries hold shared code for multiple applications... if you are entirely focused on a single application then there's no point in separating your code into 5-6 library projects.
One common way Android developers separate their project is by making sub-packages for different components. For example, custom Views and adapter's go in com.package.name.ui, utility packages go in com.package.name.util, etc. Other than that, you just have to be smart... starting an app from scratch that will have "thousands of classes" sounds pretty ambitious and there is not really any single piece of advice that will make your life easy.
Is each module separated from each other or do they share data (e.g. the same database)? If they are separated I would suggest to create 8 separate apps, which would reduce the memory footprint of your app and would improve launch time.
If some, or all are using the same database, you might be able to create a database on the SD-card and use it from each separate app.