DEV Community: Levi Albuquerque

Kotlin Data Structures - Arrays and Strings

Levi Albuquerque — Sat, 13 Jul 2019 15:16:53 +0000

Hey, so this is the first post in a series containing a basic introduction to Kotlin data structures. I'll try to be the most hands on as possible, so for that reason I'll be using problems from Cracking the Code Interview as examples of usage of such data structures. Today we'll be starting with two of the most basic ones: Arrays and Strings.

Strings

Strings in Kotlin, like in Java, are immutable, so we have to be very careful when handling them and mind the cases where new strings would be created without explicit warning. The class String is used to represent a string instance, each element of a string can be retrieved as a Char instance by indexed access, therefore you can think of it as an array of Char objects:

    val word = "Hello World"
    val letterH = word[0]

So, going through each element of a String is as easy as using a for-loop:

    for (c in word){
        println(c)
    }

Similar to many languages out there, you can escape special characters using the backslash, like "\n".

Another interesting featue of strings in Kotlin is how we can use something called string templates. If we'd like to insert values into a string at runtime, we may use string templates. To do so we'd need to use $ before the variable we'd like to insert into the string or use curly braces if we're evaluating an expression:

    val oneThousand = 1000

    println("1 thousand = $oneThousand")
    println("1 thousand and one = ${oneThousand + 1}")

Funny enough, if we decompile the bytecode back to java code we get the old + concatenation we're used to:

   public static final void main(@NotNull String[] args) {
      Intrinsics.checkParameterIsNotNull(args, "args");
      int oneThousand = 1000;
      String var2 = "1 thousand = " + oneThousand;
      System.out.println(var2);
      var2 = "1 thousand and one = " + (oneThousand + 1);
      System.out.println(var2);
   }

One last thought about Kotlin strings is that they use the same idea of String Pools as in Java. This means that if two strings are equal (structuraly speaking) they point to the same place in memory. Why is this important, you may ask? In kotlin we can compare two variablesby using the structural equality == and the referential equality ===. Because of String Pools and the whole string imutabilty, if we initialize two variables with the same string value, they'll hold the same referece, the code bellow would run to completion:

    val first = "first"
    val second = "first"

    assertTrue { first == second }
    assertTrue { first === second }

Most of the Kotlin types have nice extension functions to make our lives working with them easier. Here's a list of my favorite ones:

associate()

This method takes each character of the original string and apply a transformation that returns a Map. You can use it to create a map of characters counts of your string:

    val s = "Levi Moreira de Albuquerque"

    val bin = s.associate { c ->
        Pair(c, s.count { s -> s == c })
    }

    print(bin)


    {L=1, e=5, v=1, i=2,  =3, M=1, o=1, r=3, a=1, d=1, A=1, l=1, b=1, u=3, q=2}

capitalize() and decapitalize()

It takes a Locale and capitalizes the first letter of the string according to that Locale.

toSet

Would you like to know if there are repeated values in a string and can use extra space? Just use toSet():

    val s1 = "Levi Moreira de Albuquerque"
    val s2 = "abcdefghijk"

    false
    true

Arrays

Arrays in Kotlin are representd by the Array class, the basic anatomy of this class is as follows, this is the general implementation of an Array, but kotlin has specialized classes for primitive types such as IntArray, FloatArray and DoubleArray.

class Array<T> private constructor() {
    val size: Int
    operator fun get(index: Int): T
    operator fun set(index: Int, value: T): Unit
}

Accessing an array happens just like in Java, you can use square brackets and an index to access a position. Though this is just syntactic sugar to the get() and set() methods ilustrated above.

The primitive types arrays get translated into their counterparts when targetting the JVM plataform, for instance IntArray is represented by int[], FloatArray to float[] and so on. This is clear when we decompile the code:

    val s1 = IntArray(5) { index ->
        index * index
    }

We get this very ugly result:

      byte var2 = 5;
      int[] var3 = new int[var2];

      for(int var4 = 0; var4 < var2; ++var4) {
         int var6 = false;
         int var9 = var4 * var4;
         var3[var4] = var9;
      }

Just like strings, Arrays have some very interesting extension functions, some of my favorite ones are listed here:

binarySearch

Performs a binary search in the array, note that the array needs to be sorted for the result to work as expected.

forEach

intersect

Returns a set with the numbers that existing both in the first array and in the given collection:


    val s1 = IntArray(10) { index ->
        index * index
    }

    val s2 = IntArray(20) { index -> index }
    print(s1.intersect(s2.toList()))

    [0, 1, 4, 9, 16]

joinToString

Creates a string with the elements of the array using a separator (a comma isthe default value). We can also add a prefix/postfix to each element.

    val s1 = IntArray(5) { index ->
        index * index
    }
    print(s1.joinToString(separator = " "))

    0 1 4 9 16

max, min, average, sum

Performs the given action (find max, min or calculate the sum/average) with the elements of the given array.

The example

As an example of usage of such data structures we'll have a look at the first problem from the first chapter of Cracking the Code Interview. We need to devise an algorithm that can detect if a string contains only unique characters. The impementation is pretty straightfoward if we don't care about performance we cook up a O(n^2) time algorithm. But we'd like to have an O(n) algorithm and for that we'll use a BitSet.

A BitSet is simply an array of bits, we'll initialize our array with the number of characters in the extended ASCII alphabet (I made an assumption that we'll be only feeding ASCII strings), therefore we'll be using a constant amount of space.

