R8 Configuration Analyzer

The R8 Configuration Analyzer is available for projects using AGP 9.3 and above. It runs as a Gradle task formatted as :app:analyze<Variant>R8Config (for example, :app:analyzeReleaseR8Config or :app:analyzeDebugR8Config). If your project uses product flavours, you combine the build type and flavour name accordingly (such as :app:analyzeGithubReleaseR8Config). The interesting part is that running this task does not build the entire app. It only compiles classes and resources, stopping short of running full R8 optimisation and assembling the final AAB or APK which is time consuming.

When the Gradle task completes, it generates an HTML report showing how R8 keep rules affect the compiled classes. It displays percentage scores for how much of the app’s codebase R8 is allowed to shrink, optimise, and obfuscate. The higher the percentage, the better for the app’s size and runtime performance.

Usage in actual app

To test this out in practice, I picked an open-source app that I actively contribute to: Flow, a YouTube client reimagined for Android. Before making any optimisations, I ran ./gradlew :app:analyzeGithubReleaseR8Config to establish a baseline.

I studied the generated report and used the android-cli tool’s r8-analyzer agent skill to investigate potential optimisations. After the agent generated its analysis and recommendations, I asked it to optimise the configuration accordingly. Since Flow is an open-source project, code obfuscation isn’t necessary, so we use the -dontobfuscate flag. After going through a few rounds of iterative refinement with the AI agent to tighten overly broad keep rules, I verified and committed the code. I also used this opportunity to benchmark app startup times and submitted everything in a combined PR.

Pro tip: Always copy the generated HTML report outside the build/ directory so you don’t accidentally overwrite it when modifying keep rules and regenerating the report. Without the initial baseline report, it becomes difficult to compare whether your rule modifications changed anything.

After this optimisation, I was able to shave off ~20% of the APK size and achieve an ~11% faster warm startup.

Pros

• Generates a clear, shareable report showing the exact optimisation gains achieved.
• Provides much-needed visibility into what each ProGuard/R8 rule is actually doing.
• Fast execution because it avoids running full R8 or generating final package artifacts.
• Comes with an agent skill (r8-analyzer) that speeds up investigation and fixes.

Cons

• The report does not estimate the exact byte-level APK size savings gained from each rule change.
• You cannot simulate rule adjustments directly in the report interface without updating the rules file and re-running the Gradle task.
• The “Group by Keep Rule File” view is somewhat cumbersome, as you have to inspect each rule file individually to review its available optimisations.

Conclusion

This tool is a big step in the right direction. Previously, Android developers lacked clear visibility into how individual keep rules impacted overall app optimisation. With the R8 Configuration Analyzer, we can easily see how each rule affects the codebase and fine-tune our configurations for leaner, faster apps.

Since I was in the process of learning go language from scratch, I decided to use it for this experiment.

Code

var UserCounts = [...]int{1, 10, 100, 1000, 10000, 100000, 1000000}

func main() {
    names := readUsername(usernamesFile)

    usersList := UsersProto{
        Users: []*UserProto{},
    }

    writer := tabwriter.NewWriter(os.Stdout, 0, 0, 1, ' ', tabwriter.Debug)
    fmt.Fprintln(writer, "Users\tJSON Size\tGzipped JSON Size\tJSON Gzip size % \tProto Size\tGzipped Proto Size\tProto Gzip size %\tGzip Diff (JSON - Proto)")
    for _, num := range UserCounts {
        for i := 0; i < num; i++ {

            name := names[rand.IntN(len(names))]
            user := UserProto{
                Name:  name,
                Age:   rand.Int32N(91) + 10,
                Email: fmt.Sprintf("%s@gmail.com", name),
            }

            usersList.Users = append(usersList.Users, &user)
        }

        jsonData, _ := json.Marshal(usersList)
        protData, _ := proto.Marshal(&usersList)
        gzippedProtoSize := gzipDataAndReturnSize(protData)
        gzippedJsonSize := gzipDataAndReturnSize(jsonData)

        jsonReduction := float64(gzippedJsonSize) / float64(len(jsonData)) * 100
        protoReduction := float64(gzippedProtoSize) / float64(len(protData)) * 100
        diff := gzippedJsonSize - gzippedProtoSize

        fmt.Fprintf(writer, "%d\t%s\t%s\t%.0f%%\t%s\t%s\t%.0f%%\t%s\n",
            num,
            humanReadableSize(len(jsonData)),
            humanReadableSize(gzippedJsonSize),
            jsonReduction,
            humanReadableSize(len(protData)),
            humanReadableSize(gzippedProtoSize),
            protoReduction,
            humanReadableSize(diff),
        )
    }
    writer.Flush()
}

