Develop Reference

Multiple android app projects sharing code in Clean-Architecture

I want to create three related android apps (employee, Manager, Secretary) in clean-architecture and also share common classes (utils, Ui & etc.) among all three apps in order to reduce code duplication. Each project has multi-modular clean-architecture design. Would you guide me on how to connect these three projects to the shared classes, please? Is there any sample code for my case?
My project after using clean-architecture book by Alexandru Dumbravan:

I think you might do some separation code between apps. You can merge it in you settings.gradle to merge all apps/libraries in one project.
Here is the example
There is 4 additional code/library in 1 project which is app, xxxapi,xxxauth and xxxcommon.
So you can set your settings.gradle into something like :
include ':app', ':xxxapi', ':xxxauth', ':xxxcommon'
If you already set that code, you can use it in all your code in one project as well.

How to create Android custom view library in Android Studio?

I've created a custom view that extends a RelativeLayout for a project I'm working on. I think it might be useful to others, so I've been trying to set it up as a library so others can find and use it.
I've haven't been able to find a clear answer on how to go about setting this up in Android Studio.
To be clear - I have already built the view and it is working fine, I just want to package it up as a library.
Do I create a new project and simply put my code there, or do I need to make a new module too? Once I do either of those things, which parts of the manifest and gradle files do I need to change?
Lastly, do I need to somehow get an AAR from the files or is it best to just upload it to GitHub and let others clone it?

In Android Studio (v 1.0.2):
File -> New module... -> Android Library
In this new module put all the code you want to share. Android Studio should update Gradle's settings accordingly.
You can publish your library as source code and/or artifacts in some Maven/Gradle repository. Publishing source code allow others to contribute to your work, fixing bugs or extending functionality. However, if you just do that, it won't be very convenient to reuse it for other developers, because working with source requires checkout and build. If you publish also artifacts (in some Maven/Gradle repository) built from that code, you will simplify the life of people using your code :)

Do the main project and the library project must share the same package?

I started creating a library that will be shared with several projects.
The problem is that the Android documentation is really short about how to handle properly the library projects. I got really stuck dealing with the conflicts between the few classes I have in common in both the main projects and the library project.
I checked the sample from Android (Tic Tac Toe) but it is really too basic to help, but I just remarked that they used the following packages:
The main project: com.example.android.tictactoe
The library project: com.example.android.tictactoe.library
Is the library supposed to be always contained in the main project package? If yes, how to do when several projects have to share the same library project since the main package name belongs to one main project only?
My biggest problem right now is that my app is calling a class from the library project instead of the main project, and I have really no idea what is the best approach to follow.
Thanks!
Update: My question is related to this one: Best practice: Extending or overriding an Android library project class

There are lots of 3rd party libraries available (such as Action Bar Sherlock) and they do not share the same package as yours.

