How to clear Associate Android Developer exam?

If you are an experienced android developer or you are looking for a job opportunity in android and you are looking for the way to qualify and certify your android application development skills, Associate Android Developer Certification is the one you should be looking for.

In this article, you will know, how you can apply for the certification and how you can crack the exam.


What is Associate Android Developer?

Google introduced the Associate Android Developer Certification at Google I/O 2016.

The Associate Android Developer exam demonstrates the type of skill that a newer Android Developer should have as they begin their career. By passing this exam and earning the Associate Android Developer Certification, you will show that you are competent and skilled in tasks that a developer typically performs.

Here is the introduction video, which will give you more insight into the program.


How to apply for the certification?

To apply for the android certification, visit the Google Developer Certification website and sign up for the exam.

The fee for the exam is $149 or INR 6500 while writing this post. You can pay the fees using available payment options.

Once you pay your exam fees you can start your exam whenever you want.


What things should you learn before starting the exam?

AAD exam is to check your skills in application development.

Before applying for the exam you must have good knowledge of following areas:

1. Testing and Debugging:

  • You should be able to analyze application crashes and find common bugs such as layout errors and memory leaks.
  • Also, you must have the knowledge of writing the espresso test cases and unit tests.

2. Application User Interface (UI) and User Experience (UX):

  • You must have the knowledge of how to construct layouts–using both XML and Java code for the standard framework UI elements as well as custom views.
  • You should have knowledge of creating custom views, applying themes to the views, implementing RecyclerView, apply accessibility description to view.
  • You should also know how to localize the application’s UI text into one other language

3. Fundamental Application Components:

  • You should have good knowledge of handling the activity and fragment life-cycle, orientation changes, data loaders, deep links, notifications, async tasks and integrating code from external support library.
  • You must have knowledge of handling background services and schedule a task using alarm manager.

4. Persistent Data Storage:

  • You should have good command over creating SQLite database and querying it.
  • You should have knowledge of content provider and shared preferences.

5. Enhanced System Integration:

  • You should be able to create a widget, update the widget and also creating and updating the notifications.

Once you are prepared with all the above areas, apply for the exam. Let’s see the exam procedure in detail.


What is the exam procedure?

AAD exam is made up of two rounds.

  1. Practical exam, where you will write real code.
  2. An exit interview.

Practical exam:

null

Practical exam will be 48 hours long.

Google certification team will provide you the source code of one application and the list of tasks you need to perform. You need to complete those tasks before 48 hours and submit the application source code.

These tasks are divided into three categories:

1. Build some code from scratch.

  • In these types of tasks, you have to develop some functionality in the application from the scratch. These tasks may ask you to develop some activity, create database structure or implement a content provider for the application.
  • To complete these tasks you will require a good knowledge of all the above-described topics. Also, it is very important that the code you write should follow proper coding guidelines and it doesn’t break any existing functionality.
  • Check the implemented functionality with edge cases (e.g. rotation changes, network conditions) before you submit your application code for review.

2. Add new functionality to your existing code.

  • These type of tasks ask you to build something upon the existing functionality. You will also find ‘//TODO‘ comments throughout the code provided while starting the exams. e.g. These tasks may ask you to create a table in existing database, display some list items in the existing activity using RecyclerView etc.
  • To complete these type of tasks you must have sound knowledge of Android components. Also, you need to see that you don’t make any changes in the existing code or change the name of the classes/methods.
  • Check the functionality you worked on, thoroughly before submitting the code to review.

3. Fix bugs in existing code and test the application.

  • These tasks are specifically designed to check you testing and debugging skills. These tasks may ask you to fix some existing bugs in the application code and also ask you to write some espresso tests to test the application.
  • To complete these tasks, you must have knowledge of how to instrumentation and unit tests. You must know how to write test cases in espresso.
  • Before submitting your code it is advisable that you run your test cases and make sure that all tests are passing.

After completing all the tasks, upload your code in .zip format and submit the code for review. You will receive the result for the same within 45 days.

Exit interview:

null

Once you pass the practice exam, certification team will ask you to choose your convenient time for the exit interview. This will be a chance for you to explain your work and your knowledge.

The exit interview will be taken by one of the members from the certification team. It will be through a video call.

You have to provide proof of your identity using any other government authorized identity card at the starting of the interview.

After that, the interviewer will ask you to explain your work and the tasks you performed in the practical exam. The interviewer will also ask you some questions related to fundamentals of the Android to validate your skill level. The exit interview will take about 15 to 30 minutes.

Once you complete the interview, you will receive the final result within a couple of weeks.


How are you going to receive your badge?

  • If you pass the exam you will also receive your “Android Associate Developer” badge in the email with which you applied for the exam.
