Forem: Luke Mueller

Pro Tip: cd for macOS Finder

Luke Mueller — Sat, 23 Jan 2021 00:30:15 +0000

⌘+⇧+g

AndroidX, LiveData and the Observable Pattern

Luke Mueller — Mon, 27 Jan 2020 19:39:53 +0000

Android has come a loooong way

I was really pleased when returning to Android development after being away for a while at how much better it has gotten with AndroidX. Now this isn’t breaking news to most, but Android Jetpack and the androidx.* package libraries not only solved one of the most confusing aspects of Android development ( those pesky versioned Android Support Libraries ) but also brought the observable pattern front and center with LiveData and ViewModel. While LiveData is not quite as robust or generic as RxJava, it is effectively a basic implementation of the Observable pattern with the added benefit of being Lifecycle Aware.

That last bit there is huge. Being lifecycle aware means that you don’t have to worry about memory leaks or hard-to-debug NPEs because your observables live and die with their observers. Activities and their layouts go in and out of memory as user's navigate around. Ensuring that our asynchronous data loads don't try and update screens long gone is especially important.

It’s all about the `observe` method.

public void observe(@NonNull LifecycleOwner owner, @NonNull Observer<? super T> observer); takes two parameters: an owner with a Lifecycle and an Observer for trigger when the underlying value changes. Pretty straightforward.

Coupling this with Android’s Data Binding Library means screens that handling swiping full screen content layouts is a really clean and pleasant exercise. One of our latest client projects involved adding the capability for their customers to take the physical gift cards purchased in their stores and add them to a digital wallet. We wanted to build a way for customers to be able to view all the details of an individual card (card number, barcode, terms and conditions, transaction history, etc..) We decided that a full screen view of each card was required for all this information but wanted users to be able to swipe left and right to horizontally page between each of the cards in their wallet.

We decided to effectively use a ViewPager and PagerAdapter to accomplish the horizontal paging between gift cards. That, combined with a ViewModel to track the current page meant that the our observe callback just had to update the data binding backing the view after loading from our API.

Here is a simplified example of the Activity:

public class GiftCardDetailsActivity extends AppCompatActivity implements GiftCardDetailsPagerListener {
    private GiftCardsDetailViewModel giftCardsViewModel;
    private GiftCardDetailsActivityBinding binding;
    private GiftCardTransactionAdapter giftCardTransactionAdapter;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        int initialPosition = (int) getIntent().getSerializableExtra(GIFT_CARD_INITIAL_POSITION_EXTRA);

        giftCardsViewModel = ViewModelProviders.of(this).get(GiftCardsDetailViewModel.class);
        giftCardTransactionAdapter = new GiftCardTransactionAdapter();
        binding = DataBindingUtil.setContentView(this, R.layout.gift_card_details_activity);
        binding.giftCardViewPager.setAdapter(new GiftCardDetailsPagerAdapter(this, initialPosition);

        giftCardsViewModel.getCurrentGiftCard().observe(this, currentGiftCard -> {
            binding.setGiftCard(currentGiftCard);
            binding.barcodeImage.setImageBitmap(BarcodeGenerator.generateBarcodeImage(getResources(), currentGiftCard.getNumber()));
            giftCardTransactionAdapter.setGiftCardTransactions(currentGiftCard.getTransactions());
            giftCardTransactionAdapter.notifyDataSetChanged();
        });

        giftCardsViewModel.setCurrentGiftCardPosition(initialPosition);
    }

    @Override
    public void onPageSelected(int position) {
        giftCardsViewModel.setCurrentGiftCardPosition(position);
    }
}

And the ViewModel:

public class GiftCardsDetailViewModel extends AsyncLoadingViewModel implements GiftCardsApiResponseListener {

    private GiftCardApiService giftCardApiService;
    private MutableLiveData<GiftCard> currentGiftCard = new MutableLiveData<>(new GiftCard());
    private List<GiftCard> giftCards;
    private int initialPosition;

    LiveData<GiftCard> getCurrentGiftCard() {
        if (giftCards == null) {
            setIsLoading(true);
            giftCardsApiService.fetch(this);
        }

        return currentGiftCard;
    }

    void setCurrentGiftCardPosition(int position) {
        if (giftCards == null || position > giftCards.size()-1) {
            initialPosition = position;
            return;
        }

        currentGiftCard.setValue(giftCards.get(position));
    }

    @Override
    public void onGiftCardsApiResponseSuccess(List<GiftCard> giftCards) {
        setIsLoading(false);
        this.giftCards = giftCards;
        this.currentGiftCard.setValue(giftCards.get(initialPosition));
    }

    @Override
    public void onGiftCardsApiResponseFailure(String errorMessage) {
        setIsLoading(false);
        // classic "error handling here" blog post comment...
    }
}

On of the nice things about this implementation is that there is only one way, and exactly one way, in which data is set on the view binding. Our Activity’s onCreate() is responsible for instantiating the ViewModel that tracks the current page, and holds onto the full list of gift cards that are asynchronously loaded from our server’s API. Anytime the instance of the ViewModel’s underlying LiveData member's change, our observable callback is triggered and we simply update the bindings gift card. Notice that the first argument to the observe() call is an implementation of LifecycleAware. In this case, our Activity itself.

A few other noteworthy details:

While our ViewModel's private member currentGiftCard is of type MutableLiveData we only expose LiveData to observers. This is important because it isolates the responsibility of managing that state to our ViewModel.
The AsyncLoadingViewModel is just a parent class that extends Android's ViewModel class and manages a single piece of state for loading masks of type LiveData<Boolean>
The ViewModel holds onto the initial position until the initial data load is completed.