// gzipDataAndReturnSize gzips the input data and return the len of the data
func gzipDataAndReturnSize(data []byte) int {
    var buf bytes.Buffer
    gw := gzip.NewWriter(&buf)
    gw.Write(data)
    gw.Close()

    return buf.Len()
}

// humanReadableSize returns a human-readable size string.
// e.g. 1024 -> 1 KB
// e.g. 1048576 -> 1 MB
func humanReadableSize(bytes int) string {
}

// readUsername returns a array of dummy username
func readUsername(fileName string) []string {
}

I have intentionally kept only the important parts of the code and removed some not so important code. The full code can be found here.

In the above program, we are creating a list of user objects with fields name, age and email address. We pick a user name at random and use that in the name and email address fields. Once we have the data ready, we marshal them into JSON and proto, and then gzip them and print out the result.

We do this from 1 to 1000000 times with multiples of 10.

Result

Observation

• When we have really small data, the gzipped size increases instead of decreasing. This is because, when data is gzipped it adds some additional metadata which will be used to decompress it. Here these metadata cause the size of the data to increase instead of decrease because the size of the data in itself is less.
• JSON compression is far more efficient than proto as the compressed size ratio is consistently better than protos gzipped data. EG: for 10 users the JSON size is 637B and gzipped size is 226B which is 35% of the original data. But in the same place for proto the gziped size is 37% of the original data.
• As the size of the data increases, the gziped sized of both proto and JSON remains consistent with minor difference.

The experiment was conducted for a list of Users. Which will have keys like “Name”, “Age” & “Email” repeated the same number of times as users. This must be making JSON more efficient. The real-world data will be different with limited key repetition thus the results could vary as well.

Conclusion

When we talk about REST vs gRPC in the context of client-server communication, where the client could be a mobile device which could face latency issues. The payload size advantage of gRPC making it faster doesn’t hold true because in today’s day and age gzip has become standard when sending data over the internet. However, there would be several other advantages that gRPC would provide over REST which is a topic for another day.

Example helloworld.proto

syntax = "proto3";

option java_package = "io.grpc.examples.helloworld";

package helloworld;

// The greeting service definition.
service Greeter {
 // Sends a greeting
 rpc SayHello (HelloRequest) returns (HelloReply) {}
}

/ The request message containing the user's name.
message HelloRequest {
 string name = 1;
}

// The response message containing the greetings
message HelloReply {
 string message = 1;
 int32 message_length = 2;
}

Here we are defining 1 API call named SayHello. We need to provide the HelloRequest as input to this API and HelloReply is what is returned from the API.

HelloRequest has a name field in it of type String.

HelloReply has a message field in it of type String, and also message_length of type int.

Additionally, we would also use a protobuf plugin to generate the Models for the Request and Responses and Stubs for the RPC call, in different languages like Java, Python, Go, C++ or Objective C. Now when the server implements the SayHello rpc, and a client makes a call to this rpc with the HelloRequest using the stub generated by the protobuff plugin, the server will return a HelloReply response.

The generated code can be quite a lot for mobile clients, thus the Protbuff plugin 2 options: Regular and Protobuf-lite. Regular is meant to be used by servers where it’s ok to generate a little extra code without much cost. On mobile, generating a lot of code will quickly add up, since Classloader will have to load all this extra class. Also, it will increase the App download size significantly. Thus on mobile, it’s recommended to use protobuf-lite version, which generates relatively lesser code.

Pros of using gRPC for mobile apps

• Reduced network bandwidth when compared to REST is significantly lesser because when using data types like JSON, there is no pre-defined contract between Server and Client. This means, the messages transmitted need to include a key, which says what data we are passing and the actual data. EG name: “Saran”. Here name is the key and “Saran” is the value. Whereas the client only needs the value “Saran”. Which causes increased response size. While in gRPC, since the contract is formally defined as a protobuf file, only the actual value needs to be transmitted.
• Clearly defined contracts, which means communication between the Backend team and Client team is efficient, and there is no scope for miscommunication. Whereas, in REST this contract is not formally defined, which means the client and server can have different understandings of them.
• Support for unidirectional and multi-directional streaming. Which is often required when we have to upload files or continuously stream data like stock prices from the server.

Cons of using grpc for mobile