null
My AAD Badge
  • You will also receive an authentication link from the certification team, that you can share on your social media profile and mention it in your resume. This link will contain your badge details and authenticates you as AAD. (Here is the link to my badge: http://bcert.me/svygckgc.)

 


Should I apply for the exam?

Yes, definitely!!!

  • Android Associate Developer certification will authenticate your skill as an android developer. It will help you to increase your career opportunities if you are an employer. It will also help you to get a good job if you are a fresher.
  • Right now this is the only way to authenticate your skills and let the world know about your android development knowledge.

If you have any questions regarding the exam, feel fee to write it as a comment below or you can hit me twitter at @kevalpatel2106.

Best of luck for your exam!!!😃

How to handle background services in ANDROID O?

Nothing makes an android developer more crazy than a new version of Android.

Google has just revealed the DP1 of the next iteration of android: Android O. There are many new exciting features and under the hood performance improvements in the newest version of android.

While others talk about what will be the name of Android O, let’s analyze this flavor of android from developer’s perspective. For android developers there are four groundbreaking changes:

  • Background execution limits
  • Location updates limit
  • Removing of implicit broadcasts
  • Notification channels

Here, in this article let’s talk about background execution limitation. Background execution limitations mainly apply to two major components:

  • Service
  • Wakelocks

Let’s talk about the limitations applied on services in this article.


What is the service in android?

Let’s first refresh what is the service in Android? As per the android documentation:

A Service is an application component that can perform long-running operations in the background, and it does not provide a user interface.

So, fundamentally Service is the same thing as the activity but it doesn’t have the UI component in it. So, it doesn’t have to perform smooth animation at 60 fps. That’s why it can run perform any task for the longer period of time than the activity.

There are three types of the service:

  • Started Service — A service is started when an application component (such as an activity) calls startService().
  • Bound Service — A service is bound when an application component binds to it by calling bindService().
  • Scheduled Service — A service is scheduled when an API such as the JobScheduler.

Background vs Foreground applications:

To learn background execution changes, we need to know the difference between background and foreground application first.

Rule of thumb, your application will be considered as a foreground service if any of the below three cases are true:

  1. Your application has currently visible activity.
  2. Your application has foreground service running.
  3. Your application is connected to another foreground app by binding the service or by consuming their content providers.

If any of the above scenarios is not true in the current instance, your application is considered to be in the background.


Why do we need to restrict the use of background services?

Whenever your applications run in the background using services, your application consumes two precious resources: 1) Memory and 2) Battery.

These two are limited resources on the mobile devices and most of the low to mid-range devices doesn’t have plenty of memory or battery inside it.

Suppose, if your application is doing some very intensive tasks in the background and using the larger amount of RAM to perform that task, then this will create the very junky user experience, especially if the user is using another resource-intensive app, such as playing a game or watching a video in the foreground.

As per the documentation for the started service the best practice is,

When the operation is complete, the service should stop itself.

But, many applications have long running background services, which basically runs for the infinite time to either maintain the socket connection with the server or monitor some tasks or user activity. These services create battery drain and also they constantly consume memory.

From past couple of releases of android (Starting from Marshmallow), Google is trying very hard to increase the battery life and reduce the memory consumption used by the applications by introducing the doze mode and app standby by delaying the background execution by some amount of time if the phone is ideal.

But most of the time despite of knowing the downsides of the long-running services developers still use them. (Mostly because it is easy to implement and maintain rather than using other workarounds.)


What are the limitations on services starting from Android O?

Starting from Android O, if your application is in the background (check above three conditions), your application is allowed to create and run background services for some minutes.

After some minutes passed, your application will enter in the ideal stage. When your application enters in the ideal stage, the system will stop all the background services just like your service calls Service.stopSelf().

And here comes the fun part…

As I discussed above, the problem of battery drain and memory consumption are mainly caused by started services. To eliminate this, Android O completely prevents the use of startService() method to start the service. If you call startService() on Android O, you will end up getting IllegalArgumentException 😲.

1*e6OC5HRUY949JdG89JpXVw.gif

There are some exceptions in these scenarios when your application is whitelisted temporarily for some time window. During this period, your application can create background services freely. The application will put into temporary whitelist under below situations:

  • When high priority FCM message received
  • Receiving a broadcast.
  • Executing a PendingIntent from a notification.

How can you run background tasks?

If you are building a very large android application, there might be some genuine scenarios where you need to perform some tasks in background. Since starting a service using startService() command is not an option, we need to find out other ways to perform the tasks in background.

Scheduling your tasks using Job Scheduler API:

  • JobScheduler API introduced in API21 to perform background tasks.
  • This API allows you to run scheduled service and the android system will batch all the services from different applications and run them together in some particular timeframe. The reason behind this is to reduce the amount of time your phone’s CPU and radio wakes up by batching the tasks together. This will consume less battery and maintains system health.
  • What if your application has minSdkVersion < 21? In this situation, the official way to schedule the job is to use Firebase Job Dispatcher. Firebase Job Dispatcher is supported to all the way down up to API9.

Use foreground service:

If you want some long running tasks to be performed in the background, consider using foreground services for that. None of the above background execution limitations applies to the foreground services.

This will also keep your user aware that your application is performing some background tasks by displaying the ongoing notification. This will increase transparency with your user.

Before Android O, if you want to create foreground service, you usually start a background service by calling startService(). Then after you can promote your service to the foreground service by assigning an ongoing notification using startForeground() method. But starting from Android O, you cannot use startService() anymore. So to create foreground service you have to use NotificationManager.startServiceInForeground(). This method is equivalent to creating background service and promoting it to the foreground service combine.


Conclusion:

These limitations applied to the background service will definitely provide extended battery life and also lower RAM usage. Ultimately it will make your applications smooth and your user happy.

Should you make changes in your application code now?

