tutorial Archives - Truiton

Android JaCoCo Code Coverage Plugin for Unit Testing

Mohit Gupt — Sat, 24 Jan 2026 04:15:45 +0000

If you have an Android app and you wish to build and deploy with confidence you might think end to end test automation is the way to go. But if one goes a little deeper and understand unit testing with its application their opinion might change. As with proper use of unit test cases one can test most of their code by just writing them properly. Therefore in today’s age most of the product and tech organizations emphasize on writing Android JUnit test cases for their Android apps. But writing unit test cases are only one part of the process, as a an engineer we also need to identify the areas to write unit test cases so that we can cover most of the code. To identify the areas of code that are covered and not covered by unit test cases we use Java code coverage (JaCoCo) plugin for Android. This tutorial is aimed to share a clean approach for integrating Android Jacoco plugin and explain its use cases in CI/CD world.

Android JaCoCo Implementation

When writing JUnit test cases for an Android app, our goal is to cover as much of the codebase as possible so that we can release with confidence. However, to identify the parts of the code that are not covered by JUnit tests, we need a tool that can generate a detailed coverage report and provide a clear view of which areas still require JUnit tests.

To generate an Android JUnit test coverage report, we can use the JaCoCo plugin. JaCoCo is not limited to Android projects; it can be used with any Java project to generate JUnit coverage reports. But, keeping the scope limited to the Android implementation of JaCoCo, let us take a look at a cleaner and more streamlined way to implement the JaCoCo plugin in an Android app project.

In your app level folder parallel to build.gradle.kts(app) file create a new file jacoco.gradle.kts and add following code in it:

import org.gradle.api.tasks.testing.Test
import org.gradle.testing.jacoco.plugins.JacocoPluginExtension
import org.gradle.testing.jacoco.plugins.JacocoTaskExtension
import org.gradle.testing.jacoco.tasks.JacocoReport

apply(plugin = "jacoco")

configure {
    toolVersion = "0.8.12"
}

tasks.withType {
    configure {
        isIncludeNoLocationClasses = true
        excludes = listOf("jdk.internal.*")
    }
}

tasks.register("jacocoTestReport") {
    dependsOn("testDebugUnitTest")

    reports {
        xml.required.set(true)
        html.required.set(true)
    }

    val exclusions = listOf(
        "**/R.class",
        "**/R\$*.class",
        "**/BuildConfig.*",
        "**/Manifest*.*",
        "**/*Test*.*",
        "android/**/*.*",
        "**/Lambda\$*.class",
        "**/Lambda.class",
        "**/*Lambda.class",
        "**/*Lambda*.class",
        "**/*_MembersInjector.class",
        "**/Dagger*.*",
        "**/*Dagger*.*",
        "**/*_Factory.class",
        "**/*_Provide*Factory.class",
        "**/*_ViewBinding*.*",
        "**/BR.class",
        "**/DataBinderMapperImpl.class",
        "**/DataBinderMapperImpl\$*.class",
        "**/DataBindingInfo.class",
        "**/*\$Creator.class",
        "**/*\$DefaultImpls.class",
        "**/*\$Companion.class"
    )

    sourceDirectories.setFrom(files("${project.projectDir}/src/main/java"))
    
    // Using specific paths for Java and Kotlin classes to avoid "different class with same name" error
    val javaClasses = fileTree("${layout.buildDirectory.get().asFile}/intermediates/javac/debug/classes") {
        exclude(exclusions)
    }
    val kotlinClasses = fileTree("${layout.buildDirectory.get().asFile}/tmp/kotlin-classes/debug") {
        exclude(exclusions)
    }
    
    classDirectories.setFrom(files(javaClasses, kotlinClasses))

    executionData.setFrom(fileTree(layout.buildDirectory.get().asFile) {
        include(listOf("jacoco/testDebugUnitTest.exec", "outputs/unit_test_code_coverage/debugUnitTest/testDebugUnitTest.exec"))
    })
}

Now that we have a separate file for Android Java Code Coverage (JaCoCo) plugin implementation, its makes our original build.gradle.kts file cleaner. To make this work we just need to add the following in the build.gradle.kts (app) file at the end:

apply(from = "jacoco.gradle.kts")

In this Android JaCoCo implementation, we just defined that we want XML as well as and HTML coverage report for the available unit test cases. Now to actually get the Android JUnit coverage report we just need to run the below mentioned gradle task:

./gradlew clean :app:jacocoTestReport

Issues faced with Android JaCoCo implementation

In a modern Android project to make Android JaCoCo implementation work properly and generate reports we need to define both compiled Java and Kotlin class directories for full coverage. Otherwise we may miss out on classes to be covered, but in a one off scenario – even when it was defined correctly, I encountered this issue:

> Task :app:jacocoTestReport
[ant:jacocoReport] Classes in bundle 'app' do not match with execution data. For report generation the same class files must be used as at runtime.

This issue states that ‘same class files must be used at runtime’ – I was wondering, does that mean that the classes were being instrumented at runtime? This made me think about the working of Firebase Performance Monitoring plugin (which was also included in my build.gradle)- it instruments the classes at runtime. Then I tried disabling Firebase Performance Monitoring SDK for debug builds using the code below and JaCoCo started working just fine. If you are also facing a similar issue, try using the same work around:

        debug {
            ...
            // Added this line for jacoco plugin
            configure {
                setInstrumentationEnabled(false)
            }
        }

When I further investigated, I found out that similar issues were reported on the firebase’s GitHub repo, hope they’ll solve this in future.

Android JaCoCo Coverage Report

As a practice when developing large scale Android apps, we tend include a lot of SDKs to solve various things for us, JaCoCo is also one of them. In Android Studio we can get coverage reports by simply using Android Studio’s run with coverage option as well. But when comparing Android Studio’s coverage option with JaCoCo coverage report you’ll see a significant difference in the details that JaCoCo coverage report shares. Also its not just about the details Android Studio’s “Run with Coverage” option does not has, the main difference is that -its more of an IDE tool, vs JaCoCo report shared a detailed code analysis with coverage numbers which can be used in various CI pipelines.

The JaCoCo plugin provides an option to generate HTML reports, as shown in the image above. The Java code coverage report allows us to click through and navigate inside the classes to see exactly which lines are covered. It also highlights missed lines, methods, and classes, helping us identify areas that still need to be covered by our JUnit tests. Once you integrate and run JaCoCo plugin for Android, typically you will find the report at this path: build/reports/jacoco/jacocoTestReport/html/index.html.

JaCoCo plugin usages in CI/CD

As Android applications scale and more engineers contribute to the codebase, application stability becomes critical. If every code merge or push to a Git branch introduces compilation or logical errors, it can result in significant productivity loss. To ensure releases remain resilient and predictable, large-scale organizations typically enforce a unit test coverage target of 80% or higher.

Achieving this level of unit test coverage requires two key mechanisms: first, the ability to measure the current unit test coverage, and second, the ability to pass or fail Git pull request checks based on that coverage. For Android applications, the JaCoCo plugin helps implement both of these mechanisms effectively.

In previous sections of this Android code coverage tutorial, I have shown how JaCoCo plugin can help in measuring the code coverage. In the next sections lets have a look at how JaCoCo plugin’s coverage report can be consumed in leading tools used for tracking Android code coverage which will eventually help in building CI and PR checks.

Print in your CI Pipeline

There are many use cases where we just need Android JUnit code coverage number when our Gradle task for running the unit test cases completes. We can print the coverage by just parsing XML report generated by the JaCoCo plugin. To implement the same please add the below code at the end of your jacocoTestReport task, which was created in previous section:

doLast {
    val reportFile = file("${layout.buildDirectory.get().asFile}/reports/jacoco/jacocoTestReport/jacocoTestReport.xml")
    if (reportFile.exists()) {
        val factory = javax.xml.parsers.DocumentBuilderFactory.newInstance()
        factory.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false)
        val parser = factory.newDocumentBuilder()
        val doc = parser.parse(reportFile)
        val root = doc.documentElement
        val nodeList = root.childNodes
        
        println("-------------------------------------------------------")
        println("Code Coverage Summary (Project Level):")
        
        for (i in 0 until nodeList.length) {
            val node = nodeList.item(i)
            if (node is org.w3c.dom.Element && node.tagName == "counter") {
                val type = node.getAttribute("type")
                val missed = node.getAttribute("missed").toDouble()
                val covered = node.getAttribute("covered").toDouble()
                val total = missed + covered
                val percentage = if (total > 0) (covered / total) * 100 else 0.0
                
                if (type == "INSTRUCTION") {
                    println("Instructions : ${String.format("%.2f", percentage)}% (${covered.toInt()}/${total.toInt()})")
                } else if (type == "BRANCH") {
                    println("Branches     : ${String.format("%.2f", percentage)}% (${covered.toInt()}/${total.toInt()})")
                } else if (type == "LINE") {
                    println("Lines        : ${String.format("%.2f", percentage)}% (${covered.toInt()}/${total.toInt()})")
                }
            }
        }
        println("-------------------------------------------------------")
    } else {
        println("Jacoco report XML not found at ${reportFile.absolutePath}")
    }
}

I will add the link to complete source code at the end of this tutorial for better understanding. This script will print below text as output when the execution of jacocoTestReport task completes.

> Task :app:jacocoTestReport
-------------------------------------------------------
Code Coverage Summary (Project Level):
Instructions : 3.39% (976/28763)
Branches     : 0.56% (9/1614)
Lines        : 2.61% (140/5367)
-------------------------------------------------------

For example if Jenkins CI is being used, simply use shell commands with piping, a Groovy script in a pipeline, or the Log Parser Plugin to parse the above coverage output.

Integrate with BrowserStack

If you want to integrate a third-party tool such as BrowserStack with your CI pipeline, you can do so using BrowserStack App Automate feature, which allows you to offload your UI Espresso test executions to BrowserStack. However, in this tutorial we are focusing specifically on JUnit test coverage. Therefore, we will limit the discussion to that topic and explore BrowserStack’s support for JUnit coverage.

To track JUnit test executions using BrowserStack’s Test Reporting & Analytics feature, you need to add the following task to your jacoco.gradle.kts file:

// Task to upload coverage and test reports to BrowserStack.
tasks.register("uploadReportsToBrowserStack") {
    dependsOn("jacocoTestReport")
    doLast {
        val bsUser = if (project.hasProperty("bsUser")) project.property("bsUser") else "YOUR_USER_ID"
        val bsKey = if (project.hasProperty("bsKey")) project.property("bsKey") else "YOUR_USER_KEY"
        val buildId = java.text.SimpleDateFormat("yyyy-MM-dd_HH-mm").format(java.util.Date())

        // Upload JUnit XML Reports (to Automation Upload endpoint)
        val junitReportDir = file("${layout.buildDirectory.get().asFile}/test-results/testDebugUnitTest")
        if (junitReportDir.exists()) {
            println("Uploading JUnit reports to BrowserStack...")
            junitReportDir.listFiles { f -> f.extension == "xml" }?.forEach { xmlFile ->
                exec {
                    commandLine(
                        "curl", "-u", "$bsUser:$bsKey", "-vvv",
                        "-X", "POST",
                        "-F", "data=@${xmlFile.absolutePath}",
                        "-F", "projectName=TambolaCaller",
                        "-F", "buildName=Unit Test Coverage",
                        "-F", "buildIdentifier=$buildId",
                        "-F", "tags=unit_test, android",
                        "-F", "frameworkVersion=junit, 4.13.2",
                        "https://upload-automation.browserstack.com/upload"
                    )
                }
            }
        }
    }
}

If you wish to specify a build Id you can put that custom logic in line 7 above. Once this task executes, it would upload your JUnit test report to BrowserStack’s APIs. As of now, I did not find a way to upload JaCoCo reports to browserStack, hopefully in future they may introduce this feature.

Integration with GitHub Actions and workflows

To enforce a minimum JUnit test coverage threshold, the jacocoTestReport Gradle task is executed on the CI platform, and its result is reported back to the Git repository as a pull request (PR) check using webhooks. If GitHub is used as the source code repository, it can also serve directly as the CI/CD platform. In modern technology stacks, GitHub Actions is commonly used as the CI/CD tool, as it has the capability to trigger builds and perform automated PR checks. For this Android JaCoCo tutorial I had created a github action which acts as a gating check based on Android JaCoCo coverage report. To implement the same please create a file .github/workflows/android.yml with following code:

name: Android CI

on:
  push:
    #branches: [ "master" ]
  pull_request:
    #branches: [ "master" ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - name: set up JDK 17
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'
          cache: gradle

      - name: Grant execute permission for gradlew
        run: chmod +x gradlew
      - name: Generate JaCoCo report
        run: ./gradlew clean jacocoTestReport

      - name: Upload Report
        uses: actions/upload-artifact@v4
        with:
          name: report.xml
          path: ${{ github.workspace }}/**/build/reports/jacoco/**/jacocoTestReport.xml

      - name: JaCoCo Report
        id: jacoco
        uses: Madrapps/jacoco-report@v1.7.2
        with:
          paths: |
            ${{ github.workspace }}/**/build/reports/jacoco/**/jacocoTestReport.xml,
            ${{ github.workspace }}/**/build/reports/jacoco/**/debugCoverage.xml
          token: ${{ secrets.GITHUB_TOKEN }}
          min-coverage-overall: 80
          min-coverage-changed-files: 80
          title: Code Coverage

      - name: Get the Coverage info
        run: |
          echo "Total coverage ${{ steps.jacoco.outputs.coverage-overall }}"
          echo "Changed Files coverage ${{ steps.jacoco.outputs.coverage-changed-files }}"

      - name: Fail PR if overall coverage is less than 80%
        if: ${{ steps.jacoco.outputs.coverage-overall < 80.0 }}
        uses: actions/github-script@v6
        with:
          script: |
            core.setFailed('Overall coverage is less than 80%!')

Once the above file is pushed in code repository, whenever a code push or pull request is created GitHub Actions will trigger a CI build. This CI build will run the jacocoTestReport gradle task, whose report would be used to post a comment on the pull request(PR) and a check would be added for PR merge.

GitHub actions is a very powerful workflow which can help automate not just this use case but many other as well. For example it can be used to perform code quality checks, integrations with third party apps and much more. For better understanding please find the link to full source code used in this tutorial here:

GitHub Code

The above mentioned code link gives you full access to the jacoco.gradle.kts and android.yml files used in this JaCoCo integration tutorial for Android. As the codebase of an app evolves and team grows it becomes necessary to work on JUnit code coverage so that we can release with confidence. In this article we learned how to integrate JaCoCo plugin in an Android app in a clean way. Also I showcased how JaCoCo is used to enforce gating mechanisms via GitHub PR checks. There are many other use cases JUnit test cases and JaCoCo can solve. Please let me know what innovative use cases you are solving via JaCoCo in Android in the comments section, hope this article helped.

Mohit Gupt

Born in New Delhi, India. A software engineer by profession, an android enthusiast and mobile development evangelist. My motive here is to create a group of skilled engineers, who can build better software. Reason being programming is my passion, and also it feels good to make a device do something you want. Professionally I have worked with many software engineering and product development firms. As of now too, I am employed as a senior engineer in a leading tech company. In total I may have worked on more than 20 projects professionally, but whenever I get spare time I share my thoughts here at Truiton.

www.truiton.com

The post Android JaCoCo Code Coverage Plugin for Unit Testing appeared first on Truiton.

Implementing the Splash Activity in Android – The Right Way

Mohit Gupt — Fri, 28 Oct 2022 17:19:52 +0000

If you are working on a large scale Android app, you might realize that to give a premium experience to your users you need to implement a splash activity in Android. In most cases behind the scenes a splash screen is used to load data in background and on the foreground it is utilized to educate users about the app. In terms of implementation, when an app is starting, specially in a cold start case a lot of activity is done by the Android OS to start your app. To optimize this and give a great experience to the users, android has introduced a Splash Screen API. In this tutorial lets see how the new android splash screen API is used and its benefits.

What’s the use of new Android Splash Screen API ?

You might start to think what’s the use of this new Android SplashScreen API? We can always build a custom splash screen and use it as per requirement. To understand the actual use of this API we must first understand what’s a cold start for an Android app. To understand this lets go little deeper. A cold start means launching an app for the first time. It refers to a state of OS starting an app when its process is not running. When launching an android app for the first time, OS does a lot of work in the background and creating its process from the scratch is called a cold start. Lets have a look at the states an app goes through before actually starting.

As per the official documentation first OS starts loading and launching the app then displays a blank screen momentarily, then finally the handoff happens to the apps process where our code can actually be executed. Now from an experience standpoint even if you have a custom splash screen for launch, it would be displayed only after a blank screen is displayed momentarily. You might not get to see this experience on very fast devices, but it exists. Starting Android 12 we have this new Splash Screen API which shows a standardized splash screen, avoiding the original blank screen before the handoff to app’s process. This gives a much better experience to the user in comparison to the blank container.

Interestingly this new Android Splash Screen API is applied by default on all the apps from Android 12. Therefore whenever you launch an app on Android 12 and above you will always see a standardized animation and then your original splash screen would be displayed. This could be a little abrupt if you have used android:windowBackground, in your theme. As the standardized Android splash activity uses your app’s launcher icon and theme’s android:windowBackground, attribute to show a splash screen. To make this standardized experience blend into your app’s experience, android team has exposed some basic level of functionalities in this API, which can be used to customize your app’s launch experience. In the next section I will show an Android SplashScreen API example for the same.

This new Android SplashScreen API has been introduced from Android 12, but a compat version of the same has also been released, which allows us to use this from API 21 onwards. In our Splash Activity in android tutorial we will be using the same. To use the compat version please include this in your gradle file :

implementation "androidx.core:core-splashscreen:1.0.0"

Implementation of Splash Activity in Android

In a large scale production app, there’s a good chance that you might need to implement an Android Splash Screen. In this section we will implement the same using the latest Android SplashScreen API. As mentioned in the previous section, default Android’s splash screen gives us a very standardized implementation of the splash screen. Where your app’s launcher icon and android:windowBackground, is used to show a splash screen. If we are building a large scale app we might need to customize it according to our needs. If we have to build a splash activity in Android using the latest API, it gives us all the powers to customize it. Have a look at the animation below, this is what we will try to achieve in our app.

Android Splash Screen – Cold Start

Although as per official documentation it is advised that our apps launcher screen should be the actual main screen where the user has intended to go. But when building large scale apps a splash screen is needed to do various things like, initializing SDKs (if not in the Application class), fetching location before the main screen or maybe just to build a deep link router, there are many more such use cases (If you know a few, please add them in the comments section). Therefore in this section we will build a splash screen which would have the default enter animation with the screen customization according to our theme, and a custom exit animation which would transform the initial splash in to our custom android splash screen. In this custom splash activity we can do whatever we want, once we execute our code we will eventually load app’s main screen.

Please note – If this is not your use case and you wish to open the main screen directly, things are simpler for you. Splash screen just needs to be initialized as per the official documentation.

Firstly to start with building a splash screen in Android Studio we need to include a Gradle dependency defined in the section above, this way we will have the support from android API 21 onwards. Next we need to create a theme which inherits the "Theme.SplashScreen". Have look at the example code:

In the above section another point to note is that we also have to define a postSplashScreenTheme attribute, where we mention the theme which is to be applied after the standardized splash animation is dismissed. In our case since we are landing the user on to a custom android splash screen, we have mentioned a theme which is inheriting "Theme.MaterialComponents.DayNight.NoActionBar". Otherwise we could have used the app’s theme. Next lets have a look at the manifest where this theme needs to be specified, although in the end of this article, I will share the link to its full source code.

As you can see in our launch activity we have defined the our custom Android Splash Screen theme. Next we have to do an initialization of the SplashScreen API in the onCreate of launch activity. Please note that this needs to be done before super.onCreate and setContentView.

package com.truiton.splashscreenapi

import android.animation.AnimatorSet
import android.animation.ObjectAnimator
import android.content.Intent
import android.os.Bundle
import android.view.View
import android.view.animation.AccelerateInterpolator
import android.view.animation.OvershootInterpolator
import android.widget.ImageView
import androidx.appcompat.app.AppCompatActivity
import androidx.core.animation.doOnEnd
import androidx.core.splashscreen.SplashScreen.Companion.installSplashScreen
import androidx.lifecycle.lifecycleScope
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.delay
import kotlinx.coroutines.launch
import kotlinx.coroutines.withContext


class MyLaunchActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        val screen = installSplashScreen()
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_launch)
        val mySplashMainIcon: ImageView = findViewById(R.id.splash_main_icon)
        screen.setOnExitAnimationListener { splashScreenView ->
            val lineStartY: Int = getRelativeTop2(mySplashMainIcon)
            val animY = ObjectAnimator.ofFloat(
                splashScreenView.iconView,
                View.Y,
                lineStartY.toFloat()
            )
            //Just in case you wish to run multiple animations
            /*val animX = ObjectAnimator.ofFloat(
                splashScreenView.iconView,
                View.X,
                mySplashIcon2.x
            )*/

            val alpha = ObjectAnimator.ofFloat(
                splashScreenView.view,
                View.ALPHA,
                1f,
                0f
            )
            alpha.interpolator = AccelerateInterpolator()
            alpha.duration = 200L

            val traverseSet = AnimatorSet().apply {
                interpolator = OvershootInterpolator()
                duration = 500L
                playTogether(/*animX,*/ animY)
            }

            AnimatorSet().apply {
                play(traverseSet).before(alpha)
                doOnEnd {
                    splashScreenView.remove()
                }
                start()
            }
        }

        lifecycleScope.launch(Dispatchers.Main) {
            doSomeWork() // can do initializations on IO/Worker Thread
            launchNextScreen() // back on UI/Main thread
        }
    }

    private suspend fun doSomeWork() = withContext(Dispatchers.IO) {
        delay(5000L) // pretend we are doing some IO operation
    }

    private fun launchNextScreen() {
        startActivity(Intent(this, MainActivity::class.java))
        finish()
    }

    private fun getRelativeTop2(view: View): Int {
        val parent = view.parent as View
        val parentLocation = IntArray(2)
        val viewLocation = IntArray(2)
        view.getLocationOnScreen(viewLocation)
        parent.getLocationOnScreen(parentLocation)
        return viewLocation[1] - (parentLocation[1]*2)
    }
}

To make a splash screen exit animation on Android we have overridden setOnExitAnimationListener. This callback gives us a reference to the splash screen view through which we can get the logo view which can be used for animation. So to animate we have used an ObjectAnimator, the code for the same is self explanatory and beyond the scope of this article. You can view full source code here:

Full Source Code

Now once this setOnExitAnimationListener has completed its execution we land into the regular app flow, where we have started a coroutine which is pretending to to some work, in the actual implementation you can write all the initializations or API calls that you want to make in this doSomeWork() method. Once the execution for doSomeWork() method completes this coroutine launches the next activity of the app giving us the desired Android custom splash screen experience.

Android Splash Activity Cold Start with Profiling

Android Splash Activity Warm Start

When building this sample I also did CPU and memory profiling of the custom splash activity in the sample. Interestingly when we launch the app for the first time, basically when we do a cold start it does give a spike, since OS is loading and launching the app but there is no visual lag, neither there is any blank screen momentarily. This is the real advantage of using the Android SplashScreen API. Also when we do a warm start of the app, you can see that the handoff from splash to custom animation happens almost instantaneously, and since we have a setOnExitAnimationListener set to handle this situation it works flawlessly giving a very smooth experience. This brings us to the conclusion of this article, hope it helped in understanding the concept.

Mohit Gupt

www.truiton.com

The post Implementing the Splash Activity in Android – The Right Way appeared first on Truiton.

Android Runtime Permissions Request Tutorial

Mohit Gupt — Sat, 09 Apr 2016 20:35:06 +0000

Android M introduced a new concept of permissions model with its release. According to this new concept now apps would have to request permissions from the users at run time. In a way this is a very useful feature for the end users. Making their user experience very secure on an Android device. But inversely this feature imposes a great deal of effort on development. As the new permissions model also allows the user to deny the permission at runtime. Therefore as developers, we would have to handle all the use cases. Thankfully, requesting Android runtime permissions, is not that difficult, with a few lines of code we can build a full fledged permission handling mechanism. But before doing so lets understand the permission model first.

Understanding Android Run Time Permissions Model

Android system permissions are divided into many categories. But when it comes to permission request at runtime from Android 6.0 onward, system permissions are categorized into two categories. Normal and Dangerous, to access either of these two permissions, the first step is to declare them in the manifest, as shown below. The difference between these two is that, dangerous permissions are now granted by the user at run time. Otherwise your app would crash with security exception. On the other hand we don’t need to request permissions falling under the normal category.

In the above android manifest, first permission android.permission.INTERNET is a normal permission and other two android.permission.READ_CONTACTS, android.permission.WRITE_EXTERNAL_STORAGE are dangerous permissions. Therefore in the following example, we would request the user to grant the later two Android permissions at runtime.

There is another special category of permissions having permissions like SYSTEM_ALERT_WINDOW and WRITE_SETTINGS. Although these permissions are neither categorized in normal or dangerous section, but still it is required that these are requested by user at runtime by firing an intent (not discussed in this article).

Requesting Android Runtime Permissions

From Android 6.0 onward, declaring a permission in manifest will not enable an app to use that permission. In a way its just a way to notify the system that your app can use this permission. But to actually use the permission you would have to make an Android runtime permission request. As mentioned above, in this example we would be requesting two permissions android.permission.READ_CONTACTS, and android.permission.WRITE_EXTERNAL_STORAGE. Usually a permission should be requested only when it is required. Hence when a permission is required in your code, please initiate the permission request process by using the following code:

    if (ContextCompat.checkSelfPermission(MainActivity.this,
    Manifest.permission.WRITE_EXTERNAL_STORAGE) + ContextCompat
            .checkSelfPermission(MainActivity.this,
    Manifest.permission.READ_CONTACTS)
            != PackageManager.PERMISSION_GRANTED) {
        if (ActivityCompat.shouldShowRequestPermissionRationale
                (MainActivity.this, Manifest.permission.WRITE_EXTERNAL_STORAGE) ||
                ActivityCompat.shouldShowRequestPermissionRationale
                        (MainActivity.this, Manifest.permission.READ_CONTACTS)) {
            Snackbar.make(findViewById(android.R.id.content),
                    "Please Grant Permissions",
                    Snackbar.LENGTH_INDEFINITE).setAction("ENABLE",
                    new View.OnClickListener() {
                        @Override
                        public void onClick(View v) {
                            ActivityCompat.requestPermissions(MainActivity.this,
                                    new String[]{Manifest.permission
                                            .WRITE_EXTERNAL_STORAGE, Manifest.permission.READ_CONTACTS},
                                    REQUEST_PERMISSIONS);
                        }
                    }).show();
        } else {
            ActivityCompat.requestPermissions(MainActivity.this,
                    new String[]{Manifest.permission
                            .WRITE_EXTERNAL_STORAGE, Manifest.permission.READ_CONTACTS},
                    REQUEST_PERMISSIONS);
        }
    } else {
        //Call whatever you want
        myMethod();
    }

This would initiate an Android runtime permissions request. If you have the permission, myMethod() would be called. If you have been denied or granted the permission by user action, then the onRequestPermissionResult() method would be called:

    @Override
    public void onRequestPermissionsResult(int requestCode,
                                           @NonNull String permissions[],
                                           @NonNull int[] grantResults) {
        switch (requestCode) {
            case REQUEST_PERMISSIONS: {
                if ((grantResults.length > 0) && (grantResults[0] +
                        grantResults[1]) == PackageManager.PERMISSION_GRANTED) {
                    //Call whatever you want
                    myMethod();
                } else {
                    Snackbar.make(findViewById(android.R.id.content), "Enable Permissions from settings",
                            Snackbar.LENGTH_INDEFINITE).setAction("ENABLE",
                            new View.OnClickListener() {
                                @Override
                                public void onClick(View v) {
                                    Intent intent = new Intent();
                                    intent.setAction(Settings.ACTION_APPLICATION_DETAILS_SETTINGS);
                                    intent.addCategory(Intent.CATEGORY_DEFAULT);
                                    intent.setData(Uri.parse("package:" + getPackageName()));
                                    intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
                                    intent.addFlags(Intent.FLAG_ACTIVITY_NO_HISTORY);
                                    intent.addFlags(Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS);
                                    startActivity(intent);
                                }
                            }).show();
                }
                return;
            }
        }
    }

This is an additional method which you need to implement in your activity, to receive the Android runtime permissions request callback. Once the callback is received in the above method, and if the permission is granted you can call the same myMethod() to invoke the desired functionality. Also here in the above method we have taken care of the situation in which the permission is not granted. We would ask the user to launch the settings screen and enable permissions manually.

Android M Runtime Permissions – Design Pattern

By going through the above code you must have understood, requesting Android runtime permissions is very easy. But the implementation of this methodology in your existing code base could be a very time taking activity. Therefore a design pattern is required, where we can write the permission request code once and use it again and again.

To do so lets design an Abstract activity class, where the onRequestPermissionResult() method can be implemented. This would enable us to deliver permission granted callbacks to the child activity by using an abstract method, resulting minimal code change.

package com.truiton.runtimepermissions;

import android.content.Intent;
import android.content.pm.PackageManager;
import android.net.Uri;
import android.os.Bundle;
import android.provider.Settings;
import android.support.annotation.Nullable;
import android.support.design.widget.Snackbar;
import android.support.v4.app.ActivityCompat;
import android.support.v4.content.ContextCompat;
import android.support.v7.app.AppCompatActivity;
import android.util.SparseIntArray;
import android.view.View;

/**
 * Created by MG on 03-04-2016.
 */