The idea is simple, the array is initialized with false in all positions. We'll go through the input string checking each character, the integer version of the character will index the BitSet, if the given position is true we can immediately return false because there's a duplicate (we've seen it before), otherwise we return true in the end, because we looped through the whole string and didn't find any duplicates. I've also added a small check at the beginning because if a string is larger than the alphabet, it must contain repeated characters.

fun isUnique(s: String): Boolean {
    if (s.length > 256) return false
    val bits = BitSet(256)
    for (c in s) {
        if (bits[c.toInt()]) {
            return false
        }
        bits[c.toInt()] = true
    }
    return true
}

As you can see in the method above, both the BitSet and the String can be accessed by using an index. Also, I've used the .toInt() extension method to convert a Char to its integer equivalent.

I hope this was helpful to give you an introduction about some basic data structures in Kotlin. In the next post we'll talk about LinkedLists, see you there :)

Compare yourself with yourself

Levi Albuquerque — Mon, 15 Apr 2019 00:14:15 +0000

You're surfing Linkedin and an update pops up about an ex school colleague of yours. They've just been accepted to one of the big four and you wished that was you. This type of situation used to make me question everything I was career-wise. Why was I so behind my peers? Why couldn't I be more "known" in the community? Why wasn't I as successful? These questions popped into my head and clouded my judgement to the most obvious reason that could answer my questions: every person is different and I shouldn't compare myself and my career path to that of others.

The aims and reasons that moves each one of us are completely different, so the outcomes of those must be different and realizing this made me stop comparing myself with others. It's not very easy, in our industry there's some sort of intrinsic competition between peers and you're always comparing yourself to see where you stand among them, but if you study yourself and compare with yourself, with a little of good sense that should be enough to see if you're evolving in terms of your career or if you're in the same place for far too long.

Here's a list of things that helped me stop comparing myself with other people:

1 - Accept you can't learn/do everything.

I think of this as a Fear of Missing-out, but more career driven. There's a lot of new stuff going on and you fear you don't know enough about them. It's difficult, I know. Every time something new comes up in the Android world I just want to test it right on the spot. But I usually don't have time to do so, after work, studying and taking care of my family there's little time left to do these tests and write more code. This used to bump me out a lot in the past. I was stressed out because I couldn't stay on top of everything that was going on, but once I've accepted that it was not humanly possible to do so things go better.

First I've accepted that I knew something, my knowledge must have some value, otherwise I wouldn't have a job, I know something, not everything of course, that's impossible, but something.

I've tried to structure and time-box the new things I'd like to learn, I would do a list and give some points to each new topic and they would go up or down the list depending on how important that was. Another thing that helped me was applying that in my current job. Sometimes that is difficult because adding new technologies to a project must be a team decision, but I would present the idea and hope for the best. Sometimes it would work and I wouldn't need to spend extra time learning that. If it didn't work, back on the list it went and at some point or another I would spare a couple of hours to study that. Being patient is very important at this stage because you won't be able to learn everything in a day.

2 - Everyone has their own clock.

Time works differently for everyone, and I'm talking about both micro time, like what time you wake up and start working, and macro time, like at what age do you expect to start forming a family. It's just how it is, everyone was raised differently, even within the same family and that's why it's so strange to compare yourself with someone else. Other people had different opportunities, learned things differently and have a different career focus, so why not decide if you're behind just by comparing with yourself one year ago? I can say that a good exercise for me was to look back at myself in time. What was I doing one year ago? Two years? Is it the same, is it different? Do I feel that I've learned new stuff or just continued the same?

I don't like to feel stuck, I guess nobody does. And the only way of knowing if you're stuck is by checking periodically what you've done to not be stuck. Here's a couple of things that I like to consider when evaluating my progress through time:

What have I learned since the last time I checked?
Do I find satisfaction in my job? Do I learn new things?
Have I tried anything new recently?

By evaluating what I am at the moment when compared to what I was some time ago I can make a clear judgment whether or not I have advanced and if maybe it's time for my to focus more on my education, or maybe change projects at work or even find a new more challenging job. And it's all about evaluating yourself and your own level of happiness from where you are.

At this point you might be asking yourself, how you're supposed to evaluate where you are, how do you know you've spent too long in the same job or doing the same thing. The next step is the piece key for knowing that.

3 - Have a career plan for yourself.

Well, in order to know if you're moving forward you need to know the direction you're heading to. And that's where a career plan is here to help. And I'm not talking about a structured path where you list each and every step of the way until retirement, that's not good because that would be like predicting the future and unless you can accurately do that I don't recommend going that far. I believe that the question "Where do you see yourself in x years" is a good way to start planning your career. Some nice steps to take are:

You can pick big names where you'd like to be working in a couple of years but understand that it would be much easier to pick positions instead. If you're willing to work in any nice company at that position that gives you a lot of possibilities.
If you're like me and you've picked a big name, make a plan defining steps you think it would be necessary to increase your chances of reaching your goals.
Leave some space for the unknown. You don't know what will exactly happen in the future, so plan ahead, but leave some space to accommodate possible issues. That way you won't feel frustrated if you don't reach your go at the amount of time you expected.
Define milestones. For instance, in my career plan, by the end of this year I'd like to have been accepted in a Master's programme in my hometown. Next year, I'd like to try a summer internship in a nice company, and so on and so forth. That way you can evaluate if you're moving towards that goal or away from it.
Don't get stressed if things go out of your plan, there's always chance to either recover the time lost or to change your plan altogether.

Defining where you'd like to be in x years, 2x years, 3x years and etc is a great way of having some baseline to compare yourself with. That way you'll know if you're making progress in your career and you won't have to worry if anyone else is making more or less progress than you because the only progress that will matter is yours. After all your career is shaped by you.

I hope this can help other people not to feel so anxious (like I used to feel, and honestly still feel sometimes) about the way their careers are going.

Android Dependency Injection with Koin

Levi Albuquerque — Mon, 25 Feb 2019 20:07:30 +0000

Dependency Injection, or DI, is a design pattern/technique as old as time itself. You've probably heard it a couple of times during your career and it always comes up in the list of "good practices" when developing Android apps, but why is that?
Let's first understand a bit of what DI is and how it was done in Android and then we can have a look at how Koin approaches the idea.

What is DI?

Dependency Injection consists in simply providing the dependencies needed by an object without creating them within the object itself. As the name says we'll inject that dependency somehow into the object. I know, it sounded a bit confusing, let's see an example:

Let's say you have a repository class in your app that you can use to access your api service. You could create your class as such:

class MovieRepositoryImpl() :
    MovieRepository {
    val tmdbService = TmdbApi()

    override fun getMovies(page: Int): Single<TopMovieListResponse> {
        return tmdbService.getTopMovies(page = page)
    }
}

This however imposes a strong coupling between the service class and the repository, you're creating the service within the repository. How would you go about unit testing the Repository? You can't test just the repository because the service is there and you can't control how it behaves. Dependency Injection favors and helps us to create a mindset to enable writing testable code. We could modify the code and provide the service dependency when we create the repository, through the constructor:

class MovieRepositoryImpl(val tmdbService : TmdbApi) :
    MovieRepository {

    override fun getMovies(page: Int): Single<TopMovieListResponse> {
        return tmdbService.getTopMovies(page = page)
    }
}

Now when we try to test the repository we can provide a mock instance of the service and we can correctly unit test the repository. This is still not DI per se, but rather an approach to coding that enables us to do it later. We can write code that makes DI easier (and makes testing easier) providing dependencies in various manners:

Constructor Injection: This is the preferable way of organizing your code, we should try to always provide dependencies at the moment of creation of an object. This however can become a bit messy if there are a large number of dependencies.
Field Injection: This type of injection requires some type of harness that will populate the field with the desired dependency. This makes testing a bit harder, but if we make use of a DI framework (more soon) we can choose how this field is populated and we can provide mocks to be injected in them.
Method Injection: We can make use of a setter method to provide the right dependency. By using a setter method, however, we can end-up with an object that is in an invalid state.

What is a DI Framework

A DI framework is nothing more than a tool to help you organize how DI is done in your code. Depending on the framework you'll need to follow some steps in order to create a new class. By using a DI framework we can leverage from both constructor and field injections in a more organized way that enables us to develop a more decoupled and testable code. A very famous DI framework used in Android is Dagger, more specifically Dagger2 the latest version of it. About Dagger2 I have one thing to say:

The learning curve for Dagger2 is pretty steep and you can find many series online explaining how to setup Dagger2 in your project. The first configuration is always the toughest, after that Dagger is easily extendable and adding new dependencies is as easy as adding arguments to a method. For the purposes of learning how to apply Koin you'd need some idea of how Dagger works, specially the idea of Modules and Dependency graph.

Module: A module is a central place where you can tell the framework how to create new instances of a dependency. You can add a variety of configurations in this module to help the framework decide how the new instance will be created. This is how a module looks like in Dagger2 for instance:

@Module
abstract class MainProfileModule {

    @Binds
    abstract fun provideView(
       view: MainProfileFragment
    ): MainProfileContract.View

    @Binds
    abstract fun providePresenter(
       presenter: MainProfilePresenter
    ): MainProfileContract.Presenter

    @Binds
    abstract fun provideDataHandler(
       dhandler: MainProfileDataHandler
    ): MainProfileContract.DataHandler
}

Dependency graph: It's an "imaginary" (in memory graph) that the framework uses to keep track of where the dependencies are injected.

Koin

This is Koin as stated by the creators:

A pragmatic lightweight dependency injection framework for Kotlin developers. Written in pure Kotlin using functional resolution only: no proxy, no code generation, no reflection!

Here's some differences between Koin and Dagger:

Dagger2 is written in Java, Koin is purely kotlin so it looks more natural when used with Kotlin.
Koin works as a Service Locater masked as Dependency Injection (if that makes any sense)
Koin does not generate code == smaller build time
Koin requires more manual configuration as opposed to using Annotations like Dagger2.

This all means a nice kotlinesque alternative to Dagger2. This doesn't mean we should start replacing Dagger with Koin in every project we start from now on. Dagger is very powerful and once you get past the initial setup, it's quite easy to use. Koin is just another option to managing dependencies in a nice organized way, if you'll use it or not it will depend on your needs.

To add Koin into your project just add the dependencies to your app level build.gradle file:

    implementation "org.koin:koin-android:${koin}"
    implementation "org.koin:koin-android-viewmodel:${koin}"

Usage and Configuration

The project I'll be using to demonstrate the use of Koin can be found here. It's a simple app that shows the top rated movies from the TMDB API. Here's a peek of how it looks like:

After I've setup most of the classes in my code (keeping in mind the DI mindset) I've started writing my modules. I've started with the network module where I keep all network related injections.

Some observations from the gist:

means we need this instance to be a singleton. If you'd like to create a new instance every time the dependency is needed you can use "factory" instead.
When defining how/what type of instance you'd like koin to create you can specify a name and therefore have a named instance. This exists in Dagger through the @Named annotation and is specially useful if you have many instances of the same type.
If you'd like Koin to provide an instance for you when creating another instance you can use the get() method and pass an optional name if it is an named instance. Koin whill locate the instance and inject it when creating this new object.

I've also created a separate module to concentrate all "Movie" related object creation:

In this gist you can see one of the nicest things about Koin. It has support for Arch Components, specially ViewModel. When I tried to use Dagger2 and ViewModel I had to inject a ViewModelFactory and from that create my ViewModel, in here we need only to declare it as a and it will be easily injectable in our activity:

val movieViewModel: MovieViewModel by viewModel()

If your object is not a view model it can easily be injected as well, just use either inject() or get():

// Property Injection
val myRepository: MovieRepository by inject()

// Direct instance request
val myRepository: MovieRepository = get()

The last piece of configuration that we need to do is to initialize Koin. This needs to be done in the onCreate method from your Application class:

startKoin(this, listOf(appModule, networkModule, movieModule))

And simple as that all pieces are connected and you've created an easily testable app with decoupled dependencies :)

Being fishy with Android - Background work

Levi Albuquerque — Mon, 18 Feb 2019 16:13:58 +0000

Here I am again talking about threads and processes and background stuff :)

