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<JacocoPluginExtension> {
    toolVersion = "0.8.12"
}

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

tasks.register<JacocoReport>("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<FirebasePerfExtension> {
                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:

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.

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

When you are building backend REST APIs and if you plan to generate identifiers or primary keys for your table records, you have to pick a primary key generation strategy which could be either one of the following AUTO, IDENTITY, SEQUENCE, TABLE or UUID. When designing a system from scratch, you always would want to pick the strategy that works best for you. I was working on a set of backend REST APIs which are built using Kotlin Spring Hibernate framework with MySQL database. For persistence and ORM I decided to use Spring data JPA for this project, as it is suited the best. Here in this article I wish to share my learnings on use of GenerationType.TABLE vs. GenerationType.SEQUENCE, and determine which id generation strategy is faster when we have to dynamically generate identifiers for table records.

Problem Statement: How to generate String identifiers with a prefix with Spring boot using JPA

As mentioned, I am using MySQL database with Hibernate and Spring data JPA. For few of my tables I had a requirement to have simple numerical identifiers like 1,2,3,4 and so on. But for some of the tables in the database I wished to have an id with prefix like:

I read through a lot of posts available on the internet about how to generate an identifier with prefix and which GenerationType strategy is best for it. In most of the posts it was suggested that GenereationType.IDENTITY or GenerationType.SEQUENCE are fast and scalable enough to give a good performance. But since I wished to generate an ID which is supposed to have string characters as well as integers, IDENTITY type generation strategy was ruled out. As to utilize the true power of GenereationType.IDENTITY, I would need to have an AUTO_INCREMENT column in MySQL DB, which would have defeated the whole purpose of having a string prefix, and columns with VARCHAR cannot have AUTO_INCREMENT property.

Implementing Custom SequenceGenerator with Spring boot JPA using MySQL DB

In some of the posts on the internet it is suggested that identifier generation strategy GenerationType.SEQUENCE is one of the best strategies available. But given our use case we are using MySQL DB in this implementation, and as we know MySQL DB does not support sequences. Therefore if we wish to use SequenceGenerator strategy in Spring boot JPA using MySQL DB, then we need go with some workarounds. Since MySQL does not support the sequences, but still if we want to use this strategy, we have to create a sequence table which would maintain the next_val counter for the records in our table. JPA in Hibernate is built in such a way that SequenceGenerator strategy can work with a table as well in the case of MySQL. So to implement the same one can create a TABLE_NAME_seq table and use it with Spring data JPA in Hibernate. I created following table via SQL:

CREATE TABLE IF NOT EXISTS `cosmos`.`my_table_seq` (
  `name` VARCHAR(45) NOT NULL,
  `next_val` BIGINT(20) NULL DEFAULT NULL,
  PRIMARY KEY (`name`))

Next we need to add a record to this table, to get things started:

Now we need to build a custom Sequence Generator using the SequenceStyleGenerator class:

package com.truiton.cosmos.sequences

import org.hibernate.HibernateException
import org.hibernate.MappingException
import org.hibernate.engine.spi.SharedSessionContractImplementor
import org.hibernate.id.enhanced.SequenceStyleGenerator
import org.hibernate.internal.util.config.ConfigurationHelper
import org.hibernate.service.ServiceRegistry
import org.hibernate.type.Type
import org.hibernate.type.spi.TypeConfiguration
import java.io.Serializable
import java.util.*


class StringPrefixedSequenceIdGenerator : SequenceStyleGenerator() {
    val VALUE_PREFIX_PARAMETER: String = "valuePrefix"
    val VALUE_PREFIX_DEFAULT: String = ""
    private var valuePrefix: String? = null

    val NUMBER_FORMAT_PARAMETER: String = "numberFormat"
    val NUMBER_FORMAT_DEFAULT: String = "%d"
    private var numberFormat: String? = null

    @Throws(HibernateException::class)
    override fun generate(
        session: SharedSessionContractImplementor?,
        `object`: Any?
    ): Serializable {
        return valuePrefix + String.format(numberFormat!!, super.generate(session, `object`))
    }

    @Throws(MappingException::class)
    override fun configure(type: Type?, params: Properties?, serviceRegistry: ServiceRegistry?) {
        super.configure(
            TypeConfiguration().basicTypeRegistry.getRegisteredType(Long::class.java),
            params,
            serviceRegistry
        )
        valuePrefix = ConfigurationHelper.getString(
            VALUE_PREFIX_PARAMETER,
            params, VALUE_PREFIX_DEFAULT
        )
        numberFormat = ConfigurationHelper.getString(
            NUMBER_FORMAT_PARAMETER,
            params, NUMBER_FORMAT_DEFAULT
        )
    }
}

To use this StringPrefixedSequenceIdGenerator, we need reference it in our entity class by using the following:

@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "cosmos_sequence1")
@GenericGenerator(
    name = "cosmos_sequence1",
    type = StringPrefixedSequenceIdGenerator::class,
    parameters = [
        org.hibernate.annotations.Parameter(name = "sequence_name", value = "my_table_seq"),
        org.hibernate.annotations.Parameter(name = "increment_size", value = "50"),
        org.hibernate.annotations.Parameter(name = "optimizer", value = "pooled-lo"),
        org.hibernate.annotations.Parameter(name = "valuePrefix", value = "TPA"),
        org.hibernate.annotations.Parameter(name = "numberFormat", value = "%05d")])
@Column(name = "id", nullable = false, length = 10)
open var id: String? = null

Now when we run this, and insert any record in the database for this entity, it will generate the desired identifier format i.e. TPA00001. Also it will maintain the counter for increment in my_table_seq table, while having the pre allocated numbers in the memory. Like for this example it would hit the my_table_seq table once to increment after 50 inserts have happened.

This identifier generation strategy for Spring JPA works well with MySQL. But with this approach the only downside I feel is that, we have to create a sequence table corresponding to every table in our database where we need to maintain sequence strategy based IDs. If only, we could optimize this further, our database would be much cleaner. The answer to this problem is GenerationType.TABLE, which we’ll explore in next section.

Implementing Custom TableGenerator with Spring boot JPA using MySQL DB

Here I will show how to implement a custom TableGenerator which adds a prefix to the generated incremental numeric value in Spring boot JPA using MySQL database. Also I will explain how efficiently this identifier generation strategy can be used for multiple tables when generating primary keys for records.

Internally this GenerationType.TABLE strategy is very similar to sequence generator. Here a single table can have multiple next_val counters for multiple entity tables. There are many threads available over the internet about its performance, but lets reserve this point for next section where we compare GenerationType Table vs Sequence. For now lets create a table where we can maintain primary keys for our entities:

CREATE TABLE IF NOT EXISTS `cosmos`.`cosmos_sequence` (
  `sequence_name` VARCHAR(255) NOT NULL,
  `next_val` BIGINT(20) NULL DEFAULT NULL,
  PRIMARY KEY (`sequence_name`))

Next lets create a class for implementing a custom TableGenerator which can generate primary keys with a prefix in Spring boot JPA with MySQL.

package com.truiton.cosmos.sequences

import org.hibernate.HibernateException
import org.hibernate.MappingException
import org.hibernate.engine.spi.SharedSessionContractImplementor
import org.hibernate.id.enhanced.TableGenerator
import org.hibernate.internal.util.config.ConfigurationHelper
import org.hibernate.service.ServiceRegistry
import org.hibernate.type.Type
import org.hibernate.type.spi.TypeConfiguration
import java.io.Serializable
import java.util.*


class StringPrefixedTableGenerator : TableGenerator() {
    val VALUE_PREFIX_PARAMETER: String = "valuePrefix"
    val VALUE_PREFIX_DEFAULT: String = ""
    private var valuePrefix: String? = null

    val NUMBER_FORMAT_PARAMETER: String = "numberFormat"
    val NUMBER_FORMAT_DEFAULT: String = "%d"
    private var numberFormat: String? = null

    @Throws(HibernateException::class)
    override fun generate(
        session: SharedSessionContractImplementor?,
        `object`: Any?
    ): Serializable {
        return valuePrefix + String.format(numberFormat!!, super.generate(session, `object`))
    }

    @Throws(MappingException::class)
    override fun configure(type: Type?, params: Properties?, serviceRegistry: ServiceRegistry?) {
        super.configure(
            TypeConfiguration().basicTypeRegistry.getRegisteredType(Long::class.java),
            params,
            serviceRegistry
        )
        valuePrefix = ConfigurationHelper.getString(
            VALUE_PREFIX_PARAMETER,
            params, VALUE_PREFIX_DEFAULT
        )
        numberFormat = ConfigurationHelper.getString(
            NUMBER_FORMAT_PARAMETER,
            params, NUMBER_FORMAT_DEFAULT
        )
    }
}

Now to actually use this StringPrefixedTableGenerator we need to reference it in our entity class with all the parameters

@Id
@GenericGenerator(
    name = "my_table_sequence",
    type = StringPrefixedTableGenerator::class,
    parameters = [
        org.hibernate.annotations.Parameter(name = TableGenerator.TABLE_PARAM, value = "cosmos_sequence"),
        org.hibernate.annotations.Parameter(name = TableGenerator.SEGMENT_COLUMN_PARAM, value = "sequence_name"),
        org.hibernate.annotations.Parameter(name = TableGenerator.VALUE_COLUMN_PARAM, value = "next_val"),
        org.hibernate.annotations.Parameter(name = TableGenerator.SEGMENT_VALUE_PARAM, value = "my_table_sequence"),
        org.hibernate.annotations.Parameter(name = "initial_value", value = "1"),
        org.hibernate.annotations.Parameter(name = "increment_size", value = "50"),
        org.hibernate.annotations.Parameter(name = "optimizer", value = "pooled-lo"),
        org.hibernate.annotations.Parameter(name = "valuePrefix", value = "TPA"),
        org.hibernate.annotations.Parameter(name = "numberFormat", value = "%05d")]
)
@GeneratedValue(strategy = GenerationType.TABLE, generator = "my_table_sequence")
@Column(name = "id", nullable = false, length = 10)
open var id: String? = null

When an insert happens through the above code, a record is created in the underlying table which we have specified for the TableGenerator(in this case cosmos_sequence). Once a record is created in cosmos_sequence Spring JPA can perform 50 inserts without referencing this underlying table. This is done by using the pooled-lo optimizer, you can read more about it in its official documentation. The above code would give us the desired identifier format TPA00001.

Just to share this is how your underlying sequence table would look when you would have multiple sequences for multiple entities in the same TableGenerator table:

Therefore, as you can see, this approach would help us in optimizing the number of tables in our database. As we have used only one table for having primary key counters for multiple entities. Also, if you do not wish to have a single table due to fault tolerance or any other factors on specific entities, you can opt for an architecture where groups of specific entities have separate sequence tables while others are combined in to groups of 8, 16 or as per your need and performance.

In many online posts I have read people mentioning about the performance for TableGenerator in comparison to SequenceGenerator, I believe things are a little different when we are building with MySQL database. In the next section I would discuss about the performance of GenerationType.TABLE and GenerationType.SEQUENCE in Hibernate using MySQL database.

Comparing Custom TableGenerator vs. SequenceGenerator performance in Spring boot JPA using MySQL DB

When we compare GenerationType.TABLE vs. GenerationType.SEQUENCE using MySQL DB, there is not much of a difference in the implementation. Firstly, be it SEQUENCE generation strategy or the TABLE generation, both strategies when used with pooled-lo optimization, the primary key is generated in the memory itself after the insert of first record. To be clear, in both the implementations next_val column’s values from the underlying table(s) are fetched only once, either on first insert or after the in-memory values are completely exhausted.

Secondly, both the approaches being discussed here use row level read locking techniques to safeguard the transaction and neither of them apply a table level lock when using MySQL DB with InnoDB. To query the next_val from sequence tables, Spring data JPA uses the primary key in the where clause of the query in case of GenerationType.TABLE, therefore a lock is applied only on that row. While in generation type SEQUENCE strategy only a single record is supposed to be present in the sequence table, therefore only that is locked and it should not make a difference. To actually validate this hypothesis, while the first insert was happening, I logged the queries for both of these primary key generation strategies :

Query for generation type SEQUENCE strategy using MySQL database:

select next_val as id_val from my_table_seq for update
update my_table_seq set next_val= ? where next_val=?
insert into exp_pav_loc (created_on,exp_pav_id,is_deleted,loc_type,name,number,updated_on,id) values (?,?,?,?,?,?,?,?)

Query for GenerationType.TABLE strategy using MySQL database:

select tbl.next_val from cosmos_sequence tbl where tbl.sequence_name=? for update
update cosmos_sequence set next_val=?  where next_val=? and sequence_name=?
insert into exp_pav_loc (created_on,exp_pav_id,is_deleted,loc_type,name,number,updated_on,id) values (?,?,?,?,?,?,?,?,?,?)

As you can see in the above SQL statements both of the primary key generation strategies use SELECT FOR UPDATE statements which locks rows only under normal circumstances. This is the reason, I feel that there is not much of a difference between TableGenerator and SequenceGenerator strategy when using MySQL DB with Spring data JPA. As both of them rely on the same working strategy for maintaining the counters for next_val.

Performance of TableGenerator and SequenceGenerator in Spring boot hibernate using MySQL

To further share data on the claim that there is not much of a difference in performance of GenerationType.TABLE vs. GenerationType.SEQUENCE when using MySQL DB, I created APIs and used JMeter for performance testing. For the first test I created one REST POST API, which performs an insert on a table when called. Further I used JMeter with following load to test its performance

For the first three runs I had configured the API to use GenerationType.SEQUENCE as the primary key generation strategy using the code shared in above sections. I will log the time taken in milliseconds for an API to return response by using JMeter. Please have a look at the 15k sample results for this performance tests:

For next three runs I configured the same API to use GenerationType.TABLE, have a look at the results:

As you can see that results are very similar but for better representation, lets have a look at the average of key figures to compare the performance between SequenceGenerator and TableGenerator

As we can see these results show a very minor difference in milliseconds even at the 99th percentile. But to be completely sure, next I decided to execute a performance test between the GenerationType.SEQUENCE vs. GenerationType.TABLE with three APIs using MySQL DB on Spring data JPA. This will help us understand the behavior of TableGenerator when multiple reads/inserts/updates happen in the same sequence table.

To do this I created three different REST POST APIs, which run an insert statement on the desired table based on the code shared in above sections. Then I configured JMeter to call these APIs sequentially in a thread group, but since I am planning to have multiple threads, eventually all of these would be called in parallel.

For the first three runs I configured the APIs to use GenerationType.SEQUENCE as the primary key generation strategy. Through this performance test I will log their response time in milliseconds. Please have a look at the data gathered, in total I captured roughly 45K samples in 3 runs of 15K each, where internally 3 APIs were being called:

Next, I configured the same set of 3 APIs to use the GenerationType.TABLE strategy to generate primary keys using Spring data JPA in MySQL DB. Like all the tests performed earlier, here as well I will log response time in milliseconds. For this test I captured around 45K samples, please have a look:

As you can see the results are very similar when we compare both the tests for 3 APIs between the SEQUENCE generation strategy and TABLE generation strategy. For better representation, lets have a look at the comparison graph:

Interestingly, even when we have this large range of samples the difference between performance of SequenceGenerator and TableGenerator is very minimal. This test not just only highlights the difference but also certifies that internally the working of SequenceGenerator and TableGenerator is very similar when used for MySQL DB in Spring data JPA.

Difference between GenerationType.SEQUENCE and GenerationType.TABLE

Looking at the data captured in performance tests above, I feel the only major functional difference between GenerationType.SEQUENCE and GenerationType.TABLE when used for MySQL DB via Spring data JPA is that the first one maintains the primary key next_val counter in separate tables vs. the later one stores the same for multiple entities in a single table. Data from the above performance tests also imply that there is no significant difference in performance when either of them is used on MySQL DB with Spring data JPA.

Another advantage of GenerationType.TABLE strategy is that it helps in keeping the database clean, as a single sequence counter table can be used to store the primary key counters for multiple entities. On the contrary, if one plans to use GenerationType.SEQUENCE, they would have to maintain equal number of sequence tables. Like, for example if you have 100 tables where primary keys need to be generated, then you need to have 100 sequence tables as well when using Spring data JPA with GenerationType.SEQUENCE, in MySQL DB.

On the other hand when using TableGenerator, you can chose to optimize according to your need, where you can plan to have one or more than one table for maintaining primary key counters, you can always have groups of entities using same sequence table based on some custom logic. Or if you have a small project you can have single sequence table as well under TableGenerator strategy for all your entities. When using TableGenerator, based on your requirement you can take a decision and build your system. I understand that there are many factors which are considered when a database is chosen for a system, but if you plan to choose MySQL database hope this article helps you decide your ID generation strategy. If this article helped you, please feel free to share it with your friends.

The post Spring Boot Hibernate – JPA GenerationType Table vs Sequence strategy with MySQL appeared first on Truiton.

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.

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:

<style name="Theme.MyCustomSplash" parent="Theme.SplashScreen">
    <item name="windowSplashScreenBackground">@color/purple_500</item>
    <item name="windowSplashScreenAnimatedIcon">@mipmap/ic_launcher</item>
    <item name="postSplashScreenTheme">@style/Theme.MyCustomSplashTheme</item>
</style>

<style name="Theme.MyCustomSplashTheme" parent="Theme.MaterialComponents.DayNight.NoActionBar">
    <item name="colorPrimary">@color/purple_500</item>
    <item name="colorPrimaryVariant">@color/purple_700</item>
    <item name="colorOnPrimary">@color/white</item>
    <item name="colorSecondary">@color/teal_200</item>
    <item name="colorSecondaryVariant">@color/teal_700</item>
    <item name="colorOnSecondary">@color/black</item>
    <item name="android:statusBarColor" tools:targetApi="l">?attr/colorPrimaryVariant</item>
    <item name="android:windowActionBar">false</item>
    <item name="android:windowNoTitle">true</item>
    <item name="android:fitsSystemWindows">false</item>
    <item name="android:windowFullscreen">true</item>
    <item name="android:windowContentOverlay">@null</item>
    <!-- Customize your theme here. -->

</style>

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.

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android">

    <application
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        android:roundIcon="@mipmap/ic_launcher_round"
        android:supportsRtl="true"
        android:theme="@style/Theme.MyCustomAppTheme">
        <activity
            android:name=".MyLaunchActivity"
            android:exported="true"
            android:theme="@style/Theme.MyCustomSplash">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />

                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>

        <activity android:name=".MainActivity" />
    </application>

</manifest>

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:

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.

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.

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

Since the adoption of reactive programming in Android by Google, a new category of life cycle aware classes were released to make the concept more usable. This paradigm shift induced a lot of changes in the android stack, and lead to the conceptualization of LiveData. This Android LiveData as we know is a data holder class on which we can put an observable to observe the changes in data it holds. This works very well with SQLite databases and API calls, but what if we have to combine both of these LiveData objects and return one single Android merged LiveData. You must be thinking, its not very straight forward. But still it is very easy to implement, in this tutorial we would have a look at how to merge two android LiveData objects and maintain a single stream of merged Android LiveData at the Activity level.

For this Android LiveData merging tutorial, it expected from you as a reader to have basic understanding of following concepts:

• Androidx
• MVVM Architecture
• Android Architecture Components
• Lifecycle Aware Programming
• Room Database

When you need to combine LiveData objects from multiple data sources into one LiveData object, you also need to take care of a case where data is changed in one of the original LiveData objects. In such a case then the corresponding data should also be refreshed in the other LiveData which is merged with current one. In the next sections you will see how to refresh data dynamically from SQLite database when one of the API call based LiveData values are changed.

How to merge and combine multiple LiveData sources?

Once you start using LiveData in your apps you will realize that, it can solve almost every data flow problem, weather you are trying to communicate with a fragment from an activity, or you are trying to connect with a database. Even if you are trying to make an API call and return data to your activity, now-days the best practice is to use a LiveData object. But one issue that you may face by using LiveData is that, if you need data from multiple sources, for example from a web API call and a local database, then how will you combine two LiveData objects? This example revolves around this problem only, where we show how to merge multiple LiveData objects in Android.

By using MediatorLiveData and Transformations

In this example, we will combine two sources of data and both of them would be served by a LiveData object at the Android activity. To achieve this merging of Android LiveData we would be using MediatorLiveData and MutableLiveData classes extensively. In brief MediatorLiveData allows us to observe on multiple LiveData objects and react to their changes. For this android merged LiveData example one should have a clear understanding of LiveData and its types, therefore please refer to the official documentation for that.

At times the use case is such that a LiveData object needs to be changed into a different type of object. Such cases can be gracefully handled by the LiveData Transformations. In this LiveData merging sample, we will be using Transformations class, this will help us in transforming and merging the LiveData from Room database with LiveData from the API call. To be specific in this sample we will be using Transformations.switchMap type of transformations method which allows us to call a function and transform the data as per our needs. For full details on transformations and room database please read about them in the official documentation, as discussing them in this post would go in a different direction.

How is a merged Android LiveData object created?

Now that we have a clear understanding of how all the components would work, lets have an understanding how they will work together. We want to achieve a functionality where we can get a merged Android LiveData from two or more sources of LiveData. Here one source can be of an API LiveData and the other one can be of a room database. To do so in this example we would use retrofit as a networking client and get a LiveData response. We will also create a stream of LiveData from room database and finally merge the two android LiveData objects with respect to each other by using MediatorLiveData and Transformations.switchMap functions. Once this is done we can put an observer on the final output of the MediatorLiveData object and fulfill our motives. Lets explore some code part in the next sections to have full understanding.

Merging Android LiveData

To showcase how to combine multiple android LiveData objects we will build a sample where we would enter a location in an EditText and show places data for that location. To fetch the surrounding places we would use the Foursqaure venues API in this case. The surrounding places that we fetched would be displayed in a RecyclerView on the same screen. To make this problem a little more interesting, we would also allow the user to mark a place favorite by tapping on a button on the details screen. To do so we will keep the ‘favorite marked place’ in our local Room Database.

Now that the final data on the listing screen would be displayed from two sources i.e. from the local Room database and from a web API call we would need to merge the data from two LiveData sources. To do so we will use MediatorLiveData and Transformations.switchMap, by following full MVVM architecture.

We will use retrofit as an API client in this Android LiveData merging sample. We have defined an interface by the name of FSInterface to make the API call, you can find the full source code at the end of the tutorial. Also we have defined a room database to store the favorite flag, with respect to the data from API. We intend to store this flag in the room database when user marks a place as favorite. Both these data sets would be eventually merged in the repository and passed on to a view model so that it can be displayed on a view i.e. our activity shown above. So lets start by defining the favorite entity:

package com.truiton.mergedlivedata.entity

import androidx.room.ColumnInfo
import androidx.room.Entity
import androidx.room.PrimaryKey

@Entity(tableName = "favourite_table")
class Favourite(@PrimaryKey @ColumnInfo(name = "foursquareId") var foursquareId: String,
    @ColumnInfo(name = "fav") var favourite: Boolean)

Next lets define the DAO functions for fetching and modifying the data from database:

package com.truiton.mergedlivedata.dao

import androidx.lifecycle.LiveData
import androidx.room.Dao
import androidx.room.Insert
import androidx.room.OnConflictStrategy
import androidx.room.Query
import com.truiton.mergedlivedata.entity.Favourite

@Dao
interface FavouriteDao {

    @Query("SELECT * from favourite_table")
    fun getAllFavourites(): LiveData<List<Favourite>>

    @Query("SELECT * from favourite_table WHERE foursquareId LIKE :id")
    fun getFavouritesById(id: String): List<Favourite>

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insert(favourite: Favourite)

    @Query("DELETE FROM favourite_table")
    fun deleteAll()
}

You can find the full implementation for room database, retrofit client and interfaces in the GitHub link shared at the end of the tutorial. Next we can define the repository where we will generate a merged Android LiveData by combining mentioned two LiveData sources:

package com.truiton.mergedlivedata

import androidx.annotation.WorkerThread
import androidx.lifecycle.LiveData
import androidx.lifecycle.MediatorLiveData
import androidx.lifecycle.MutableLiveData
import androidx.lifecycle.Transformations
import com.truiton.mergedlivedata.dao.FavouriteDao
import com.truiton.mergedlivedata.entity.Favourite
import com.truiton.mergedlivedata.model.Venues
import com.truiton.mergedlivedata.rest.FSInterface
import com.truiton.mergedlivedata.rest.RetrofitService


class FourSquareRepo(private val favouriteDao: FavouriteDao) {

    val allVenues: MutableLiveData<List<Venues>> = MutableLiveData()
    var foursquareApi = RetrofitService.createService(FSInterface::class.java)
    val mediatorLiveData = MediatorLiveData<List<Venues>>()
    var roomLiveData: LiveData<List<Venues>> = MutableLiveData()

    init {
        allVenues.value = emptyList()

        mediatorLiveData.addSource(allVenues) {
            mediatorLiveData.value = it
        }

        roomLiveData = Transformations.switchMap(favouriteDao.getAllFavourites()) { favs -> getVenues(favs) }
        mediatorLiveData.addSource(roomLiveData) {
            mediatorLiveData.value = it
        }
    }

