Annyce Davis

Davis Technology Consulting

Talk: RxJava in Baby Steps

by

Reactive Programming with RxJava has widely been adopted by both backend services and Android applications alike. Yet, the steep learning curve leaves many developers hesitant about adding it to their own Software tool belt. I was one such developer. Over the past two years, I’ve watched countless videos, read numerous blog posts and attended several conference talks on the subject. Yet, I often left each experience feeling only slightly more knowledgeable, but not quite empowered to start using RxJava in my apps. That’s not going to happen in this talk!

We cover the bare minimum concepts you need to grok, in order to start using RxJava today. In particular, we focus on:

  • The 3 O’s: Observable, Observer and Operator
  • The most common Operators: map(), flatMap(), and filter()
  • Understanding those Marble Diagrams

Reactive Programming is not going away any time soon. It’s a powerful way to create asynchronous, event-based applications. It allows developers the ability to craft applications that can easily combine multiple network calls, gracefully handle failures, all while providing a snappy user experience. I want everyone to feel comfortable with the basic concepts of RxJava. Today can be your first step…

 

Resources for Learning More:

Learning RxJava for Android Devs

by

One of my goals this year was to learn RxJava. Similar to my goal of going to the gym, I procrastinated a bit.


However, I have recently been digging deep into RxJava, especially as it’s used in Android applications. Figured I’d share some of the resources I’ve come upon to help others in their reactive journeys.

Resources:

What have you found useful? Share in the comments. Thanks!

Android Devs Listen Up!

by

So listening to podcasts used to be the “thing”, then it wasn’t the “thing” anymore, and now it’s back to being the “thing” to do.  So with that in mind I thought I’d share some of my favorite podcasts for Android developers.

Fragmented

So Fragmented is a podcast for Android Developers that focuses on providing information about the trends in Android Development and the best tools available to produce quality applications.  What I like about this podcast is that the hosts are actual developers responsible for building and maintaining apps that are in the wild, so it lends credibility to the advice that they provide.
 
Favorite Episodes So Far:

Android Developers Backstage

Android Developers Backstage is also focused on Android as the name implies, however it is hosted by two Google employees.  So it allows you to hear the motivation behind some of the platform decisions and get a better understanding of how Google intended for certain APIs and tools to be used by developers.
 

Java Posse

Finally, I leave you with the Java Posse podcast. I only just discovered this one and unfortunately they are no longer making any new episodes. However, the archives are still available and they are full of great content for Java developers.  Each and every episode that I’ve heard so far has left me with at least one idea that I can use to continue growing as a Java developer.
 
Favorite Episodes So Far:
 
Unfortunately I don’t know of any technical podcasts where the hosts are women, so if you do, please leave me a comment below. Thanks!

Conquering Cyclomatic Complexity

by

Have you ever received a warning about Cyclomatic Complexity while working with a class in Android Studio? Would you like to know how to fix it?  If yes, keep reading…

What is cyclomatic complexity?


Here is a definition from Wikipedia:

“The cyclomatic complexity of a section of source code is the number of linearly independent paths within it. For instance, if the source code contained no control flow statements (conditionals or decision points), such as IF statements, the complexity would be 1, since there is only a single path through the code.” — Wikipedia

Ok, so that particular definition is a tad verbose, but it’s essentially saying that the more control structures (if, else, switch, etc.)  you have in your code the more you introduce complexity into your program.

Why is high cyclomatic complexity bad?


Short answer, it can make it more difficult to write unit tests that cover all possible branches of a given function as well as hinder debugging efforts. Others argue that it affects the readability of your code, making it more challenging for another developer to understand the intent of your functions and/or classes.

How do you fix it?


You start by reducing the number of paths through any given function.  Let’s take a look at a very contrived example.

public void overlyComplexMethod(Video video) {
    if (video != null && video.getStreamUrl() != null) {
        switch (video.getCategory()) {
            case "CAT1" :
                playVideo(video);
                if (video.getLargeImageUrl() == null) {
                    video.setLargeImageUrl("http://www.largeImage.png");
                }
                updateMetadata(video);
                break;
            case "CAT2" :
                if (video.getLargeImageUrl() == null) {
                    video.setLargeImageUrl("http://www.smallImage.png");
                }
                updateMetadata(video);
                break;
            case "CAT3" :
                if (video.getLargeImageUrl() == null) {
                    video.setLargeImageUrl("http://www.mediumImage.png");
                }
                updateMetadata(video);
                break;
            default:
                break;
        }
    }
}


This function has several different paths through it, notice the use of a switch statement with several cases and within the cases more if statements. The cyclomatic complexity of this method is 9, ideally you would want to have most functions with a value of 8 or less.  So let’s clean it up!

First we’re going to move the switch statement into its own method.

public void overlyComplexMethod(Video video) {
    if (video != null && video.getStreamUrl() != null) {
        updateVideoBasedOnCategory(video);
    }
}

private void updateVideoBasedOnCategory(Video video) {
    switch (video.getCategory()) {
        case "CAT1" :
            playVideo(video);
            if (video.getLargeImageUrl() == null) {
                video.setLargeImageUrl("http://www.largeImage.png");
            }
            updateMetadata(video);
            break;
         case "CAT2" :
            if (video.getLargeImageUrl() == null) {
                video.setLargeImageUrl("http://www.smallImage.png");
            }
            updateMetadata(video);
            break;
         case "CAT3" :
            if (video.getLargeImageUrl() == null) {
                video.setLargeImageUrl("http://www.mediumImage.png");
            }
            updateMetadata(video);
            break;
          default:
            break;
    }
}


By making this simple change we’ve already reduced the complexity down to a value of 7. The next step would be to look for code duplication among the case statements and then create one method that they can all share.  Let’s see how that might look…

public void overlyComplexMethod(Video video) {
    if (video != null && video.getStreamUrl() != null) {
        updateVideoBasedOnCategory(video);
    }
}

private void updateVideoBasedOnCategory(Video video) {
    switch (video.getCategory()) {
        case "CAT1" :
            playVideo(video);
            updateVideoMetaDataAndUrl(video, "http://www.largeImage.png");
            break;
        case "CAT2" :
            updateVideoMetaDataAndUrl(video, "http://www.smallImage.png");
            break;
        case "CAT3" :
            updateVideoMetaDataAndUrl(video, "http://www.mediumImage.png");
            break;
        default:
            break;
    }
}

private void updateVideoMetaDataAndUrl(Video video, String url) {
    video.setLargeImageUrl(url);
    updateMetadata(video);
}

Now by extracting out this common method, updateVideoMetaDataAndUrl, we have reduced the cyclomatic complexity to 4. We could reduce this further by eliminating the need for a switch statement with polymorphism.  I leave that to you as an exercise.

Conclusion


As we can see it’s a simple refactoring effort to reduce the cyclomatic complexity of methods and by extension classes.  I would however like to mention that having unit tests in place before you begin the refactoring is ideal to ensure you don’t make any breaking changes.

If you want to learn more about writing clean code, I highly recommend the book Clean Code by Robert Martin. 

Follow Me

  • Bluesky