One of the first things you learn when doing Android (or even iOS) is to keep heavy load processing off the Main Thread. The Main Thread is too busy drawing those beautiful animations you love seeing and it doesn't like being stopped to do mundane things such as network requests. It will complain, mark my words.

There are many ways of doing background work in Android, many APIs have been developed (and deprecated, right Loaders?) and it's always good to remember who they are and when they can help you. This is going to be very quick, I promise :)

AsyncTasks

Let's start with the first one you've heard about, AsyncTasks. You hear about it first because it's one of the easier APIs to run work off the Main Thread and then easily publish the results of such work back to it. The usage is quite straightforward. I'll use the canonical example of an AsyncTask that performs a download operation whilst showing a progress bar. First, you have to think about three things:

1 - The input type of the task you want to run. For me, I'll take an array of URL instances which contains the Urls for the files I wished to download.
2 - The type of intermediate output you'd like to show. In my case that's an integer representing the percentage of the files that has been downloaded so far so I can update my progress bar.
3 - The third thing you need to think about is the type produced by your task. In my case it will be a Long because I'd like to know how many bytes were downloaded at the end of the task.

class DownloadFilesAsyncTask : AsyncTask<URL, Int, Long>() {

    override fun onPreExecute() {
        showProgressBar()
    }

    override fun doInBackground(vararg urls: URL?): Long {
        var downloadedSize: Long = 0
        var filesToDownload = 0

        for (i in 0 until filesToDownload) {
            downloadedSize += downloadFileWithSize(urls[0])
            publishProgress((i / urls.size * 100))
        }

        return downloadedSize
    }