Followup

I should note here that there are a few other ways to accomplish similar behavior by leveraging more of the AndroidX library, including Two-way data binding, @BindingAdapters, and BaseObservables. Given we are not taking any user input on these largely view-only screens, this felt like overkill. This simple pattern seemed to work well for the initial version of these screens.

Perhaps a follow-up post to compare / contrast is in order!

Scratching the surface of composition with React Native and Apollo

Luke Mueller — Thu, 02 Jan 2020 15:27:34 +0000

When I first stumbled upon Andrew Clark's recompose library I thought awesome, I'm always up for some composition! However, a quick glance at the docs left me feeling like there was a large learning curve ahead of me as I was still just getting comfortable with React Native and GraphQL.

In this post I'll share a few recipes that helped me get started with recompose that had a high degree of impact of the quality of my code. The code examples below are from a project I've been working on called Broce.
At a high level, the tech stack is:

React Native
Expo
React Apollo
GraphQL backend in Ruby/Rails

On the Menu today

Starter: Factor out reusable logic with pure, composable functions
Main Course: Factor out fetching remote data from our component all together
Dessert: Convert our component to a React PureComponent

Tasting Notes

This article assumes you have experience with React and GraphQL
Are familiar with or have dappled in composition and higher-order functions

Let's eat!

If you follow the React and Apollo docs you'll quickly end up with a component that looks like the following:

const COMPANY_QUERY = gql`{
  company {
    name
    website
  }
}`;

export default class CompanyScreen extends React.Component {
  render() {
    return (
      <Query query=>
        {({ client, loading, error, data }) => {
          if (loading) return <LoadingMask/>;
          if (error) return <ErrorScreen error=/>;

          return (
            <ScrollView>
              <CompanyForm company=/>
            </ScrollView>
          );
        }}
      </Query>
    );
  }
}

This component has a few responsibilities:

It extends a React.Component and is responsible for rendering the component's layout
The CompanyScreen's render element is wrapped by Apollo's Query component so that it can fetch data from the GraphQL server
It handles the loading and error states for the respective GraphQL query

It's fair to say that Uncle Bob would have an opinion about such a component. We're violating the Single Responsibility Principle a few times over. My main issue with Apollo's Query wrapping component is that it couples the concern of fetching remote data with display logic.

Appetizer

Our first step is to factor away those 2 if conditions that deal with loading and error states. I had been copy and pasting that code around and could easily imagine scenarios where that logic would get more complex (think different error types that warrant different handlers).

We can create 2 plain old javascript constants which leverage recompose's branch function:

export const displayLoadingState = branch(
  (props) => props.data.loading,
  renderComponent(LoadingMask)
);

export const displayErrorState = branch(
  (props) => props.data.error,
  renderComponent(ErrorScreen)
);

The branch function takes 3 arguments. The first is a test function, the second and third arguments are the potential return components if the test functions returns either true or false. Really, it's just another way to go about an if/else condition.

Our test functions look at the component's Apollo provided props and checks if the data.loading or data.error states are set. In that event that the query is loading or returned an error, we call recompose's
renderComponent function, passing it our beautifully styled LoadingMask and ErrorScreen components. In the falsey case, we do nothing as we want our CompanyScreen component to render.

A litter further down we'll see how recompose manages to pass the component's props to the test functions above, for now let's just assume magic is real and the props will safely arrive

Main course

Now, let's go about removing that Apollo query logic from our CompanyScreen component.

The react-apollo library offers a HOC function called graphql which will allow us to avoid wrapping our screen components with <Query />. A Higher-Order-Component (HOC) is just a function that takes a component as an argument and returns a new component. All recompose functions are just that, HOC component functions. We'll chain them together shortly.

Introducing Apollo's graphql HOC function will replace <Query query=> ... with graphql(COMPANY_QUERY). This will be the first function passed to our composable component chain. Apollo will take and execute that query, returning a new component whose props receive Apollo's data object.

We've managed to factor away a lot of functionality but need to stitch it all back up.

class CompanyScreen extends React.Component<Props> {
  render() {
    const = this.props;

    return (
      <ScrollView>
        <CompanyForm company=/>
      </ScrollView>
    );
  }
}

export default compose(
  graphql(COMPANY_QUERY),
  displayLoadingState,
  displayErrorState,
)(CompanyScreen);

We can see a lot of code is gone from the CompanyScreen component's render function. At the same time, we've introduced a new default export to this file. We no longer export the CompanyScreen class itself, but rather we export the component that recompose's compose function will create for us.

The call to compose at the bottom of the file will take multiple higher-order components and create a single HOC. This means our resulting CompanyScreen component will have triggered our GraphQL query and Apollo will handle putting the ever important data object onto its props. recompose will also handle chaining the component's props as arguments to each one of the HOC functions passed to compose.

Our CompanyScreen component now only has one concern, rendering a layout in the case of company data having been fetched. Uncle Bob would be proud.

Dessert

For desert we're going to convert our React component into a pure component, as it does not maintain any state. Only the declaration of the CompanyScreen needs to change here. Rather than declaring it as a class we declare it as a function, one that receives and de-structures the props argument.

const CompanyScreen = (     ) => {
  return (
    <ScrollView>
      <CompanyForm company=/>
    </ScrollView>
  );
};

export default compose(
  graphql(COMPANY_QUERY),
  displayLoadingState,
  displayErrorState,
)(CompanyScreen);