I'm doing an interview homework that's an android ...

# android

[Bruno_]

I'm doing an interview homework that's an android app, the only thing that's left to do is network error handling
I have no idea how to approach this, could you help?

[Bruno_]

i've tried implementing BroadcastReceiver but it wouldn't work

[Bruno_]

this piece of code is working but I'd have to setup a loop that would check the connection, I don't think that's the best idea

val cm = getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
val activeNetwork: NetworkInfo? = cm.activeNetworkInfo
val isConnected: Boolean = activeNetwork?.isConnectedOrConnecting ?: false

[Brian]

you can monitor for changes in connectivity using ConnectivityManager.NetworkCallback

[satyan]

Read ConnectivityManager documentation you should find something useful to handle the offline case.

To handle network errors upon requests you should read your HTTP client documentation (Retrofit on top of OKHttp ? Java HTTP ? )

This Slack is supposed to be about Kotlin so it might not be the best place to ask interview homework questions.

Try doing the Sunshine app application course on Udacity there must be a part about network calls.

[Bruno_]

thanks, that'll solve the problem

[Bruno_]

or it won't, I have to support API14, would it be a good idea to listen for a flowable error somewhere?

[Bruno_]

not sure if it's a good idea tho, I've separated my retrofit module and I return flowable from it, the only place that has the flowable is a repository

[Bruno_]

this one works

Untitled

[Ryan Mentley]

as it happens I was semi-recently helping update one of the training articles on exactly this topic: https://developer.android.com/training/monitoring-device-state/connectivity-status-type

[Ryan Mentley]

note specifically the bit about ConnectivityManagerCompat

[Anastasia Finogenova]

You can always go for a retey button, on a snackbar or a dialog or even come up with a new UI for the network error state with the retry option , it is very straightforward imo

[Anastasia Finogenova]

The network error will be returned differently depending on the network library you use. You mentioned you use Flowable so apparently RxJava, your network error is gonna fall in the the onError callback. So inside the onError callback check if the error is instance of Sockettimeoutexception or unknownhostexception if using retrofit and then just show your network error prompt with the retry

[Bruno_]

the only place that has access to the flowable is the repository, which means that I can do doOnError only there. would it be a bad idea to throw an error in a repository and catch it in a fragment using a global exception handler? https://stackoverflow.com/questions/4427515/using-global-exception-handling-on-android

[Bruno_]

other solution would be to somehow use rxjava flowable instead of a view model (so fragment would call repository directly instead of fragment -> view model -> repository flow), is that a good idea?

[Bruno_]

I should probably mention that I use MVVM

[Bruno_]

@Anastasia Finogenova @Ryan Mentley

[Bruno_]

it's more of an architecture question, I know how to handle the rror, display a snackbar etc, I just don't know how to design the module properly

[Bruno_]

I think I'll do something like that https://stackoverflow.com/questions/50855715/android-mvvm-how-to-handle-network-request-failiures

[Raul Tunduc]

@Bruno_ you can check this too?
https://developer.android.com/jetpack/docs/guide#addendum

[Anastasia Finogenova]

Just return this Flowable from the repo method and subscribe to it in the view model and do actions on result on success or on error

[Anastasia Finogenova]

Throwing an error in the repo and catching in the fragment is a very bad not straightforward idea

[Raul Tunduc]

From my point of view, I would NOT recommend using RX for HTTP requests. It's easier with Coroutines

[Anastasia Finogenova]

It is not easier imo, after using coroutines a lot I realized they are not easier in any way that RxJava from the dev stand point

[Anastasia Finogenova]

I am recommending Flowable as he said he already has it

[Mikael Alfredsson]

Since its an interview assignment, shouldn’t be able to solve it if youre qualified for the position? 🧌
The error you should get back when you are trying to call the endpoint, so a normal try/catch works for that, and for the download automatically/retry, I would go for the first option and use Workmanager to achieve that.

[Bruno_]

@Mikael Alfredsson it was my first real android app 😄 I'm a fullstack dev on a daily basis
anyway, what I did was pretty much what you can see in the last SOF link I've sent - throwable field in a view model that I check on every view model update