    override fun onProgressUpdate(vararg values: Int?) {
        setValueInProgressBar(values[0])
    }

    override fun onPostExecute(result: Long?) {
        closeProgressBar()
        showDialog(result)
    }

This is a rather simplified version so you can get the idea: we've created a custom class that extends AsynTask. Usually you'll want to implement this as an inner class of the Activity that requires the task to be performed. Up top we've defined the three things we had in mind when creating this AsyncTask: the input type (URL), the Progress output type (Int) and the final output type(Long). From that we just necessarily need to implement one single method: doInBackground, but I've written some of the others so we could see all the capabilities:

onPreExecute will run in the Main Thread, this means you can access (touch) any view in the activity. Use this to prepare the UI for the task ahead.
doInBackground, as the name says will be run in a different Thread. You need to peform you work and return a value in the end. Here you can use the publishProgress to output a progress on your task to the UI.
onProgressUpdate is called anytime you call publishProgress inside doInBackground and this method is executed in the UI thread.
onPostExecute is called when your task finishes. Here you can show in the UI the final result from your task.

To use it, you must call it in the UI thread:

DownloadFilesAsyncTask().execute(urls)

AsyncTasks are nice and all but this tight coupling with the UI you gain with the easy way of using it can cause a couple of headaches when not cared for carefully. Just to mention one of them imagine if you start running a very long AsyncTask and the user rotates the device... You know where I'm getting at right? The activity will be destroyed, the AsyncTask will finish at some point and it'll try to access the views that no longer exist, boom! Your app crashes... So, be careful when using them. As the docs say: "AsyncTask is designed to be a helper class around Thread and Handler and does not constitute a generic threading framework. AsyncTasks should ideally be used for short operations (a few seconds at the most.)"

JobScheduler

As the name says this is the go to API for scheduling tasks in Android. Another option is AlarmManager which we'll talk a bit about later, but the JS APIs were launched in Lolipop therefore they contain far more interesting and complete methods for running tasks.

Usually we'd use JobScheduler in the following cases:

When we'd like to execute tasks within a certain system constraint. This means for instance that JS is ideal for when we'd like to run tasks only when the device is plugged or when we have wifi connection.
Tasks that can be deferred. The JS API will defer tasks for when is most appropriate to run them, this means that such tasks can't be time critical.
Periodic tasks.

The first step to use this API is to create an instance of JobService to handle your work.


class MyJobService : JobService() {
    override fun onStopJob(params: JobParameters?): Boolean {
    }

    override fun onStartJob(params: JobParameters?): Boolean {
    }
}

As this is a Service it will need to be defined in the Manifest file as well:

<service
   android:name=".MyJobService"
   android:permission="android.permission.BIND_JOB_SERVICE"/>

As you could see the JobService requires us to override two methods:

onStartJob: As the name says this method is called as soon as Android decides to start running our service. Note that the job will run on the Main Thread unless otherwise specified, that means you'll need to put any heavy lifting work on another thread. This method should return true if the job is to keep running. The job will keep running until you call jobFinished() or until any of the constraints you set to run the job can't be satisfied.
onStopJob: This method is called only when the service is cancelled before it's finished. This can happen because of multiple reasons, for instance, because the constraints it was set to run against can't be satisfied. If you return true in this method the job will be rescheduled.

Once you've implemented the service, the next step is to start the job. To do so you need to create a JobInfo instance through a builder. In this JobInfo you can specify any constraints that you might have to run this job, for example you can set it to run only when the device is connected to the power, or when it is connected to the WiFi.

 val componentName = ComponentName(this, MyJobService::class.java)
        val jobInfo = JobInfo.Builder(123, componentName)
            .setRequiresCharging(true)
            .build()

To finally schedule your job is quite simple:

 val jobScheduler = getSystemService(Context.JOB_SCHEDULER_SERVICE) as JobScheduler
        jobScheduler.schedule(jobInfo)

Please note that whilst the service is running, your app will keep a wakelock (will prevent the device from going to sleep). Therefore if you forget to finish it (either automatically or manually) it will drain your battery, so never forget to do so.

Firebase JobDispatcher

Did you notice something odd about the JobScheduler API? It was released for Lollipop+ devices, so we didn't actually had an option for scheduling background work for pre-Lollipop devices. Well, we didn't. The Firebase JobDispatcher library was created exactly for that reason. To use it we'd need to include the dependency:

implementation 'com.firebase:firebase-jobdispatcher:0.8.5'

We'd need to create an instance of JobService, like the one before, overriding similar methods. But we'll use the JobService from the library. We add the service to the manifest just like before:

<service
    android:exported="false"
    android:name=".MyJobService">
    <intent-filter>
        <action android:name="com.firebase.jobdispatcher.ACTION_EXECUTE"/>
    </intent-filter>
</service>

Things are a bit different when we need to schedule the job. First we create a dispatcher:

 val dispatcher = FirebaseJobDispatcher(GooglePlayDriver(context))

Then we use the dispatcher to both create the Job (here we can add constraints just like before) and schedule it:

        val myJob = dispatcher.newJobBuilder()
            .setService(MyJobService::class.java)
            .setTag("tag")
            .build()

        dispatcher.mustSchedule(myJob)

To cancel a specific job we simply call cancel on the dispatcher passing the tag we've set when we created the job:

dispatcher.cancel("tag");

AlarmManager

AlarmManager is as old as Android itself, this API is very useful for firing up tasks at a specific time, periodically. It should be used only when the task must execute at a specific time and you don't need the conditions that the JobScheduler provide. I won't be providing an example for it, but the official page is a great place to retrieve examples. WorkManager would be the best option to use in most cases, and AlarmManager is one of the composing APIs of WorkManager.

I'm not going to talk about Services or WorkManager because I'm dedicating different posts in the near future just for them :)