    private fun getVenues(favourites: List<Favourite>?): LiveData<List<Venues>>? {
        val venues: MutableLiveData<List<Venues>> = MutableLiveData()
        var list = ArrayList<Venues>(allVenues.value!!)
        for (fav in favourites!!) {
            for (venue in list) {
                if (fav.foursquareId == venue.id) {
                    venue.favourite = fav
                }
            }
        }
        venues.value = list
        return venues
    }


    @WorkerThread
    suspend fun insert(favourite: Favourite) {
        favouriteDao.insert(favourite)
    }

    @WorkerThread
    suspend fun getNearbyPlaces(query: String) {
        val foursquareResponse =
            foursquareApi.getPlacesList(
                "your client_id",
                "your client_secret",
                "Seattle,+WA",
                query,
                "20180401",
                "20"
            )
        if (foursquareResponse.isSuccessful) {
            var list = foursquareResponse.body()!!.response.venues.toMutableList()
            for (venue in list) {
                if (favouriteDao.getFavouritesById(venue.id).isNotEmpty()) {
                    venue.favourite = favouriteDao.getFavouritesById(venue.id)[0]
                }
            }
            allVenues.postValue(list)
        } else {
            allVenues.postValue(emptyList())
        }

    }
}

As you can see in the above piece of code we have generated a merged LiveData object mediatorLiveData by merging allVenues data and roomLiveData which are responses from the API call and room database respectively. To do so we have used Transformations.switchMap, which helped us in calling a function in the repository itself through which we modified the structure of every object which being returned in LiveData, without putting an observer. The advantage of using a switchMap here for merging android LiveData objects is that it returns a LiveData object. To actually use this piece of code and display data on the screen please have a look at the full source code at the GitHub link below.

You can see in the full source code that we have used MutableLiveData objects, transformations and MediatorLiveData to merge and pass on the data. To see the merged LiveData in action you need to implement the ViewModel class along with an Activity with all the components for a RecyclerView. In this Android LiveData merging example we have tried to build a sample with all the latest architecture principles, if you wish to implement similar functionality in a different architecture, feel free to do so.

In this Android merged LiveData example we merged two LiveData sources, one from a web API and the other one from a local database, but in real world scenarios there could be situation where you would want to merge more than two LiveData objects. Let me assure you and say all those scenarios can be achieved by using transformations and the approach mentioned in this tutorial. Also it is not possible to cover all the capabilities of LiveData in a single article as there are infinite use-cases where it can be used. For example merging error and success LiveData responses in a single stream or combining different object types in a single stream of LiveData. For more such use-cases stay connected with us on twitter, and Facebook, also if you like this tutorial please share it with your friends and subscribe to our newsletter.

The post Merging Android LiveData appeared first on Truiton.

Google’s material design has been evolving year by year. At first when Material Design was introduced a lot of new components were listed in its documentation. But their implementation or official widgets were not released at that time. But with every support library release, few new significant components are released. With this year’s Google I/O, Androidx was released as a new implementation for Android’s support library framework, along with this a new material design component library was also released. As I mentioned above a few new components were released this year too, one of them is Android Chip. This new Android chips widget is now a part of design support library v28 and has also been introduced in this new material design component library 1.0.0. This library has many components but in this article we will be discussing on Android chips only and how to make an Android chips example, via the new Material Component library.

Android Pill button or chips have always been a part of our apps. One way or the other building a button like a pill has never been a difficult task for us. But now that Google has officially released a widget by the name of Chips, it will definitely make our lives easier to some level. In this Android chips example we would learn how to make an android chip button which looks like a pill shaped interact-able element. Please note: To make use of this example, you might have to switch over to AndroidX and com.google.android.material packages by refactoring from the Refactor menu of the Android Studio, as the new material library does not work with old support packages. If you wish to use old support libraries for the time being, please use the v28 of it. It has the Chip widget.

Exploring Material Design : Android Chips Example

Generally Android chips are used to capture user input, filter content, trigger actions and simply to make a selection from a choice of options. It should not be used in a situation where a single call to action has to be performed. One of the most obvious example of Android Chips, that you must have seen, should be the Gmail app. In Gmail app when an email address is entered, it is shown in an Android Chip like view. If you wish to make a UI element which looks like the gmail email address pill button type view, you should use the Android Chip widget. To start with the implementation part, first you would have to include the following dependency in your gradle file:

dependencies { 
implementation 'com.google.android.material:material:1.0.0' 
}

Using Android Chips with Styles

In simple terms Android Chip is just a combined object of text, icon and optional close icon. With this, the new material design component also gives us a few new attributes to change its appearance and behavior. It allows us to make it represent an attribute, text, entity, or perform an action. This eventually allows the user to trigger an action, filter content, select a choice, or enter information. Also if you have to represent a contact with image, this Android chip can be of good use. To have a more detailed look at the chips, lets have a look at its styles.

Action Chip (Default)

The most basic chip of all the available ones is the Action chip. Its a single actionable chip, in short its an alternative to the button widget. If you have to perform an action, based on users tap, this is the chip that you should use. Generally this type of chip is placed after the content of the page and is used as a clickable, just like a button. Have a look at the images below to understand its usage.

To make a working example of Android action chip, you can either define it in the XML or you can insert it dynamically by Java/Kotlin code. In this Android chips example, we will do so by XML and will use its properties in Java code. Please have a look below:

    <com.google.android.material.chip.Chip
        android:id="@+id/action_chip"
        style="@style/Widget.MaterialComponents.Chip.Action"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_below="@+id/action_chip_txt"
        android:layout_marginLeft="10dp"
        android:layout_marginStart="10dp"
        android:padding="10dp"
        android:text="Hello World"
        app:chipIcon="@drawable/ic_android_24dp"
        app:iconStartPadding="5dp"/>

In the above code, please see that we have defined a style tag style="@style/Widget.MaterialComponents.Chip.Action". This is used to define the style for action chip, but in case if this is missing, it would still render an Android chip with ‘Action’ style. As this is also the default style. Moving ahead, to capture this Android chip’s click event, we use this piece of code:

        Chip actionChip = findViewById(R.id.action_chip);
        actionChip.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                Log.i(TAG, "Clicked action chip");
            }
        });

Entry Chip (Input Chip)

Another type of chip is the input one, this chip used display captured user input in a non editable format. Its a very nice way to showcase the user input. One of the most obvious usages of Android Entry chip is shown in the gmail app. Particularly the email input experience- when an email is entered by the user, it is showcased as an entry chip, sort of a pill shaped layout. Now according to the material design this element should be an Android Chip with style as ‘Entry’. This chip can also have a close icon along with a chip icon. Generally this type of chip is contained in a ChipGroup. ChipGoup class is similar to RadioGroup class, as it is used to hold multiple chips. It has the properties to display all the chips in a single line. Have a look at the images below to have a better understanding on how the entry chips would look:

In case of Android entry chips, in the XML we will create an empty ChipGroup and add chips programmatically. Lets have a look at the layout.xml of the activity:

    <com.google.android.material.chip.ChipGroup
        android:id="@+id/entry_chip_group"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_below="@+id/entry_chip_txt">

    </com.google.android.material.chip.ChipGroup>

Now since we will be adding chips dynamically through code, a big challenge would be to maintain style along the chips. As per my understanding to maintain consistent styles there are two ways, either by code we style it and use in a loop. Or we create a standard chip style in XML and use it across. Interestingly Android Chips widget also supports a ChipDrawable class through which we can create a chip dynamically, and this ChipDrawable object can be created by using an XML resource. Therefore as per the principle I like this way better, have a look at my chip style which I used to inject a chip in ChipGroup :

<chip
    style="@style/Widget.MaterialComponents.Chip.Entry"
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:checkable="false"
    app:chipIcon="@drawable/ic_android_24dp"
    app:iconStartPadding="5dp"/>

Next to create an Input Chip dynamically we need to define a method :

    private Chip getChip(final ChipGroup entryChipGroup, String text) {
        final Chip chip = new Chip(this);
        chip.setChipDrawable(ChipDrawable.createFromResource(this, R.xml.my_chip));
        int paddingDp = (int) TypedValue.applyDimension(
                TypedValue.COMPLEX_UNIT_DIP, 10,
                getResources().getDisplayMetrics()
        );
        chip.setPadding(paddingDp, paddingDp, paddingDp, paddingDp);
        chip.setText(text);
        chip.setOnCloseIconClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                entryChipGroup.removeView(chip);
            }
        });
        return chip;
    }

And this is how an Android Entry Chip is inserted in the chip group:

final ChipGroup entryChipGroup = findViewById(R.id.entry_chip_group);
final Chip entryChip = getChip(entryChipGroup, "Hello World");
final Chip entryChip2 = getChip(entryChipGroup, "Test");
entryChipGroup.addView(entryChip);
entryChipGroup.addView(entryChip2);

Filter Chip

These type of chips should be used in situations exactly as its name suggests, i.e. for creating filters. Android filter chips are similar to check boxes, in a way they should be used to filter the content. For example if you have to show a UI where there’s a list and user has to filter a specific type of content from it, in this situation a filter chip would be an apt solution. Generally filter chips do not have a icon attached to them, as a check icon is displayed once a chip is selected. Please have a look at the images below:

Further lets define the XML for Android Filter Chips, they have style="@style/Widget.MaterialComponents.Chip.Filter" :

    <com.google.android.material.chip.ChipGroup
        android:id="@+id/filter_chip_group"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_below="@id/filter_chip_txt">

        <com.google.android.material.chip.Chip
            android:id="@+id/filter_chip"
            style="@style/Widget.MaterialComponents.Chip.Filter"
            android:layout_width="wrap_content"
            android:layout_height="35dp"
            android:layout_marginLeft="10dp"
            android:layout_marginStart="10dp"
            android:text="Dogs"/>

        <com.google.android.material.chip.Chip
            android:id="@+id/filter_chip2"
            style="@style/Widget.MaterialComponents.Chip.Filter"
            android:layout_width="wrap_content"
            android:layout_height="35dp"
            android:text="Cats"/>
    </com.google.android.material.chip.ChipGroup>

Now that we have filter chips in place, we need to detect clicks on the filter chips. We can do so simply by attaching a OnCheckedChangeListener to it:

        ChipGroup filterChipGroup = findViewById(R.id.filter_chip_group);
        Chip filterChip = findViewById(R.id.filter_chip);
        Chip filterChip2 = findViewById(R.id.filter_chip2);
        CompoundButton.OnCheckedChangeListener filterChipListener = new CompoundButton.OnCheckedChangeListener() {
            @Override
            public void onCheckedChanged(CompoundButton buttonView, boolean isChecked) {
                Log.i(TAG, buttonView.getId() + "");
            }
        };
        filterChip.setOnCheckedChangeListener(filterChipListener);
        filterChip2.setOnCheckedChangeListener(filterChipListener);

Filter Chip – Single Selection Mode

In this Android Chips Example, I will also show a filter chip with single selection mode. In this mode, filter chips would start acting as a radio button. This means in a way only one selection can be made at a time. This functionality is achieved by adding all the filter chips in a ChipGroup and setting the property : app:singleSelection="true" of Chip Group. To have a better understanding, lets have a look at the layout XML file:

    <com.google.android.material.chip.ChipGroup
        android:id="@+id/filter_chip_SS_group"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_below="@id/filter_chip_ss_txt"
        app:singleSelection="true">

        <com.google.android.material.chip.Chip
            android:id="@+id/filter_ss_chip"
            style="@style/Widget.MaterialComponents.Chip.Filter"
            android:layout_width="wrap_content"
            android:layout_height="35dp"
            android:layout_marginLeft="10dp"
            android:layout_marginStart="10dp"
            android:text="Dogs"/>

        <com.google.android.material.chip.Chip
            android:id="@+id/filter_ss_chip2"
            style="@style/Widget.MaterialComponents.Chip.Filter"
            android:layout_width="wrap_content"
            android:layout_height="35dp"
            android:text="Cats"/>
    </com.google.android.material.chip.ChipGroup>

Next to capture the selected chip out of all chips, we need to attach a ChipGroup.OnCheckedChangeListener() on the ChipGroup.

        ChipGroup filterChipGroupSingleSelection = findViewById(R.id.filter_chip_SS_group);
        filterChipGroupSingleSelection.setOnCheckedChangeListener(new ChipGroup.OnCheckedChangeListener() {
            @Override
            public void onCheckedChanged(ChipGroup group, @IdRes int checkedId) {
                // Handle the checked chip change.
                Log.i(TAG, "ID: " + group.getCheckedChipId());
            }
        });