Android O is still in DP1. There are 3 more developer previews to be release before the final version of Android O gets released. There might be some API changes in upcoming releases. So, right now it’s time to think the effects of these changes in your application and think about the alternative solution for them. Once developer preview 3–4 gets released, apply those changes to your applications and make your application Android O compatible.

How you can decrease application size by 60% (In only 5 minutes)?

Mobile devices always have limited resources. They have a limited amount of battery, limited storage, limited processing power, limited RAM, limited internet connectivity … and the list goes on. This doesn’t matter if you are targeting Android or iOS. This is the universal truth.

In past couple of months, I was developing an android application Anti-Theft Screen Lock. This application capture image using device’s front camera, play alert whenever someone entered the wrong password to unlock the device. If you want to know more here is the play store page, go ahead and read the description:

http://bit.ly/2lLDOML

Here, I am going to tell you about some simple the tweaks and tricks I applied to decrease the application size. These tricks are very simple and easy to apply. These may help you in your current/future applications too.


Smaller is always batter:

As a developer we always care about the application performance, design and user experience the most. But, most of the developer forget (or underestimate) one thing: Application Size. This is one of the key factors if you want to target next billion users with your application.

There are more than 11000 android powered devices available on the market and most of them are having low-end configurations, limited storage capacity (1GB to 8GB of internal storage) and even 2G or 3G connectivity. These devices are having major market share in developing countries like India, Bazil or countries in Africa etc, where you can find your next billion users.

Keeping your application size optimum becomes very important. The less your application uses storage, the more user gets more free space to store their videos and images. Let’s be honest, you don’t want your user to uninstall your application because of “Storage out of space” notification.

1*cjMsR_IEniBq3SXQ3YtJ6g.jpeg

These developing countries are also having the limited 2G/3G connectivity. So, if your application is large in size, it will take the larger time to download the application (And more chances that user won’t download it in the first place). Also, most of the users are having a limited amount of internet data. Every byte user uses to download the application, will affect your user’s wallet.

So, it is clear that in the world of mobile application,

Smaller is always better.


Breakdown your APK using APK Analyser

Android studio provides a handful tool: APK Analyser. APK Analyser will tear down your application and let you know which component in your .apk file is taking the larger amount of space? Let’s have a look in Anti-Theft screen lock apk file without any optimization applied.

1*qwluezWR7KE9-raJVkAc9A.png

From the apk analyzer output, you can see that the application raw size is about 3.1MB. After applying play store compressions, the application size is roughly 2.5 MB.

As you can see from the screenshot, there are main 3 folders that are consuming most of the application size.

  • classes.dex — This is the dex file which contains all the bytecode files of your java code that will run on your DVM or ART.
  • res — This folder includes all the files under your res folder. Most of the time this will contain all the images, icons and raw files, menu files, and layouts.

1*8ITi0D6JrpibvAC9iTG2rA.png

  • resources.arsc — This file holds all the value resources. This file contains all the data you have under your different value folders. This resource contains strings, dimensions, styles, integers, ids etc.

1*B1MMigEQSVfKIJRmujeIag


So, now you know what an APK is made of. Let’s see, how can we decrease the application size by optimising one by one component.

Reduce classes.dex:

As we discussed, this contains all the java code. While you build your application, gradle will combine all of your .class files from all the modules and convert those .class files to .dex files and combine them in single classes.dex file.

If you are curious, how the compilation process works, visit my another blog post : The Jack and Jill: Should you use in your next Android Application?

Single classes.dex file can accommodate, approximately 64K methods. If you exceed this limit, you have to enable multidexing in your project. Which will create another classes1.dex file to include all remaining methods. Thus the number of classes.dex file depends on the number of methods you have.

1*koKowwJQ0aavZ6-Sh1I6AQ.png

As you can see currently “Anti-Theft Screen Lock” contains 4392 classes and 29897 methods. This result is without applying proguard. You have two default proguard file you can apply.

  • proguard-android-optimize.txt
  • proguard-android.txt

As the name suggests “proguard-android-optimize.txt” is the more aggressive progurard configuration. We used this as the default proguard configuration. You can add you custom proguard configurations in proguard-rules.pro file in your /app directory.

By setting minifyEnabled to true, yo are telling proguard to remove all the unused methods, instructions and slim down the classes.dex file.

Here is the result from minify enabled APK,

 1*FPR6BZkWLBYhHs6YO9lLvA.png

As you can see by enabling the proguard in every module of our project we can we are able to reduce the classes.dex file size almost by 50%. Also, you can see method count decreased from 29897 to 15168 (almost 50%). Hurray…!!!🎊🎉

Size decreased from 3.1 MB to 1.98MB. (~50% decrease)


Reduce res:

The second largest component in your apk size is your res folder, which contains all the images, raw files, and XML. You cannot add/remove/modify your XML, as they are containing your layouts. But we can decrease the image files.

  • shrinkResourcesattribute will remove all the resources, those are not used anywhere in the project. Enable this in your build.gradle file by adding below line:
  • resConfigs attribute will remove all the other localized resources while building the application. In our case, “Anti-Theft Screen Lock” only supports the English language. While all the support libraries may have localized folders for other languages. Which we don’t need. So, add following line to allow only English resources to be added in APK file.
  • Android Studio 2.3, and you application minimum version is 18 or above, you should use webp instead of png. webp images are having less size than png files and also it retains the original image quality. More to that webp images are natively supported in Android. So you can load webp images in ImageView same as other raster images. So, you don’t have to change your layouts.