Three Continuous Integration options for Android Projects

Levi Albuquerque — Wed, 27 Jun 2018 19:22:40 +0000

Hello y'all :)

Since we last spoke I've been meddling with some pretty nice things. One of those is Continuous Integration options for Android projects. So I've identified three that can be used with various levels of setup difficulty, usage price and integration and I came up with a list of options that worked for me. Note that I had had experience with CI only in Django projects, besides I'm no expert in CI at all.

Quick reminder: Continuous Integration

Continuous integration is a great principle that helps projects evolve safely when considering a team of developers. This means that the devs can integrate the code they write continuously, this code is regularly "checked" for bugs (through tests written by the devs themselves) and helps detect bugs early whilst keeping everyone up to date. Usually CI practices involve setting up a CI Server responsible for checking the code that the devs write in order to detect bugs. You may be asking yourself how does it do that? Well, this involves a setup in the server as well as a mindset with the developers that use the tool:

We keep the code in a remote repository (Github, Gitlab, Bitbucket...). Well, everyone does that already...
The CI server is configured to "know" how to build and test the code. This is usually a script that mimics the commands we use locally to do those same things. For example, in Android when we want to run unit tests we usually do:./gradlew test. So our CI server "knows" how to run that command.
The CI server also knows about how to build and sometimes how to deploy the artifacts produced by the build (apks in the case of Android).
We usually commit code to the repo and the CI server, that knows about push events, will pull the code and run some pre-defined steps to run and build the code.
We should frequently push code (to keep the "continuous" part of the integration flowing)
We shouldn't push untested code, this means we should at least run the existing tests locally to see if our changes didn't break them. Ideally you need to add to the test suit whilst developing (TDD, right?).
We shouldn't push broken, half-finished or otherwise not built code.

Now with the options

Option 1 : Circle CI

The first option I'd like to talk about is Circle CI. It's very advertised due to its nice integration with Github. For free you get 1 container that will be able to run 1 "parallel" job. It's enough for testing and small projects so let's dive into it.

You'll see that with such tools the setup is quite similar, we need to add a configuration file to our project's base folder and all the CI setup is done in this file.

In the case of Circle CI this file is called ./circleci/config.yml. The structure is also somehow similar to other options, you can see the complete file here.
Basically, this files tells Circle CI the following:

1- Define a job step called "build"

jobs:
  build:
    working_directory: ~/code

2- Use the docker image circleci/android:api-28-alpha which contains all the Android SDK options for running command line builds/tests/deploys.

    docker:
      - image: circleci/android:api-28-alpha

3 - Define a series of steps that include making gradlew runnable, download the project dependencies, running linters, building and unit testing.

      - run:
         name: Chmod permissions
         command: sudo chmod +x ./gradlew
      - run:
          name: Download Dependencies
          command: ./gradlew androidDependencies
      - run:
          name: Run Unit Tests
          command: ./gradlew test
      - run:
          name: Run Linters
          command: ./gradlew check
      - run:
          name: Build
          command: ./gradlew assemble

Please note, this configuration file is a simplified version. We can add many steps to this build which include integration and UI tests, packaging and even deployment. This is just a simple example.

Once you've added the configuration file all you need to do is go in the Circle CI page and add a new project pointing it to your Github repo. This part is really straightforward so here's a picture of the builds when they're executed in their servers:

Once you integrate Circle CI you can add it as a dependence in your PR workflow, that way the tests will need to pass in the CI server before you can merge. It will show in your PR like this:

The image above is a great segway for our next option.

Option 2 : Gitlab