Please Note: This ChipGroup.OnCheckedChangeListener() would return callbacks only when single selection mode is set to true.

Choice Chip

A perfect example of choice chip is similar to the filter chip one. Choice chip allows the user to select only one of the available options just like the filter chips. But with one difference, it does not have a check icon on it. Instead according to material design guidelines, it displays the selection with a change of color, when it is selected. If you wish you can use a chipIcon with this chip. But ideally they should be used wherever you feel the need to show RadioButton. Lets have a look at the UI for Android Choice Chip:

To use the choice chip, we use style="@style/Widget.MaterialComponents.Chip.Choice" parameter in the XML. Lets have a look at the XML:

    <com.google.android.material.chip.ChipGroup
        android:id="@+id/choice_chip_group"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_below="@id/choice_chip_txt"
        app:singleSelection="true">

        <com.google.android.material.chip.Chip
            android:id="@+id/choice_chip"
            style="@style/Widget.MaterialComponents.Chip.Choice"
            android:layout_width="wrap_content"
            android:layout_height="35dp"
            android:layout_marginLeft="10dp"
            android:layout_marginStart="10dp"
            android:text="Cars"/>

        <com.google.android.material.chip.Chip
            android:id="@+id/choice_chip2"
            style="@style/Widget.MaterialComponents.Chip.Choice"
            android:layout_width="wrap_content"
            android:layout_height="35dp"
            android:text="Trucks"/>
    </com.google.android.material.chip.ChipGroup>

As shown in this Android Chips Example earlier, ChipGroup can return the selected chip only when single selection mode is set to true. Even here we will utilize the same property and capture the selection:

        ChipGroup choiceChipGroup = findViewById(R.id.choice_chip_group);
        choiceChipGroup.setOnCheckedChangeListener(new ChipGroup.OnCheckedChangeListener() {
            @Override
            public void onCheckedChanged(ChipGroup chipGroup, @IdRes int i) {
                Log.i(TAG, i + "");
            }
        });

If you wish to have a look at all the working sample of the Android Chip types mentioned above, please have a look at the full source code here: 

Full Source Code 

In this Android Chips Example, as you can see we built a working sample of all the chip styles, by using the latest Google’s material library. Here in this tutorial we also showcased, that a chip has the properties of a radio button as well as a check box. In a way its a better representation of both. You can use it either in a single selection or in multiple selection mode. Both ways it would give a great experience. As the Android Chips are compact, relevant and focused. Hope this example made you understand things better, for latest news on Android connect with us on Twitter, Facebook and Google+. Also subscribe to our newsletter, for news right in your inbox.

The post Android Chips Example: Material Design appeared first on Truiton.

When building a mobile app, one of the most basic things to have in an app is an auto suggest box. It is such a common widget that anyone who’s using an app expects it to be there. But recently I realized that not many Android autocomplete examples exist on the internet where a web service or an API call is used to fetch data dynamically. Instead many tutorials are present showing the wrong practices of implementing an Android AutoCompleteTextView with web API call. Hence here I would show how I built an autosuggest feature on my Android app.

To start with lets, understand the new additions in the AutoCompleteTextView widget. Recently with the release of Android support appcompat library 25.1.0 a background tint support was added and post which the new widget class was named as AppCompatAutoCompleteTextView. This new widget class is not much different from the original one, but since its an enhanced version of AutoCompleteTextView we will using this class for this Android AutoCompleteTextView with and API call tutorial.

Android AutoCompleteTextView with data from Web API Call example

To start with, lets define the objectives of this tutorial. Here we will create and Android AutoCompleteTextView example, where data is fetched dynamically from a web API call. Once the data is fetched dynamically based on the user’s input, we would display it accordingly in a drop down scrolling list. The Android AutoCompleteTextView implementation is so flexible that even its dropdown can also be customised. But to keep things simple and focused, we would keep this out of the scope of this example.

1. Prerequisites

To make any API call in an android app, we must have a REST framework implemented. So that we can have some basic set of features relating to web API call. Since Android Volley is a very simple framework, we would be using volley in this example to make API calls. But just in case, if you are comfortable with any other REST framework, please feel free to use that in your app.

First lets add internet permission in the manifest:

<?xml version="1.0" encoding="utf-8"?>
<manifest ...>

    <uses-permission android:name="android.permission.INTERNET" />

    <application .... >
    </application>
</manifest>

Secondly lets define a basic class to make an API call through the app.

package com.truiton.autosuggesttextviewapicall;

import android.content.Context;

import com.android.volley.Request;
import com.android.volley.RequestQueue;
import com.android.volley.Response;
import com.android.volley.toolbox.StringRequest;
import com.android.volley.toolbox.Volley;

/**
 * Created by MG on 04-03-2018.
 */

public class ApiCall {
    private static ApiCall mInstance;
    private RequestQueue mRequestQueue;
    private static Context mCtx;

    public ApiCall(Context ctx) {
        mCtx = ctx;
        mRequestQueue = getRequestQueue();
    }

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

    public RequestQueue getRequestQueue() {
        if (mRequestQueue == null) {
            mRequestQueue = Volley.newRequestQueue(mCtx.getApplicationContext());
        }
        return mRequestQueue;
    }

    public <T> void addToRequestQueue(Request<T> req) {
        getRequestQueue().add(req);
    }

    public static void make(Context ctx, String query, Response.Listener<String>
            listener, Response.ErrorListener errorListener) {
        String url = "https://itunes.apple.com/search?term=" + query
                + "&country=US";
        StringRequest stringRequest = new StringRequest(Request.Method.GET, url,
                listener, errorListener);
        ApiCall.getInstance(ctx).addToRequestQueue(stringRequest);
    }
}

Method to take note of in the class above is make, as this is the only static method in this class. This method would be used to make an API call for the Android AutoCompleteTextView implementation ahead. Internally this method would create a request queue for volley and handle all the network I/O itself. Also in the above class, I just defined a basic example of Android volley request queue, through which we will be making an API call for the implementation of Android AutoCompleteTextView showing dynamic data from the same. To learn more in detail on Android volley please refer to my tutorial on it here.

2. Define an Adapter for Android AutoCompleteTextView with dynamic data from API call

As you may know, the drop down list shown on top of an AutoCompleteTextView is just a ListView inside of the overflow. Therefore as per principle, we have to make an adapter for the underlying ListView. Now since we are going to use an adapter, where only data needs to be shown in a form of list and also we don’t need any sort of processing on the list therefore we would use an ArrayAdapter. But keeping the future improvements in mind we will also implement a Filterable interface. This can help us in processing the list as well without making an API call.

package com.truiton.autosuggesttextviewapicall;

import android.content.Context;
import android.support.annotation.NonNull;
import android.support.annotation.Nullable;
import android.widget.ArrayAdapter;
import android.widget.Filter;
import android.widget.Filterable;

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

public class AutoSuggestAdapter extends ArrayAdapter<String> implements Filterable {
    private List<String> mlistData;

    public AutoSuggestAdapter(@NonNull Context context, int resource) {
        super(context, resource);
        mlistData = new ArrayList<>();
    }

    public void setData(List<String> list) {
        mlistData.clear();
        mlistData.addAll(list);
    }

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

    @Nullable
    @Override
    public String getItem(int position) {
        return mlistData.get(position);
    }

    /**
     * Used to Return the full object directly from adapter.
     *
     * @param position
     * @return
     */
    public String getObject(int position) {
        return mlistData.get(position);
    }

    @NonNull
    @Override
    public Filter getFilter() {
        Filter dataFilter = new Filter() {
            @Override
            protected FilterResults performFiltering(CharSequence constraint) {
                FilterResults filterResults = new FilterResults();
                if (constraint != null) {
                    filterResults.values = mlistData;
                    filterResults.count = mlistData.size();
                }
                return filterResults;
            }

            @Override
            protected void publishResults(CharSequence constraint, FilterResults results) {
                if (results != null && (results.count > 0)) {
                    notifyDataSetChanged();
                } else {
                    notifyDataSetInvalidated();
                }
            }
        };
        return dataFilter;
    }
}

The above piece of code would turn out to be a fully functional ArrayAdapter, with the capability of setting the data without instantiating the adapter object once again. Also this would have a Filterable implementation, therefore it would be perfect example for an Android AutoCompleteTextView where suggestions from an API call are shown.

3. Using Android AppCompatAutoCompleteTextView with web API call

As mentioned earlier for this tutorial we will be using Android AppCompatAutoCompleteTextView widget for building an auto suggest experience, as this widget gives an extra advantage over standard implementation. That is with this new one, we can set background tint color and modify it dynamically with ViewCompat methods. Lets start by defining a layout:

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context="com.truiton.autosuggesttextviewapicall.MainActivity">

    <android.support.v7.widget.AppCompatAutoCompleteTextView
        android:id="@+id/auto_complete_edit_text"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_alignParentTop="true"
        android:layout_margin="10dp"
        android:inputType="text"
        android:maxLines="1"/>

    <TextView
        android:id="@+id/selected_item"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_below="@id/auto_complete_edit_text"
        android:layout_marginTop="50dp"
        android:padding="20dp"/>

</RelativeLayout>

Next to implement an Android AppCompatAutoCompleteTextView where suggestions come from a WebService call, we need to define an activity where all of this is done.

package com.truiton.autosuggesttextviewapicall;

import android.os.Bundle;
import android.os.Handler;
import android.os.Message;
import android.support.v7.app.AppCompatActivity;
import android.support.v7.widget.AppCompatAutoCompleteTextView;
import android.text.Editable;
import android.text.TextUtils;
import android.text.TextWatcher;
import android.view.View;
import android.widget.AdapterView;
import android.widget.TextView;

import com.android.volley.Response;
import com.android.volley.VolleyError;

import org.json.JSONArray;
import org.json.JSONObject;

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

public class MainActivity extends AppCompatActivity {
    private static final int TRIGGER_AUTO_COMPLETE = 100;
    private static final long AUTO_COMPLETE_DELAY = 300;
    private Handler handler;
    private AutoSuggestAdapter autoSuggestAdapter;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        final AppCompatAutoCompleteTextView autoCompleteTextView =
                findViewById(R.id.auto_complete_edit_text);
        final TextView selectedText = findViewById(R.id.selected_item);

        //Setting up the adapter for AutoSuggest
        autoSuggestAdapter = new AutoSuggestAdapter(this,
                android.R.layout.simple_dropdown_item_1line);
        autoCompleteTextView.setThreshold(2);
        autoCompleteTextView.setAdapter(autoSuggestAdapter);
        autoCompleteTextView.setOnItemClickListener(
                new AdapterView.OnItemClickListener() {
                    @Override
                    public void onItemClick(AdapterView<?> parent, View view,
                                            int position, long id) {
                        selectedText.setText(autoSuggestAdapter.getObject(position));
                    }
                });

        autoCompleteTextView.addTextChangedListener(new TextWatcher() {
            @Override
            public void beforeTextChanged(CharSequence s, int start, int
                    count, int after) {

            }

            @Override
            public void onTextChanged(CharSequence s, int start, int before,
                                      int count) {
                handler.removeMessages(TRIGGER_AUTO_COMPLETE);
                handler.sendEmptyMessageDelayed(TRIGGER_AUTO_COMPLETE,
                        AUTO_COMPLETE_DELAY);
            }

            @Override
            public void afterTextChanged(Editable s) {

            }
        });

        handler = new Handler(new Handler.Callback() {
            @Override
            public boolean handleMessage(Message msg) {
                if (msg.what == TRIGGER_AUTO_COMPLETE) {
                    if (!TextUtils.isEmpty(autoCompleteTextView.getText())) {
                        makeApiCall(autoCompleteTextView.getText().toString());
                    }
                }
                return false;
            }
        });
    }

    private void makeApiCall(String text) {
        ApiCall.make(this, text, new Response.Listener<String>() {
            @Override
            public void onResponse(String response) {
                //parsing logic, please change it as per your requirement
                List<String> stringList = new ArrayList<>();
                try {
                    JSONObject responseObject = new JSONObject(response);
                    JSONArray array = responseObject.getJSONArray("results");
                    for (int i = 0; i < array.length(); i++) {
                        JSONObject row = array.getJSONObject(i);
                        stringList.add(row.getString("trackName"));
                    }
                } catch (Exception e) {
                    e.printStackTrace();
                }
                //IMPORTANT: set data here and notify
                autoSuggestAdapter.setData(stringList);
                autoSuggestAdapter.notifyDataSetChanged();
            }
        }, new Response.ErrorListener() {
            @Override
            public void onErrorResponse(VolleyError error) {

            }
        });
    }
}

