Android Studio best practices on app modules - android

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.

Related

What's the best practice for adding Android TV support to an existing smartphone / tablet app?

The way I see it, there are a few options using Android Studio:
Add a new module for Android TV, and create a common module to share some of the code, but mainly re-write most of my code for Android TV.
Add one or more Android TV specific packages in my existing application code; add the Leanback manifest intent filter for the Android TV main Activity, and finally do manual checks in code. Some of the existing stuff can be re-used on Android TV, and some areas will need to be re-written.
What do you think is the best option?
I personally think that the second option is the best, as it's significantly easier to do, but it does have a few disadvantages, i.e. a larger APK size.
It really goes down to your project, how it is built, how big it is, and so on. In a general sense, each option has its own advantages and disadvantages.
EXTENDING THE SAME PROJECT
You can decide to share your code base and add some TV-specific classes to your existing project. This allows for a faster bootstrap for sure, since you have all the code you need right there. Plus, to the end user, the Play Store entry will not change, so you will benefit from the same ratings, downloads, visibility and so on. The downside, in this case, is the risk of your app becoming monolithic and thus, harder to handle.
CREATING A NEW MODULE
On the other hand, going for a separate project "forces" you to write common modules, which (to me) sounds like a good thing. You will have a longer bootstrap if your code/project is not modular enough, but in the long term it will pay off. Also, the APK of your TV application will benefit too, since it's going to be smaller. You will have a different Play Store entry, but that could be a downside as well as an upside. Finally, I think it feels refreshing to work on a separate project once in a while, so this is a totally subjective plus :)
In my company, we decided to go for a separate project/module. We wanted to modularize some common components, so it felt like the right time to do so. That alone was a good reason for us, and we did not regret it. Also, we had the chance to experiment with a new project structure, which involved using a bus (Otto) and a job queue (Path's).
All in all, it's up to you and to your project. I will try to add as many other points as I can.

Architecture guidance for an android application

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.

How to deal with the Release Management of two projects that are basically the same?

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.

Android Library Project - Defining Classes

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.

How do you release two versions of an app on the Market?

I would like to add two versions of my app to the Android Market, one for a few cents, and one free version, with ads. That's a very common practice.
I'm currently building AdMod into my app, and it seems I'll have to change quite a few files, so it seems best to make a separate version of my app for this.
How do you achieve that? A branch? A different repository? Has anyone found a way to keep both apps in the same repository in a reasonable manner?
The title is not misspelled, I do mean "realise", i.e. how people manage the two versions, not how they add them to the Market.
This kind of thing is a complete nightmare - unfortunately the Android build system doesn't really support it in any good way.
We do it by having 99% of the code of our application in a library project. We then create one application project for each different version of the app, each of which use that library.
Where we need different versions of the app to behave differently, we currently achieve that by having different resources that are queried at runtime. We are in the process of moving to using Dependency Injection via RoboGuice, however.
There are elements of this that work reasonably well, and others that don't. It's necessary, for example, to duplicate the AndroidManifest.xml file, which can be error-prone (it's easy, for example, to add a new activity to one manifest and forget to do so in the others). It's a mess, unfortunately, but the least-bad solution we've found.
Personally speaking, I would strongly advise against using branches to achieve this effect. They can work well initially, but will rapidly become a maintenance nightmare.
One side benefit of using a library is that we've found that it makes testing considerably easier. For an example of how to set this up, see:
http://www.paulbutcher.com/2010/09/android-library-project-with-tests-step-by-step/
People usually upload them twice(like two different programs) and just modify the title for adding something like Ad-Free, Donate and things like that. And on the free version just add the Free label and also put on the description that it's Ad-Supported.
Here is an example with the SMS Popup application:
For the Android Market, they are considered different programs, but for us it's the same, but one is Ad-Supported and the other isn't.

Categories

Resources