Forem: Emmanuel Guerra

Handle your Android app orientation changes in semi-automatic

Emmanuel Guerra — Fri, 15 May 2020 01:53:17 +0000

TLDR: Using the power of a shared ViewModel + LiveData (and some debugging to see what is happening) you could listen to orientation changes in any activity/fragment by overriding the onConfigurationChanged function and observing the new Configuration values.

When developing an Android application, most teams point to a portrait-only experience, which is good if it fills your needs, but it often limits the user experience and will result of users uninstalling the app.

Today, I will show you how to manage configuration changes in a reactive way and from both sides: the sensor and from a user interaction.

The example comes from a pet project I have been working: An app to see Twitch clips from a streamer and download them.
First, let’s see why I needed to listen to orientation changes:

Change the orientation if the user pressed a button.
Update the player’s UI when the orientation changed.
If leaving the player, the user’s orientation must remain the same it had previously.

The 1st point was easy to do: The Android API provides a function to change the orientation:

activity?.requestedOrientation = ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE

And that is. The screen orientation changes, and the app will be in landscape mode.

The second, however, was trickier since I needed a variable that tell me the current orientation and update the UI in base of that.

My first approach was to have a variable attached to my fragment. It failed because the user can enter either on landscape or in portrait. So, at start, I needed to know the current configuration.

I started to dig into the ActivityInfo code to see how many orientations are. Turns out there are 17 different orientations. Four of them contains the name PORTRAIT, so we will start from that. Let’s define an extension function that check is the current activity is in portrait:

fun Activity.isInPortrait() = requestedOrientation == ActivityInfo.SCREEN_ORIENTATION_USER_PORTRAIT ||
        requestedOrientation == ActivityInfo.SCREEN_ORIENTATION_PORTRAIT ||
        requestedOrientation == ActivityInfo.SCREEN_ORIENTATION_REVERSE_PORTRAIT ||
        requestedOrientation == ActivityInfo.SCREEN_ORIENTATION_SENSOR_PORTRAIT

However, I was missing one definition that is the default orientation when you have not locked your screen: UNSPECIFIED. This is the default orientation of activities if in the manifest we define the configChanges value and add the orientation specification.

This specify the system that we will manually take care of configuration changes. I am using ViewModels and Room so there is no problem with doing it by myself.
On a side note, this also let’s ExoPlayer to behave like in Youtube app: The video does not stop if your orientation changes.

Now, our function we look like this:

fun Activity.isInPortrait() = requestedOrientation == ActivityInfo.SCREEN_ORIENTATION_USER_PORTRAIT ||
        requestedOrientation == ActivityInfo.SCREEN_ORIENTATION_PORTRAIT ||
        requestedOrientation == ActivityInfo.SCREEN_ORIENTATION_REVERSE_PORTRAIT ||
        requestedOrientation == ActivityInfo.SCREEN_ORIENTATION_SENSOR_PORTRAIT ||
        requestedOrientation == ActivityInfo.SCREEN_ORIENTATION_UNSPECIFIED //The new orientation

Now the UI updates properly if we enter on PORTRAIT, LANDSCAPE and if an user triggers the full screen mode.

But we still lack a way of knowing when the configuration changes when the devices is rotated with the sensor.

After digging through StackOverflow and Github, I knew about the onConfigurationChanged method. It’s an overridable method of the Activities that receives a Configuration object as a parameter. The configuration object comes with a orientation variable that is an interger with 3 possible values:

UNSPECIFIED, LANDSCAPE, PORTRAIT. This is exactly what I need!

I define a simple ViewModel which would update the Configuration object with MutableLiveData. The ViewModel will be created lazily on the activity, and be shared across fragments inside that activity:

class OrientationViewModel: BaseViewModel() {

    private val _configData = MutableLiveData<Configuration>()
    val configData = _configData as LiveData<Configuration>

    fun changeConfiguration(configuration: Configuration?){
        _configData.value = configuration
        Timber.d("New configuration. Orientation: ${configuration?.orientation}")
    }

}

Override the onConfigurationChanged method on my HostActivity:

    override fun onConfigurationChanged(newConfig: Configuration) {
        super.onConfigurationChanged(newConfig)
        orientationViewModel.changeConfiguration(newConfig)
    }

Then, on my fragment that holds the Player, observe the changes:

orientationViewModel.configData.observe(viewLifecycleOwner, Observer { config ->
            if(config != null){
                updatePlayerView(fullScreenBtn, config.orientation)
                updateWindowMode(config.orientation)
            }
        })

Done! If I set a new orientation with activity?.requestOrientation or the user use the sensor to change to landscape/portrait, the activity will handle the UI changes.

As for the last problem, a simple line inside the Fragment's onDetach function will leave the user in their default orientation:

requireActivity().requestedOrientation = ActivityInfo.SCREEN_ORIENTATION_UNSPECIFIED

That’s it! You could check the full project in Github:

eagskunst / VideoWorld

Repository that contains my tests with Exoplayer and network videos APIs.

If you are interested on how to make a custom ExoPlayer controls view, how to download files using WorkManager, building recycler views with Epoxy or anything related to the project, like this article and leave a comment with what you want see next!

Making safe API calls with Retrofit and Coroutines

Emmanuel Guerra — Sat, 11 Jan 2020 22:36:47 +0000