The above implementation of an Android AppCompatAutoCompleteTextView is a bit different from the regular implementation. Here firstly an adapter is instantiated, which we defined in the previous section of tutorial. Secondly an instance of AdapterView.OnItemClickListener() is set, to capture the clicks on the dropdown items. Next one of the most important part, a TextWatcher is attached to the AutoCompleteTextView. This TextWatcher captures all the all the user inputs and sends it to a handler. Here in this Android AutoCompleteTextView example, we are processing the changes of EditText via a delayed handler. In a way, this approach saves us some unnecessary web API calls, as a delay in consecutive requests is introduced with the help of Handler class. Once a successful call is reached to the handler, we make an API call which returns the results in expected form and they are shown with the help of an Adapter. This way, data is shown on the AutoCompleteTextView drop down. To view the full source code, please checkout the link below:

Full Source Code

This is how the output of the above example would look:

Some Important properties of Android AutoCompleteTextView

Now that we have a fair understanding of how an Android AutoCompleteTextView works, lets have a look at some of its frequently used properties:

• setThreshold(int threshold) – This sets a character input threshold, for triggering the dropdown.
• setCompletionHint(CharSequence hint) – Once the threshold is reached and a dropdown is shown, over the bottom this completion hint is also shown.
• setDropDownBackgroundResource(int id) – With the help of this method, you can set a background resource for the dropdown list.
• setDropDownBackgroundDrawable(Drawable d) – With this method, we can set a background drawable for auto suggest list. But on a separate note, if you wish to style the Android AutoCompleteTextView dropdown background you can also consider styling the list item of dropdown by using a custom xml for inflating the item(explained in next section).

Android AutoCompleteTextView dropdown positioning

At times when making an Android autosuggest, we wish to move the dropdown and attach it to some other view on screen. This may sound complex, but its very simple to implement with Android AutoCompleteTextView, we just need to define a few properties in xml. To get started, lets discuss some properties for dropdown positioning of Andorid AutoCompleteTextView:

• android:dropDownAnchor=”@id/selected_item” – This property basically defines the view to which the dropdown popup of Android AutoSuggest should be attached to. This property can also be used by a java method setDropDownAnchor().

When using the above property, if the dropdown length goes beyond the keyboard height, in some scenarios it will be automatically detached and positioned on top of the screen. To avoid this behaviour of Android AutoCompleteTextView, we can use the following properties, these will help in curbing the mentioned behaviour:

• android:dropDownHeight – sets the height of auto suggest drop down.
• android:dropDownHorizontalOffset – sets the horizontal offset of the list from attached view.
• android:dropDownVerticalOffset – sets the vertical offset of the list from attached view.
• android:dropDownWidth – sets the dropdown list width.

Now addressing the issue of custom views in Android AutoCompleteTextView, to do so in the above piece of code firstly you need to make a new layout for the custom list item. Next, that xml resource needs to be specified in the adapter initiation like this: new AutoSuggestAdapter(this,R.layout.custom_dropdown_item);. Once this is done, in the adapter you need to implement the getView() method and use the custom layout xml. This way as a result you would see a list dropdown in an Android AutoCompleteTextView with a custom layout. That said, lets conclude this tutorial and please connect with us on Twitter, Facebook and Google+ for more updates.

The post Android AutoCompleteTextView: Suggestions from Web Service Call appeared first on Truiton.

In August 2015, Google announced the release of Android Mobile Vision API. At that time this API had mainly three components Face Detection, Barcode scanner and ways to capture the tracking of objects in real time. But later on some bugs were found in its implementation, due to which the access to this API was restricted by Google to the existing users only. Then recently in June 2016 these issues were resolved and Mobile Vision APIs were re-launched. But this time it had a few new features like OCR and scanning of Aztec barcodes. In the next sections lets understand what exactly is the new Mobile Vision API and how can we use it to build an efficient code base.

What is Android Mobile Vision API ?

Ever wondered how to detect a face, a QR code or a Bar code on an Android Device? If yes; you might have heard of, or used the FaceDetector.Face API of the Android framework, or the OpenCV SDK, or maybe you had opted for a cloud based solution like Cloud Vision API, which makes the requests to a web server, fetching the results for scans. But this new Android Mobile Vision API does not make any requests to a web server. Instead it performs real time image/video scanning on the device itself. Although this may sound a little in-effective, but its not. The Mobile Vision API is very efficient and deeply integrated in to the Android system by the means of Google Play Services SDK. This gives this API an added advantage over all other solutions, as being a developer you do not need to integrate any third party SDK to perform media analysis. All you may need to do is integrate the Google Play Services properly and start building on it. Android Mobile Vision API as of now performs three types of image/stream detection as shown in next sections.

Setting up Android Mobile Vision Library

When speaking of this new multipurpose Android offline image recognition library, the only downside is that one has to set it up before the actual usage. Although it does not mean any manual configuration but a tag needs to be added in the application manifest. So that the installer knows that an extra package is needed to be downloaded as the app is being installed. As of now the mobile vision API has three components, therefore all three dependencies can be included in a single manifest tag under the application tag as shown:

<meta-data
            android:name="com.google.android.gms.vision.DEPENDENCIES"
            android:value="barcode,face,ocr"/>

This would instruct the OS to download the packages for all three types of offline image analysis. Next lets have a brief understanding of all the features of this powerful Mobile Vision API.

1. Barcode and QR Code scanning on Android

The Barcode Scanner API is used to scan various types of bar codes and qr codes. Some of them are:

• 1D barcodes: EAN-13, EAN-8, UPC-A, UPC-E, Code-39, Code-93, Code-128, ITF, Codabar
• 2D barcodes: QR Code, Data Matrix, PDF-417, AZTEC

Using this Mobile Vision API for Bar codes is very simple, even with so many supported formats. All you need to do is write around 10 lines of code to parse a Barcode or QR Code. One of the most interesting things about this API is that, it also parses the type of barcode/QR code it is scanning. All the information about the scanned barcode or QR Code type is found in the valueFormat field of Barcode Object besides the scanned barcode. To learn more about the usage of Barcode Scanner API of the Android Mobile Vision API please refer to this tutorial:

Android Barcode Tutorial

2. Optical Character Recognition (OCR) on Android

Mobile Vision Text API is another great feature packed into this library. Its purpose is straight forward, i.e. text recognition in an image or a stream of frames. It can recognize a majority of Latin character based languages like English, French, Italian Dutch etc. Therefore if your app needs to extract text out of an image, this is the perfect solution for you. As once its dependencies are downloaded, you no more required to have an internet connection, all the character recognition takes place on device itself.

Incase you wonder; how would this Android Mobile Vision Text API deliver large results, as when scanning a page of a book- a lot of words could be scanned. But thankfully this API returns text in a structured way. It mainly divides text into three sections:

1. Block: Top level structure, contains all the paragraphs.
2. Line: Mid level structure, contains lines in a block.
3. Word: Low level structure, contains a single word from line.

To learn more about the Text API, please refer to this tutorial:

Android OCR Tutorial

3. Face Detection on Android

This is the most powerful API in all, as it has human Face Detection capabilities. It is a perfectly suited API for any face filter or camera app, as it performs the analysis on the device itself once the package is downloaded. Interestingly it not only recognizes a face but can also extract the facial features of that face, including eyes nose and mouth etc. Since this API as of now does not support face recognition it cannot identify similarity between two faces, but can still classify the features like, if the eyes are open or not. The functionalities that Mobile Vision Face Detection API supports are:

1. Landmark Detection: Face API understands the human face in terms of landmarks. When a face is scanned via this API, it identifies that face via landmarks. In simple terms face landmarks are: nose, mouth, left eye, and right eye etc. By using this API you can actually extract the position of all these landmarks. 
2. Classification: This API not only scans a face but can also apply some basic logic and identify certain characteristics on the scanned face. For ex. with this feature we can find out whether the face has its eyes open or not. Also we can find out the probability of a smile on that face. 
3. Tracking: This is the most interesting feature of this API, you can actually track a face in a video sequence through this API. This feature of Mobile Vision API can be used to identify and track a face in a video. Once again this is not an application of face recognition, instead it tracks the face through movement of that particular face in the video. 

To learn more in detail about Face Detection, please refer to this tutorial:

Face Detection Tutorial 

Tracking Faces, Bar codes and QR Codes Simultaneously

Interestingly, if you want to scan and track multiple faces simultaneously, even that is possible through this API. All you need to do is initialize a MultiProcessor and track multiple faces through this API. Also if you want to track multiple Bar codes or QR codes, same thing is applicable, as all of this is a part of Mobile Vision API, backed by Google Play Services. But even more interesting thing is that you can track Bar codes, QR codes and Faces in a single frame, by using the MultiDetector class of the same API suite. This makes the mobile vision APIs an outstanding leader in terms of features when compared to any other such library in the market. As its light, easy to integrate and very easy to use. For more updates, please connect with us on Twitter, Facebook and Google+.

The post Introducing Android Mobile Vision API appeared first on Truiton.

Nowadays face filter apps are one of the most common apps available on a users phone, where a user can apply various funny filters on their face pictures. Interestingly the base tech that powers these sort of apps is similar to what we are going to discuss in this tutorial. That’s right we are going to discuss an Android Face Detection API. Interestingly to power all these apps, officially Google has released an Android Face Detection API in their Mobile Vision set of APIs. Basically all the face filter apps detect a face through a face detection API, and apply various overlays on the selected picture. Although when speaking of Face Detection APIs for Android, we have multiple options. But for this article we will be discussing Google backed Mobile Vision APIs only. As its fast and has deeply integrated Android development SDK/APIs.

Android Face Detection API – Mobile Vision

When speaking of face detection, it is often misunderstood by face recognition, therefore let me put it discretely. As of now Mobile Vision APIs do not support Face Recognition, right now they only support face detection. Although it does have the ability to identify the characteristics of a face, which includes eyes, nose, mouth and smile etc. But besides these characteristics Mobile Vision Face Detection API can also track a face in a video sequence, which is again not an application of face recognition, but face detection as it is identified by tracking the movement of that particular face in the sequence. Also since this API is a part of Google’s Play Services library, it is not bundled as a part of the APK, instead an ad-on package is downloaded internally by the play services itself if it is not present to support Android face detection. To do so, we need to set up the play services with the mobile vision dependency in build.gradle file as shown below:

compile 'com.google.android.gms:play-services-vision:11.4.0'

Also the build.gradle(project) should have this:

allprojects {
    repositories {
        jcenter()
        maven {
            url "https://maven.google.com"
        }
    }
}

Post this a <meta-data> tag for face detection api along with <uses-feature> and <uses-permission> tag for camera and accessing external storage needs to be added in the manifest as shown below:

<?xml version="1.0" encoding="utf-8"?>
<manifest package="com.truiton.mobile.vision.facedetection"
          xmlns:android="http://schemas.android.com/apk/res/android">

    <uses-feature
        android:name="android.hardware.camera"
        android:required="true"/>
    <uses-permission
        android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
    <application
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        android:supportsRtl="true"
        android:theme="@style/AppTheme">
        <meta-data
            android:name="com.google.android.gms.vision.DEPENDENCIES"
            android:value="face"/>

        <activity android:name=".MainActivity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>

                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </activity>
        <provider
            android:name="android.support.v4.content.FileProvider"
            android:authorities="${applicationId}.provider"
            android:exported="false"
            android:grantUriPermissions="true">
            <meta-data
                android:name="android.support.FILE_PROVIDER_PATHS"
                android:resource="@xml/provider_paths"/>
        </provider>
    </application>

</manifest>

Android Face Detection Library – Features 

Next lets understand the features of Mobile Vision Face Detection APIs. As amazing things can be done by correct usage of this API. Broadly speaking, this API can perform detailed facial analysis- like detection of facial features and identifying their states. Currently its features can be divided into three categories shown below:

1. Landmark Detection: One of the most important features of Mobile Vision Face Detection APIs is the detection of facial landmarks. In case you are wondering what are facial landmarks? They are the basic facial features or points of interest, like Nose, Eyes, and Mouth etc. Interestingly these features are detected very accurately by this Android Face Detection API. As of now following facial features are detected by this API:

• Landmark.BOTTOM_MOUTH
• Landmark.LEFT_CHEEK
• Landmark.LEFT_EAR_TIP
• Landmark.LEFT_EAR
• Landmark.LEFT_EYE
• Landmark.LEFT_MOUTH
• Landmark.NOSE_BASE
• Landmark.RIGHT_CHEEK
• Landmark.RIGHT_EAR_TIP
• Landmark.RIGHT_EAR
• Landmark.RIGHT_EYE
• Landmark.RIGHT_MOUTH