public abstract class RuntimePermissionsActivity extends AppCompatActivity {
    private SparseIntArray mErrorString;

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        mErrorString = new SparseIntArray();
    }

    @Override
    public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {
        super.onRequestPermissionsResult(requestCode, permissions, grantResults);
        int permissionCheck = PackageManager.PERMISSION_GRANTED;
        for (int permission : grantResults) {
            permissionCheck = permissionCheck + permission;
        }
        if ((grantResults.length > 0) && permissionCheck == PackageManager.PERMISSION_GRANTED) {
            onPermissionsGranted(requestCode);
        } else {
            Snackbar.make(findViewById(android.R.id.content), mErrorString.get(requestCode),
                    Snackbar.LENGTH_INDEFINITE).setAction("ENABLE",
                    new View.OnClickListener() {
                        @Override
                        public void onClick(View v) {
                            Intent intent = new Intent();
                            intent.setAction(Settings.ACTION_APPLICATION_DETAILS_SETTINGS);
                            intent.addCategory(Intent.CATEGORY_DEFAULT);
                            intent.setData(Uri.parse("package:" + getPackageName()));
                            intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
                            intent.addFlags(Intent.FLAG_ACTIVITY_NO_HISTORY);
                            intent.addFlags(Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS);
                            startActivity(intent);
                        }
                    }).show();
        }
    }

    public void requestAppPermissions(final String[] requestedPermissions,
                                      final int stringId, final int requestCode) {
        mErrorString.put(requestCode, stringId);
        int permissionCheck = PackageManager.PERMISSION_GRANTED;
        boolean shouldShowRequestPermissionRationale = false;
        for (String permission : requestedPermissions) {
            permissionCheck = permissionCheck + ContextCompat.checkSelfPermission(this, permission);
            shouldShowRequestPermissionRationale = shouldShowRequestPermissionRationale || ActivityCompat.shouldShowRequestPermissionRationale(this, permission);
        }
        if (permissionCheck != PackageManager.PERMISSION_GRANTED) {
            if (shouldShowRequestPermissionRationale) {
                Snackbar.make(findViewById(android.R.id.content), stringId,
                        Snackbar.LENGTH_INDEFINITE).setAction("GRANT",
                        new View.OnClickListener() {
                            @Override
                            public void onClick(View v) {
                                ActivityCompat.requestPermissions(RuntimePermissionsActivity.this, requestedPermissions, requestCode);
                            }
                        }).show();
            } else {
                ActivityCompat.requestPermissions(this, requestedPermissions, requestCode);
            }
        } else {
            onPermissionsGranted(requestCode);
        }
    }

    public abstract void onPermissionsGranted(int requestCode);
}

To request Android runtime permissions we would have to extend the above activity and call its requestAppPermissions() method, as shown below:

package com.truiton.runtimepermissions;

import android.Manifest;
import android.os.Bundle;
import android.support.design.widget.FloatingActionButton;
import android.support.v7.widget.Toolbar;
import android.view.View;
import android.widget.Toast;

public class MainActivity extends RuntimePermissionsActivity {

    private static final int REQUEST_PERMISSIONS = 20;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar);
        setSupportActionBar(toolbar);

        FloatingActionButton fab = (FloatingActionButton) findViewById(R.id.fab);
        fab.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                MainActivity.super.requestAppPermissions(new
                                String[]{Manifest.permission.READ_CONTACTS,
                                Manifest.permission.WRITE_EXTERNAL_STORAGE}, R.string
                                .runtime_permissions_txt
                        , REQUEST_PERMISSIONS);
            }
        });
    }

    @Override
    public void onPermissionsGranted(final int requestCode) {
        Toast.makeText(this, "Permissions Received.", Toast.LENGTH_LONG).show();
    }
}

In the above piece of code, we took the full advantage of an abstract class. Where we made all Android run time permission requests in the parent class, and called the abstract method onPermissionsGranted() of that class, to return callbacks to the child activity. Full source code available here:

Source Code

This way, when implementing Android runtime permissions model, to support Android M and above, minimal code needs to be written in the existing activities. As the permission request would be made through the parent class method requestAppPermissions(), and results would be propagated back by the onPermissionsGranted() method. Although if you have already implemented a base activity pattern in your app, implementing this pattern would be very easy, as the same class would be reused to implement this pattern. Hope this helped. For more updates please connect with us on Facebook, Twitter and Google+.

Mohit Gupt

www.truiton.com

The post Android Runtime Permissions Request Tutorial appeared first on Truiton.

Android Activity To Fragment Communication

Mohit Gupt — Tue, 29 Dec 2015 22:16:50 +0000

Now days usage of tabs in apps, have become a necessity. Being an android developer I have implemented them in many Android apps. But I feel, till date most of the developers don’t know how to implement them correctly. As most of the implementations would make your app crash in corner cases. Therefore in this tutorial I plan to discuss a very specific problem which is encountered while implementing tabs in android. That is, how to perform communication between an activity and fragment, two fragments, and a fragment and an activity while using tabs. Although if you to wish to simply learn – how implement tabs in Android please use this link. Since this tutorial also addresses a specific problem of Android Activity To Fragment Communication. If you have implemented tabs in android, I am sure you must have encountered this sort of problem. Therefore here in this example we would make a PagerAdapter, get its current fragment and would try to perform communication in both directions.

To perform an Android activity to fragment communication, the standard suggested way is to get the fragment instance and call public methods of that fragment directly. But when implementing tabs in Android, things are not that simple. Being a developer the first challenge I faced was; getting an instance of the already instantiated fragment in the PagerAdapter. As the standard FragmentStatePagerAdapter class of android does not provide any methods to retrieve the already instantiated instance of the fragment in discussion. Therefore before jumping on to; how to pass data in a fragment from activity, lets make a PagerAdapter and get its current fragment.

Android PagerAdapter: How to get the current fragment?

As I mentioned to pass data from an activity to a fragment in case of tabs we need to make the PagerAdapter in a special way. To do so lets start by implementing tabs in android by adding the design support library in the dependencies section of the build.gradle of your app:

compile 'com.android.support:design:23.1.1'

Please Note: Full source code is present at the GitHub. Link at the bottom of page.

Next lets define a PagerAdapter where we would define a method by the name of getFragment(), which would be used to return an instance of the Fragment class. This instance could be further casted into our local fragment type. In order to make this implementation work properly we may need to override some more methods of the FragmentStatePagerAdapter/FragmentPagerAdapter class. Please have a look at the code sample below:

package com.truiton.activitytofragment;

import android.support.annotation.Nullable;
import android.support.v4.app.Fragment;
import android.support.v4.app.FragmentManager;
import android.support.v4.app.FragmentStatePagerAdapter;
import android.util.SparseArray;
import android.view.ViewGroup;

import java.lang.ref.WeakReference;
import java.util.ArrayList;

public class PagerAdapter extends FragmentStatePagerAdapter {
    private final SparseArray> instantiatedFragments = new SparseArray<>();
    private ArrayList mTabHeader;

    public PagerAdapter(FragmentManager fm, ArrayList tabHeader) {
        super(fm);
        this.mTabHeader = tabHeader;
    }

    @Override
    public Fragment getItem(int position) {

        switch (position) {
            case 0:
                TabFragment1 tab1 = new TabFragment1();
                return tab1;
            case 1:
                TabFragment2 tab2 = new TabFragment2();
                return tab2;
            default:
                return null;
        }
    }

    @Override
    public int getCount() {
        return mTabHeader.size();
    }

    @Override
    public Object instantiateItem(final ViewGroup container, final int position) {
        final Fragment fragment = (Fragment) super.instantiateItem(container, position);
        instantiatedFragments.put(position, new WeakReference<>(fragment));
        return fragment;
    }

    @Override
    public void destroyItem(final ViewGroup container, final int position, final Object object) {
        instantiatedFragments.remove(position);
        super.destroyItem(container, position, object);
    }

    @Nullable
    public Fragment getFragment(final int position) {
        final WeakReference wr = instantiatedFragments.get(position);
        if (wr != null) {
            return wr.get();
        } else {
            return null;
        }
    }

    @Override
    public CharSequence getPageTitle(int position) {
        return mTabHeader.get(position);
    }
}

As you can see in the above piece of code, we have implemented two extra methods instantiateItem() and destroyItem() to support the implementation of getFragment() method. Also a SparseArray with WeakReference of Fragment has been used. This allows the fragments to be garbage collected if they are destroyed, preventing a memory leak. To understand how to get a fragment from PagerAdapter, lets have a closer look at the PagerAdapter above. The instantiateItem() method of the FragmentStatePagerAdapter is responsible for creation of a Fragment instance at the current position. This instance of the fragment is created through the help of getItem() method of the adapter. By doing this process we created a SparseArray of fragments in the instantiateItem(). Which would be used to get the fragment from ViewPager. Now that we have successfully retrieved an instance of fragment from PagerAdapter we need complete the cycle by removing the fragment from SparceArray once it it destroyed, in the destroyItem() method.

Another interesting thing about the adapter above is that, we are using the inbuilt getPageTitle() method to set the titles for tabs. Usually in most of the implementations we manually set title for tabs by using the method TabLayout.Tab setText() method, which is not wrong. But using the getPageTitle() method, makes fragment independent of tabs and also it describes the fragment. Next lets define the layout for MainActivity class:

Now lets have a look at the onCreate() method of our activity, where most of the action would happen:

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar);
        setSupportActionBar(toolbar);

        ArrayList tabs = new ArrayList<>();
        tabs.add("Tab 1");
        tabs.add("Tab 2");
        tabLayout = (TabLayout) findViewById(R.id.tab_layout);
        tabLayout.setTabGravity(TabLayout.GRAVITY_FILL);

        final ViewPager viewPager = (ViewPager) findViewById(R.id.pager);
        adapter = new PagerAdapter(getSupportFragmentManager(), tabs);
        viewPager.setAdapter(adapter);
        tabLayout.setupWithViewPager(viewPager);
    }

Since the code base is too large for this example, please find the link to GitHub repo at the end of this page. In the above example to perform Android activity to fragment communication, tabs have been initialized a little differently. As you can see TabLayout.setupWithViewPager() method is used. This method simplifies the usage of tabs in Android with a ViewPager. It is advised not to use setupWithViewPager() method in conjunction with setOnTabSelectedListener() method of TabLayout class. As you would have to do all the implementation manually once again, which is already taken care of, in the setupWithViewPager() method. Although if you wish to use setOnTabSelectedListener() please refer to this tutorial, and this stackoverflow link.

Android Tabs: Activity to Fragment Communication