• Increased App size in the long run. This is because even if use protobuf-lite it still generates a lot of code, whereas libraries like Retrofit in combination with gSON or Moshi make things a lot more efficient when using REST.
• Lack of resources and tooling support. When compared to REST which has gotten mature over time, especially on the client side there is an ample amount of resources and tooling which makes debugging or solving a complex challenge easier. However, since gRPC is new there are fewer resources and tools. Also, since gRPC is protobuf based all the tools need the .proto file to understand the request and response which only adds complexity to the tooling support.
• Rigid: Because gRPC is protbuf-based, the contracts are very strict and it’s not easy to make new changes. To change, we have to update the proto file, generate both client and server codes from the proto file and then implement them. This is time-consuming.

Conclusion

Yes, gRPC is great for mobile apps especially due to the reduced transmission size of data. Reduced data to be transmitted means, faster transfer even when on slow internet. However, we still need better tooling support for gRPC because without them debugging becomes very difficult. Whereas tools like Stetho by Facebook makes debugging network calls as easy as a breeze.

Before we begin, I want you to remember that the Fi app uses GRPC as its core network stack. However, these solutions can be applied to other types of network calls as well. However, the implementation steps may vary.

With Vanilla TLS, it’s easy to do a Man In The Middle (MITM) attack. Thus we wanted something stronger than that.

Certificate Transparency (CT)

Certificate Transparency is an additional step performed over the standard TLS verification, like verifying the Hostname name and root CA etc. When Certificate Transparency is performed, it makes a network call to a separate log server with the Signed Certificate Timestamp (SCT) embedded in the certificate.

You can learn how certificate transparency works here.

Fi also being a payments app, people would use the app at the storefront to make payments. The internet connectivity here would likely be very flaky or poor. In such cases making any additional calls on the network leads to extra time taken in app launch. After doing a lot of analysis, we found that CT was adding up to an extra 2 seconds even before a connection was established with the server.

Thus we started looking for something more efficient while also secure. That’s how we decided to try certificate pinning.

Certificate Pinning (Pinning)

Most of the time when we pin, we are not pinning the certificate itself, but the hash of the public key, found in the certificate. The advantage here is that we can rotate the certificate but may keep the public key the same. However, this is not recommended. Thus the name Certificate Pinning is incorrect and should have been Public Key pinning.

We pinned the public key using a network security config. Which is the recommended way to do it according to Android’s docs.

Whenever we do pinning, it always comes at the cost of flexibility. The flexibility to change the public key before the expiry of the certificate or unexpected leak of the private key.

Because the certificate rotation bit is very complex. If we miss any step during key rotation, then we block several users out of the app. Since pinning is also done within an XML file, it doesn’t allow us to implement any logic. These were some of the big factors for us not to go with just vanilla pinning. This made us look for alternatives.

Hybrid approach

We came up with a hybrid approach that combined both CT and pinning. The drawback of CT is that it was slow, but flexible in terms of certificate rotation. The problem with pinning is that it’s faster even when on a slow network but not flexible when rotating the keys. Thus we combined both to get the goodness of each.

We implemented a mechanism in our HostNameVerifier where firstly we did the traditional check performed by TLS and then verified the pins. This would pass in most of the cases. However, when we have just rotated the certificate, the older app versions with older pins will fail the pinning check. When it fails, we fall back to CT to verify the certificate, over the network. This is also effective in blocking the unsolicited MITM attacks.

internal class PinningOrCertificateTransparencyHostNameVerifier(
    private val pins: Map<Host, Set<PublicKeySha256>>,
    private val certificateTransparencyHostNameVerifier: HostnameVerifier
) : HostnameVerifier {

    @SuppressLint("BadHostnameVerifier")
    override fun verify(hostname: String, session: SSLSession): Boolean {
        // We should call verifyOkHostname first and if it passes
        // call pinning first or certificate transparency either has to return true
        // for the connection to be considered secure.
        return verifyOkHostname(hostname, session)
            && (verifyPublicKeyPinning(hostname, session)
            || verifyCertificateTransparency(hostname, session))
    }

    private fun verifyOkHostname(hostname: String, session: SSLSession): Boolean {
        val okHttpResult = OkHostnameVerifier.verify(hostname, session)
        Timber.i("OkHostnameVerifier result: $okHttpResult")
        return okHttpResult
    }

    private fun verifyPublicKeyPinning(hostname: String, session: SSLSession): Boolean {
        // We try and find a pin for the hostname, else return false
        val setOfPins = pins[Host(hostname)] ?: kotlin.run {
            Timber.w("No pin found for $hostname")
            return false
        }
        val leafCertificate: Certificate = session.peerCertificates[0]
        val sha256: String = leafCertificate.publicKey.encoded.sha256String()
        val pin = PublicKeySha256(sha256)
        val isPinVerificationSuccessful = setOfPins.contains(pin)
        Timber.i("VerifyPublicKeyPinning result: $isPinVerificationSuccessful")
        return isPinVerificationSuccessful
    }

    private fun verifyCertificateTransparency(hostname: String, session: SSLSession): Boolean {
        val ctResult = certificateTransparencyHostNameVerifier.verify(hostname, session)
        Timber.i("CertificateTransparency result: $ctResult")
        return ctResult
    }
}