The next option is Gitlab. You can either host your complete project in their site and use the CI system, or you can use their integration with Github and use only CI option. If you choose the latter (which is the one I've tested for Android) the setup involves giving authorization to Gitlab to clone your repo and it will add a webhook (just like Circle CI) to monitor push events in the original repo.To finish our set up we'll add a configuration file just like we did with Circle CI, but this time our file is called .gitlab-ci.yml. Here's the complete file.

This configuration file was inspired by the one in this post. You can see that it's a bit similar to the one I used for Circle CI. The idea is the same:
1 - Define two stages, build and test. Also, tell Gitlab to use the java docker image:

image: openjdk:8-jdk

stages:
  - build
  - test

2 - The before_script is used to do configurations you'll run before the main purpose of each step. In the case of the build step we use the build.gradle file to identify the compile sdk version we'd need to use. We also define an environment variable called ANDROID_COMPILE_SDK that will be used to download the SDK files (this can be easily added in the CI configuration menu in Gitlab, under the option "variables"). The variable ANDROID_SDK_TOOLS is used to download other sdk files. In this script we also set up an environment variable called ANDROID_HOME pointing to the folder where we've installed the sdk tools. We add the folder to the container PATH so we can run its utilities in other places. Finally we made gradlew runnable.

before_script:
    - export ANDROID_COMPILE_SDK=`egrep '^[[:blank:]]+compileSdkVersion'  app/build.gradle | awk '{print $2}'`
    - echo $ANDROID_SDK_TOOLS
    - echo $ANDROID_COMPILE_SDK
    - wget --quiet --output-document=/tmp/sdk-tools-linux.zip https://dl.google.com/android/repository/sdk-tools-linux-${ANDROID_SDK_TOOLS}.zip
    - unzip /tmp/sdk-tools-linux.zip -d .android
    - export ANDROID_HOME=$PWD/.android
    - export PATH=$PATH:$PWD/.android/platform-tools/
    - echo y | .android/tools/bin/sdkmanager "platforms;android-${ANDROID_COMPILE_SDK}"
    - chmod +x ./gradlew

3 - For any branch, except for master, I'll call the command ./gradlew assembleDebug. If the push event happened in the master branch we call ./gradlew assembleRelease.

  script:
    - ./gradlew assembleDebug

  only:
    - master
  script:
    - ./gradlew assembleRelease

4 - For testing, if the push event happened in any branch, we'll call ./gradlew test.

unit_test:
  stage: test

  before_script:
    - export ANDROID_HOME=$PWD/.android
    - export PATH=$PATH:$PWD/.android/platform-tools/

  script:
    - ./gradlew test

Note that because we've set the artifacts of the build phase to expire only in 4 hours, our before_script for the testing phase didn't need to setup the SDK all over again.

Option 3 : Jenkins

Circle CI and Gitlab are the "easy" options, but that comes with a cost. For full on professional projects the free resources might not be enough and then we'd need to go into one of the paid plans. For that reason I brought the third option: Jenkins.

Jenkins is open sourced and the limit for its operation is set by the server where you're hosting it. Awn, yeah. It's "free" because you won't pay a licence to use it, but you need to host it somewhere, and THAT's not free. I've been using a t2-small EC2 instance and it's been working great.

Most of the tutorials I've find about this are a bit outdated, but the basic steps are listed below:

1 - Install the JDK in your instance, this is usually a simple command such as the one bellow. Moreover, install unzip because you'll need it later and git for using git commands in the CI steps.

sudo apt-get install java-8-openjdk
sudo apt-get install unzip
sudo apt-get install git

2 - Install Jenkins.
3 - Download the command line tools for Android, you can check which one is the latest here:

sudo -iu jenkins wget https://dl.google.com/android/repository/sdk-tools-linux-4333796.zip

4 - Create a folder to host the android sdk and unzip the sdk into it:

sudo -iu jenkins mkdir sdk
sudo -iu jenkins unzip sdk-tools-linux-4333796.zip -d sdk

5 - Accept the license:

yes |sudo -iu jenkins sdk/tools/bin/sdkmanager --licenses

6 - Install Platform Tools:

sudo -iu jenkins sdk/tools/bin/sdkmanager 'platforms;android-27'

Once you've gone through the steps you can start setting up jobs in your Jenkins dashboard. First we need to tell Jenkins where we've installed the SDK, this can be done by going into System Configuration in the Jenkins dashboard:

After setting the sdk folder we need to create a set of credentials so Jenkins can pull the code from our repository. You can go into the Credentials menu and under the Jenkins namespace click in Add Credential:

For username you can use your own Github username, the password is a bit different. You'll need to go into your Github account, under settings -> Developer settings options and select Personal token. You'll need to generate a token to be used by jenkins as the password for the credential.

After setting up the credential you can create the job. Go into new item in your Jenkins dashboard and select Freestyle project. In the following screen make sure you set up:

1- Github project

2 - Git repo, credentials and branches to watch for push events.

3 - Build trigger

Build triggers determine how our jobs will start running, for our case we want to detect push events from Github, so we select "GitHub hook trigger for GITScm polling".

For that to work you need to go into the settings for your repo and add a new webhook. Just fill in the payload URL option with: http://<JENKINS_HOST_ADDRESS>/github-webhook/.

4 - Build steps

Here we add two steps (by clicking in Add Gradle Script). Check to use gradlew wrapper and add the tasks assembleRelease and test. Don't forget to check the box to make gradlew runnable.

Woof. That's a lot to configure isn't it? I guess that's why they've come up with Blue Ocean... After that your jenkins setup is ready to receive push events and build/test automatically.

So, to sum it up:

Circle CI is great for its integration with Github, from what I've seen in the docs it is pretty versatile with a wide range of options to cover most CI scenarios out there. Gitlab is also very good, but there's somehow an overhead if you want to integrate it with Github, it feels less natural than Circle CI, but still very functional. I believe if you host your code with them, then it works really well (I've been working in projects where the code is hosted in Gitlab and we use the CI option almost seamlessly). Jenkins is perfect for customization, it offers the greatest flexibility, but there's a learning curve to understand how it works and the interface is less intuitive than the other two.

I guess that's it :) These are only my points of view from a small amount of time dedicated to exploring these tools. From those three I've only been working regularly with Gitlab so I can vouch for it, the other two, well, you've read my opinions... Also, these are NOT the only options out there, other famous option is Travis CI for instance.

I "Love" Anti-patterns

Levi Albuquerque — Sat, 09 Jun 2018 19:08:40 +0000

Everyone talks about design patterns, but getting to know the other side of the force can be as enlightening as visiting the old good friends. I don't like to produce them, of course, but rather learning about them. As developers we're always trying to improve ourselves, but to be able to improve we need to make mistakes and some of these are mistakes we make during our careers. Getting to know the most common ones can help us steer clear of them. Here I present a top 5 with my favorite ones :)

5 - Big ball of mud

This is a nice way of referring to a piece of code that doesn't have a clear architecture. Many of us are guilty of producing balls of mud in the beginning of our history with a technology. I remember when I was beginning with Android writing a lot of code inside the Activity and hoping for the best. Some symptoms that you have a BBM:

A lot of repeated code
Data is completely decentralized, appearing in many locations and many times repeatedly
The code looks like it's been patched many times by many different people.

The original term was coined by Brian Foote and Joseph Yoder and it says:

A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle.

This is easily remedied with the use of an architecture, or a minimum level of organization in our code.

4 - Design By Committee

A.K.A : Gold Plating, Make Everybody Happy
Gold Plating is the foe of perfectionists. It's simply wanting to add more and more features, even tough the product is ready. It's also all about being too elaborate or complex without needing to be so. Some symptoms that this is happening:

Meetings are taking excessively long time and don't feel like grasping the important aspects of the project:
Design development costs more and takes more time than initially planned.
Overly designed feature beyond the scope of the client's requirements.

To keep things on track: the duration of the meetings and the sticking to the requirements are essential.

3 - Cargo cult programming

Have you ever joined a cult? Was it fun? Or did you spent most of the time not knowing what actually was going on there? (insert awkward face)

Well, that's basically what cargo cult programming is. You've just heard of a new tech, process or tool and you simply want to join in the hype even though you know nothing about it. Usually, this happens when we're young and fresh in our trade, but sometimes more experienced developers are guilty of joining in. Some symptoms this is happening around you:

Use of technologies just because it's "trendy" without evaluating the costs of implementing it
Copy-and-paste programing

2 - Lava flow

You know that room in your house where the messy stuff lives. Or even that pile of clothes that gets shifted around in your room and that would be much better off organized inside your closet? Those are your own personal lava flows :)