Now that we have a working pager adapter, lets have a look on how to do the android activity to fragment communication with tabs. As suggested in the official docs for Android fragment communication, when an activity needs to deliver a message to the fragment, it can call the fragment’s public methods. Same principle can also be used in case of tabs as well. The only problem one could face; is getting the instance of an already initialized fragment. Although now this problem could be solved by the first section of this tutorial. Continuing from there, to successfully demonstrate android activity to fragment communication, in this tutorial we will call a public method of the fragment through the menu of host activity. To start, lets define a menu item:

This XML would simply create a refresh button on the main activity of our app. For this Android Activity to Fragment Communication tutorial we would make two tabs. Now to deliver a message from an activity to a fragment we need to call its public method from the activity. Therefore first lets define a fragment with a public method:

package com.truiton.activitytofragment;

import android.content.Context;
import android.os.Bundle;
import android.support.v4.app.Fragment;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
import android.widget.Button;
import android.widget.Toast;

public class TabFragment1 extends Fragment implements View.OnClickListener {
    private IFragmentToActivity mCallback;
    private Button btnFtoA;
    private Button btnFtoF;

    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
        View view = inflater.inflate(R.layout.tab_fragment_1, container, false);
        btnFtoA = (Button) view.findViewById(R.id.button);
        btnFtoF = (Button) view.findViewById(R.id.button2);
        btnFtoA.setOnClickListener(this);
        btnFtoF.setOnClickListener(this);
        return view;
    }

    @Override
    public void onAttach(Context context) {
        super.onAttach(context);
        try {
            mCallback = (IFragmentToActivity) context;
        } catch (ClassCastException e) {
            throw new ClassCastException(context.toString()
                    + " must implement IFragmentToActivity");
        }
    }

    @Override
    public void onDetach() {
        mCallback = null;
        super.onDetach();
    }

    public void onRefresh() {
        Toast.makeText(getActivity(), "Fragment 1: Refresh called.",
                Toast.LENGTH_SHORT).show();
    }

    @Override
    public void onClick(View v) {
        switch (v.getId()) {
            case R.id.button:
                mCallback.showToast("Hello from Fragment 1");
                break;

            case R.id.button2:
                mCallback.communicateToFragment2();
                break;
        }
    }
}

Please have a look at the highlighted lines in the piece of code above. The onRefresh() method of this fragment above, is a public method. This method would be called from the host activity to perform activity to fragment communication. This method would simply display a Toast message, but will complete the task at hand (please ignore other methods defined in this fragment, as they will be used in next section of this tutorial).

Now lets define two more methods in the MainActivity.java (Full source code available at GitHub, link at the end of this tutorial):

    @Override
    public boolean onCreateOptionsMenu(Menu menu) {
        getMenuInflater().inflate(R.menu.menu_main, menu);
        return true;
    }

    @Override
    public boolean onOptionsItemSelected(MenuItem item) {
        int id = item.getItemId();
        if (id == R.id.action_refresh) {
            int position = tabLayout.getSelectedTabPosition();
            Fragment fragment = adapter.getFragment(tabLayout
                    .getSelectedTabPosition());
            if (fragment != null) {
                switch (position) {
                    case 0:
                        ((TabFragment1) fragment).onRefresh();
                        break;
                    case 1:
                        ((TabFragment2) fragment).onRefresh();
                        break;
                }
            }
            return true;
        }
        return super.onOptionsItemSelected(item);
    }

Above we first created a menu with refresh button, and in the next onOptionsItemSelected() method of the activity we retrieved the fragment’s instance and called its public method onRefresh().

Android Tabs: Fragment to Activity Communication

There are situations when you may need to deliver a message to the host activity of your fragment. This type of communication is called fragment to activity communication. The best way to perform this type of communication is by using an interface and implementing it in the host activity. For this example we would use the below defined interface:

package com.truiton.activitytofragment;

public interface IFragmentToActivity {
    void showToast(String msg);

    void communicateToFragment2();
}

For this section of the tutorial we would use only the first method, i.e. showToast(String). But first lets define the layout for Tab 1 from the previous section:

This would look something like this :

Now to perform Android fragment to activity communication, lets first understand the concept a little. To perform this type of communication, we need to implement the above defined interface in the host activity and define its methods in it. This would allow us to call these newly implemented methods from the fragment itself through the callback. This callback would be nothing but an instance of the host activity itself. In other word we are just calling a public method of an activity. But a callback, tightly couples the fragment to an activity. Therefore it is always advised to use interfaces in case of fragment to activity communication. Also, since we are discussing callbacks, I would like to mention here, please don’t forget to nullify the callback instance in the onDetach() method the fragment. As this could produce a serious memory leak. Next lets implement the interface in our host activity and define its methods:

public class MainActivity extends AppCompatActivity implements IFragmentToActivity {

.
.
.

    @Override
    public void showToast(String msg) {
        Toast.makeText(this, msg, Toast.LENGTH_LONG).show();
    }

    @Override
    public void communicateToFragment2() {
        TabFragment2 fragment = (TabFragment2) adapter.getFragment(1);
        if (fragment != null) {
            fragment.fragmentCommunication();
        } else {
            Log.i(LOG_TAG, "Fragment 2 is not initialized");
        }
    }
}

(Please note: full source code is available at GitHub, link at the bottom of page)

Android Tabs: Fragment to Fragment Communication

When implementing tabs in android, one of the most complex problems, is passing data from one fragment to another. But believe me its not that difficult, we can accomplish Android fragment to fragment communication with the help of above pieces of code. In a way, when both Fragment to Activity and Activity to Fragment communication takes place simultaneously it is called Fragment to Fragment communication. Before jumping on to; how this takes place, first lets define the second fragment of our example:

package com.truiton.activitytofragment;

import android.content.Context;
import android.os.Bundle;
import android.support.v4.app.Fragment;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
import android.widget.Button;
import android.widget.TextView;
import android.widget.Toast;

public class TabFragment2 extends Fragment implements View.OnClickListener {
    private IFragmentToActivity mCallback;
    private TextView mTextView1;
    private Button btnFtoA;

    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
        View view = inflater.inflate(R.layout.tab_fragment_2, container, false);
        mTextView1 = (TextView) view.findViewById(R.id.textView1);
        btnFtoA = (Button) view.findViewById(R.id.button);
        btnFtoA.setOnClickListener(this);
        return view;
    }

    @Override
    public void onAttach(Context context) {
        super.onAttach(context);
        try {
            mCallback = (IFragmentToActivity) context;
        } catch (ClassCastException e) {
            throw new ClassCastException(context.toString()
                    + " must implement IFragmentToActivity");
        }
    }

    @Override
    public void onDetach() {
        mCallback = null;
        super.onDetach();
    }

    public void onRefresh() {
        Toast.makeText(getActivity(), "Fragment 2: Refresh called.",
                Toast.LENGTH_SHORT).show();
    }

    public void fragmentCommunication() {
        mTextView1.setText("Hello from Tab Fragment 1");
    }

    @Override
    public void onClick(View v) {
        switch (v.getId()) {
            case R.id.button:
                mCallback.showToast("Hello from Fragment 2");
                break;
        }
    }
}

Its layout:

This fragment would look something like this:

To perform Android fragment to fragment communication in tabs lets have a look at the code above. As I indicated earlier, fragment to fragment communication is a combination of fragment to activity and activity to fragment communication. In the above example we have already implemented fragment to fragment communication via the host activity. As you can see above, our host activity implements the IFragmentToActivity interface. This interface delivers the message from TabFragment1 to the MainActivity. Further in our MainActivity we retrieve the TabFragment2 from the PagerAdapter and call its public method fragmentCommunication() to deliver the message to that fragment. This process as a whole is called android fragment to fragment communication. For full understanding please have a look at the GitHub repo for this project:

Complete Source

Tabs have become an integral part of the android apps these days. Also as the android framework is evolving, side by side developers are also getting skilled. But at times we need to revisit the basics. This Android activity to fragment tutorial is aimed to reinvent the basics for tabs pattern in Android. If it helped, like, share and follow us on Twitter, Facebook, Google+ and GitHub for more updates.

Mohit Gupt

www.truiton.com

The post Android Activity To Fragment Communication appeared first on Truiton.

Android Action Bar In A Dialog Using ToolBar

Mohit Gupt — Sat, 25 Apr 2015 16:43:38 +0000

Android Toolbar widget is one of the new UI components available in AppCompat v21. This widget works just like an ActionBar, the only difference is, it can be placed any where on screen. The Android Toolbar widget can also be used to replace the original ActionBar in your Activity. This feature will open many new possibilities in your application. Like you can place multiple action bars on a screen, place action bars / toolbars with some specific dimensions- not covering the whole width of the screen. Also it solves one of the major issue that I faced during development, i.e. placing an Android action bar in a dialog fragment. Now with Android’s ToolBar widget this can be done very easily.

Android Toolbar widget supports a logo image, a title and a subtitle. It also supports a navigation button, custom views and more importantly an action menu. Now the question is how to display an action bar in a dialog using Toolbar widget.

Android ActionBar in a DialogFragment

Android Toolbar is available through the AppCompat v21 support library. Therefore this widget can be used with Android API 7 and above without any problems. On the other hand DialogFragment class is already available in the support v4 library. Hence an Android ToolBar can be used to display the action bar in a dialog with support from API 7 onwards. To start off please make sure you have AppCompat dependencies in place:

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

Next you may need to include Android ToolBar in the dialog layout:

As you can see in the highlighted lines above, I have used the android.support.v7.widget.Toolbar tag to display an action bar in the dialog’s layout. Android Toolbar widget can also be used with the styles defined in your app. As shown above, please use the android:background attribute to specify the color of action bar. Also app:popupTheme and android:theme attributes can be used to display the standard action bar themes as shown. Further lets define the DialogFragment class.

package com.truiton.toolbardialog;

import android.app.Dialog;
import android.os.Bundle;
import android.support.v4.app.DialogFragment;
import android.support.v7.widget.Toolbar;
import android.view.LayoutInflater;
import android.view.MenuItem;
import android.view.View;
import android.view.ViewGroup;
import android.view.Window;
import android.widget.TextView;