@JvmInline
internal value class Host(val host: String)

@JvmInline
internal value class PublicKeySha256(val pin: String)

This of course comes with some drawbacks

1. An app would make many different forms of connection in different areas of the app. Eg: We make the API call to load the page, which shows a Terms and Conditions hyperlink. When clicked on it, it opens a web view which shows the Terms and conditions. Here we are making a REST API call to load the page and then loading a Webpage, which will form its new connection to the server even when the endpoints remain the same. In such cases having a centralised place like the Android’s recommended way of pinning would be the best. Since it will verify the same pin for any connection established to the domain by the app. However, when we use the hybrid approach, the code to verify the pin lives within a HostNameVerifier, which we will have to individually apply on any new connection established by the app.
2. When the certificate is rotated, older versions of the app will fall back to CT. The users who are accustomed to the shorter load time will see this increased load time, which is not an ideal experience for any user. However, once in the app, we can nudge them to update the app to the latest version with pins for new certificate.

Summary

• Certificate Transparency
  • Pro
    1. No extra handling is needed when the certificate is rotated, as some verification happens on the network.
  • Con
    1. Very slow when on an unstable internet connection
• Certificate pinning or public key pinning
  • Pro
    1. Faster than CT as all the checks are performed locally on the device.
    2. Can be configured in one place and it will take effect across the app.
  • Con
    1. Very tricky to rotate the certificate. If not planned and executed properly We might lock some or all users out of the app forever.
• Hybrid Approach (Combination of pinning and CT)
  • Pro
    1. Speedy verification of pinned certificate
    2. Gets the flexibility of CT when certificates are rotated
  • Con
    1. Cannot be configured centrally in one place
    2. Takes time to establish the connection as pin verifications will fail and it will fall back to CT.

Exception: java.lang.IllegalStateException: Vertically scrollable component was measured with an infinity maximum height constraints, which is disallowed. One of the common reasons is nesting layouts like LazyColumn and Column(Modifier.verticalScroll()). If you want to add a header before the list of items please add a header as a separate item() before the main items() inside the LazyColumn scope. There are could be other reasons for this to happen: your ComposeView was added into a LinearLayout with some weight, you applied Modifier.wrapContentSize(unbounded = true) or wrote a custom layout. Please try to remove the source of infinite constraints in the hierarchy above the scrolling container.

Now let’s try to understand the issue here. LazyColumns by default have an infinite maximum height because they lazy-load items. Due of this nature, it cannot determine its height and thus uses an infinite as its height. Also, since LazyColumns are scrollable, it needs to keep track of the items visible on the screen. When an item is scrolled out of the screen, a new item gets added. Now since the internal LazyColum’s height is infinity, it disrupts the outer LazyColumn from knowing its child’s actual height. This is why we are not allowed to nest LazyColumns.

Now that we understand the problem, let’s look what solutions are avilable to us.

1. Flatten the list

One way to solve the nesting of LazyColumns is to flatten the list, such that we can get rid of the internal LazyColumn. This way we will have only 1 lazy column which solves the problem.

Pro

• Solves the LazyColumn issue without adding any new components.

Con

• Loses data hierarchy. EG: If we are building a feed like Facebook, where we have a post and 2 comments on the post and then the next post. If the user likes a comment, then we can’t immediately identify which post the comment belongs to because our list is flattened.

2. Compute the height of the nested LazyColumn

As we found earlier, the infinite height of the LazyColumn is the root cause of the issue. This is understandable as there would be different-sized elements loaded into the LazyColumn. However, this is not the case always. For example, we are building a contacts app or a simple calendar events list. Here the height of the component redered by the list remains consistent. In such cases, we can compute the height of our list in dp and set it as the height of our inner LazyColumn. This caused, the height of the list nit be infinite and which solves the problem.

EG: The height of 1 item in the nested list is of 40.dp and the list has 10 items. It means we can set the height of the LazyColumn to 40 * 10 = 400.dp

Pro

• Unlike a flattened list, the hierarchy is still maintained.

Con

• Computing the expected height can be challenging depending on the data rendered by the composable functions.

3. Setting max height