Lava flow is that piece of code that gets shifted around in our projects just because we don't want to think about all the work it would take to get rid of it. You know it's useless, ugly and potentially buggy. But the stress of working on it puts you off from the necessity of striping your project off it. Sometimes it's code you didn't even write and you're like 99% sure it's not used anywhere. But that 1% keeps you from cleaning it up.

Some symptoms that you have this in your project are:

There's a part of the code where nobody likes to go.
Some bits of the code look important and "might" be used somewhere else.
You refer to some bits of your code as "that part that (insert the name of a previous colleague) did, it probably serves a purpose, probably...(awkward pause)"

1 - Copy and paste programming

We've all done this once(and still do) and I'm not saying it's wrong copy and pasting from other sources. Code reuse is a primary topic and foundation in our trade. We can't reinvent the wheel every time we need to add a new feature to our app. The world is huge and many things have been tried, tested and done, so why not reuse what's out there?

The problem rises when we overdo it, or do it without thinking. Copy and paste solutions without analyzing the impact of them in our code or in the overall architecture of the project is bound to cause many headaches down the line. Some of the symptoms this is happening in your project are:

You see the same bug repeating itself, even tough you've fixed it somewhere else.
Your code starts looking like a piece of (literally) patchwork.
Some parts of your code become obscure as you don't actually know how they work.

A culture of quick-fixes rather than code quality can stimulate such Anti-Pattern. A simple fix for this is to create a culture of code reuse that stimulates analysis over speed.

Most of the patterns here are discussed in depth here
That's it, I hope you guys enjoyed the reading :)

A word on Android Threading

Levi Albuquerque — Sun, 03 Jun 2018 15:15:44 +0000

A couple of days ago I saw a question o StackOverflow asking: "Where is the main method in Android?". I thought to myself, that's a very interesting question and I think I'll write something about it alongside with other threading stuff. Yeah, the fact that we don't see the main() method in Android has everything to do with threading.

Where are you, main?

Let's start with the question above. Where's the main method in Android?
Well, as any java application, the entry point is the main method and, even tough we don't see it, every app starts off from a main() method just like other java apps. The class that holds it is the ActivityThread:

The ActivityThread is responsible for:

Preparing the Main Looper - That is the Looper (more on that later) where the MainThread will be run.
Designating a special Handler to this Main Looper
Starts the Main Looper (by calling its loop() method).
A whole lot of other stuff...

This is basically saying that the ActivityThread will designate a class to execute the many methods necessary to render the UI of your app and keep it running.

And now you may be asking yourselves: Ok Levi, but you didn't mention how my main activity get's called. You just talked about a thread that is responsible by managing UI stuff

And I'll tell you: Calm down, we'll get to that

Inside the ActivityThread.java file (it's a huge file) there is another class called simply H that extends the Handler class and it was used before when we designated a special Handler to the Main Looper. This class is used extensively throughout the ActivityThread because it's a special Handler that deals with the possible states that our (or for that matter any other app in Android) can be.
Every handler has a nice little method called handleMessage and this special handle's method looks like this:

public void handleMessage(Message msg) {
            if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + msg.what);
            switch (msg.what) {
                case LAUNCH_ACTIVITY: {
                    ActivityClientRecord r = (ActivityClientRecord)msg.obj;
                    r.packageInfo = getPackageInfoNoCheck(
                            r.activityInfo.applicationInfo, r.compatInfo);
                    handleLaunchActivity(r, null);
                } break;
                ....

This is just a small portion of it of course, it's a huge switch handling every different state. But in this portion we can see it handling the LAUNCH_ACTIVITY case. In there it calls the method handleLaunchActivity() which in turn calls the performLaunchActivity() method.

 private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent) {
 ...
        Activity a = performLaunchActivity(r, customIntent);
 ...
 }

The latter is very important because it adds a bunch of known structures we're used to simply use in Android such as Application, Context and Intent. It also calls the mInstrumentation.callActivityOnCreate() that will, guess what, call our darling onCreate() method in our main Activity.

So, it's a long path from main() to onCreate() to sum it up:

ActivityThread's main gets executed
The UI Thread is set up with its Looper, special Handler and etc.
The Special Handler initiates the process of creating the Activity object
The Activity object is created with associated properties
The onCreate method is called.

Magic words: Handler, Message, MessageQueue, Looper

Now, we've talked about how we get from main() to onCreate() and we've used some pretty words like Handler and Looper and when you're developing an app you rarely see these in code (maybe a Handler here and there, but a Looper is quite rare, unless you're dealing with dark stuff like low level multi-threading). We see these quite frequently though when our app crashes:

That happens because they are the foundation of how android performs multi-threading. Let's start with some definitions:

Looper

A Looper is a low-level class responsible for executing a message loop for a thread. If you take a look at the implementation of the loop() method in this class, this becomes quite clear:


for (;;) {
            Message msg = queue.next(); // might block
            if (msg == null) {
                // No message indicates that the message queue is quitting.
                return;
            }
}

It's an infinite loop that reads messages from a MessageQueue and execute them. Funny thing is when I was in college we used to meddle with threads by putting them in an infinite loop. I guess that was useful now, right? Also, we loop through a thread because there is an overhead associated with creating Threads in java which can be diminished if we reuse some of the threads. Threads are meant to run once and be gone, but with a loop we can keep them around for more time.

MessageQueue

A MessageQueue is simply that, a queue that gives messages. Not much else to say.

Message

A Message is a special wrapper class that wraps some data that can be exchanged between threads.

Runnable

A Runnable in simple terms is a wrapper for a piece of work you wish to perform (a task, for lack of a better word).

Handler

A Handler processes messages (or Runnables) and schedule their processing to a Looper, that is, it receives messages and it also add messages to/from the MessageQueue associated with it. A handler is associated with a thread only and its MessageQueue, but a thread can have (and it usually does) multiple handlers.

handler.sendMessage(msg); //adds to the MessageQueue

handler.post(new Runnable() {
    @Override
public void run() {
        // this will run in the MQ thread
    }
});

public void handleMessage(Message msg) {
        // process messages from the MQ
    }

So, how do they connect together?