public class ActionBarDialog extends DialogFragment {

    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container,
                             Bundle savedInstanceState) {
        Bundle args = getArguments();
        String title = args.getString("title");
        View v = inflater.inflate(R.layout.action_bar_dialog, container, false);
        TextView tv = (TextView) v.findViewById(R.id.text);
        tv.setText("This is an instance of ActionBarDialog");
        Toolbar toolbar = (Toolbar) v.findViewById(R.id.my_toolbar);
        toolbar.setOnMenuItemClickListener(new Toolbar.OnMenuItemClickListener() {
            @Override
            public boolean onMenuItemClick(MenuItem item) {
                // Handle the menu item
                return true;
            }
        });
        toolbar.inflateMenu(R.menu.menu_main);
        toolbar.setTitle(title);
        return v;
    }

    @Override
    public Dialog onCreateDialog(Bundle savedInstanceState) {
        Dialog dialog = super.onCreateDialog(savedInstanceState);
        // request a window without the title
        dialog.getWindow().requestFeature(Window.FEATURE_NO_TITLE);
        return dialog;
    }
}

As you can see in the above class, in onCreateDialog method I have applied, no title bar feature. This basically removes the header of DialogFragment. Now we can add our own header, a Toolbar which would act just like an Android ActionBar in the DialogFragment. I would also like to highlight that you can also receive arguments in this dialog from the calling activity by using getArguments() method, as shown above.

Using Android Toolbar instead of ActionBar

As I mentioned, the new Android Toolbar can also be used as a normal action bar in your fragment or activity. But to avoid conflict, first you may need to disable the standard action bar, by using a Theme.AppCompat.NoActionBar theme. Else you would see two action bars. In this example I have specified this theme in the styles.xml as only one activity was there. If you need to use Android ToolBar as an action bar for a specific activity, please use this theme only for that activity. Now lets have a look at styles.xml:

Now that our activity will not be having an action bar, we need to define a Toolbar in the layout as shown:

Now lets have a look at the main activity:

package com.truiton.toolbardialog;

import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;
import android.support.v7.widget.Toolbar;
import android.view.Menu;
import android.view.MenuItem;
import android.view.View;
import android.widget.Button;


public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar);
        setSupportActionBar(toolbar);

        Button dialogButton = (Button) findViewById(R.id
                .dialogButton);
        dialogButton.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                Bundle args = new Bundle();
                args.putString("title", "Dialog with Action Bar");
                ActionBarDialog actionbarDialog = new ActionBarDialog();
                actionbarDialog.setArguments(args);
                actionbarDialog.show(getSupportFragmentManager(),
                        "action_bar_frag");
            }
        });
    }

    @Override
    public boolean onCreateOptionsMenu(Menu menu) {
        getMenuInflater().inflate(R.menu.menu_main, menu);
        return true;
    }

    @Override
    public boolean onOptionsItemSelected(MenuItem item) {
        int id = item.getItemId();
        if (id == R.id.action_settings) {
            return true;
        }
        return super.onOptionsItemSelected(item);
    }
}

As you can see in the above class, that I have used setSupportActionBar(toolbar) method to set the toolbar as default ActionBar. By doing this no extra code needs to be written for using the standard onCreateOptionsMenu and onOptionsItemSelected callback methods. Also please note: in onClick method, I am sending the arguments to ActionBarDialog class, where they are supposed to be used accordingly in the DialogFragment.

Conclusion

To conclude I would say Android Toolbar widget is a great addition in the AppCompat class. This not only helps in showing an Android action bar in a dialog, but also helps us in many other ways. For example, when multiple action bars are required on a screen, or an action bar of variable width is required. Also Android Toolbar can be used in any layout, to display a fully functional ActionBar/Toolbar. Hope this helps. Connect with us on Facebook, Google+ and Twitter for more updates.

Mohit Gupt

www.truiton.com

The post Android Action Bar In A Dialog Using ToolBar appeared first on Truiton.

Android Bluetooth Low Energy (BLE) Example

Mohit Gupt — Wed, 22 Apr 2015 19:21:03 +0000

As you might be aware, Bluetooth technology has been one of the most used technology when a connection has to be established with a remote device. But this technology also has a major limitation, i.e. high battery consumption. Therefore an improved version of this technology with low energy consumption was introduced, called BLE (Bluetooth Low Energy). Therefore also on Android Bluetooth Low Energy was introduced with API 18 (Android 4.3). This opened up a whole new dimension in the world of Android development. All sorts of new hardware devices were introduced in the market, with compliance to Bluetooth low energy standard, like heart rate monitors, fitness devices and many more. Since this Android Bluetooth low energy API is a little new. Till now there is no proper code example available for its implementation. Therefore here in this tutorial, I will show you how to make an Android Bluetooth Low Energy Example, with latest APIs.

Since BLE is still new to Android, some improvements were made in API 21 for the same, where the way to detect low energy Bluetooth devices was changed. This lead to deprecation of some old APIs. Primarily scanning for available Bluetooth LE devices using, mBluetoothAdapter.startLeScan(mLeScanCallback) method is now deprecated. The new API suggests to use startScan method of BluetoothLeScanner class, which can be initialized from the same BluetoothAdapter class. But the problem which many of you must have faced, is these new API methods do not work on old APIs, as they are not backward compatible. Hence here we will make an Android Bluetooth Low Energy example, with backward support till API 18.

Android Bluetooth Low Energy Example

Since BLE was introduced in API 18 and cannot be used on old devices, due to change of Bluetooth specifications. I suggest you to specify the min SDK version to 18 in your app. Next add these permissions and feature tags in the manifest tag of your app manifest:

Since I will be printing all the data in logs, there is no need for a layout file, lets have a look at the code for using Bluetooth low energy on Android:

package com.truiton.bleexample;

import android.annotation.TargetApi;
import android.app.Activity;
import android.bluetooth.BluetoothAdapter;
import android.bluetooth.BluetoothDevice;
import android.bluetooth.BluetoothGatt;
import android.bluetooth.BluetoothGattCallback;
import android.bluetooth.BluetoothGattCharacteristic;
import android.bluetooth.BluetoothGattService;
import android.bluetooth.BluetoothManager;
import android.bluetooth.BluetoothProfile;
import android.bluetooth.le.BluetoothLeScanner;
import android.bluetooth.le.ScanCallback;
import android.bluetooth.le.ScanFilter;
import android.bluetooth.le.ScanResult;
import android.bluetooth.le.ScanSettings;
import android.content.Context;
import android.content.Intent;
import android.content.pm.PackageManager;
import android.os.Build;
import android.os.Bundle;
import android.os.Handler;
import android.support.v7.app.ActionBarActivity;
import android.util.Log;
import android.widget.Toast;

import java.util.ArrayList;
import java.util.List;

@TargetApi(21)
public class MainActivity extends ActionBarActivity {
    private BluetoothAdapter mBluetoothAdapter;
    private int REQUEST_ENABLE_BT = 1;
    private Handler mHandler;
    private static final long SCAN_PERIOD = 10000;
    private BluetoothLeScanner mLEScanner;
    private ScanSettings settings;
    private List filters;
    private BluetoothGatt mGatt;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mHandler = new Handler();
        if (!getPackageManager().hasSystemFeature(PackageManager.FEATURE_BLUETOOTH_LE)) {
            Toast.makeText(this, "BLE Not Supported",
                    Toast.LENGTH_SHORT).show();
            finish();
        }
        final BluetoothManager bluetoothManager =
                (BluetoothManager) getSystemService(Context.BLUETOOTH_SERVICE);
        mBluetoothAdapter = bluetoothManager.getAdapter();

    }

    @Override
    protected void onResume() {
        super.onResume();
        if (mBluetoothAdapter == null || !mBluetoothAdapter.isEnabled()) {
            Intent enableBtIntent = new Intent(BluetoothAdapter.ACTION_REQUEST_ENABLE);
            startActivityForResult(enableBtIntent, REQUEST_ENABLE_BT);
        } else {
            if (Build.VERSION.SDK_INT >= 21) {
                mLEScanner = mBluetoothAdapter.getBluetoothLeScanner();
                settings = new ScanSettings.Builder()
                        .setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY)
                        .build();
                filters = new ArrayList();
            }
            scanLeDevice(true);
        }
    }

    @Override
    protected void onPause() {
        super.onPause();
        if (mBluetoothAdapter != null && mBluetoothAdapter.isEnabled()) {
            scanLeDevice(false);
        }
    }

    @Override
    protected void onDestroy() {
        if (mGatt == null) {
            return;
        }
        mGatt.close();
        mGatt = null;
        super.onDestroy();
    }

    @Override
    protected void onActivityResult(int requestCode, int resultCode, Intent data) {
        if (requestCode == REQUEST_ENABLE_BT) {
            if (resultCode == Activity.RESULT_CANCELED) {
                //Bluetooth not enabled.
                finish();
                return;
            }
        }
        super.onActivityResult(requestCode, resultCode, data);
    }

    private void scanLeDevice(final boolean enable) {
        if (enable) {
            mHandler.postDelayed(new Runnable() {
                @Override
                public void run() {
                    if (Build.VERSION.SDK_INT < 21) {
                        mBluetoothAdapter.stopLeScan(mLeScanCallback);
                    } else {
                        mLEScanner.stopScan(mScanCallback);

                    }
                }
            }, SCAN_PERIOD);
            if (Build.VERSION.SDK_INT < 21) {
                mBluetoothAdapter.startLeScan(mLeScanCallback);
            } else {
                mLEScanner.startScan(filters, settings, mScanCallback);
            }
        } else {
            if (Build.VERSION.SDK_INT < 21) {
                mBluetoothAdapter.stopLeScan(mLeScanCallback);
            } else {
                mLEScanner.stopScan(mScanCallback);
            }
        }
    }


    private ScanCallback mScanCallback = new ScanCallback() {
        @Override
        public void onScanResult(int callbackType, ScanResult result) {
            Log.i("callbackType", String.valueOf(callbackType));
            Log.i("result", result.toString());
            BluetoothDevice btDevice = result.getDevice();
            connectToDevice(btDevice);
        }

        @Override
        public void onBatchScanResults(List results) {
            for (ScanResult sr : results) {
                Log.i("ScanResult - Results", sr.toString());
            }
        }

        @Override
        public void onScanFailed(int errorCode) {
            Log.e("Scan Failed", "Error Code: " + errorCode);
        }
    };

    private BluetoothAdapter.LeScanCallback mLeScanCallback =
            new BluetoothAdapter.LeScanCallback() {
                @Override
                public void onLeScan(final BluetoothDevice device, int rssi,
                                     byte[] scanRecord) {
                    runOnUiThread(new Runnable() {
                        @Override
                        public void run() {
                            Log.i("onLeScan", device.toString());
                            connectToDevice(device);
                        }
                    });
                }
            };

    public void connectToDevice(BluetoothDevice device) {
        if (mGatt == null) {
            mGatt = device.connectGatt(this, false, gattCallback);
            scanLeDevice(false);// will stop after first device detection
        }
    }

    private final BluetoothGattCallback gattCallback = new BluetoothGattCallback() {
        @Override
        public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState) {
            Log.i("onConnectionStateChange", "Status: " + status);
            switch (newState) {
                case BluetoothProfile.STATE_CONNECTED:
                    Log.i("gattCallback", "STATE_CONNECTED");
                    gatt.discoverServices();
                    break;
                case BluetoothProfile.STATE_DISCONNECTED:
                    Log.e("gattCallback", "STATE_DISCONNECTED");
                    break;
                default:
                    Log.e("gattCallback", "STATE_OTHER");
            }

        }

        @Override
        public void onServicesDiscovered(BluetoothGatt gatt, int status) {
            List services = gatt.getServices();
            Log.i("onServicesDiscovered", services.toString());
            gatt.readCharacteristic(services.get(1).getCharacteristics().get
                    (0));
        }

        @Override
        public void onCharacteristicRead(BluetoothGatt gatt,
                                         BluetoothGattCharacteristic
                                                 characteristic, int status) {
            Log.i("onCharacteristicRead", characteristic.toString());
            gatt.disconnect();
        }
    };
}