If you have worked with Veiws before there is an attribute android:maxWidth & android:maxHeight. The purpose of this is to set the content in the View scale the view but beyond a certain point. Since we are setting a max height, initially the composable function will be loaded with the height required by the content, and is allowed to scale up to the set max height. In Compose, we use the Modifier.heightIn(max) to set the max height for a component.

Pro

• Easy to implement with minimal code changes.

Con

• Requires hardcoding a maximum height, which may be challenging for dynamic layouts.

Example

@Preview
@Composable
private fun PreviewNestedWithWeight() {
    LazyColumn {
        items(2) { num ->
            if (num == 0) {
                // Using a fixed height for the LazyColumn as I know the height of each item
                // and the number of items in the list. ie: 100.dp * 10 = 1000.dp
                LazyColumn(modifier = Modifier.height(1000.dp)) {
                    items(10) { i ->
                        Text(
                            text = i.toString(),
                            Modifier
                                .size(width = 100.dp, height = 100.dp)
                                .background(Color.Gray)
                        )
                    }
                }
            } else {
                // Using an upper bound for the height of the LazyColumn. This can be some
                // arbitrary value like 10000.dp which we don't expect this Column to reach.
                LazyColumn(modifier = Modifier.heightIn(max = 10000.dp)) {
                    items(10) { i ->
                        Text(
                            text = i.toString(),
                            Modifier
                                .size(100.dp)
                                .background(Color.DarkGray)
                        )
                    }
                }
            }
        }
    }
}

Conclusion

We explored several approaches to address the crash caused by nested LazyColumns or LazyRows in Compose. Personally, I prefer setting a max height using Modifier.heightIn(max) as it is straightforward and requires minimal code changes. However, the best solution depends on your specific requirements. I hope these solutions help you resolve the nested scrolling issue in your Compose application.

When a QA engineer raises a bug with small inconsistencies, such as missing alignment or a crash due to an off-by-1 error, it means I have to stop what I’m doing and address the reported issue. I dislike nothing more than having to switch branches, pull the master, fix the minor bug, run the build, and wait for the entire build to verify the fix. This becomes more frustrating when there’s no build-cache because we are working on a new branch. Once the issue is fixed, I have to switch back to the previous branch, run the build again, and wait for the entire build to complete, all because this is a new branch.

When working in a team, we often learn something new from each other. Similarly, when working with a senior engineer, I learned a solution to this problem, which is to keep multiple copies of the repository.

Having multiple copies of the repository saves me from waiting for two fresh builds, which can cause 20-30 minutes of lost productivity. With multiple copies of the repository, I can verify the fix for the issue on my primary project along with the changes I was working on for a new feature. Once verified, I apply the same code in the secondary repository and publish it to raise the pull request.

I even go 1 step ahead and never open the secondary project in my IDE. Instead, I copy the file with the fix from the primary repository into the secondary repository. Of course, this only works for simple fixes.

I wish I had known this hack earlier in my career I would have saved hundreds of hours wasted switching the branch and triggering fresh builds.

class ViewModel {
  private val _mLiveData = MutableLiveData<Boolean>()
  val mLiveData: LiveData<Boolean> = _mLiveData
}

OR

class ViewModel {
  private val _mLiveData = MutableLiveData<Boolean>()
  val mLiveData: LiveData<Boolean>
    get() = _mLiveData
}

When we look at it, both methods look similar. However, that’s not the case. Let’s look at some examples.

1. With Direct assignment

We will start with the first code snippet, but with little bit logging.

class Test() {
  private val a = mutableListOf(5, 10, 15)
  val b : List<Int> = a // Hiding the mutablity from a external class
  
  fun updateList() {
    a.clear()
    a.apply {
      add(2)
      add(4)
      add(6)
    }
  }
}

val t = Test()
print("list = " + t.b.joinToString())
t.updateList()
print("updated list = " + t.b.joinToString())

And the output when the above code gets executed is.

list = 5, 10, 15
updated list = 2, 4, 6

Well, what’s wrong? It worked, didn’t it?

The answer is Yes, it worked. Now let’s make some changes to the above code.

class Test() {
  private var a = mutableListOf(5, 10, 15)
  val b : List<Int> = a  // Hiding the mutablity from a external class
  
  fun updateList() {
    a = mutableListOf(2, 4, 6)
  }
}

val t = Test()
print("list = " + t.b.joinToString())
t.updateList()
print("updated list = " + t.b.joinToString())

And the output of the above code is

list = 5, 10, 15
updated list = 5, 10, 15

Wait, what? How did the output change? Let’s first understand what changed.

1. a become mutable (a was val but is var now)
2. Implementation of updateList() changed from updating the current list to creating a new list with new values.

