Data-binding Pros and Cons, Choose wisely


I have used data-binding in two projects, I would say data-binding is too bad for your project, it can be the cause of spaghetti code. Let’s see the pros and cons of data-binding.


1- Easy to use
2- Less boilerplate code (eliminating findViewById and more)
3- Fit to MVVM pattern
4- Synchronize data between sources and UI elements


1- Showing unrelated errors

Showing unrelated errors when compiler can’t compile the project for any problem, (e.g. Dagger2 or Room or Realm) so compiler can’t generate data-binding related classes so it will show unrelated errors like below:

2- Business logic belongs in code

It can be more complex if you have different layouts for different screens.

3- Updating view after changing data can be cause of blink

4- Auto-rename for package names doesn’t work on XML files

5- The auto-generated .class files increases app size

it will matter if you have tons of it.

Other Solutions

  • Use databinding but do not use events !! (It can fix the cons #2)
  • Using ButterKnife
  • Using traditional way, findViewById()
  • Using Kotlin Android Extensions

Learn Dagger2 with simple example


I have read and watched a lot of different Dagger2 tutorials but most of them are too long or hard to understand so I decided to write a new simple and short tutorial for Dagger2, I hope you like it.

Why we need it?

  • Simplifies access to shared instances: It provides a simple way to obtain references to shared instances, for example once we declare in Dagger our singleton instances such as `SharedPrefrences` then we can declare fields with a simple `@Inject` annotation.
  • Easier unit and integration testing: We can easily swap out modules that make network responses and mock out this behavior.

Lest’s start with a simple example

Full source of example is available on my GitHub account.

Add Dagger2 dependencies

First of all we need to add Dagger2 dependencies, Put below code to your module-level build.gradle file.


If you are getting an error like Error:Conflict with dependency ‘’ in project ‘:app’ you should add the following to your main app/build.gradle file.


Two simple class

We have two classes (Vehicle and Motor), Vehicle class needs Motor class to run and MainActivity needs Vehicle class. We will use Dagger2 to provide these instances.



Module class

Module class is responsible for providing objects which can be injected, In this example we want to inject Motor class to Vehicle class and inject Vehicle class to MainActivity so  we should create MyModule to provide these instances.


@Provide annotation: returned object from this method is available for dependency injection.

@Component interface

Dagger2 needs component class to know how should it create instances from our classes.


@Component interface: connection between the provider of object and the objects which express a dependency.

Inject Dependency in Constructor

By adding @Inject annotation, dagger2 can automatically create an instance from that object like our example Motor object in Vehicle class.

Inject dependency in MainClass

Dagger2 can automatically inject dependencies in constructors, but Android components (activities, fragments, etc.) are instantiated by Android framework which makes it difficult to use dependency injection on them, so we should inject them manually like below code:


Little more

Read this article : Dependency Injection with Dagger2
Watch these videos:

Change text color of MenuItem in Navigation Drawer


Navigation drawer style is my worst nightmare. In my navigation drawer I have different items with different text colors. In this post I will show you how we can change MenuItems text color programmatically.

For doing this we need two methods:

  1. Set text color for menu item:
  2.   private void setTextColorForMenuItem(MenuItem menuItem, @ColorRes int color) {
        SpannableString spanString = new SpannableString(menuItem.getTitle().toString());
        spanString.setSpan(new ForegroundColorSpan(ContextCompat.getColor(this, color)), 0, spanString.length(), 0);
  3. Reset all menu items text color:
  private void resetAllMenuItemsTextColor(NavigationView navigationView) {
    for (int i = 0; i < navigationView.getMenu().size(); i++)
      setTextColorForMenuItem(navigationView.getMenu().getItem(i), R.color.textPrimary);

We are almost done, we should just set text color for each menu item in onNavigationItemSelected method like below:

  public boolean onNavigationItemSelected(@NonNull MenuItem item) {
    setTextColorForMenuItem(item, R.color.colorPrimary);

    switch (item.getItemId()) {
        setTextColorForMenuItem(item, R.color.nav_search);
        // do other stuff
        setTextColorForMenuItem(item, R.color.nav_recommendation);
        // do other stuff

That’s it 😉

What’s your flavor?


Product Flavor is a very powerful feature. It’s the most useful way to work with different hosts, icons, package names or even makes free and paid versions of your app depending on various versions of the same app.

What is Product Flavors?

According to Google:
“You can customize product flavors to use different code and resources while sharing and reusing the parts that are common to all versions of your app.”

How can you define it?

You must write it on module-level build.gradle file inside the android block.

  productFlavors {
    free {
      applicationId ''
    paid {
      applicationId 'com.example.myapp.paid'

After you create and configure your product flavars, click on Sync Now. after the sync completes, Gradle automatically creates build variants based on your build types and product flavars, and names them according to (product-flavor)(Build-Type).


Let’s see some useful examples

Multiple package names

What if you want to have installed on your phone one app with development state and one for production state. The only thing you have to do is define it like below:

  productFlavors {
    devel {
      applicationId "com.example.myapp.devel"
    prod {
      applicationId "com.example.myapp"

or if you have two different versions like demo version and full version:

  productFlavors {
    demo {
      applicationIdSuffix ".demo"
      versionNameSuffix "-demo"
    full {
      applicationIdSuffix ".full"
      versionNameSuffix "-full"

Use multiple hosts

We should define HOST variable:

  productFlavors {
    devel {
      buildConfigField 'String', 'HOST', '""'
    prod {
      buildConfigField 'String', 'HOST', '""'

We will try to show you how you can integrate this with Retrofit to send requests to the appropriate server without handling which server you’re pointing and based on the flavor:

retrofit = new retrofit2.Retrofit.Builder()

Like the above example you can define different variables in Gradle and then use it in java code, check the below snippet:

productFlavors {
    devel {
      buildConfigField 'int', 'FOO', '52'
      buildConfigField 'String', 'FOO_STRING', '"bar"'
      buildConfigField 'boolean', 'LOG', 'true'
    prod {
      buildConfigField 'int', 'FOO', '42'
      buildConfigField 'String', 'FOO_STRING', '"foo"'
      buildConfigField 'boolean', 'LOG', 'false'

You can use them in your java code:

    Integer foo = BuildConfig.FOO;
    String fooString = BuildConfig.FOO_STRING;
    boolean log = BuildConfig.LOG;


You can find all information and data relating to the Build Variant in BuildConfig.class, This class created automatically for each Build Variant by Gradle. You can find this file in build directory or with Ctrl+N shortcut in AndroidStudio.


Declare Dependencies

You can configure a dependency for a specific build variant or even testing source set.

dependencies {
    freeCompile project(":mylibrary")
    fullReleaseCompile project(path: ':library', configuration: 'release')
    fullDebugCompile project(path: ':library', configuration: 'debug')
    testCompile 'junit:junit:4.12'
    androidTestCompile ''

Build with source sets

Do you want to use some mocking objects in your tests? or you don’t want to use full version files or classes in the demo version? Let’s see how we can do it.

First of all, You should add ‘demo’ and ‘full’ product flavors into build.gradle file then click on Sync Now button in notification bar, after syncing you should put the real files for full version into /src/full/ path and put the demo files for demo version into /src/demo/ path. Gradle will find the corresponding files and will add them to the output package. let’s see it in code:

My build.gradle file:

  productFlavors {
    demo {
    full {

Now we have 4 different build variants:


We need an interface class like below in /src/main/java/com/hanihashemi/test path:

public interface iApplicationCoreValue {
  void doImportantJob();

We should implement it for demo and full version.

For full version we should implement ApplicationCoreValue in /src/full/java/com/hanihashemi/test path

public class ApplicationCoreValue implements iApplicationCoreValue {
  public void doImportantJob() {
    // show message ==> Please buy the full version 

For demo version we should implement ApplicationCoreValue in /src/demo/java/com/hanihashemi/test path

public class ApplicationCoreValue implements iApplicationCoreValue {
  public void doImportantJob() {
    // do it here

YESSS it’s done, by choosing releaseFull we can build full version and by chossing releaseDemo we can build it for demo version.

If you think I missed something, please leave me a comment 😉

For a more in-depth and technical description of Build Variants, check out the Android Studio Build Variant user guide:
Configure Build Variants

I encourage you to read this tutorial as well:
Android Testing Codelab

Espresso, Using Intent Extra


As you know for creating a new Espresso test in JUnit 4 style you should use ActivityTestRule to reduce the amount of boilerplate code you need to write. By using it, the testing framework launches the activity under test before each test method annotated with @Test and @before.

public class UserProfileTest {

  public ActivityTestRule<UserProfileActivity> mActivityTestRule = new ActivityTestRule<>(UserProfileActivity.class);

  public void signUpActivityTest() {

So what if you want to send Intent to an activity? Here is the example:

public class UserProfileTest {

  public ActivityTestRule<UserProfileActivity> mActivityTestRule = new ActivityTestRule<>(UserProfileActivity.class) {
    protected Intent getActivityIntent() {
      Context context = InstrumentationRegistry.getInstrumentation().getTargetContext();
      Intent intent = new Intent(context, UserProfileActivity.class);
      intent.putExtra("ID", "120");
      return intent;

  public void signUpActivityTest() {


Start Activity from another Application


We want to start Notification Activity in FSB app from our app, To doing this we have two different solution:

1. By set component

Intent intent = new Intent();
intent.setComponent(new ComponentName("application-package-name","class-path"));

For example FSB application package name is “” and Notification Activity class path is “” so my ComponentName should be like this:

intent.setComponent(new ComponentName("",""));

2. By action name

You should add “intent-filter” for the target Activity (NotificationActivity) in “AndroidManifest.xml” like this:

<activity android:name=".features.main.NotificationActivity">
      <action android:name="action-name" />
      <category android:name="android.intent.category.DEFAULT" />

For action name you define, it’s best to use the package name as a prefix to ensure uniqueness. For example, a NOTIFICATION action might be specified as follows:

<action android:name=""/>

Intent should be like this:

Intent intent = new Intent("unique-action-name");
intent.putExtra("title", "my custom title");

You can get extra data in target activity like this:

protected void onNewIntent(Intent intent) {
   String title = intent.getStringExtra("title");

Note: Do not use onCreate method because if your activity’s launchMode was set to singleTop the onCreate method will not call if activity is already loaded in memory.

Which Activity should we use?


There are four different activities:


Every activity inherits from this one.

This class doesn’t support fragment until API level 11.

This class doesn’t support nested fragments until API level 17.


This class is from appcompact-v4 library.


  • Supporting nested fragments
  • Loader

To use this class you should add below dependency to

compile ''


This class is from appcompact-v7 library.


  • Supporting all v4 features
  • Material Design

To use this class you should add below dependency to

compile ''


This class is the old name of AppCompatActivity. For various reasons they changed the name.


  • If you want support Material Design look and fragment under API level 21 you should use AppCompatActivity
  • If you want support nested fragments under API level 17 you should use FragmentActivity
  • If you want support fragment under API level 11 you should use FragmenActivity
  • Else use Activity