Data-binding Pros and Cons, Choose wisely

android

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.

Pros

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

Cons

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:
data-binding_unrelated_errors

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

Change text color of MenuItem in Navigation Drawer

ezgif-3-5ca8deec47

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);
        menuItem.setTitle(spanString);
      }
    
  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:

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

    switch (item.getItemId()) {
      case R.id.nav_search_jobs:
        setTextColorForMenuItem(item, R.color.nav_search);
        // do other stuff
        break;
      case R.id.nav_job_recommended:
        setTextColorForMenuItem(item, R.color.nav_recommendation);
        // do other stuff
        break;
    }
    ...
  }

That’s it šŸ˜‰

What’s your flavor?

product_flavors

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 'com.example.myapp.free'
    }
    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).

screenshot-from-2017-02-13-14-50-02

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', '"http://37.61.202.252:8580"'
    }
    prod {
      buildConfigField 'String', 'HOST', '"http://37.61.202.252:8580"'
    }
  }

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()
        .baseUrl(BuildConfig.HOST)
        .client(okHttp)
        .build();

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;

Bonus: BuildConfig.java

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.

buildconfig

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 'com.android.support.test.espresso:espresso-core:2.2.2'
}

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:

screenshot-from-2017-03-06-20-30-44

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 {
  @Override
  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 {
  @Override
  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

Espresso

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.

@RunWith(AndroidJUnit4.class)
public class UserProfileTest {

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

  @Test
  public void signUpActivityTest() {
    ...
  }
}

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

@RunWith(AndroidJUnit4.class)
public class UserProfileTest {

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

  @Test
  public void signUpActivityTest() {

  }
}

Start Activity from another Application

start_activity

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"));
startActivity(intent);

For example FSB application package name is “de.findsomebuddy.app” and Notification Activity class path is “de.findsomebuddy.app.activity.NotificationActivity” so my ComponentName should be like this:

intent.setComponent(new ComponentName("de.findsomebuddy.app","de.findsomebuddy.app.activity.NotificationActivity"));

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">
   <intent-filter>
      <action android:name="action-name" />
      <category android:name="android.intent.category.DEFAULT" />
   </intent-filter>
</activity>

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="de.findsomebuddy.app.activity.NOTIFICATION"/>

Intent should be like this:

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

You can get extra data in target activity like this:

@Override
protected void onNewIntent(Intent intent) {
   super.onNewIntent(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.

Quick Overview on Java 8 Features

android_development

After all we have some features of java 8 on android :D, lets look at them.

DefaultĀ Methods

Default methods enable us to add new functionalities to interfaces without breaking the classes that implements that interface (For more information please check this link).

Important Note: This feature just work on API levelĀ 24.

Static Methods

A static method is a method that is associated with the class in which it is defined rather than with any object. Every instance of the class shares its static methods.

Important Note: This feature just work on API levelĀ 24

Repeating Annotations

There are some situations where you want to apply the same annotation to a declaration or type use. Repeating annotations enable you to do this.

Important Note: This feature just work on API levelĀ 24

Lambda Expressions

Lambda expression facilitates functional programming, and simplifies the development a lot.
Important characteristics of a lambda expression:

  • Optional type declaration
  • Optional parenthesis around parameter
  • Optional curly braces
  • Optional return keyword

This feature is available on API level 24 and lower.

Method References

You use lambda expressions to create anonymous methods. Sometimes, however, a lambda expression does nothing but call an existing method. In those cases, it’s often clearer to refer to the existing method by name.

This feature is available on API level 24 and lower.

 

lambda

Migrating to Jack compiler

jackjill

What is Jack?
Google says:

Jack is a new Android toolchain that compiles Java source into Android dex bytecode. It replaces the previous Android toolchain, which consists of multiple tools, such as javac, ProGuard, jarjar, and dx.

What about existing .jarĀ libraries?
Jill tool translates the existing jar libraries into new library format šŸ˜€

Why we need migrating to Jack compiler?

  • Speeds compilation time
    Jack compiler can compile java code to .dex in one step

    • OldĀ toolchain:Ā javac (java -> .class) -> dx (.class -> .dex)
    • Jack toolchain: Jack (java -> .jack -> .dex)
  • Using Java8 features
  • Shrinking, obfuscation, repacking without using different tools

 

Note: Make sure your Android Studio is updated to the last available version.

To enabling Java 8 and Jack for your project your build.gradle file should be like this:

android {
   ...
   defaultConfig {
      ...
      targetSdkVersion 24
      jackOptions{
         enabled true
      }
   }
   compileOptions {
      sourceCompatibility JavaVersion.VERSION_1_8
      targetCompatibility JavaVersion.VERSION_1_8
   }
}

Rebuild your project and it’s should work without any error, But if you see below error:

Error:Could not get unknown property ‘classpath’ for task ‘:app:transformJackWithJackForDebug’ of type com.android.build.gradle.internal.pipeline.TransformTask.

It’s means you should use annotationProcessor dependency scope instead of apt.

 

Important Note: Instant Run doesn’t work with Jack.