You can select drawable and mipmap folders from you project, right click and select convert to webp. This will open below configuration dialog.

1*Y51gzPlk1Pcd_0s8lqcc9Q.png

Press ok and it will convert all the png images to webp format one-by-one. If the webp image is having the larger size than png, Android Studio will automatically skip that file.

Let’s see the final result:

1*UiwJkvIhWjrNNj2DU7Z3kA.png

Volla!!! res folder size decrease from 710KB to 597KB.

Size decrease by 105KB. (Decrease by 16%)

You can also convert the images to vector drawable. But for that, you have to make some changes to make it backward compatible. If you want to learn more on vectors see this great post by Chris Banes.


TL;DR:

  • Enable proguard in your project by adding following lines to your release build type.
  • Enable shrinkResources.
  • Strip down all the unused locale resources by adding required resources name in “resConfigs”.
  • all the images to the webp or vector drawables.

Conclusion:

By applying above simple tricks the application size decreases from 3.19 MB to 1.89 MB.

These are the most simple tricks. There are many other tweaks that can reduce your application size. But, you should always apply above simple tricks to your android applications to make sure you reduce the application size as much as you can.

For more tips and tricks you can read this from Android Developers website.

Remember: Smaller is Alway Better. 😉

Glide vs. Picasso

Glide and Picasso are the most used image loading library in the world of android applications. Most of the android application developers have used any of these or both libraries in their career. Both libraries provide number of features, very fast and optimized. They are also well tested on many applications. On the surface, it looks like both are working on the same mechanism. But they both are very different in the way how they download images, caches images and loads them into memory. Today, we are going to look into the core differences between both the libraries and try to figure out which one is the best for application development.

We are comparing Glide v3.7.0 and Picasso v2.5.2 versions for this article. The latest available version might be different depending on when you are reading this article.

Import to the project:

Picasso and Glide, both are on jcenter. You can simply import those into your project with below dependency.

Picasso:

Glide:

support-v4 dependency is not needed for most of the projects as most of them uses support library by default.

Size and Method Count:

While comparing the sizes of the .jar file of both the libraries, Glide is almost 3.5 times larger than Picasso in size.

1rqe23b0xa6fpd6zopjx2aq

Picasso has method count of 849, while Glide has total 2678 method count. 2678 is quite a lot for 65535 methods limit of Android DEX file. You should enable ProGuard if you choose to use Glide.

1se-djihhpw8iwf4gij66aa

Syntax:

Both libraries have almost same syntax if you want to simply load the image from the URL and display them into the image view. Both support the fade animations and center crop. You can also add placeholder image to display while loading the image or while the image loading fails.

Glide:

Picasso:

One thing in which Glide dominates is, it is designed to work with Activity and Fragment’s life cycle too. You can pass the activity or fragment context with Glide.with() and it will brilliantly integrate with activity lifecycle callbacks such as onPause() or onResume().

1*Luh0ueUaCghrAywvkMxE4Q.png

Disk caching:

Both the library supports caching the image in the disk. They download the images from the URL and store those images on the disk by caching. But there are some differences how they store the images in the cache.

Picasso downloads the image and stores the full-size image (in my case the image resolution was 1160*750) in the cache and whenever we ask for the same image, it will return the full-size image and resize them to fit into the ImageView in real time.

On the other hand, Glide works differently. Glide downloads the image from the given URL, resize it to the size of the image view and stores it to the disk cache. So if you are loading the same image in two different sized image views, Glide will store two different copies of the same image in the cache with different resolutions. That will increase the disk cache size, but it has some of its own benefits. We will see that in the next section.

When I tried to adjust ImageView to the different sizes, Picasso cached only single size of the image and that is full-size. While Glide caches separate files for each size of ImageView. On down point of this approach is, although an image has already been loaded once, if you need to load the image in another size ImageView, it needs to be downloaded once again before be resized to the right resolution and then be cached.

Memory:

By default, Glide uses RGB_555 configuration while Picasso loads images in ARGB_8888 configuration to load the bitmap into memory. So for fair comparison, I made some changes in GlideModule to load images in ARGB_8888 format by creating a new class which extended from GlideModule like this:

Below is the graph of memory consumption of loading the image in Glide and Picasso:

1*-TOjFF8NJ6W7bmHZycjDtw.png

By looking into the graph, we can see that Glide is more memory efficient (about 8 MB) than Picasso (about 13 MB). This is pretty much understandable as we discussed in the earlier section, that Picasso loads the full-size image into the memory and relies on GPU to resize that image to fit into the size of the ImageView. While Glide loads an image that is already resized as per the ImageView, that requires significantly less memory than loading the full image like Picasso. This helps to prevent your app from throwing popular OutOfMemoryError.

Time taken to load the Image:

When we try to load an image from the URL, both libraries checks their local caches and if the image is not present in the cache, they will download the image from the URL.

When I tried to download images from the URL, Picasso was quite fast in loading the image from the internet than Glide. Maybe because after downloading the image, Picasso directly pushes the full-size image to the memory; while Glide resizes the image as per the dimension of the ImageView. That needs some time to resize the image. (You can reduce this time by using thumbnail() which we will discuss in later section.)

