Annyce Davis

ones and zeros

Fall in love ❤️ with Android Studio all over again

by Leave a Comment

I still remember that day back in May of 2013. I was sitting in Moscone Center, eager to hear what Google had to announce at its annual Google I/O conference. And then it happened. Android Studio was announced. The crowd went wild. And I joined the hundreds of other conference-goers in an attempt to download the brand new app over the conference wifi.

Fast forward to today, it’s been ten years, and Android Studio continues to deliver on its promise. We are both faster and more productive as app developers due to its existence.

So in honor of its ten-year anniversary, here are ten features that will make you fall in love ❤️ with Android Studio. In no particular order…

Feature 1: Based on IntelliJ IDEA

The beloved IntelliJ IDEA IDE is a fan favorite for developing, debugging, and refactoring Java and Kotlin applications. Its massive plugin ecosystem, smart code suggestions, and intuitive navigation make it a joy to develop with. Having Android Studio built on this foundation was a brilliant decision.

Feature 2: Editor Margin

Next up is the editor margin. You can learn a lot about a line of code by paying attention to the margins. For example, you can see which line of code is causing crashes from Android Vitals. Understand that a given line of code is going to execute asynchronously. See the color represented by a resource id. And much more. A true time-saver.

Feature 3: String Previews

String Previews allows you to see a preview of how your text will look in your app before you actually build and run it. It’s one of those little things that makes Android Studio a delight to use.

I’m often in and out of various codebases; this feature helps me to understand quickly the purpose of a given screen or composable.

Feature 4: Android Vitals

I no longer have to jump back and forth between Chrome and Android Studio to debug reported crashes. Android Vitals has entered the building in the latest release. I use Android Vitals to help improve the quality of our app on Google Play.

Since this is the data that Google is using to determine how our app is performing in the store. It’s “vital” to pay attention to these metrics and debug reported issues.

Feature 5: Firebase Crashlytics

Another feature that helps improve app quality is the Firebase Crashlytics integration. You can watch me geek out about it in the video below. It’s the convenience of having this critical information in your IDE that makes it a game-changer. You can go directly from a stack trace to the line in the code that caused the issue. If you’re not using it yet, do give it a try.

Benefits of App Quality Insights

Five more features to go. In love yet?

Feature 6: Logcat

Despicable Me Fun GIF - Find & Share on GIPHY
Me fighting with Logcat

Logcat and I were not the best of friends. It was a struggle to do the most basic things:

  • filter out unwanted logs
  • search for specific words
  • copy the message text

And then Logcat got a serious upgrade. 😎 Not only can you do all of the basic things faster, they’ve added new features. Here are my favorites:

  • the age filter to restrict log messages based on their timestamp
  • ability to quickly create a Scratch file from JSON
  • ability to fold log messages that you’re never interested in
  • the built-in color scheme that makes it simple to parse the logs

If you’ve been frustrated with Logcat in the past, time to give it another try.

Feature 7: Android Emulator

Android fragmentation: multiple devices, multiple versions, multiple headaches. What’s a developer to do? You can’t install all the things. Enter the Android emulator. The emulator ships with tons of functionality. I run and debug all of my apps on it and use it to capture screenshots and videos. You can change the location, language, battery strength; the list goes on and on. It’s the Swiss Army knife of Android Studio.

Feature 8: Layout Inspector

The Layout Inspector helps you figure out what’s going on with your app’s layout while it’s running. You can see the view hierarchy and check out the properties of each view. It’s perfect for spotting layout issues and unexpected behavior, especially for dynamic layouts.

One of the aspects that I appreciate is the ability to isolate a single view. Our app has complex layouts. It’s helpful to view only a subset of the views when debugging. Then if you want, you can go directly to the code where it’s defined.

Feature 9: App lnspection

The Network Inspector shows you what’s happening with your network in real-time. You can see the data being sent and received on a timeline. I use it to debug API responses being made from my apps. Specifically, I find it easier to inspect the headers and responses in this view over Logcat.

Another feature of the Network Inspector that was new to me is the Rules tab. It lets you change your API responses – status codes, headers, and bodies. To create a new rule, give it a name and say where the response comes from. Then, say what you want to change in the response. I use it to test how my app’s UI behaves when receiving bad responses.

Feature 10: Studio Bot

The newest kid on the block is Studio Bot. Since AI is everywhere, why not in Android Studio? 😅 I was skeptical at first. However, I find that it’s useful for my many Jetpack Compose questions. Keep in mind, however, that it’s still experimental. This means that occasionally it spits out some invalid code.

I believe there’s a solid future for Studio Bot. The conversational style and the ease of including recommended code snippets make it a real contender in the IDE AI wars.

Conclusion

Overall, Android Studio provides developers with a powerful set of features that enhance productivity, streamline development, and enable the creation of high-quality Android applications.

So, what are you waiting for? 👀 Download the latest version of Android Studio today. 😍

Bash Scripting for Flutter Tests and Code Coverage Reports

by Leave a Comment

Do you have a development task that is mostly a series of commands? Do you have to perform that task on a regular basis? If so, a script might be just what you need. Over the years I’ve wanted to learn bash scripting several times. Yet there’s always something else that takes priority and my desire to script takes a back seat. Not any more!

I finally decided to start learning how to write bash scripts and I want to share it with you in case you’d like to do the same. At the bottom of this post, I’ve listed several resources that I’m using to help me on this journey. If you’re an Android developer, you can use Gradle to handle many automated tasks. If you want to learn about Gradle on Android or how to create a Gradle plugin, check out my course here.

On to the script. It does the following:

  • Runs the unit and widget tests for a Flutter application
  • Generates a code coverage report
  • Removes the unwanted files from the coverage output
  • Converts the coverage data to HTML
  • Opens the HTML page in your browser

I’m going to break down what each section of the script does so that you can start having fun creating your own scripts! (This post assumes you are already familiar with programming and related concepts.)

Continue Reading

Google I/O 2016 Recap

by Leave a Comment

This was my second time attending Google I/O and it was once again a great experience. I put together a few highlights of the event below:

Venue

So the event took place at Shoreline Amphitheatre in Mountain View, California. It was my first time in Mountain View and it’s such a beautiful city. On Day 1 of the conference it was a bit “toasty” outside so that proved to be challenging, but eventually the remaining days were pleasant and breezy. The majority of the talks took place inside tents and there tended to be a lot of interest on the part of attendees.

Attendees

For me one of the best parts of attending I/O this year was getting to meet so many of the people that I have interacted with online. Most of them were really cool people and managed to keep their spirits up despite putting up with the heat and long lines.

Takeaways

I was completely impressed with the updates to Android Studio. Some of the things that I felt would be nice to haves, like showing Gradle dependencies clearly or having the Espresso Test Recorder were released. Definitely one of the major highlights for me.
 

 

Something that surprised me though was how Firebase has become the de facto standard of all things mobile for Google. In fact, several products were renamed “Firebase X, Y, Z”. The following tweet summarizes it best:


 

Also there were several talks on developing applications for emerging markets. I especially enjoyed the one titled, “Building for Billions”. The speakers talked about the best strategies for making sure your application is always interactive and responsive for users regardless of network and memory conditions.

All in all, I am very thankful I was able to attend; I know that everyone doesn’t get this opportunity. I learned a lot, I drank a lot of coffee, and I met some awesome folks.



Make sure you subscribe to my newsletter to keep up with my Android Adventures. Until next year…

Conquering Cyclomatic Complexity

by Leave a Comment

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.