Menu

In my last post, I introduced how to write a Java model class to model the OpenWeatherMap API. Specifically, it models the response from the API using the SDK documentation. Today, I’m writing a manager class to implement an SDK for accessing the API, again using the SDK documentation.

Let’s start with the basics. You generally need to sign up so that your app can access the API. OpenWeatherMap is no different. Once you have signed up, you will be given an API key. You should generate an API key for each and every mobile app that will use the API. I’d even go so far as to generate an API key for different versions. That way you can easily revoke access later.

Your mobile app needs to get this API key somehow. Most developers will just embed the API key in their code, and I’m going to do this as well. However, you could also store the API key in a JSON blob, for example in a JSON file that is served via Amazon S3. In this case, your mobile app would first download and decode the JSON file, then configure the manager.

You also need to be able to make HTTP calls. I use the okhttp library for this. It’s more friendly than the standard library and is available for both iOS and Android, making my life easier as I switch between platforms. You can also use the standard Android library (HttpURLConnection) or another library if you so desire. To add the okhttp library to your app, edit your app’s build.gradle file and add the following line:

Sync your workspace to download the new library. Now, let’s move on to the actual implementation. I like to write a “Manager” class. In this case, it will be called WeatherManager. It’s job is to hide the implementation details of the actual SDK call. The rest of my app will call the exposed API and the underlying details can change if they like. In addition, my WeatherManager API will throw a WeatherException – a standard exception method to hide the internal details. Here is my exception class:

There are two constructors. The mobile app will call the default constructor. However, I may want to mock the HTTP Client in my unit tests. The getWeather() method uses the OkHttp library to do the HTTP GET call. The code here comes directly from the okhttp documentation.

I don’t want developers calling the getWeather() method directly. I want to provide helper methods that “do the right thing”. There is one helper method for each API type within the OpenWeatherMap API:

When I was doing this, I found that certain values that I had assumed were integers in the model were in fact floating point, so I had to change some types. That also changed the tests for the model. This indicates that it is important to do online tests.

However, we can also do mock tests. This involves replacing the OkHttpClient with one that we generate, and allows us to test that the JSON we provide gets decoded properly when loaded via the HTTP client. We can set up a standard HTTP response by implementing an interceptor within the WeatherManagerTests.java file:

When I instantiate the WeatherManager(), I’m passing the modified OkHttpClient with the interceptor that doesn’t actually do the request – it just returns my JSON blob. I can now test the response for the actual values. I can’t do this on the “live network tests” because the data changes. The JSON I’m using to test the WeatherResponse() and the JSON in the interceptor are the same, so I can test the data the same way.

That’s it for this blog post. You can, as always, find the code on my GitHub Repository. In the next blog post, I’m going to look at some Android code for displaying the data in a basic manner.