1*P7b1K_pp494aPLZ2sFI3Sw.gif

But while loading the image from the cache, Glide wins the battle. This is because of an advantage of the way Glide was designed. While the Picasso causes some delay on loading since it needs to be resized the image first in real-time before images are set to an ImageView. Even if you use .noFade()to appear it instantly.

1*0nIGJyOVgut-kCDMbu3kIg.gif

Other features that Glide support but not Picasso:

  • Animated GIF support: Glide supports animated GIF images out of the box. Loading GIF is simple. Just use the same Glide.with(...).load(...)call and if the image you load is an animated GIF. Also, because of Glide integrates with your activity life-cycle, animated GIFs are also paused in onStop() to avoid draining the battery in the background. While as of now, Picasso does not support animated GIF images. So, if you want to display some animated GIF, then Glide is the only option here.
  • Thumbnail support: With Glide, you can load multiple images into the same view at the same time. To first load a thumbnail at 1/10th the size of your view and then load the full image on top, you can use below code:

 This will reduce the time your user has to see image loading spinners without sacrificing quality.

  • Configurations & Customization: One good thing about Glide is, it provides various conflagrations and customization options. So, you can tweak Glide library as per your requirement. You can read more about this at configuration page.

Conclusion:

Neither Glide nor Picasso is perfect. You can use any of this library based on your application requirement. If you want the smaller app and you require very fewer features in the image loading, than Picasso is best. But If you want more customization, animated GIF support, and very better memory management, you should use Glide as your image loader library.

In my opinion, Glide is the winner over here as it handles memory very well and prevents my app from OutOfMemoryError. Also, loads image much faster than Picasso. And yes, the support for animated GIFs is almost killer.

References:

How to decrease your Gradle build time by 65%?

Gradle is very powerful build system. It handles the very complex process of building .dx files from java source code, merging all the resources and assets into the application package (.apk) and signing the application.

But gradle isn’t perfect. It is comparatively slower than other build systems out there.


Why should you care about build time of your project?

For a long time, I was OKAY with my build timings. I thought I can live with this. I used to do other stuff like surfing the internet, making coffee and even taking my lunch while gradle builds my project.

Now, let’s say you work on the above I/O’16 application project for 6 hours a day and run gradle build to install debug apk file on your test device for almost 15 times, you will spend 35 minutes a day and almost 3 hours/week(almost 10% of total time) just sitting idle and watching gradle build running.

That’s why it is very important that you optimize your build timing. The less time you spend watching gradle build your project, the more you can be productive. After all, time is precious.

I applied some modifications in my build process to decrease the build time and here are a few tips for you that will help you to decrease your build timings.


Here for example purpose, we will use Google I/O application as the sample project. We are going to run all the benchmarks on that project. This project contains more than 28 dependencies and 41538 method references. Also, the source code of the application is openly available on GitHub.

1d3wzkk8xca6siekdwgzclq


Build without any modifications:

Let’s measure the time to build and debug app from the project with the current configuration using below command.

./gradlew android:assembleDebug --profile

— profile will tell gradle to measure the time taken to execute each task and dump that data into HTML file. You can find that report under /projectDir/build/reports/profile directory.

1*owSs_JMY2F5KkOziRaRolg.png

  • As you can see it takes 2 minutes and 43 seconds to build the debug apk from the source on my machine. Keep this figure in your mind.

These benchmark timings may vary on your machine depending on your system configuration. Here I am going to use my 13″ Macbook Pro 2016 with touch barto run all these tasks.

Now, let’s try to decrease this time.


Gradle Build Cycle:

Gradle has three distinct phases in build life cycle:

  1. InitialisationIn this stage of the build life cycle, gradle picks the project and decides what things to build.
  2. ConfigurationHere, gradle will evaluate your build.gradle script, configure all the plugins and evaluate the task graph.
  3. ExecutionIn this phase gradle actually runs all the task those were evaluated in previous phase to get the work done and build the application.

As you can see that out of all three phases, only execution phase performs all the operations. That means that first two phases are just overhead to the gradle build process. We don’t care about them. But, sadly whenever you do anything with gradle this two phases will always get executed.

So, how can we measure the time taken to execute first two phases? Luckily, gradle provides — dry-run command, that tells gradle to evaluate the project but don’t run any task. Thus execution phase won’t get executed. So, run this command in your terminal:

./gradlew android:assembleDebug --dry-run --profile

Here is the time taken by first two phase on over Google I/O project.

You can see in above statistics that gradle passed almost 7.8 seconds just to initialise and configure the project. That is completely waste of time for us.


Let’s see if we can decrease the time taken to initialise and configure the project.

Configure on demand:

Google I/O app has two components/modules:

  • Android : That contains the source code related to the andorid application and
  • Server : This contains code related to backend server.

Now, if you are building an android application, you don’t want to configure server component. Right? But previous statistic shows that gradle passed almost a second to just configure server component.

Gradle provides — configure-on-demand flag, that will tell gradle to only build the projects that it really needs to build. Let’s run this command.

./gradlew android:assembleDebug --dry-run --profile --configure-on-demand

As you can see, if we use — configure-on-demandgradle will skip configuring the server module and it will decrease the build time by almost a second. I know this is not a huge gain, but small drops can fill the whole lake!!!