2. Facial Classification: Interestingly this API can also apply some logic on the detected facial landmarks and identify facial classifications. For ex. it can be detected through this API if the detected face has its eyes open or is smiling or not. Although this feature set may not sound very impressive as of now; but its very accurate and has a lot of room to grow. Maybe in near future some additional features might come in.

3. Face Tracking: Another very powerful feature of Mobile Vision Face Detection APIs is this face tracking feature. It simply gives us the ability to track a face in a video sequence. Once again, here I would like to clarify that this is not Face Recognition, this feature simply works on face detection only. As it tracks that face based on its movement in the consecutive video frames. 

Android Face Detection API – Example

Now that we have a basic understanding of how the Face Detection APIs work, here in this section we would build a short example where we showcase its capabilities. Since Android Face Detection is itself a huge topic we would limit the scope of this tutorial, and showcase the Facial Classification feature with Landmark Detection only. Also this would solve our primary use case of Face Detection. Therefore for this Android Face Detection Example we would simply take a picture from a camera and run face detection on it, by using the Mobile Vision Face Detection APIs. To start building, lets continue from the steps mentioned in the first section of this article and define a layout to take a picture as shown below:

<?xml version="1.0" encoding="utf-8"?>
<android.support.constraint.ConstraintLayout
    android:id="@+id/activity_main"
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context="com.truiton.mobile.vision.facedetection.MainActivity">

    <ImageView
        android:id="@+id/imageView"
        android:layout_width="70dp"
        android:layout_height="70dp"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintHorizontal_bias="1.0"
        app:layout_constraintLeft_toLeftOf="parent"
        app:layout_constraintRight_toRightOf="parent"
        app:srcCompat="@mipmap/truiton"/>

    <Button
        android:id="@+id/button"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_marginBottom="8dp"
        android:text="Scan Face"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintLeft_toLeftOf="parent"
        app:layout_constraintRight_toRightOf="parent"
        tools:layout_constraintLeft_creator="1"
        tools:layout_constraintRight_creator="1"
        />

    <TextView
        android:id="@+id/textView"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_marginTop="8dp"
        android:text="Scan Results:"
        android:textAllCaps="false"
        android:textStyle="normal|bold"
        app:layout_constraintLeft_toLeftOf="parent"
        app:layout_constraintRight_toRightOf="parent"
        app:layout_constraintTop_toTopOf="parent"
        tools:layout_constraintLeft_creator="1"
        tools:layout_constraintRight_creator="1"/>

    <ScrollView
        android:layout_width="0dp"
        android:layout_height="0dp"
        android:layout_marginTop="8dp"
        android:paddingLeft="5dp"
        android:paddingRight="5dp"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintHorizontal_bias="1.0"
        app:layout_constraintLeft_toLeftOf="parent"
        app:layout_constraintRight_toRightOf="parent"
        app:layout_constraintTop_toBottomOf="@+id/textView"
        app:layout_constraintVertical_bias="1.0"
        tools:layout_constraintBottom_creator="1"
        tools:layout_constraintLeft_creator="1"
        tools:layout_constraintRight_creator="1"
        tools:layout_constraintTop_creator="1">

        <LinearLayout
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:orientation="vertical">

            <TextView
                android:id="@+id/results"
                android:layout_width="match_parent"
                android:layout_height="wrap_content"
                android:layout_gravity="center_horizontal"
                android:layout_marginTop="8dp"/>

            <ImageView
                android:id="@+id/scannedResults"
                android:layout_width="wrap_content"
                android:layout_height="wrap_content"
                android:layout_gravity="center_horizontal"
                android:layout_marginBottom="8dp"
                android:layout_marginTop="8dp"/>
        </LinearLayout>
    </ScrollView>
</android.support.constraint.ConstraintLayout>

Here for this layout I have used ConstraintLayout as my root layout, but its not mandatory to use this for your activity’s layout. You can also use the normal RelativeLayout or LinearLayout as per your needs, but if you wish to use ConstraintLayout, please don’t forget to add its dependency in your build.gradle file, as shown below:

compile 'com.android.support.constraint:constraint-layout:1.0.2'

Also full source code is available at the end of this tutorial. Next lets define the MainActivity for this Android Face Detection tutorial.

package com.truiton.mobile.vision.facedetection;


import android.Manifest;
import android.content.Context;
import android.content.Intent;
import android.content.pm.PackageManager;
import android.graphics.Bitmap;
import android.graphics.BitmapFactory;
import android.graphics.Canvas;
import android.graphics.Color;
import android.graphics.Paint;
import android.net.Uri;
import android.os.Bundle;
import android.os.Environment;
import android.provider.MediaStore;
import android.support.annotation.NonNull;
import android.support.v4.app.ActivityCompat;
import android.support.v4.content.FileProvider;
import android.support.v7.app.AppCompatActivity;
import android.util.Log;
import android.util.SparseArray;
import android.view.View;
import android.widget.Button;
import android.widget.ImageView;
import android.widget.TextView;
import android.widget.Toast;

import com.google.android.gms.vision.Frame;
import com.google.android.gms.vision.face.Face;
import com.google.android.gms.vision.face.FaceDetector;
import com.google.android.gms.vision.face.Landmark;

import java.io.File;
import java.io.FileNotFoundException;

public class MainActivity extends AppCompatActivity {
    private static final String LOG_TAG = "FACE API";
    private static final int PHOTO_REQUEST = 10;
    private TextView scanResults;
    private ImageView imageView;
    private Uri imageUri;
    private FaceDetector detector;
    private static final int REQUEST_WRITE_PERMISSION = 20;
    private static final String SAVED_INSTANCE_URI = "uri";
    private static final String SAVED_INSTANCE_BITMAP = "bitmap";
    private static final String SAVED_INSTANCE_RESULT = "result";
    Bitmap editedBitmap;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Button button = (Button) findViewById(R.id.button);
        scanResults = (TextView) findViewById(R.id.results);
        imageView = (ImageView) findViewById(R.id.scannedResults);
        if (savedInstanceState != null) {
            editedBitmap = savedInstanceState.getParcelable(SAVED_INSTANCE_BITMAP);
            if (savedInstanceState.getString(SAVED_INSTANCE_URI) != null) {
                imageUri = Uri.parse(savedInstanceState.getString(SAVED_INSTANCE_URI));
            }
            imageView.setImageBitmap(editedBitmap);
            scanResults.setText(savedInstanceState.getString(SAVED_INSTANCE_RESULT));
        }
        detector = new FaceDetector.Builder(getApplicationContext())
                .setTrackingEnabled(false)
                .setLandmarkType(FaceDetector.ALL_LANDMARKS)
                .setClassificationType(FaceDetector.ALL_CLASSIFICATIONS)
                .build();
        button.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                ActivityCompat.requestPermissions(MainActivity.this, new
                        String[]{Manifest.permission.WRITE_EXTERNAL_STORAGE}, REQUEST_WRITE_PERMISSION);
            }
        });
    }

    @Override
    public void onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults) {
        super.onRequestPermissionsResult(requestCode, permissions, grantResults);
        switch (requestCode) {
            case REQUEST_WRITE_PERMISSION:
                if (grantResults.length > 0 && grantResults[0] == PackageManager.PERMISSION_GRANTED) {
                    takePicture();
                } else {
                    Toast.makeText(MainActivity.this, "Permission Denied!", Toast.LENGTH_SHORT).show();
                }
        }
    }

    @Override
    protected void onActivityResult(int requestCode, int resultCode, Intent data) {
        if (requestCode == PHOTO_REQUEST && resultCode == RESULT_OK) {
            launchMediaScanIntent();
            try {
                scanFaces();
            } catch (Exception e) {
                Toast.makeText(this, "Failed to load Image", Toast.LENGTH_SHORT).show();
                Log.e(LOG_TAG, e.toString());
            }
        }
    }

    private void scanFaces() throws Exception {
        Bitmap bitmap = decodeBitmapUri(this, imageUri);
        if (detector.isOperational() && bitmap != null) {
            editedBitmap = Bitmap.createBitmap(bitmap.getWidth(), bitmap
                    .getHeight(), bitmap.getConfig());
            float scale = getResources().getDisplayMetrics().density;
            Paint paint = new Paint(Paint.ANTI_ALIAS_FLAG);
            paint.setColor(Color.rgb(255, 61, 61));
            paint.setTextSize((int) (14 * scale));
            paint.setShadowLayer(1f, 0f, 1f, Color.WHITE);
            paint.setStyle(Paint.Style.STROKE);
            paint.setStrokeWidth(3f);
            Canvas canvas = new Canvas(editedBitmap);
            canvas.drawBitmap(bitmap, 0, 0, paint);
            Frame frame = new Frame.Builder().setBitmap(editedBitmap).build();
            SparseArray<Face> faces = detector.detect(frame);
            scanResults.setText(null);
            for (int index = 0; index < faces.size(); ++index) {
                Face face = faces.valueAt(index);
                canvas.drawRect(
                        face.getPosition().x,
                        face.getPosition().y,
                        face.getPosition().x + face.getWidth(),
                        face.getPosition().y + face.getHeight(), paint);
                scanResults.setText(scanResults.getText() + "Face " + (index + 1) + "\n");
                scanResults.setText(scanResults.getText() + "Smile probability:" + "\n");
                scanResults.setText(scanResults.getText() + String.valueOf(face.getIsSmilingProbability()) + "\n");
                scanResults.setText(scanResults.getText() + "Left Eye Open Probability: " + "\n");
                scanResults.setText(scanResults.getText() + String.valueOf(face.getIsLeftEyeOpenProbability()) + "\n");
                scanResults.setText(scanResults.getText() + "Right Eye Open Probability: " + "\n");
                scanResults.setText(scanResults.getText() + String.valueOf(face.getIsRightEyeOpenProbability()) + "\n");
                scanResults.setText(scanResults.getText() + "---------" + "\n");

                for (Landmark landmark : face.getLandmarks()) {
                    int cx = (int) (landmark.getPosition().x);
                    int cy = (int) (landmark.getPosition().y);
                    canvas.drawCircle(cx, cy, 5, paint);
                }
            }

            if (faces.size() == 0) {
                scanResults.setText("Scan Failed: Found nothing to scan");
            } else {
                imageView.setImageBitmap(editedBitmap);
                scanResults.setText(scanResults.getText() + "No of Faces Detected: " + "\n");
                scanResults.setText(scanResults.getText() + String.valueOf(faces.size()) + "\n");
                scanResults.setText(scanResults.getText() + "---------" + "\n");
            }
        } else {
            scanResults.setText("Could not set up the detector!");
        }
    }

    private void takePicture() {
        Intent intent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);
        File photo = new File(Environment.getExternalStorageDirectory(), "picture.jpg");
        imageUri = FileProvider.getUriForFile(MainActivity.this,
                BuildConfig.APPLICATION_ID + ".provider", photo);
        intent.putExtra(MediaStore.EXTRA_OUTPUT, imageUri);
        startActivityForResult(intent, PHOTO_REQUEST);
    }

    @Override
    protected void onSaveInstanceState(Bundle outState) {
        if (imageUri != null) {
            outState.putParcelable(SAVED_INSTANCE_BITMAP, editedBitmap);
            outState.putString(SAVED_INSTANCE_URI, imageUri.toString());
            outState.putString(SAVED_INSTANCE_RESULT, scanResults.getText().toString());
        }
        super.onSaveInstanceState(outState);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        detector.release();
    }

    private void launchMediaScanIntent() {
        Intent mediaScanIntent = new Intent(Intent.ACTION_MEDIA_SCANNER_SCAN_FILE);
        mediaScanIntent.setData(imageUri);
        this.sendBroadcast(mediaScanIntent);
    }

    private Bitmap decodeBitmapUri(Context ctx, Uri uri) throws FileNotFoundException {
        int targetW = 600;
        int targetH = 600;
        BitmapFactory.Options bmOptions = new BitmapFactory.Options();
        bmOptions.inJustDecodeBounds = true;
        BitmapFactory.decodeStream(ctx.getContentResolver().openInputStream(uri), null, bmOptions);
        int photoW = bmOptions.outWidth;
        int photoH = bmOptions.outHeight;

        int scaleFactor = Math.min(photoW / targetW, photoH / targetH);
        bmOptions.inJustDecodeBounds = false;
        bmOptions.inSampleSize = scaleFactor;

        return BitmapFactory.decodeStream(ctx.getContentResolver()
                .openInputStream(uri), null, bmOptions);
    }
}