Bluetooth LE is huge topic, hence the example above only shows how to scan available Bluetooth low energy devices, discover their services and read the basic characteristics of it. The above example shows the best practices to detect a BLE device in an Android app with support up to API 18. To keep it short and simple, instead of writing full code for selecting a Gatt profile/service. I have randomly selected a Generic attribute (Gatt) profile above to print its BluetoothGattCharacteristic object using gatt.readCharacteristic(services.get(1).getCharacteristics().get(0)). To actually read BLE attributes, you may need to write code specifically for your application as there may not be a single way to do it, as there are around 50 Gatt based profile specifications. Hence lets understand each component of Android Bluetooth Low Energy API individually.

Working of Bluetooth LE in Android

As I mentioned BLE has different Gatt profiles, each BLE device has a profile, through which they can act as a server. Like all network devices, Bluetooth LE also works in a client/server manner. Here in the example above, mobile app would act as a client and the BLE device would act as a server.

Scanning Bluetooth Low Energy Devices

In the above example I scanned BLE devices using the highest power consumption mode ScanSettings.SCAN_MODE_LOW_LATENCY. As here my objective was to detect nearby BLE devices immediately. But in total, the new API offers three modes in which nearby BLE devices could be scanned.

ScanSettings.SCAN_MODE_LOW_POWER – This is the default BLE scan mode, consuming the lowest power, but has a high latency. Good for use when BLE device detection needs to be done in background.
ScanSettings.SCAN_MODE_BALANCED – This mode scans Bluetooth LE devices in a balanced power consumption mode, with respect to latency.
ScanSettings.SCAN_MODE_LOW_LATENCY – This mode uses the highest power, when compared to other modes. Also detects the BLE devices fastest, hence should be used when the app is in foreground.

Reading BLE Characteristics in Android

BLE characteristic is the actual data which is served through the BLE device. For example heart rate from a heart rate BLE device is a characteristic. Reading BLE characteristics or getting notified of changed BLE characteristics could be a whole different tutorial. As this could have a huge amount of customizations. Therefore here lets lets discuss the basic part only to get you started.

To read Bluetooth low energy characteristics after scanning, we first need to connect to a BLE device using connectToDevice method as shown above. Then further a connection needs to be established with a Gatt profile using device.connectGatt method, returning connection callbacks to the BluetoothGattCallback class also as shown in the example above. Further when a connection is established we need to discover all the services using gatt.discoverServices() method. This would invoke onServicesDiscovered method, where you can select a service and determine the types of characteristics it has. If the characteristic type is read, then the gatt.readCharacteristic method could be used, which would fire the onCharacteristicRead callback as shown above. But if characteristic type is notify, you may need to set notifications using the setCharacteristicNotification method. More of this could be read from here, as reading Bluetooth Low Energy characteristic notifications is not in our scope. Hope this Android Bluetooth Low Energy example helped you in getting started and scanning your first BLE device. Connect with us on Facebook, Google+ and Twitter for more updates.

Mohit Gupt

www.truiton.com

The post Android Bluetooth Low Energy (BLE) Example appeared first on Truiton.

Obtaining SHA1 Fingerprint from Android Keystore

Mohit Gupt — Fri, 10 Apr 2015 20:18:29 +0000

To access APIs in Android from Google API console you need to generate an API Key. This same API key can me used for accessing multiple APIs under the same project. To generate an API key you require, SHA1 fingerprint of your keystore. Keystore is basically a place where the private keys for your app are kept. In simple words its a certificate generated by user or a program, used for signing an Android app.

In android there are two types of keystores. A debug keystore, and a release keystore. Debug keystore is generated automatically when the Android SDK is installed or run for the first time. Release keystore has to be generated manually by the user for each application before release. As it requires private information such as name, password etc. To obtain an Android SHA1 fingerprint from your desired keystore, please follow the steps below:

1) Getting Android Debug Keystore SHA1 Fingerprint:

The hard way:

Open a terminal window.
Change the directory to the JDK bin directory, mine was jdk1.7.0_05 (could be different for you).
```
cd C:\Program Files\Java\jdk1.7.0_05\bin
```

Next we have to run the keytool.exe. Use the following line to get the Android SHA1 fingerprint.
Windows:

keytool -list -v -keystore "%USERPROFILE%\.android\debug.keystore" -alias androiddebugkey -storepass android -keypass android

Mac and Linux:

keytool -list -v -keystore ~/.android/debug.keystore -alias androiddebugkey -storepass android -keypass android

The easy way (Only for Eclipse IDE):

Open Preferences by Navigating to Window -> Preferences.
Select Android -> Build.

2) Getting Android Release Keystore SHA1 Fingerprint:

To find out the Android SHA1 fingerprint for release keystore, follow these steps:

Open terminal
Change the directory to the JDK bin directory, mine was jdk1.7.0_05 (could be different for you).
```
cd C:\Program Files\Java\jdk1.7.0_05\bin
```

Next we have to run the keytool.exe. Use the following line to get the SHA1 fingerprint.

keytool -list -v -keystore {keystore_name} -alias {alias_name}

Example:

keytool -list -v -keystore C:\Users\MG\Desktop\test.jks -alias test

It will prompt for a password.

Enter the password, you will get the SHA1 and MD5 fingerprint.

Extracting the SHA1 fingerprint from an Android keystore cannot be simpler than this. Above steps can be used on Windows, Mac and on Linux machines.

Mohit Gupt

www.truiton.com

The post Obtaining SHA1 Fingerprint from Android Keystore appeared first on Truiton.

Android Volley ImageLoader and NetworkImageView Example

Mohit Gupt — Thu, 26 Mar 2015 07:52:45 +0000

One of the new concepts introduced in Android is Volley. The reason, volley library is preferred over other similar libraries is because it is authored by Google engineers. But one of the major problems with volley library is that it lacks proper documentation. As far as I know the only official documentation available is at this Android Developers page. Coming to the point, here I will discuss how to make an Android Volley ImageLoader Example using the NetworkImageView. As in one of my earlier tutorials, we discussed how to make asynchronous HTTP calls through Volley, I will not go in details of Volley. Volley is a highly customizable library and can be used in many situations like, displaying images in a ListView, RecyclerView, or just getting plain data from REST web APIs. Here we will discuss the basic building blocks of volley which may help you to retrieve images from the network.

To start off with volley first you may need to download and include Android volley library in your project. For steps please refer to this volley tutorial. Next you may need to add the internet permission in your manifest:

How to load images through Android Volley ImageLoader?

Earlier to load images in an Android ImageView, the standard approach taken was, the usage of HttpURLConnection class. But now with volley this is simplified as we may not need to get in to such complex code. Volley gives us two new classes which make life easier.

Android Volley ImageLoader

Volley uses ImageLoader to load images from network, and also to cache them into your Android phone’s in-memory cache by using the LruCache class. A good approach would be to use Android ImageLoader in a singleton pattern, as same cache should be used throughout the application. Also if used in a singleton pattern your cache would not be activity dependent. Hence whenever you close and open the activity, your images could be picked up from the cache, saving network requests. Now this brings up a question, how to make this volley singleton class? please have a look at the code below:

package com.truiton.volleyimageloader;

import android.content.Context;
import android.graphics.Bitmap;
import android.util.LruCache;

import com.android.volley.Cache;
import com.android.volley.Network;
import com.android.volley.RequestQueue;
import com.android.volley.toolbox.BasicNetwork;
import com.android.volley.toolbox.DiskBasedCache;
import com.android.volley.toolbox.HurlStack;
import com.android.volley.toolbox.ImageLoader;

/**
 * Custom implementation of Volley Request Queue
 */
public class CustomVolleyRequestQueue {

    private static CustomVolleyRequestQueue mInstance;
    private static Context mCtx;
    private RequestQueue mRequestQueue;
    private ImageLoader mImageLoader;


    private CustomVolleyRequestQueue(Context context) {
        mCtx = context;
        mRequestQueue = getRequestQueue();

        mImageLoader = new ImageLoader(mRequestQueue,
                new ImageLoader.ImageCache() {
                    private final LruCache
                            cache = new LruCache(20);

                    @Override
                    public Bitmap getBitmap(String url) {
                        return cache.get(url);
                    }

                    @Override
                    public void putBitmap(String url, Bitmap bitmap) {
                        cache.put(url, bitmap);
                    }
                });
    }