Time decreased : 1 second (6% win).

How you can enable configure-on-demand in android studio?

You can enable — configure-on-demand for every build you can add org.gradle.configureondemand=true in your gradle.properties file or in your android studio, navigate to Preferences > Build, Execution, Deployment > Compiler and check configure on demand option.

1*MBn53rnxIQdfEIWMp9JOOw.png

Enable daemon:

Gradle has a very good feature called Gradle DaemonDaemon keeps the instance of the gradle up and running in the background even after your build finishes. This will remove the time required to initialize the gradle and decrease your build timing significantly.

You won’t be able to see the time difference in your first build as gradle has to initialize and start the daemon, but build times will decrease in subsequent builds as gradle daemon is already initialised.

./gradlew android:assembleDebug --dry-run --profile --configure-on-demand --daemon

1hdjpmnafvlwiwhf4eaqj1q

In our case, the build time is decreased by about 4.5 seconds. Hurray!!!

Time decreased by : 4.5 seconds (71% win)

How you can enable daemon in android studio?

If you are using the gradle version 3.0 or above, the gradle daemon is by default enabled. But, if you are running on older versions of gradle then you can enable it for every build by adding org.gradle.daemon=true in your gradle.properties file.

Always keep your gradle up-to-date:

Gradle itself got faster with each new releases. There are many tweaks and performance improvements in the latest versions of gradle. Also, if you are running on gradle 2.4 or above, gradle will also cache build artifacts and that will improve the build time significantly.

So, always make sure that you are using the latest version of the gradle. You can go to /gradle/wrapper/gradle-wrapper.properties and upgrade gradle version by changing distributionUrl.

While writing this article, the gradle the latest gradle version is 3.3. Here is the updated gradle-wrapper.properties file for I/O application.1*77iuK0YxGUcRmcTPNHpeXg.png

./gradlew android:assembleDebug --dry-run --profile --configure-on-demand --daemon

1*s4ymdQIRaAgpZy_h6Yja8A.png

Time decreased by : 0.7 seconds (82% win 🍾)


So far we achived almost 82% gain in initialise and configuration timings. Now, let’s try to decrease the time required in execution phase.

Increase the heap size:

Since android studio 2.0, gradle uses dex in the process to decrease the build timings for the project.

“Dex in process” is a process that allows to run multiple dex processes to run within the single VM that is also shared with the gradle.

Generally, while building the applications, multiple dx processes runs on different VM instances.1*L-XJGmxyWGvmqYErQ7klZw.png

But starting from the Android Studio 2.0, all these dx processes runs in the single VM and that VM is also shared with the gradle.(You need to have build tool version 23.0.2 or above to enable dex in the process.)

1*6JRzZijRNkHPHlbyUIlaFQ.png

This decreases the build time significantly as all the dex process runs on the same VM instances. But this requires larger memory to accommodate all the dex processes and gradle. That means you need to increase the heap size required by the gradle daemon. By default, the heap size for the daemon is about 1GB. You have to increase the heap size by adding below line in your gradle.properties.

org.gradle.jvmargs=-Xmx3072m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

The required heap size varies from machine to machine. For my machine, I found that 3GB heap size is perfect. Any more increase in the heap size doesn’t affect the build timing significantly.

Now, let’s run full clean build using the below command:

./gradlew android:assembleDebug --profile --configure-on-demand --daemon

1*2Bi_Rwf7ySeveu-Icl7nWg.png

Time decrease by : 1 min 43 sec (63% win) — From 2 min 43 sec to 1 min

Modularise and Parallelise build:

Allow gradle to build your project in parallel. If you have multiple modules in you project, then by enabling this, gradle can run build operations for independent modules parallelly. This may decrease the build time significantly for very complex and multi-module projects.

You can enable parallelism by adding org.gradle.parallel=true in your gradle.properties file.

As our project doesn’t have multiple modules, building parallel won’t make much difference.

1*YnJyE8U214HG_4aHinXn1w.png

Time decrease by : 1 min 45 sec (64.5% win)


Other small things to remember:

Avoid heavy computations, like increasing the version code from git commits count or downloading some files from url while building the project. Gradle will spend time to perform those computations or network operations and that will afftect build timings.

Don’t use dynamic dependency like,

compile 'com.android.support:appcompat-v7:23.0.+'

If you are using the dynamic dependencies, gradle will go online and check if there is any newer version for the library is available or not? (Most of the time, it is just waste of the precious build time). Instead, use the fixed dependencies and update them manually time to time.

compile 'com.android.support:appcompat-v7:23.0.2'

TL;DR:

The long story short, add below lines to your gradle.properties file and you will get almost 65% decrease in your build time.

 <gist>2fbf175066a0cadbb3af1008954ed077</gist>

1*5Fmeh0sckqPGpgBbybARHQ-2.jpeg

Continuous Integration and Code Coverage in Android using Travis CI

Testing has always been a trending topic in the world of Android. It becomes a time consuming task in large android projects where multiple developers are working together, maintaining the code quality and resolving bugs; which is a very difficult task.

This is a very serious issue in the open source projects where multiple developers from different environment and different level of expertise contribute to a single code base. Everyone is not the perfect and someone can commit changes that break the application code and we should have something that can alert us if someone is doing something wrong as soon as possible.