Now let’s try to understand why did it print updated list = 5, 10, 15 instead of updated list = 2, 4, 6. For that, let’s look under the hood and understand how does this kotlin code look when converted to Java using byte code converter.

// Only has code relevent to us
class Test {
  private List a;
  private final List b;

  public Test() {
    this.b = this.a;
  }

  public void updateList() {
    a = CollectionsKt.mutableListOf(new Integer[]{2, 4, 6});
  }
}

As we can see here, b is like an indirect reference to the memory pointing to exact same address pointed by a. Now if we look at the updateList() above, what we did was change the address pointed by a by assigning a new value. However, we never update b to point to same address. So the b is still pointing to the old address where a was pointing. Which produced the bug in our code.

2. With a property getter

Let’s take the above code, which was buggy and use a getter instead of assignment.

class Test() {
  private var a = mutableListOf(5, 10, 15)
  val b : List<Int>  // Hiding the mutablity from a external class
    get() = a

  fun updateList() {
    a = mutableListOf(2, 4, 6)
  }
}

val t = Test()
print("list = " + t.b.joinToString())
t.updateList()
print("updated list = " + t.b.joinToString())

And the output is

list = 5, 10, 15
updated list = 2, 4, 6

Well, it worked as we expected. But why?

To understand why let’s look at the kotlin byte code decompiled to Java

class Test {
  private List a;

  @NotNull
  public final List getB() {
    return this.a;
  }
}

Well, here b is only acting as a getter of a. So whenever we call b it will always have the latest value of a. Isn’t this we always wanted?

Conclusion

We often need to use the backing property. But, it’s always prone to bug and it’s difficult to spot them. Hence, always use the backing property via a getter.

val getUserCall = apiService.getUser(15)
getUserCall.enqueue(object: Callback<User> {
    override fun onResponse(call: Call<User>, response: Response<user>) {
        doSomeThing(response.body())
    }

    override fun onFailure(call: Call<User>, t: Throwable) {
        t.printStackTrace()
    }
})

This is how a typical callback based code would look like in Kotlin. But, aren’t we talking about co-routines, why do we still have callbacks?

Ok let me show you the above example using co-routines

launch {
    try {
        val user = apiService.getUser(15)
        doSomeThing(user)
    } catch(t: Throwable) {
        t.printStackTrace()
    }
}

Cool!! but here we assume that apiService.getUser(15) is a function which supports co-rotines. However often that’s not the case, becasue usually we are using a framework or libraries, thats written on/or for Java. In such case, we can’t avoid using callbacks.

In such cases what we can do though is convert these callbacks into Kotlin co-routines. Lemme show you how!!

Let’s take the previous example of getting a user from a api call.

launch {
    try {
        val user = getUser(apiService, 15)
        doSomeThing(user)
    } catch(t: Throwable) {
        t.printStackTrace()
    }
}