The packages for the library project and the main app project have no requirement of being related in any way.
In some cases it does help having the library as a sub-package of your main app package: this comes from the way you split the project and if the package for your library being a sub-package would help with organising the code, by all means make it a sub-package of your main package; otherwise, don't. It's all about structuring the code in the end.
It is ok for your app to call (actually use would be the work) classes from your library project. That's what libraries are for. They help keep code contained, reusable and decoupled from other pieces of code.
The problem is the other way around: when your library is calling a class from your main project.
The most common approach for Java and Android here is to use an interface: the library provides the interface that the main project implements, then the main project passes an instance of that implemented interface for the library project to use. The best example here would be callbacks. Android provides a set of interfaces (such as View.OnClickListener) that allow you to hook into the system and perform your application's logic (from the application's point of view, the Android classes in the SDK are the libraries).
Other approaches would be providing classes to be extended (this is just like providing interfaces, but it's used when you want to either leave the library user the option of not implementing/overriding all the methods or when you want to keep some base functionality in the object you will be receiving in your library through the use of the final modifier) and reflection (stay away from it as long as possible as it is very error-prone).

"Library projects" in iOS

Some time ago I created and Android app. Then I needed to create very similar app (functionality-wise) with some cosmetic, branding and small-scale functionality changes. I refactored the original app as a library project, created an app that used this library project and recreated the original functionality. Then I created a new app that used that same library project and also implemented the small-scale changes required for the second app. This worked perfectly fine. Now if a change is needed, it's very easy to implemented it in multiple apps: I just change the library project and recompile all the apps.
I also had the original application available for iOS - and need to make the second app available for iOS. I could, naturally, copy the project, make the changes and create another apps. However this would mean double work if I needed to change something in the core functionality. I'd like to be able to refactor the iOS project/app similarly to the Android one, but not sure how to go about it - or if such functionality is even available. Any suggestions are much appreciated.

You can create a Single project with differents targets.
Then, you will have target A, and B for example and CoreFile files that are common for all targets.
Let's suppose you have HomeViewController with some slightly differences.
You can create a single interface HomeViewController.h and two implementation AHomeViewController and BHomeViewController, both extending BaseViewController.
Then open AHomeViewController, and on FileInspector at 'Target Membership' mark only target A. On BHomeViewController you do the same. Image 1, illustrate what you have to do (names are differents from the example because it's a real example from one of my projects).
If for some reason you have need to know what's targets are you using you can define it using Preprocessor Macros on Target -> Build Settings. As illustrate by Image 2.
Then you can use #ifdef APP_CB to check the current target.

As was mentioned you can really regulate target membership[About] of every file which you add. But in my opinion is better to create a separate framework(library) and add it as dependency
[Swift consumer -> Swift dynamic framework]

Manage code/build for Android app stores (Google/Amazon/etc)?

I have an Android app that's downloaded primarily from Android Market (now, Google Play). We made a few tweaks to the source and also submitted to the Amazon App Store to see what sort of traction it gets. I'm now looking for a sustainable way to develop from a common code base and yet build so that I can submit to either/both.
Amazon's store has some restrictions about available APIs, and hence I'd like to conditionally remove/modify features from that version. Since Java doesn't support traditional conditional compilation, and conditionally including files in Eclipse doesn't seem trivial (is it even possible?), I wanted to ask what others are doing to solve this.
Admittedly, I'm no Eclipse/Java expert so feel free to school me.
What I'm looking for in a solution:
Building/debugging using Eclipse.
Static code files, with environment/settings toggles to control what to build.
No duplicate code or conditional logic in code to pick code flow at runtime
Is this something you've solved for Android apps specifically, or for other Java/Eclipse based projects? Suggestions for where to begin?

It's quite easy to do in the newest versions of ADT (version 17), though I do find it makes compilation a bit longer:
Create a new Android project (proj-A)
Go to Project->Properties, select Android, and check "Is Library"
Move all your common code to proj-A, import all the necessary libraries
Create a new Android project for Google Play (proj-B)
Go to Project->Properties, select Android, and add Proj-A to the Library
Repeat #4&5 for the Amazon version
If you have some variables that should be set differently for each sub project (i.e. boolean GOOGLE_PLAY_VERSION to enable Google Play specific functions), you have to create another project to contain these values since you can't have projects that reference one-another in a circular fashion. You can solve this by adding the following steps:
Pull all of your sub-project specific variables into one or more Classes that just serves as container(s) for these variables
Create a "dummy" Java project (dummy)
Config proj-A to add a new Source link to the bin directory of dummy
Add the config Classes in each sub-project with project-specific changes
Profits!
Note that the variables in dummy should not be set as final, otherwise it will override sub-project's setting.
This may seem like quite a bit of up-front work, but has worked quite well for me as far as version control goes.
Edit:
Now with Google's move to Android Studio & Gradle, it may be better to move to that if you are starting a new project if you want to support multiple APKs, see Android dev site's Building Your Project with Gradle#Work with build variants. It definitely doesn't hurt to evaluate that option before deciding.

Unfortunately, it's sort of a convention in Android to change flow at runtime based on what would be in C/C++-land conditional compilation.
Our app has to maintain different behavior for different API levels, so we've created some application-level constants that are initialized statically based on API-level information available to us, and used throughout the code. This is the way that Google does things in their examples (for example, see the ActionBarCompat compatibility library, and in particular the factory method used here).
You could create an interface CustomBuild, and implement it in AmazonBuild and GooglePlayBuild, then use a static getBuild() method to switch functionality as necessary:
if(getBuild().shouldEnableFeatureX()){
doStuff();
} else {
doDifferentStuff();
}
Then all you've got to worry about switching between builds is a line or two of code in the factory along with maintaining which things you want enabled in which versions. Or you could include a different version of a static class CustomBuild for each build.
I'm going to second the suggestion of others above re: switching to something like Maven for building; it should make your life much easier once you have it set up.
I'm also going to say you should make the core of the app a library as suggested above, and have two different modules (one for amazon, one for play store) that depend on the library but each only contain the one custom factory file (or just a static class for each type of build that contains the same "should I do this thing?" methods... once you have the infrastructure it's just a matter of preference).

I haven't actually tried this yet, but it's something I've thought about.
How about using Eclipse's ability to link to files from a directory outside your workspace?
Start with one Eclipse project: for the sake of argument, say it's the Google Play version.
Now build a second project, beginning with asking Eclipse to link (not copy) the source files from your first project.
To develop the second project, add classes that subclass ones from the original project to realize your modifications. For resources, you can use some combination of includes, attribute overrides, and selectors.
Where it's not possible to subclass or extend, then obviously you'll have to just copy the original source file and hack on it. If you're really OCD about it, you can probably just maintain a patch set rather than a whole redundant set of files.
What do you think, will it work?

You may create manually two projects in Eclipse pointing to the same source folders but with different inclusion/exclusion filters and different target directories.
Then two Ant targets using properties to switch excluded files from javac fileset are enough to generate corresponding jar files.
The aim is to get a clean application for each target, without any code from the other one.
With features listed as pluggable behaviors in a property file or XML configuration, your runtime will adapt itself with the addition of menu entries.