It would be great if we can find out that whether the code we are going to push onto our master branch of repository contains any possible bugs that can break the system. Here, continuous integration comes into play.


What is Continuous Integration?

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

In simple words, each time you commit and push your code to the remote repository, continuous integration will check if everything is working correctly in the code before you merge it into your master (assuming you are using git for version control).

With continuous integration, you can:

  •  Automated build process. Every commit/push to a git repo will automatically trigger a new build.
  • Find out Android Lint errors.
  • Coding styles to ensure that the new code is matching the code format that your team has decided.
  • Get the code coverage percentage. This will be really helpful to figure out if any part of the code is remaining to test.
  • Run Unit tests located on your /test directory of project.
  • Run Instrumentation tests located in your /androidTest project.

How to configure Continuous Integration?

As the title of this post suggests, here I am going to use Travis CI. You can use other services available to the market like CircleCI, Codeship, etc. But here, I will stick to Travis CI as it is most used CI service for GitHub projects and also it is free for Open Source projects.

Prerequisites:

  • An account on GitHub. I believe nowadays every developer has it.
  • An account in Travis CI. If you don’t have it yet you can create it from here.

Let’s start with the integration. For the demo purpose, I am going to use API 25 as the targeted Android version in our Gradle and we are going to test our build on API 21 and API 19.

We have skipped the description of some lines as we don’t want to make this article too long and boring. We will concentrate more on the lines which are more important and difficult to understand.

Step-1 : Creating .yml file

First, create a .travis.yml file into your project’s root directory. This file will contain the configuration script for the automated build testing.

1fshca7ehyvosixq8sczwca

Step-2 : Basic setup:

Add above lines at the starting of the file. This basically tells Travis that this repository is an android application source code and it has to use Java 8 for compilation. The notification section will provide email notifications on the email you provided whenever a build gets completed successfully or fails due to some error.

Step-3 : Defining android targets:

Next, add above lines to your .travis.yml file. The line under the matrix section defines the Android API version and the processor architecture, on which the code will be tested. These lines re-executes the script for each variable. So if I write another line with: “– ANDROID_TARGET=android-16 ANDROID_ABI=armeabi-v7a”, it will execute the whole script with the 21, 19 and 16 APIs. We can say it is really useful to test different API levels. So, each commit you push to the repository will start two separate builds and test prepossess. You can see this in Travis dashboard like below.

1xrxjad5hawop4pgcypscpa

In the global section, you can declare any global environment variable that is required to successfully complete the build process. This field is optional. Here, we defined “ADB_INSTALL_TIMEOUT =10”. This will increase the ADB connection timeout to 10 mins. Normally, it is 2 minutes by default.

Step-4 : Setting up the build configs

The android section contains the build related configurations. Specify the build tools version, targeted android API and extra repository you required to complete the build process like play services, m2repository, etc. At the end, specify emulator system images on which application testing will be performed. If you are going to use more than one API levels like this example, remember to define all the emulators needed. In our case, we are going to perform a test on API 21 and 19. So “sys-img-armeabi-v7a-android-25”, “sys-img-armeabi-v7a-android-18” are required emulator images.

Step-5: Enabling caching of resources:

Travis can cache directories that you need to speed up the subsequent builds by caching the Gradle dependency folders. To enable the caching, you have to specify which directories you want to cache under the cache section. Here, I am caching some of the .gradle folders.

Step-6: Writing build script:

In every project, we need to run the instrumentation tests. So we will run the emulator using “emulator -avd test -no-skin -no-audio -no-window &”. “ android-wait-for-emulator” script will wait until emulator is up and running. This will print “Waiting for emulator” in Travis log until emulator starts. The next two lines are printing the available devices for our information and sending the key “menu” to the emulator to unlock it.

Make sure you are using supported android targets and android ABI. You can list out supported android targets by running “android list targets”. You will get list of the supported android targets for given build environments in Travis log window like below:

1*he10rbUQvNTLQQ1IRAUeDQ.png

Step-7: Enabling code coverage:

Code coverage is the best way to motivate you and your team to write more tests. Once we launched the tests and connected tests on Travis, we can generate the code coverage report with all the results. Once the jacoco (Java Code Coverage library) report is generated, it uploads all the reports tothe codecov server. You can see these reports online. (If you don’t know how to integrate jacoco in your android project, we found this article very useful. Or you can see the sample project, created by the codecov team.)

To run the code coverage after every successful build, you can integrate codecov by adding below lines in .travis.yml.

Congratulations! We completed all the required changes in our repository.

Your final .travis.yml file should look like this:

Step-8:

We are almost there. Stay with us. Now, sign in to Travis CI website and go to “Add new repository”. Select the repository in which you integrated .travis.yml file and enabled the Travis integration.

1ul3byu0joekdm2f68wqn7w
Enable travis integration by clicking the switch

That’s it. You are ready to push your commit with .travis.yml file.


Run your first build:

As soon as you push the commit to your GitHub repository, Travis will start building the project automatically. You can see the past build history by going to the “Build history” tab.

1utqdiqolts5wgkelt8ua-g

You can see your build status (whether it is running, passed or failed) right behind your GitHub repository commits list.

1*f4OxepYumczZgVvwV1cmqw.png

