Hey! (Apologies for the long post here)
I am writing a few applications which will be based off of essentially the same code.
Each application will have its differences, some will have new activities, all will have different resources assigned.
I am attempting to use an Android Library project so that I can place all of the common code in one place, so manjor changes only have to be made once and all projects will be updated.
Now, the resources are an easy solution, as I can just define each resouce in the main application and these will override the ones in the library project as long as naming conventions stay the same.
Now, my question is how do I do the same but for classes? For example, ill have a base view as a wrapper for common code across all views. in this, i launch various activities. What if all three applications need to launch a different activity as they will contain different UI and features? How would I go about this? The library project will never know that the main project wants to use a different activity, as its already been compiled.
I have a couple of solutions I have thought up, but I want to know if anyone else has some ideas? It would be of great help for any feedback here:
The Activity in the Library Project that is to be launched stores a reference to the class to be loaded, which will be defined in the main application at its launch. This was when the library project calls this activity, it can load what its been told to.
I leave all functionality that will not change inside the library projects activity. I then extend this activity, and override the onCreate to do what I need here (such as loading different layouts, setting up views, etc). Now this has a drawback, as I have to define most of the entry points in my main application rather than in the library project.
I hope you follow what my issue is here. Please ask if I have explained this poorly.
Thanks,
Adam
Or more simple: Should you use inheritance or composition to achieve that kind of flexibility?
I had this kind of structure quest as well. Usually you would solve it by reusing a applicable pattern & break the necessary code parts in smaller pieces. I.e. if you know the difference are views, then extract that into some distinguished classes that will implement against an common interface and refer to the interface in your base activities.
Some links for you:
http://tiedyedfreaks.org/eric/CompositionVsInheritance.html
http://mindview.net/Books/TIPatterns/
http://en.wikipedia.org/wiki/Decorator_pattern - maybe applicable in your case
At least from how I understand your question, this is more of a OOP Design question.
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.
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.
My scenario
I have to implement a "modular" android app. There is a core module from which I should be able to invoke other modules. Each module provides a different feature to the user. Imagine I am making a city guide, then one module may contain a map with POIs, another one an event calendar and a third one pre-defined city guides. The modules contain views to be loaded in activities of the core module (like dashboards where each module puts its item/picture). They also contain activities which should be invoked (like when a user taps an item on the dashboard). As far as I know, I will need a database and/or preferences only in the core module. The "plug-in modules" use classes (utilities) of the core module, e.g. when connecting to the backend.
My solution on iOS
For iOS, I achieved this with targets in XCode. I have one project and depending on the customer's needs I compile only the relevant modules. It would be even better if the user can install modules whenever he wants, without the need of reinstalling the "core" application.
My problems on Android
In SO, I already found various solutions like library project, switching from Eclipse to Android Studio + something, using package manager and broadcast receiver... But I still don't understand... How is the modularity of an android application to be achieved?
Here are some concrete problems that I see:
Libraries: My modules all use classes of the core module, so they are not independent. I achieve the modularity by using interfaces/inheritance depending on the flexibility that I need.
Broadcast receiver: This seems to be everything else than recommended. See, for example, here or here.
What I need is, at least, to be able to use the same code for delivering app with features A and B to one customer and with B and C to another one. And, until now, I have no idea how to achieve it.
PS: I don't want to use scripting, I am not familiar with that.
I don't see this "modular" app as anything different from one app, with several packages, each containing discrete functionality, that is adapted to some list of settings or external parameter (either provided by the user or you).
My approach would be to have a "main" package. That package would contain the shared functionality you mention above and serve as the hub for your application. I would then create separate sub-packages for the different "add on" functionality. This allows you to still use the code in your main package with a simple import statement. From your description these additional functions should probably be implemented as a Fragment. A Fragment is almost a stand alone application with the exception that it is "hosted" by an Activity. Depending on how these add on functions are used (I cannot tell if they relate to the UI, just background processing etc) you could easily have 3 of 4 different fragments and choose to load only 1 or 3 or 2 of them at runtime.
To control which parts of the code are used I would just set up a simple switching class (it could even be part of the first activity launched, I cant tell from your description above). Here I would check for some setting indicating which parts of the app will be "active." This could be easily defined using SharedPreferences to store a specific configuration, e.g. use A and B, prior to delivering the final project. You would then just initialize the fragments you need and display them either (1) individually in a Fragment layout element or FrameLayout; (2) collectively in some other view structure like a ViewPager.
I follows your links on the BroadcastReceiver and I am still not sure why they are "everything else than recommended." Used correctly a BroadcastReceiver is very useful. I tend to use a LocalBroadcastManager along with a BroadcastReceiver to notify other sections of the app when some AsyncTask, e.g. downloading a lot of data, is complete. These parts of the app can then access a local database or process the information downloaded on their own time. I wouldn't use a BroadcastReceiver to modulate parts of the app if that is what you're looking for. I would instead just use a SharedPreference file to set the configuration at runtime.
If you need modules like facebook sdk or something like that better use library project. If you use Idea or Android Studio there is such thing like Module. If I need some modeles in one app I prefer just put in different packages like com.appname.model, com.appname.ui and so on. Broadcast Receiver isn't about modules. As I know there isn't analog of ios target.
What would be the right way of including smaller android apps, into one bigger if requirements are the following:
little apps should be loosely coupled and should be developed separately
bigger app should handle some common things, instead of each little app do it for itself.
bigger app should now something about state of little apps, in order to do some decisions.
First thing that comes into my mind is some sort of plug-in pattern (although I don't know much about it, so I could say something wrong), so that each little app should implement some common interface, and big app should use that interface when dealing with component.
Is that right approach?
Is this right way of thinking considering android as a platform?
Your best bet is to make each sub app a "library." You create a workspace in Eclipse and create a new Android project and mark it as a Library.
You do that for each sub app.
You then have a non-library application that imports each library and uses each as part of the full application.
This means you don't need to worry about writing a plugin interface, etc.
Also if you follow this sort of pattern, when you create a free vs paid application, you are able to just add another application and remove / change functionality as that one all needs and compile both from the same code base.
Update
Take a look at http://developer.android.com/tools/projects/projects-eclipse.html for some decent documentation.
This shows how to create both types of projects and how to reference them in your manifest which is the annoying part.
Update2
From comments it was asked if you can use a library Activity in a main application that imports the library.
You create an Activity in the library
com.example.myapp.library.MyActivity
Then you add details to your manifest
<activity name="com.example.myapp.library.MyActivity">
This then let's you use it there. You can even use a library Activity as your main startup Activity if that's what you need.
You can also extend a library Activity by changing your manifest to
<activity name="MyNewActivity">
Then create a new activity
class MyNewActivity extends com.example.myapp.library.MyActivity
Then just override what you want, call super to access your library method if desired, etc.
Feel free to ask questions.
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.