suspend fun getUser(apiService: Service, id: Int) = suspendCoroutine<User> { continuation ->
    val getUserCall = apiService.getUser(15)
    getUserCall.enqueue(object: Callback<User> {
		
        override fun onResponse(call: Call<User>, response: Response<User>) {
            continuation.resume(response.body())
        }

        override fun onFailure(call: Call<User>, t: Throwable) {
            continuation.resumeWithException(t)
        }
}

Here we ar using a suspendCoroutine {} to convert a callback into a co-routine. In getUser() first we launch a suspendCoroutine block.

INFO: In order to use suspendCoroutine{} we declare getUser() as a suspend function.

It supplies a continuation as an parameter. We will be using this continuation to inform the coroutine to continue from the point where the function was suspended. We can also pass a result to the continutaion which will be returned when the suspended function returnes.

How the distribution of library work on Android

In Android, Gradle is our default build system. In Gradle to include a library, we add the name of a library in the build.gradle file. But, how does it find the library just by including a single line in the build file? The answer is it looks up for the library in some cloud repository and downloads it. One such famous cloud repository is Jcenter and is by default included when we create a new Android Project.

I will be continuing on my project from my last post. We will be publishing our library to JCenter through JFrog Bintray. It provides distribution of open-source libraries for free :)

I. Creating an Account and setting up our Repository on Bintray

1. On Bintray scroll to the bottom of the page and click on “For Open Source Plan Sign Up Here”
2. Create an account
3. Click on “Add new Repository” and it will present a page with a form.
4. Enter the name for your Repository. It is like a project name.
5. Since our library will be used through Gradle which is a Maven-based build system. You need to select “Maven” in the “Type” dropdown.
6. Select the Licence under which you want your library to be distributed. (To know which licence to choose, visit choosealicense.com)
7. Click on “Create” and you will be taken to the repository page.

INFO: I have only named the mandatory fields.

II. Adding a package to the newly created Repository

1. Click on “Add new Package”

2. Enter a name for the package.

   WARNING: This name will be used while including your library into a project by other developers.

   INFO: A common convention that developers follow is including their GitHub username in the package name.
   i.e: com.github.saran2020.mylibrary

3. You can choose the same licence which you choose while creating your repository.
4. Enter your GitHub project URL into the “Version Control” field.

III. Saving the bintray API key.

Open “Edit Profile” and go to “API Key” section and save the API key somewhere. We will need this API Key when we automate the release of a new version.

We have almost completed setting up our library on Bintray. We will now be moving ahead to automating our release from Android Studio. I have shared a sample project on Github You can go through the commits while following my steps here.

Before continuing to the next section, we need to clear some terms I have used in the below steps.

RootProject

is the name of my project. Therefore, RootProject’s build.gradle will mean your projects build.gradle file.

app

is the name of my app module. So, “app” module build.gradle will mean your app module’s build.gradle file.

library

is the name of my library module. Hence, “library” module build.gradle will mean your library build.gradle file.

IV. Automating release of our library.

1. Add Bintray Gradle plugin and maven Gradle plugin to the RootProject build.gradle (Commit)

   buildscript {
    ...
    dependencies {
        ...
        classpath "com.jfrog.bintray.gradle:gradle-bintray-plugin:1.8.4"
        classpath "com.github.dcendents:android-maven-gradle-plugin:2.1"
    }
   }
   

2. Add version details to gradle.properties file.

    versionName=0.1
    versionCode=1 
   

   We will be referring to these version code when sending out a new release. Making it easier for you to release a new version, without making changes to the build.gradle file.

3. Add Bintray authentication details to local.properties file.

    bintray.user=<bintray_username>
    bintray.gpg.password=<bintray_password>
    bintray.apikey=<bintray_apikey>
   

   You will be replacing the <bintray_username> with your Bintray username, <bintray_password> with your password and <bintray_apikey> with your “API key” from step III above.

   WARNING: You need to make sure that local.properties file is included in the .gitignore file. Or else you might end up exposing your username password or API Key to GitHub accidentally.

4. Include upload script to the library build.gradle file.

    repositories {
    	mavenCentral()
    }
   
    // Add these lines to publish library to bintray. This is the readymade scripts made by github user nuuneoi to make uploading to bintray easy.
    // Place it at the end of the file
    if (project.rootProject.file('local.properties').exists()) {
    	apply from: 'https://raw.githubusercontent.com/nuuneoi/JCenter/master/installv1.gradle'
    	apply from: 'https://raw.githubusercontent.com/nuuneoi/JCenter/master/bintrayv1.gradle'
    }
   

   This code will be added to the end of the library build.gradle file. This is some script created by other developers, which will help us automating our upload.

5. Configuring the library for upload.

    apply plugin:...
   
    ext {
    	bintrayRepo = 'MyLibrary'
    	bintrayName = 'com.github.saran2020.mylibrary'
   
    	libraryName = 'MyLibrary'
   
    	publishedGroupId = 'com.github.saran2020.mylibrary'
    	artifact = 'MyLibrary'
    	libraryVersion = '1.0'
   
    	libraryDescription = "Demo"
   
    	siteUrl = 'https://github.com/saran2020/MyLibrary'
    	gitUrl = 'https://github.com/saran2020/MyLibrary.git'
   
    	developerId = 'saran2020'
    	developerName = 'Saran Sankaran'
    	developerEmail = 'sands.developer@gmail.com'
   
    	licenseName = 'GNU GENERAL PUBLIC LICENSE'
    	licenseUrl = 'https://www.gnu.org/licenses/gpl-3.0.en.html'
    	allLicenses = ["GPL-3.0"]
    }
   
    android {
        ...
    }
   

   Add the above code to the library build.gradle after apply plugin and before android section.

6. Reading the version information from gradle.properties file, which we added in step 2

    ext {
        ...
        libraryVersion = project.versionName
        ...
    }
   
    android{
        defaultConfig {
            ...
            versionCode project.versionCode.toInteger()
            versionName project.versionName
            ...
        }
    }
   

   You need to replace the existing libraryVersion in the ext section and versionCode and versionName in the defaultConfig section with the above code.

   Whenever you want to release a new version, you just need to update the version in gradle.properties.

7. Disabling creation of JavaDocs.

    ...
    subprojects {
    	tasks.withType(Javadoc).all { enabled = false }
    }
   

   Add the below code to the last line of RootProject build.gradle file. We are disabling the creation of Javadoc becasue, this some times give an error.

8. Uploading the project

    foo@bar:~$ ./gradlew assembleRelease bintrayUpload
   

   Run the above command by navigating to the root of your project through Terminal/CMD and wait till the upload finishes.

You can verify the upload by going to the Repository -> Package -> Files -> {Version you uploaded} on Bintray dashboard and confirming that an .aar file exists.

V. Making the library available to Developers through JCenter

To make your library available to developers you will need to link your library package to Jcenter. You will find the option your package page. To add your library to Jcenter click on “Add to Jcenter”

It will open a page asking for comments. Tick the “is pom project” and add some comment about your project before submitting. It takes up to 24hrs to add your package to JCenter. Once it is added, an E-mail will be sent to you.

INFO: My package was accepted without any comment :)