At this stage, if your build fails, try to find out what went wrong. You can find answers on how to fix those bugs on StackOverflow or paste your error in the comments below. We will try our best to resolve those the errors.

Here is one sample project to help you:

You can also find the test project that we used for the demonstration purpose in this tutorial in the below link. Go ahead and take a look into it.

https://github.com/multidots/Android-Automated-Test-and-CI-Demo

This is an sample application which validates email address you entered in edit text. Here, we integrated Travis CI and CodeCov using Jacoco. You can see all the build statuses in Travis CI from here. If you want to see the latest code coverage report for the project, you can find it over here. This will give you an idea of how code coverage report looks like.


Conclusion:

Continuous Integration (CI) is one of the good practice while developing the code. This lets you and your team concentrate on development and reduces the efforts required for maintaining the code. By outsourcing the maintenance of your test infrastructure, you can remove a whole bunch of work from your engineering team that can then be used to build your product. On another hand, code coverage gives you better idea of the amount of code remaining to test and inspires your team to write better test cases. As an overall effect, they both together help you and your team to develop robust product and allows you to deploy your code with confidence.

Code your next android app using RxJava

RxJava is new hot topic in the world of Android Development. The only problem is that it is very difficult to understand. Especially, Functional reactive programming is very hard to understand when you come from Object Oriented Programming. So, I am developing a series of articles to help you understand the basic concept of Reactive Programming.

In the previous Part 1we get the basic concept of the reactive programming. If you did not read yet, I will encourage you to first go through Part 1 and get the basic idea about reactive programming.

As we discussed in Part 1, Rx is made up of three key component.

RX = OBSERVABLE + OBSERVER + SCHEDULERS

Let’s create each component one by one. But, first let’s start with integration.


Integrate RxAndroid in project

RxAndroid is basically an android specific wrapper that provides some functions explicit to android and those are not available in RxJava. So, if you want to integrate Rx into your java project only, you don’t need to implement RxAndroid library into your project.

Here is the gradle dependency of RxJava and RxAndroid.

The version of both the library may change, depends on when you are reading this article. You can find latest version from here.


Marble Diagram

Rx uses marble diagram to explain how any operator works. Marble diagrams are very convenient and easy to understand.

  • The line above the box indicates the raw data. This data needs to be emitted by the observable. Different types of objects are display with different shapes.
  • Box in the middle indicates operator. There are many other operators available, that basically controls when and how the observable should emit the data. We are going to look into those operators in future.
  • The line below the box indicates the data that is emitted by the observable. Observer in Rx receives this emitted data.

filter


Let’s create Observable

As you know observable is nothing but a function that emits the data stream. Below is the observable that emits 1 to 5 one after another.

Here just() is called as an operator. It emits the values provided in arguments. (And that’s why they named as just.)

0bhyoyg_o-glxlikv

Sometimes we want to refine specific event only to be emitted by observable. Let’s say in our above example we only want to emit only odd numbers out of the observable. We can achieve this thing using another operator called filter(). As the name suggest filter operator filters items emitted by an Observable.

06oy3ienx8ysblul


Creating observer

Observers consume the data stream emitted by the observable. Wheneverthe observable emits the data all the registered observer receives the data.

In RxJava there are three callbacks you are going to receive in an observer.

  • onNext() : This method will be called when there is any new data emitted by the observer. The object that is emitted by the observable can be found in argument parameters of this callback.
  • onError() : You will receive this callback whenever there is any error occurred on observable. (After all the world is not perfect.)
  • onComplete() : Whenever observable is done with emitting the data streams, you will receive this callback. This indicates that there is no more data to emit.

In many cases you don’t care about onCompleted() or onError(). So instead of using Observer<T> we can use a simpler class to define what to do during onNext() using Action1 class.

Here, onCall() is equivalent to onNext() in our first approach.


Manage concurrency using Scheduler

As you know scheduler in the reactive programming manages the concurrency.

In Android the most common operation when dealing with asynchronous tasks is to observe the task’s result or outcome on the main thread because you want to update the UI. Using vanilla Android, this would typically be accomplished with an AsyncTask. But with Rx you can achieve this by using the schedulers.

There are two methods, which controls thread management.

  • subscribeOn() : By using this method you can define on which thread the observable should run.
  • observeOn() : By using this method you can define on which thread the observer should run.

RxJava and RxAndroid library provides some predefined schedulers. Like, Schedulers.io() indicates the IO thread. While Schedulers.newThread() will create a new thread to run observer/observable. You can find other various types of schedulers here.

Finally, we will use subscribe() to subscribe the observer to receive the data issued by the observable. This will return Subscription object that holds the reference to that specific connection between observer and observable.

Let’s see the output of above program.

16zdedxewtwsrasybxipjvw

We can see from the output that only odd numbers were emitted by the observer. At the end, when all the data are emitted, onComplete() got execute.

Unsubscribe:

If you want to unsubscribe the observer from observable, you can call unsubscribe.

In android this is essential that you call unsubscribe in onDesrtoy() of your activity/fragment to release the connection between observer and observable. Otherwise, it may call memory leak.

If you have multiple subscriptions in your class, then you can use CompositeSubscription to unregister all the subscriptions at once. Below is an example on how you can do that:


In the next part I am going to explain different operators used in RxJava. Meanwhile, If you liked the article, click the 💚 below so more people can see it!

twitter-follow