A Handler dealing with a Message or a Runnable (units of work in Android) adds one of them to a MessageQueue that is associated with a Looper and a Thread. The Looper keeps the Thread alive looping through them and asking a Handler to execute the messages it pops from the MessageQueue.

We usually don't create these classes by ourselves but rather use a HandlerThread that creates a Looper with a Thread automatically for us.

This is just an intro to a much more deeper and complex subject (not only in Android) but I hope it was useful to someone out there :)

Smiley faces with MLKit :)

Levi Albuquerque — Sun, 20 May 2018 17:09:26 +0000

So Google I/O was last week, very exciting and all and this week whilst preparing the sample app for this post I saw this on instagram that's a nice summation of the conference:

So Machine Learning, Machine Learning everywhere. And I don't blame them, ML is this "magical" tool that makes everything work so much better for humans.It takes a lot of effort, sometimes hours/days of "training", but the final result is, for instance, a virtual assistance that can set hair appointments for you and uses freakishnessly (is this even a word) realistic onomatopoeic sounds...

But let's focus on the matter at hand.

I love Firebase <3. I know sometimes it's a headache, but it has its uses and they're very versatile. You can either use all of them in one project or just some parts of it. For example, I'm currently working on an app that uses the Real Time Database, Cloud Functions and FCM to implement a chat feature. The rest is integrated with a different Backend, but for the chat feature we use Firebase and it works like a charm (with some caveats, of course).
This year, Google has added the MLKit beta version to Firebase with three "simple" key capabilities:

Ready to use APIs for common problems faced by ML users in real world applications such as: Text Recognition, Face Detection, Bar Code Scanning, Image Labelling, Landmark recognition
Possibility to use these models on-device and in the cloud.
You can deploy a custom model (if you have it ready in Tensor Flow Lite)

So it all looks quite interesting and in my mind this is how the conversation goes.

Google: Do you want to use Machine Learning in your app?
Dev: Yes, sir.
Google: Here are some ready-to-use APIs. If you use the horse-power in your phone to run the model, you won't have to pay anything. Now, if you want to use our machines in the cloud, then let's see those green bills..
Dev: These models don't work for my specific problem.
Google: Okay, then write one using our other product and you can deploy using this product.

You might be saying now, please just show me the code...
The example I'm going to use in this app is a very simple smile detector. I'm an Android Dev so I'll use Kotlin because:

First thing, dependencies:

dependencies {
...
    implementation 'com.google.firebase:firebase-core:15.0.2'
    implementation 'com.google.firebase:firebase-ml-vision:15.0.0'
...
}

Pretty simple, just Firebase Core and ML-Vision.

The method bellow is the one I used after acquiring the image. In order to process your images you need to convert them to an object that the API understands, in this case a FirebaseVisionImage:

   private fun faceDetect(image: Bitmap) {
        val firebaseImage = FirebaseVisionImage.fromBitmap(image)
        val detector = FirebaseVision.getInstance().getVisionFaceDetector(firebaseOptions)

        detector.detectInImage(firebaseImage)
                .addOnSuccessListener {
                    processFaces(it)
                }.addOnFailureListener {
                    it.printStackTrace()
                    Toast.makeText(this, "Something bad happended. Cry in a corner.", Toast.LENGTH_SHORT).show()
                }
    }

In this method I use a bitmap (for simplicity) to create the FirebaseVisionImage but you can use other formats like byteArray, byteBuffer, filePath, mediaImage. Also, to create the detector which will be used to actually classify our images you need an instance of FirebaseVisionFaceDetectorOptions to configure your detector. The one I'm using looks like this:

val firebaseOptions = FirebaseVisionFaceDetectorOptions.Builder()
                .setModeType(FirebaseVisionFaceDetectorOptions.ACCURATE_MODE)
                .setLandmarkType(FirebaseVisionFaceDetectorOptions.ALL_LANDMARKS)
                .setClassificationType(FirebaseVisionFaceDetectorOptions.ALL_CLASSIFICATIONS)
                .setMinFaceSize(0.15f)
                .setTrackingEnabled(true)
                .build()

Here I set the mode type to ACCURATE_MODE meaning I want to favor accuracy over speed. The landmarks type is set to ALL_LANDMARKS because it improved pose estimation. The classification is set to ALL_CLASSIFICATIONS because I need it to detect the smiling feature in images. The min face size tells what's the smaller face it will be able to detect, I've set this to 15% of the size of the image. Enabling tracking helps us keep track of the faces that had be found so far (if the model is presented with multiple images).

Everyone who uses Firebase knows that most async APIs there work under Task objects. It's no different here, we attach a listener to receive the result of the detection when it completes successfully and another for when something wrong happens and you should shed a tear...

As a result you'll receive a list (filled or not) with "Faces" that you can check many properties in. For example, you can call getBoundingBox() to check the location of the face within the image, or getSmilingProbability() which is the probability (from 0.0 to 1.0, if -1 it didn't find a smile) of this face to be smiling.

For me I'm simply doing this:

private fun processFaces(faces: List<FirebaseVisionFace>) {
        if (faces.isEmpty()) {
            Toast.makeText(this, "Is there a face here?", Toast.LENGTH_SHORT).show()
        } else {
            for (face in faces) {
                if (face.smilingProbability != FirebaseVisionFace.UNCOMPUTED_PROBABILITY) {
                    val smileProb = face.smilingProbability
                    if (smileProb > 0.5) {
                        Toast.makeText(this, "Smily face :)", Toast.LENGTH_SHORT).show()
                    } else {
                        Toast.makeText(this, "Not a Smily face :(", Toast.LENGTH_SHORT).show()
                    }
                } else {
                    Toast.makeText(this, "Is there a face here?", Toast.LENGTH_SHORT).show()
                }
            }
        }
    }

So for each face it finds it will check if the probability of a smile is larger than 0.5 (I could use a larger number), if so then it shows a smiley toast :). If not :(.

So as a tool for speeding up development of ML models in mobile apps I reckon ML Kit does a decent job, I've written this app in a couple of hours and only because I was worried the UI was too ugly (it's still is lol). The built-in models are quite accurate (from what I've tested) and (not tested by me) the custom models are a great option for very specific applications. Let's see how much the usage and the tools will evolve in the next few months...

That's it, I hope you liked this post because it was a lot of fun writing it ;)