After the 2.6.0 release, Retrofit has official support for coroutines. The migration from other adapters (like RxJava) it simple. Just change your interface from:

@GET("movie/{category}")
fun getMovieListForCategory(@Path("category") category: String) : Single<MovieListResponse>

to:

@GET("movie/{category}")
suspend fun getMovieListForCategory(@Path("category") category: String) : MovieListResponse

An make your call within a CoroutineContext:

GlobalScope.launch {
   val response = movieListApi.getMovieListForCategory(category)
}

You can see that instead of using a wrapper around the object, you receive the object itself, which it's pretty helpful but has one disanventage: this does not provide a way to determine an error.

Of course you could use the classic try-catch, but writting this for every single call is not optimal and it's a bad solution in the long term. Also, who wants to write a try-catch for every request?

That's why I'm showing you the solution I made for my work and personal projects!

First of all, let's define the problems we have:

We need to make safe calls, so every call needs to be around a try-catch block.
We need it to work for every call.
We need to return something in case the call fails
We need to somehow emit an error or a message if the call fails.

For the first two problems, we can create an static class or an abstract class that handles the calls. But how do we know what to return?
Since every object is different and we are trying to find a solution for every one, we could use a generic function.

suspend fun <T> safeApiCall() : T

We have now what will be our function. The problem we face now: how to exactly make it work for every interface?
After a lot of thinking, reading from the Retrofit repository and articles in the internet, I remember the powerfulness of Kotlin's higher order functions!
Passing a function as a parameter make the solution work for any interface.
So now, we have this:

suspend inline fun <T> safeApiCall(responseFunction: suspend () -> T): T

Now, the only thing we need to do is to call responseFunction around a try-catch and return it as a parameter. But now we face the 3rd problem. The solution is simple: return a nullable object instead of the non-nullable:

suspend inline fun <T> safeApiCall(responseFunction: suspend () -> T): T?{
    return try{
            responseFunction.invoke()//Or responseFunction()
           }catch (e: Exception){
            e.printStackTrace()
            null
           }
}

Done! We have the function that will handle every single call safely. Now, let's see what optimizations we can do and how to inform other classes about the error.

We will handle 3 types of error: HttpExceptions, SocketTimeoutException and IOExceptions. For this, we will create an enum for easy handling. You could also use Int values if you want to.

enum class ErrorType {
    NETWORK, // IO
    TIMEOUT, // Socket
    UNKNOWN //Anything else
}

For the HttpExceptions, let's create a function that gets the error message from the API. Here, you need to check what kind of JSON object use the API for error response and the error codes.

companion object {
    private const val MESSAGE_KEY = "message"
    private const val ERROR_KEY = "error"
}

fun getErrorMessage(responseBody: ResponseBody?): String {
    return try {
        val jsonObject = JSONObject(responseBody!!.string())
        when {
            jsonObject.has(MESSAGE_KEY) -> jsonObject.getString(MESSAGE_KEY)
            jsonObject.has(ERROR_KEY) -> jsonObject.getString(ERROR_KEY)
            else -> "Something wrong happened"
        }
    } catch (e: Exception) {
        "Something wrong happened"
    }
}

Now, we are going to create an interface that will be in charge of notifying the errors to the classes that implement it:

interface RemoteErrorEmitter {
    fun onError(msg: String)
    fun onError(errorType: ErrorType)
}

Finally, let's modify our try-catch block. For optimizations, we would change to coroutine context to Dispatchers.IO when calling responseFunction and changing the context to Dispatchers.Main on the catch block. We use the Main dispatcher so there are no exceptions from modifying the UI thread.

suspend inline fun <T> safeApiCall(emitter: RemoteErrorEmitter, crossinline responseFunction: suspend () -> T): T? {
    return try{
        val response = withContext(Dispatchers.IO){ responseFunction.invoke() }
        response
    }catch (e: Exception){
        withContext(Dispatchers.Main){
            e.printStackTrace()
            Log.e("ApiCalls", "Call error: ${e.localizedMessage}", e.cause)
            when(e){
                is HttpException -> {
                    val body = e.response()?.errorBody()
                    emitter.onError(getErrorMessage(body))
                }
                is SocketTimeoutException -> emitter.onError(ErrorType.TIMEOUT)
                is IOException -> emitter.onError(ErrorType.NETWORK)
                else -> emitter.onError(ErrorType.UNKNOWN)
            }
        }
        null
    }
}

We are finally done! Now you have a class that can handle exception on Http calls make with coroutines.
Here's an example on how to use this from a ViewModel:

class MovieListViewModel(api: MovieListApi): ViewModel(), RemoteErrorEmitter {
  val movieListLiveData = liveData {
      val response = ApiCallsHandler.safeApiCall(this@MovieListViewModel){
          api.getMovieListForCategory("popular")
       }
      emit(response)
  }
  //RemoteErrorEmitter implementation...
}

You can see more examples on a recent app I made:

Forem: Emmanuel Guerra

Handle your Android app orientation changes in semi-automatic

eagskunst / VideoWorld

Repository that contains my tests with Exoplayer and network videos APIs.

Making safe API calls with Retrofit and Coroutines

eagskunst / MoviesApp

An application that show a list of categories, a list of movies,the details of the movie and let the user save it on his own list.