Annyce Davis

Davis Technology Consulting

  • Home
  • About Me
  • Blog
  • Courses
  • Newsletter

Jetpack Compose and the Speed of Thinking

February 22, 2026 by Annyce Davis

I wasn’t excited about Jetpack Compose. There. I said it.

When it first came out, it felt like Flutter in a different outfit. Kotlin instead of Dart. Same declarative energy. And look, I didn’t have anything against Flutter. Once you get comfortable with it you can build a solid multiplatform app.

I just didn’t feel the need to adopt something new. XML worked. Views worked. We were shipping.

And then there was the terminology. <insert multiple facepalms> mutableStateOf. derivedStateOf.

It sounded like I needed an encyclopedia just to build a button. I wasn’t eager to relearn concepts I already understood — definitely a lot of “get off my lawn” going on.

Back in 2017 at Google I/O, I ran into Dave Burke. He was leading Android at the time. I asked him what he thought about Flutter. Was it the future? Should we all be paying closer attention?

He didn’t tip his hand. But he mentioned that declarative UI had clear advantages. I remember nodding politely. It was Dave after all. But I wasn’t fully sold.

Years later, however, that comment made a lot more sense.

Continue Reading

Realm Migrations Supercharged with Dagger

March 8, 2017 by Annyce Davis

My current tech obsessions are: Realm, Dagger and Unit Testing. Therefore, I’m always looking for opportunities to improve my code in some way that involves one or more of the above. That being said, I realized that the recommended way of handling migrations in Realm could be improved significantly by means of Dagger 2.

We’re going to be refactoring the following Migration class:


With only two version updates, we already have a decent sized method to deal with. What’s more if you didn’t start out by creating tests for your migrations, once this method gets much longer you probably never will. But all is not lost, Dagger’s Multibinding Support is coming to the rescue. Let’s take a look!Continue Reading

Testing Tricks #4 – Improving Readability

January 9, 2016 by Annyce Davis

Readability is one of the key components to creating high quality unit and integration tests. Yet, we may hinder the readability of our tests by bogging them down with needless information. Let’s take a look at an example.

Example


Here we have a simple test that is desiring to make sure the URL we used to create the Video object matches the result of calling the playCurrentVideo method in the VideoPlaybackService class. We have created a helper method that allows us to pass in the variables for the Video object creation. However, in most cases we don’t need to have all of the parameters set. In fact, the duration and displayDate have no impact on the current method under test. So we’ve added additional, needless information to the test that makes it more difficult to understand what’s going on.

Solution


We can fix this issue by updating the Video class to adhere more closely to the Builder Pattern so that the additional setting of fields is not needed. Here is the current setter used for the video’s URL.


We can update it to pass back the Video object (this) instead of just being void. Let’s see how this will help to make the test more readable and understandable.

With Builder Pattern


The end result is something much more readable and maintainable. Happy testing!

Testing Tricks #3: Third Party APIs

December 14, 2015 by Annyce Davis



When you’re writing unit tests for your Android applications, you will often need to handle interactions with third party APIs. In the above image we’re using the Picasso Image Loading library in our classes. Picasso has a very clean API, so it’s relatively simple to work with; but with other libraries you may not be so fortunate. So what can we do to simplify our interactions with those APIs and also set ourselves up for more maintainable code in the future?

We can encapsulate the calls to Picasso (or whatever API) into another class that allows us to control the API and make assertions against it in our tests. So here’s an example:

Initial Code

// MyClass class

public void loadImageFromUrl(String imageUrl) {
    presenter.setCurrentPreviewImageUrl(imageUrl);
    if (showThumbImage) {
        Picasso.with(context)
               .load(imageUrl)
               .into(thumbImageView);
    }
}

So in this method, loadImageFromUrl, we want to make sure that our Presenter is being called and that when the showThumbImage variable is set to true, we call the method to load the image. We want to do this of course, without actually loading the image since we’re attempting to verify this behavior inside of a unit test.

For our use case we will need two new classes: ImageLoader and ImageLoaderImpl. The first will be an interface that we will use to expose the desired API, and the second will be a class that implements that interface and wraps the calls to the third party API.

Updated Code

// ImageLoader interface

public interface ImageLoader {

    void loadImage(String imageUrl, ImageView imageView);

}

// ImageLoaderImpl class

public class ImageLoaderImpl implements ImageLoader {
  
    // fields omitted

    @Override
    public void loadImage(String imageUrl, ImageView imageView) {
        Picasso.with(context).load(imageUrl).into(imageView);
    }
}

// loadImageFromUrl method

public void loadImageFromUrl(String imageUrl) {
    presenter.setCurrentPreviewImageUrl(imageUrl);
    if (showThumbImage) {
        imageLoader.loadImage(imageUrl, thumbImageView);
    }
}

Unit Test

// MyClass

@Mock private ImageLoader imageLoader;

@Test
public void shouldLoadImageWhenShowThumbIsTrue() throws Exception {
    myClass.setShowThumbImage(true);

    myClass.loadImageFromUrl("http://www.myimageurl.png");

    verify(imageLoader).loadImage(anyString(),
                                  any(ImageView.class));
}

@Test
public void shouldNotLoadImageWhenShowThumbIsFalse() throws Exception {
    myClass.setShowThumbImage(false);

    myClass.loadImageFromUrl("http://www.myimageurl.png");

    verifyZeroInteractions(imageLoader);
}
 
So in these two unit tests we are able to successfully verify the interactions with our Image Loader and we don’t have to be concerned with what’s going on inside our third party API. What’s more, if we decide in the future that we would like to use another Image Loading library, we’ve encapsulated those changes in one place!


How do you like to unit test third party APIs? Please leave a comment below.
Next Page »

Follow Me

  • Bluesky

Categories

  • AI (2)
  • Android (62)
  • Career (6)
  • Communication (4)
  • Flutter (1)
  • Git (4)
  • Gradle (4)
  • Grails (23)
  • iOS (1)
  • Java (8)
  • JavaScript (6)
  • Kotlin (17)
  • Leadership (2)
  • Life (5)
  • Public Speaking (26)
  • Revenue (2)
  • RxJava (1)
  • Software Development (15)
  • Twitter (3)
  • Uncategorized (11)
  • Video Course (5)

Follow Me

  • Bluesky

Copyright © 2026 · All Rights Reserved · Log in

Loading Comments...