VI. Releasing a new version of your library

To release a new version, you need to update the version information in the gradle.properties file and run the command.

foo@bar:~$ ./gradlew assembleRelease bintrayUpload

It is a good practice to check if your library has been published properly after every release. To do that, you need to comment out the

implementation project&lt;path: '<Your library name>'&gt;

from the dependencies block and adding the version from the Jcenter which you just published directly like this

implementation 'com.github.saran2020.mylibrary:MyLibrary:0.1' 

It is also a good practice to mark every new release of your library on your GitHub repository.

Follow me on Twitter for new updates or for any queries

When I started as an Android dev about 1.5 years back, I used to think, why do I need libraries when I can build all that cool stuff myself? However, as I completed about 2 months in the profession I started realizing the importance of the library and re-inventing the wheel every time was not at all a good idea. Every time I used a library from GitHub, I used to think, how do they build such cool library and how is it different from the normal app which I was used to building? If you wonder the same, you are in the right place. Today I will be explaining what libraries are, how you can build them, also why and how to distribute a library you built.

What is a library?

To know what is a library, you must know what a module is. Let’s learn what a module is.

A Module in a project follows the Separation of Concern (S) from the SOLID principles of Object-Oriented Design.[*] Modules help in splitting a project into smaller modules which would run independently or dependently on other modules.

Whenever we create a new project, Android Studio creates a single module which is an application module or app in short. App modules can run independently. Whereas, library modules cannot run independently. It is dependent on another application module which will invoke this library module for it to run. In Android, all of this is handled via build.gradle file of the application module.

Why should I build them?

When we work on multiple projects, we often write a lot of components in our project which we later need in other projects as well. What we end up doing is copy-pasting the code from project one to project two. Later we find that there was a bug in the component and we fix them in project two. However, the bug still exists in project one. Maintaining the same codebase twice is a challenging task and is not the best way to do it.

The best way to handle such a situation is to convert the component to separate library modules. This module can then be imported into both the projects. This also makes maintenance of this component easier and no copy paste needed, Yay!!. Here we are sharing the module (library) locally. But can’t this be done globally? Where one person writes components and makes it available for any developer to use it. If any developer using this component finds a bug, he can report it to the creator and wait for him to fix it or fix it himself. We all developers live in peace. 🙂

How to build a library?

1. Let’s create a new empty project in Android and name it “MyApp”. On completing of creating a new project, the “Project” pane of Android Studio will look like this. Congratulations we have successfully created a new module. However, this is not the type of module we are here for. This is an application module, what we need is a library module. So let’s create one

2. Go to File -> New -> New module… it will show us a popup asking for the type of module you want to add. Select “Android Library” from the list and click Next and then it will ask us to name our module. Let’s name it “My Library” and click Finish. After we complete this step our project pane will look like this. Notice the mylibrary there? That’s the new library module which we just created. Android studio differentiate between them by showing a different icon for the app module and library module.

How does Android Studio know which one is an app module and which one is a library module? What changed? The answer is hidden inside the module level build.gradle file. If you open the app and library modules’ build.gradle you will see the first line of app’s Gradle file is

apply plugin: 'com.android.application'

and that of the library is

apply plugin: 'com.android.library'

This is what tells Android Studio what type of Module it is. Now we can write all of our fancy code inside the library module which we want to distribute.

Pro Tip: It’s considered good practice to make your library code configurable for most common use cases. Because, what we build our library for might not be the exact use case for the developer using the library.

How do I use this library module in my app?

Simple!! you just have to add one lie to your app module-level build.gradle file

implementation project(path: ':mylibrary')

This will only work if your module is in the same project as your app.

If your library module is in some other project, you will have to import it to your current project or publish that library through JCenter. About which I will explain in my next post.

Since you have added this library as a dependency to the app module, now you can use the code/feature from the library as if it is a part of your project.