In the above piece of code, in onCreate method I have simply initialized the face detector by calling the FaceDetector.Builder(getApplicationContext()) builder. This would download the Google Play Service dependencies for performing face detection and initialize them. In a way this also works as a safety measure to download the dependencies even when we specified the app to download the dependencies for face detection in the manifest (shown in first step). Also to make it event more reliable, we have also put a check; to check whether the detector is operational or not just before scanning the actual image in scanFaces() method. Full source code is available here:

Full Source Code

Also as you can see above we have initialized the Mobile Vision Face Detector with two capabilities, i.e. setLandmarkType(FaceDetector.ALL_LANDMARKS) and setClassificationType(FaceDetector.ALL_CLASSIFICATIONS). This would identify all the facial landmarks and classifications on a detected face, rest of the code just shows how we have plotted it on screen, which is self explanatory. The end result would look something like this:

Additional Capabilities

In addition to all what we have discussed above in this Android Face Detection Example, there is one more capability present in these Face Detection APIs. That is the face tracking capability with MultiProcessor. The great thing about this feature is that it can not only track a single face, but can also track multiple faces in a video sequence.  But due to limited scope of this article it is not covered here. Also since the face detection APIs are a part of Google’s Mobile Vision Suite, we have the capability to build a multi detector. Where we can track multiple faces and multiple bar codes or QR codes in a single video sequence by using the MultiDetector class. This feature is something very new and very powerful which opens a whole new area to explore into. Connect with us on Twitter, Facebook and Google+ for more updates on this. 

The post Android Face Detection Example appeared first on Truiton.

Its been a while since Google introduced Material Design, but recently with Design Support Library v25 they released a new widget to make an Android Bottom Navigation Bar, as described in the official material design specs. This new navigation component is called the BottomNavigationView and as mentioned, its packaged under the design support library, having full backward support. Although if you browse the internet, you may find many examples, showing how to implement an Android bottom navigation bar. But this new Android BottomNavigationView widget makes it very easy for the developers to build and deploy apps with bottom navigation, as its an official component.

Android BottomNavigationView Widget

At first when you look at the new BottomNavigationView widget it may look similar to the TabLayout of the same library. But but do not get confused, as its implementation is a lot different than that of the later one. As the new bottom bar navigation implementation of Android is based out of menu items. Hence to populate a BottomNavigationView you need to specify a menu resource file, unlike in the TabLayout. Although if you look at the final output i.e. the screen, there is still a striking similarity between the two. But putting this discussion to rest, lets have a look at the new features of the Android BottomNavigationView.

Whenever a new component is introduced, along with it some new methods and attributes are also added with it. Hence with the Android’s official bottom navigation widget the BottomNavigationView following new XML attributes are added:

• android.support.design:itemBackground – It is used to set the background color of the navigation item. It does not take a ColorStateList, as per design specifications.
• android.support.design:itemIconTint – It is used to set the icon tint color, use a ColorStateList to specify colors for all states.
• android.support.design:itemTextColor – It is used to set the text color of the navigation item, use a ColorStateList to specify colors for all states.

As I mentioned BottomNavigationView takes a menu resource file to inflate the navigation items. To do so following are the ways in which it can be done:

• XML
  • app:menu
• Java
  • BottomNavigationView.inflateMenu()

Once a BottomNavigationView is inflated and visible, a click listener can be attached to it:

• BottomNavigationView.OnNavigationItemSelectedListener

Method used to select a specific item in the BottomNavigationView:

• BottomNavigationView.getMenu().getItem(index).setChecked(true);

Although this component gives us the flexibility of changing screen content dynamically. But it is advised to not implement swiping views with an Android bottom navigation bar as per specs. Therefore this rules out the possibility of using a ViewPager with the bottom navigation bar. Instead a simple view or a set of fragments for complex implementation can be used. Therefore here in this tutorial, I will show how to implement a BottomNavigationView with a set of fragments. Lets have look at the example below.

Android Bottom Navigation Bar Example

To demonstrate a working example of Android BottomNavigationView widget, I would make three fragments and switch between them by using the bottom navigation bar. Here are the steps:

Step 1 : Add the dependencies

To start off with an example of bottom navigation bar on android , first we need to include following dependencies in our build.gradle file.

compile 'com.android.support:appcompat-v7:25.1.0'
compile 'com.android.support:design:25.1.0'
compile 'com.android.support:support-v4:25.1.0'

Step 2 : Define the Fragments

For this example I will be building a screen with three fragments, which could be switched by the BottomNavigationView. Hence before jumping on to the main screen, lets define three fragments.

Fragment 1:

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
                xmlns:tools="http://schemas.android.com/tools"
                android:layout_width="match_parent"
                android:layout_height="match_parent"
                tools:context="com.truiton.bottomnavigation.ItemOneFragment">

    <ImageView
        android:id="@+id/truiton_image"
        android:layout_width="300dp"
        android:layout_height="300dp"
        android:layout_centerInParent="true"
        android:src="@mipmap/truiton"/>

    <TextView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_below="@id/truiton_image"
        android:layout_centerHorizontal="true"
        android:text="Fragment 1"
        android:textSize="30sp"/>

</RelativeLayout>

package com.truiton.bottomnavigation;

import android.os.Bundle;
import android.support.v4.app.Fragment;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;

public class ItemOneFragment extends Fragment {
    public static ItemOneFragment newInstance() {
        ItemOneFragment fragment = new ItemOneFragment();
        return fragment;
    }

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
    }

    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container,
                             Bundle savedInstanceState) {
        return inflater.inflate(R.layout.fragment_item_one, container, false);
    }
}

Fragment 2:

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
                xmlns:tools="http://schemas.android.com/tools"
                android:layout_width="match_parent"
                android:layout_height="match_parent"
                tools:context="com.truiton.bottomnavigation.ItemTwoFragment">

    <ImageView
        android:id="@+id/truiton_image"
        android:layout_width="300dp"
        android:layout_height="300dp"
        android:layout_centerInParent="true"
        android:src="@mipmap/truiton"/>

    <TextView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_below="@id/truiton_image"
        android:layout_centerHorizontal="true"
        android:text="Fragment 2"
        android:textSize="30sp"/>

</RelativeLayout>

package com.truiton.bottomnavigation;

import android.os.Bundle;
import android.support.v4.app.Fragment;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;

public class ItemTwoFragment extends Fragment {
    public static ItemTwoFragment newInstance() {
        ItemTwoFragment fragment = new ItemTwoFragment();
        return fragment;
    }

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
    }

    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container,
                             Bundle savedInstanceState) {
        return inflater.inflate(R.layout.fragment_item_two, container, false);
    }
}

Fragment 3:

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
                xmlns:tools="http://schemas.android.com/tools"
                android:layout_width="match_parent"
                android:layout_height="match_parent"
                tools:context="com.truiton.bottomnavigation.ItemThreeFragment">

    <ImageView
        android:id="@+id/truiton_image"
        android:layout_width="300dp"
        android:layout_height="300dp"
        android:layout_centerInParent="true"
        android:src="@mipmap/truiton"/>

    <TextView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_below="@id/truiton_image"
        android:layout_centerHorizontal="true"
        android:text="Fragment 3"
        android:textSize="30sp"/>

</RelativeLayout>

package com.truiton.bottomnavigation;

import android.os.Bundle;
import android.support.v4.app.Fragment;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;

public class ItemThreeFragment extends Fragment {
    public static ItemThreeFragment newInstance() {
        ItemThreeFragment fragment = new ItemThreeFragment();
        return fragment;
    }

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
    }

    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container,
                             Bundle savedInstanceState) {
        return inflater.inflate(R.layout.fragment_item_three, container, false);
    }
}

Step 3 : Defining the bottom navigation menu XML

As mentioned before to populate the actual items into an Android bottom navigation bar, a menu type XML is used. This XML should contain at minimum three attributes:

• android:title
• android:icon
• android:id

For this example of BottomNavigationView, I would make a menu of three items:

<?xml version="1.0" encoding="utf-8"?>
<menu xmlns:android="http://schemas.android.com/apk/res/android">
    <item
        android:id="@+id/action_item1"
        android:icon="@drawable/ic_account_box_black_24dp"
        android:title="@string/item_1"/>
    <item
        android:id="@+id/action_item2"
        android:icon="@drawable/ic_account_circle_black_24dp"
        android:title="@string/item_2"/>
    <item
        android:id="@+id/action_item3"
        android:icon="@drawable/ic_assignment_ind_black_24dp"
        android:title="@string/item_3"/>
</menu>

Step 4 : Defining the Activity XML

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout
    android:id="@+id/activity_main"
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context="com.truiton.bottomnavigation.MainActivity">

    <FrameLayout
        android:id="@+id/frame_layout"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:layout_above="@+id/navigation"
        android:animateLayoutChanges="true">

    </FrameLayout>

    <android.support.design.widget.BottomNavigationView
        android:id="@+id/navigation"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_alignParentBottom="true"
        android:background="@color/colorPrimary"
        app:itemIconTint="@color/nav_item_state_list"
        app:itemTextColor="@color/nav_item_state_list"
        app:menu="@menu/bottom_navigation_items"/>
</RelativeLayout>

As you can see above, for attributes app:itemIconTint and app:itemTextColor, I have used a ColorStateList. Please make sure when you make a color state list, its according to the Material design specs for bottom navigation bar. Full source code is available at the end of the tutorial.

Step 5 : Defining the activity with bottom navigation bar

package com.truiton.bottomnavigation;

import android.os.Bundle;
import android.support.annotation.NonNull;
import android.support.design.widget.BottomNavigationView;
import android.support.v4.app.Fragment;
import android.support.v4.app.FragmentTransaction;
import android.support.v7.app.AppCompatActivity;
import android.view.MenuItem;

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        BottomNavigationView bottomNavigationView = (BottomNavigationView)
                findViewById(R.id.navigation);

        bottomNavigationView.setOnNavigationItemSelectedListener
                (new BottomNavigationView.OnNavigationItemSelectedListener() {
                    @Override
                    public boolean onNavigationItemSelected(@NonNull MenuItem item) {
                        Fragment selectedFragment = null;
                        switch (item.getItemId()) {
                            case R.id.action_item1:
                                selectedFragment = ItemOneFragment.newInstance();
                                break;
                            case R.id.action_item2:
                                selectedFragment = ItemTwoFragment.newInstance();
                                break;
                            case R.id.action_item3:
                                selectedFragment = ItemThreeFragment.newInstance();
                                break;
                        }
                        FragmentTransaction transaction = getSupportFragmentManager().beginTransaction();
                        transaction.replace(R.id.frame_layout, selectedFragment);
                        transaction.commit();
                        return true;
                    }
                });

        //Manually displaying the first fragment - one time only
        FragmentTransaction transaction = getSupportFragmentManager().beginTransaction();
        transaction.replace(R.id.frame_layout, ItemOneFragment.newInstance());
        transaction.commit();

        //Used to select an item programmatically
        //bottomNavigationView.getMenu().getItem(2).setChecked(true);
    }
}

As you can see above when making a screen with the help of BottomNavigationView we have to initialize it with a default view. As there is no ViewPager here, we are doing it all manually. By default when a BottomNavigationView is initialized it is loaded with the first item selected. But if you wish to load the screen with any other item selected, you can do so by getting the menu item and setting it checked as shown above. For full source code, please refer to the following link:

Full Source Code

The final output would look like this:

BottomNavigationView Limitations

Although the view itself is recently released, hence it is bound to have some issues. But if you are trying to build an Android screen with bottom navigation, here is a list of issues you might face:

• Item Background cannot be colored for selected state.
• It does not have a bottom navigation behavior, hence no integration is available for FAB, Snackbar, and CoordinatorLayout.
• Ethically swiping of views should not be done – Stated in Material Design guidelines.
• Text and icon sizes cannot be changed.
• No way to hide title for non selected items.
• Only 5 items can be added at a time.

But besides all this, building an Android bottom navigation bar has become a lot more simpler with the new BottomNavigationBar widget. As this is the new official component for bottom navigation. Also when speaking of shaping a product, giving upfront options like the bottom navigation has always gotten more traction, since it presents all the options to a user right away. Hope this helped, follow us on Twitter, Facebook and Google+ for more updates.

The post Android Bottom Navigation Bar Example appeared first on Truiton.

Android itself is a smart OS, still it lacked a very basic feature of text recognition. But not anymore; with the official Optical Character Recognition API of Android and the Mobile Vision library, now Android can perform OCR very efficiently and correctly. I did a very basic feature test to have a look at the new functionality and found out its very fast and easy to use. Here in this Optical Character Recognition(OCR) example of Android, I would simply import the library, click a picture of a piece of text and look for text blocks in it. But before doing so lets take an overview of Android Mobile Vision API to understand the working of Text API better.