    public static synchronized CustomVolleyRequestQueue getInstance(Context context) {
        if (mInstance == null) {
            mInstance = new CustomVolleyRequestQueue(context);
        }
        return mInstance;
    }

    public RequestQueue getRequestQueue() {
        if (mRequestQueue == null) {
            Cache cache = new DiskBasedCache(mCtx.getCacheDir(), 10 * 1024 * 1024);
            Network network = new BasicNetwork(new HurlStack());
            mRequestQueue = new RequestQueue(cache, network);
            // Don't forget to start the volley request queue
            mRequestQueue.start();
        }
        return mRequestQueue;
    }

    public ImageLoader getImageLoader() {
        return mImageLoader;
    }

}

In the above class you may see that a CustomVolleyRequestQueue is set up which can return an object of ImageLoader. The class above also creates an ImageCache which works with normal volley cache, but only caching images for requests. Please note here: I just modified the singleton class from my previous Volley Example. Therefore as a whole, the above class can be used to make any type of Android volley requests, be it a JsonRequest, ImageRequest, or just a simple StringRequest.

Android Volley NetworkImageView

A new view introduced with Android volley is NetworkImageView. As a matter of fact this view replaces the standard ImageView, when comes to the usage of volley. Android Volley NetworkImageView is designed in such a way that it creates an image request, sends it and even displays the image, after it is downloaded from the URL. Also it cancels the request on its own if it is detached from the view hierarchy. Hence no need to handle the request cancellations with Volley NetworkImageView. Have a look at the layout for this Android Volley ImageLoader and NetworkImageView Example, it just includes a NetworkImageView instead of ImageView:

Next lets have a look at the code for the main activity class:

package com.truiton.volleyimageloader;

import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;

import com.android.volley.toolbox.ImageLoader;
import com.android.volley.toolbox.NetworkImageView;


public class MainActivity extends AppCompatActivity {
    private NetworkImageView mNetworkImageView;
    private ImageLoader mImageLoader;


    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mNetworkImageView = (NetworkImageView) findViewById(R.id
                .networkImageView);
    }

    @Override
    protected void onStart() {
        super.onStart();
        // Instantiate the RequestQueue.
        mImageLoader = CustomVolleyRequestQueue.getInstance(this.getApplicationContext())
                .getImageLoader();
        //Image URL - This can point to any image file supported by Android
        final String url = "http://goo.gl/0rkaBz";
        mImageLoader.get(url, ImageLoader.getImageListener(mNetworkImageView,
                R.mipmap.truiton_short, android.R.drawable
                        .ic_dialog_alert));
        mNetworkImageView.setImageUrl(url, mImageLoader);
    }
}

As you may see in the above class I used an instance of CustomVolleyRequestQueue to get the volley ImageLoader object. Further I just specified the URL through setImageUrl method of NetworkImageView. This handles all the functionality by itself.

Want to display images in a ListView using volley?

If you need to display images in a ListView just use the setImageUrl method of NetworkImageView in the getView method of your adapter. This will handle all your image requests automatically. Just a reminder, don’t forget to use the NetworkImageView instead of normal ImageView.

Screenshot of Android Volley ImageLoader Example:

For better understanding, please refer to full source code below:

Full Source Code

Default images in Android Volley NetworkImageView

There are situations when you may just want to simply display a placeholder for an image which is about to be fetched from the the network. With Android Volley ImageLoader this can be done very easily. It gives a get method, through which you can display a default image as well as an error image in-case the request fails. In this ImageLoader tutorial I have used R.mipmap.truiton_short as a default image and android.R.drawable.ic_dialog_alert as an error image in the main activity class above. Hope this helped you. Please connect with us on Facebook, Google+, and Twitter for more updates.

Mohit Gupt

www.truiton.com

The post Android Volley ImageLoader and NetworkImageView Example appeared first on Truiton.

Android ViewSwitcher vs ViewFlipper – The Difference

Mohit Gupt — Sun, 14 Jul 2013 10:19:24 +0000

While working on Android development at Truiton, everyday I encounter new unique issues which nobody has ever faced or maybe if faced they didn’t share their experience on the internet, hence I end up writing them for community myself. Today’s topic of discussion is Android ViewSwitcher vs ViewFlipper – The Difference. Usually both of these classes are used to transform one view to another, its up to your coding style how you do it. Both classes have the ability to transform one view to another with or without animations. In this tutorial I would be sharing my experience on Android ViewSwitcher vs ViewFlipper, which one to use in which situation.

Although since this article Android ViewSwitcher vs ViewFlipper – The Difference would only give you an over view of both ViewSwitcher and ViewFlipper Class and majorly explain the difference between the two, If you intend to read my detailed tutorials on Switchers and Flippers please have look at the links below:

Recently I was working for an app in which I had to transform one view into another in an animated way. The problem was, that I had three LinearLayouts on screen of which only two were supposed to be visible at a time to end user. These LinearLayouts were sort of input forms for the end user and layouts number two/three were supposed to appear on a conditional input from layout one. To my dismay when I looked up the internet I found two classes of android which were serving to this purpose i.e Switching/Flipping views. It got me thinking which one to use? After a thorough research I found out which one to use for my purpose. But to explain it here first I have to set base by giving an intro to both classes and then explain Android ViewSwitcher vs ViewFlipper – The Difference.

Another important and simple use that I could think of these classes, was to swipe through the screens, I have explained it with examples in my complete series above, but here lets have a look at :

Android ViewSwitcher

Android View Switcher class is used, as its name suggests to switch between views. And here by switch we mean there can only be two views. If one more view is added the app would crash. The official documentation states that it has a setFactory method which could be used to load views from factory interface, also it states a ViewAnimator can be used with this, but here in my tutorial about ViewSwitcher I have used the android XML files for e.g. android.R.anim.fade_in as it gives a better control on which animation you intend to show. To understand the difference in Android ViewSwitcher vs ViewFlipper, lets have a look at the other class.

Android ViewFlipper

Android View Flipper in another class which is used in Android to flip between views. The main advantage of using this class is that it can have any number of views, through which we can flip. But keep in mind here too that only one view is shown at a time. This ViewFlipper class can also be used to create a slideshow of views with regular intervals. Its documentation also states that a ViewAnimator can be used to display animations but here to in my detailed tutorial about Android ViewFlipper, I have used android XML files for e.g. android.R.anim.fade_in as it gives a better control. Now that we have an idea of idea of both the classes lets have a look at Android ViewSwitcher vs ViewFlipper – The Difference.

Android ViewSwitcher vs ViewFlipper – The Difference

By now if you have read the complete article you must have understood the difference between Android ViewSwitcher and ViewFlipper. The key difference between them is that ViewSwitcher can accommodate only two views whereas ViewFlipper can accommodate more than two views. An advantage of ViewSwitcher is that it has factory interface ViewSwitcher.ViewFactory which could be used from setFactory method but still maximum up to two layouts can be added. An advantage of ViewFlipper is that it can flip through all the specified views with a regular interval like a slideshow.

With this I can conclude this tutorial on Android ViewSwitcher vs ViewFlipper – The Difference. If you liked it please share it with your friends on Google+ and Facebook, also like our Facebook page to keep in touch.

Mohit Gupt

www.truiton.com

The post Android ViewSwitcher vs ViewFlipper – The Difference appeared first on Truiton.

Google Maps Android API v2 – Introduction

Mohit Gupt — Wed, 01 May 2013 15:30:55 +0000

Recently in late 2012 Google released a new version of its flagship maps API, Google Maps Android API v2. Initially Google Maps Android API v2, was released with humongous amount of bugs, which were later on fixed in Feb 2013 release. Google Maps Android API v2 is not released as a part of Android APIs, instead its released as a part of Google Play Services SDK. Therefore to use the features of Google Maps Android API v2, we need to include Google Play Services SDK in our project, this article Google Maps Android API v2 – Introduction, focuses on general feature introduction as well as creating a project with Google Maps Android API v2.

Google Maps Android API v2 Tutorials

Google Maps Android API v2 can be displayed in an android app via two classes MapFragment and SupportMapFragment. This article is the first of three, to explain the process of displaying Google Maps on Android. In this Google Maps Android API v2 – Introduction, I will be discussing basic features and lay foundation of Google Maps Android API v2 by explaining on how to include Google Play Services Library in our project. This article would be followed by 2 tutorials in this series:

Including Google Play Services SDK Library

As I stated earlier Google Maps Android API v2 is not included in Android API, its bundled with Google Play Services SDK. Therefore to use Google Maps on Android we need to include Google Play Services SDK Library in our project. At Truiton I followed these steps to create a project:

Open Android SDK Manager -> Extras -> Google Play Services -> Install Packages.
In Eclipse File-> Import -> Android -> Existing Android Code into Workspace -> Browse to your Android SDK Folder -> /Extras/google/google_play_services/libproject -> Finish.
Create new android project -> After creating project right click on its folder and select properties.
Goto “Android” property -> click add button below -> select “google-play-services_lib” -> hit Ok and you’re all set.

Google Maps Android API v2 Emulator Issue

It has been a topic of discussion on various forums, some people confirmed that they installed Google Play Store by vending.apk and gms.apk via ADB. But when I tried none of them worked for my config of emulator. I searched about it and found that Google has stated that Google Play Services SDK wont run on emulator, you can read it here.

Google Maps Android API v2 – Features

One of the features that I like about Google Maps Android API v2 is that it displays maps in 3D, you can pan and tilt the screen to view the buildings in 3D on your mobile device. Another good feature is that we can rotate the map according to out convenience. Also Google Maps Android API v2 has advantages from a developers perspective. For e.g. to display maps on an android device now, we have to use MapFragment and SupportMapFragment classes, over the previous method of using MapActivity. This way we can include a MapFragment in an Activity which could have some other functionality as well. This functionality alone can benefit many in many ways. With this I can conclude first part of my series on Google Maps Android API v2. If this tutorial helped you in some way please like and share this with your friends on Google+ and Facebook, also like our Facebook page for updates.

Mohit Gupt

www.truiton.com

The post Google Maps Android API v2 – Introduction appeared first on Truiton.