Android Mobile Vision Library

Consider a scenario where you wish to scan and an image or a video stream and detect faces, barcodes, QR codes or Text in it on Android. Astonishingly till now no such framework existed on Android. But now Google has introduced Mobile Vision APIs. These set of APIs provide a very easy to use programming interfaces through which we can scan Faces, Barcodes, QR Codes and Text without writing huge amount of code. And the best part is that these can be used offline as well, i.e. only once when the app is downloaded the required dependencies are downloaded, post that an internet connection is not required any more. As this feature is introduced on Android through the Google Play services. To enable your app to use Mobile Vision APIs, you need to add this dependency in your build.gradle file:

compile 'com.google.android.gms:play-services-vision:11.4.0'

Please Note: Learn more on how to setup Google Play Services. Or learn more about Mobile Vision API.

Introducing an Android OCR Library – Text Recognition API

Since the Android OS was brought on to production devices, Optical Character Recognition has been a common area of research. But this Text Recognition API of Mobile Vision suite would bring all these researches to a stop. As this Google powered API contains features like multiple language recognition where languages are like : English, French, German, Spanish or any other Latin based text. Also the text can be parsed from a stream of frames i.e. a video and displayed on the screen in real time as displayed in the image above. But due to the scope of this Android OCR Library example we would keep things simple and scan the text from an image only, as this tutorial is targeted for beginners. Apart from this the interesting part is, all this is done offline by the Google Play services itself, i.e. no internet connection is required after once it has been set up in the app (shown in steps ahead).  Now when it comes to structuring the text, this Android OCR library not only recognizes the text but can also divide the captured text into the following categories:

1. Block – TextBlock – A top level object where a scanned paragraph or column is captured.
2. Line – Line – A line of text captured from a block of text.
3. Word – Element – A single word recognized in a Line.

Android OCR Example

Now that we have a basic understanding of Android OCR library, particularly the Text Recognition API. I will demonstrate by an example where we would simply take a picture and scan for text in it. Now as a thumb rule to do so first we may need to set up our Android app to download the play services dependency for Optical Character Recognition. Therefore please include the block of code below in your manifest to instruct installer to download the OCR dependency at the time of installing the app.

<meta-data
            android:name="com.google.android.gms.vision.DEPENDENCIES"
            android:value="ocr"/>

Please Note: This is not a mandatory step, but helps in downloading the dependencies beforehand. Also the link to full source code is at the end of this tutorial.

Next lets define a layout to display the scanned results:

<?xml version="1.0" encoding="utf-8"?>
<android.support.constraint.ConstraintLayout
    android:id="@+id/activity_main"
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context="com.truiton.mobile.vision.ocr.MainActivity">

    <ImageView
        android:id="@+id/imageView"
        android:layout_width="200dp"
        android:layout_height="200dp"
        android:layout_marginTop="16dp"
        app:layout_constraintLeft_toLeftOf="parent"
        app:layout_constraintRight_toRightOf="parent"
        app:layout_constraintTop_toTopOf="parent"
        app:srcCompat="@mipmap/truiton"
        tools:layout_constraintLeft_creator="1"
        tools:layout_constraintRight_creator="1"/>

    <Button
        android:id="@+id/button"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_marginBottom="8dp"
        android:text="Scan Text"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintLeft_toLeftOf="parent"
        app:layout_constraintRight_toRightOf="parent"
        tools:layout_constraintLeft_creator="1"
        tools:layout_constraintRight_creator="1"
        />

    <TextView
        android:id="@+id/textView"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_marginTop="40dp"
        android:text="Scan Results:"
        android:textAllCaps="false"
        android:textStyle="normal|bold"
        app:layout_constraintLeft_toLeftOf="parent"
        app:layout_constraintRight_toRightOf="parent"
        app:layout_constraintTop_toBottomOf="@+id/imageView"
        tools:layout_constraintLeft_creator="1"
        tools:layout_constraintRight_creator="1"/>

    <ScrollView
        android:layout_width="0dp"
        android:layout_height="0dp"
        android:layout_marginTop="8dp"
        android:paddingLeft="5dp"
        android:paddingRight="5dp"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintHorizontal_bias="1.0"
        app:layout_constraintLeft_toLeftOf="parent"
        app:layout_constraintRight_toRightOf="parent"
        app:layout_constraintTop_toBottomOf="@+id/textView"
        tools:layout_constraintTop_creator="1"
        tools:layout_constraintRight_creator="1"
        tools:layout_constraintBottom_creator="1"
        tools:layout_constraintLeft_creator="1">

        <LinearLayout
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:orientation="vertical">

            <TextView
                android:id="@+id/results"
                android:layout_width="wrap_content"
                android:layout_height="wrap_content"
                android:layout_marginTop="8dp"
                app:layout_constraintLeft_toLeftOf="parent"
                app:layout_constraintRight_toRightOf="parent"
                tools:layout_constraintLeft_creator="1"
                tools:layout_constraintRight_creator="1"
                tools:layout_constraintTop_creator="1"/>
        </LinearLayout>
    </ScrollView>
</android.support.constraint.ConstraintLayout>

I was playing around with ConstraintLayout in Android. Hence made it in Constraint layout, although its not a requirement to use ConstraintLayout for this Android OCR Library example. The above layout basically contains a ScrollView to accurately display the scanned text. Next lets define the main Activity:

package com.truiton.mobile.vision.ocr;

import android.Manifest;
import android.content.Context;
import android.content.Intent;
import android.content.pm.PackageManager;
import android.graphics.Bitmap;
import android.graphics.BitmapFactory;
import android.net.Uri;
import android.os.Bundle;
import android.os.Environment;
import android.provider.MediaStore;
import android.support.annotation.NonNull;
import android.support.v4.app.ActivityCompat;
import android.support.v4.content.FileProvider;
import android.support.v7.app.AppCompatActivity;
import android.util.Log;
import android.util.SparseArray;
import android.view.View;
import android.widget.Button;
import android.widget.TextView;
import android.widget.Toast;

import com.google.android.gms.vision.Frame;
import com.google.android.gms.vision.text.Text;
import com.google.android.gms.vision.text.TextBlock;
import com.google.android.gms.vision.text.TextRecognizer;

import java.io.File;
import java.io.FileNotFoundException;

public class MainActivity extends AppCompatActivity {
    private static final String LOG_TAG = "Text API";
    private static final int PHOTO_REQUEST = 10;
    private TextView scanResults;
    private Uri imageUri;
    private TextRecognizer detector;
    private static final int REQUEST_WRITE_PERMISSION = 20;
    private static final String SAVED_INSTANCE_URI = "uri";
    private static final String SAVED_INSTANCE_RESULT = "result";

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Button button = (Button) findViewById(R.id.button);
        scanResults = (TextView) findViewById(R.id.results);
        if (savedInstanceState != null) {
            imageUri = Uri.parse(savedInstanceState.getString(SAVED_INSTANCE_URI));
            scanResults.setText(savedInstanceState.getString(SAVED_INSTANCE_RESULT));
        }
        detector = new TextRecognizer.Builder(getApplicationContext()).build();
        button.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                ActivityCompat.requestPermissions(MainActivity.this, new
                        String[]{Manifest.permission.WRITE_EXTERNAL_STORAGE}, REQUEST_WRITE_PERMISSION);
            }
        });
    }

    @Override
    public void onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults) {
        super.onRequestPermissionsResult(requestCode, permissions, grantResults);
        switch (requestCode) {
            case REQUEST_WRITE_PERMISSION:
                if (grantResults.length > 0 && grantResults[0] == PackageManager.PERMISSION_GRANTED) {
                    takePicture();
                } else {
                    Toast.makeText(MainActivity.this, "Permission Denied!", Toast.LENGTH_SHORT).show();
                }
        }
    }

    @Override
    protected void onActivityResult(int requestCode, int resultCode, Intent data) {
        if (requestCode == PHOTO_REQUEST && resultCode == RESULT_OK) {
            launchMediaScanIntent();
            try {
                Bitmap bitmap = decodeBitmapUri(this, imageUri);
                if (detector.isOperational() && bitmap != null) {
                    Frame frame = new Frame.Builder().setBitmap(bitmap).build();
                    SparseArray<TextBlock> textBlocks = detector.detect(frame);
                    String blocks = "";
                    String lines = "";
                    String words = "";
                    for (int index = 0; index < textBlocks.size(); index++) {
                        //extract scanned text blocks here
                        TextBlock tBlock = textBlocks.valueAt(index);
                        blocks = blocks + tBlock.getValue() + "\n" + "\n";
                        for (Text line : tBlock.getComponents()) {
                            //extract scanned text lines here
                            lines = lines + line.getValue() + "\n";
                            for (Text element : line.getComponents()) {
                                //extract scanned text words here
                                words = words + element.getValue() + ", ";
                            }
                        }
                    }
                    if (textBlocks.size() == 0) {
                        scanResults.setText("Scan Failed: Found nothing to scan");
                    } else {
                        scanResults.setText(scanResults.getText() + "Blocks: " + "\n");
                        scanResults.setText(scanResults.getText() + blocks + "\n");
                        scanResults.setText(scanResults.getText() + "---------" + "\n");
                        scanResults.setText(scanResults.getText() + "Lines: " + "\n");
                        scanResults.setText(scanResults.getText() + lines + "\n");
                        scanResults.setText(scanResults.getText() + "---------" + "\n");
                        scanResults.setText(scanResults.getText() + "Words: " + "\n");
                        scanResults.setText(scanResults.getText() + words + "\n");
                        scanResults.setText(scanResults.getText() + "---------" + "\n");
                    }
                } else {
                    scanResults.setText("Could not set up the detector!");
                }
            } catch (Exception e) {
                Toast.makeText(this, "Failed to load Image", Toast.LENGTH_SHORT)
                        .show();
                Log.e(LOG_TAG, e.toString());
            }
        }
    }

    private void takePicture() {
        Intent intent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);
        File photo = new File(Environment.getExternalStorageDirectory(), "picture.jpg");
        imageUri = FileProvider.getUriForFile(MainActivity.this,
                BuildConfig.APPLICATION_ID + ".provider", photo);
        intent.putExtra(MediaStore.EXTRA_OUTPUT, imageUri);
        startActivityForResult(intent, PHOTO_REQUEST);
    }

    @Override
    protected void onSaveInstanceState(Bundle outState) {
        if (imageUri != null) {
            outState.putString(SAVED_INSTANCE_URI, imageUri.toString());
            outState.putString(SAVED_INSTANCE_RESULT, scanResults.getText().toString());
        }
        super.onSaveInstanceState(outState);
    }

    private void launchMediaScanIntent() {
        Intent mediaScanIntent = new Intent(Intent.ACTION_MEDIA_SCANNER_SCAN_FILE);
        mediaScanIntent.setData(imageUri);
        this.sendBroadcast(mediaScanIntent);
    }

    private Bitmap decodeBitmapUri(Context ctx, Uri uri) throws FileNotFoundException {
        int targetW = 600;
        int targetH = 600;
        BitmapFactory.Options bmOptions = new BitmapFactory.Options();
        bmOptions.inJustDecodeBounds = true;
        BitmapFactory.decodeStream(ctx.getContentResolver().openInputStream(uri), null, bmOptions);
        int photoW = bmOptions.outWidth;
        int photoH = bmOptions.outHeight;

        int scaleFactor = Math.min(photoW / targetW, photoH / targetH);
        bmOptions.inJustDecodeBounds = false;
        bmOptions.inSampleSize = scaleFactor;

        return BitmapFactory.decodeStream(ctx.getContentResolver()
                .openInputStream(uri), null, bmOptions);
    }
}

In the above piece of code, I simply initialized a TextRecognizer and asked the user to grant the permission to store the captured image on disk. Post which, when an image like shown below is captured, we resize the image in method decodeBitmapUri to a smaller size so that, it can be scanned faster. Once the image is scaled, we check for operational TextRecognizer. Then after the detector is operational, we scan out the text from picture.

When the Android OCR library – the Mobile Vision, returned the text from the picture above, it was very accurate. Have a look at the result below:

For full source code, please refer to the link below:

Full Source Code

Hence I believe this is one of the best OCR libraries available for Android till date. As it gives the unique capability of offline text scanning, without compromising on quality. Therefore if you have to make an app where it is required to scan the text and process it, use the Text API of Mobile Vision for Optical Character Recognition. For more posts like this, please connect with us on Twitter, Facebook and Google+. Hope this helped.

The post Optical Character Recognition on Android – OCR appeared first on Truiton.