<commit_before># EasyCallback
Easier Retrofit callbacks

[![Build Status](https://travis-ci.org/Commit451/EasyCallback.svg?branch=master)](https://travis-ci.org/Commit451/EasyCallback)
[![](https://jitpack.io/v/Commit451/EasyCallback.svg)](https://jitpack.io/#Commit451/EasyCallback)

Many times when using Retrofit, you would probably want your `!isSuccessful()` responses to just fall through into your failure case. That is what this do. It is very reminiscent of Retrofit 1.X callback days

# Usage
Usage is simple:
```java
api.getUsers().enqueue(new EasyCallback<ResponseBody>() {
    @Override
    public void success(@NonNull ResponseBody response) {
        textView.setText("Things worked!");
    }

    @Override
    public void failure(Throwable t) {
        mTextView.setText("Something went wrong");
    }
});
```   

If you actually need to perform different actions depending on the HTTP error status code, you can still do so:
```java
@Override
public void failure(Throwable t) {
    Timber.e(t, null);
    if (t instanceof HttpException) {
        switch (((HttpException) t).getCode()) {
            case 404:
                mTextView.setText("Thingy not found");
                break;
            case 500:
                mTextView.setText("Our server broke :(");
                break;
        }
    } else {
        mTextView.setText("Some generic error message");
    }
}
```

# Note
If your API happens to return a `200` code, but contains an empty body, this will fall through to the `failure` block due to the fact that we check for `null` in the `onResponse` and redirect to `failure` if the response is null. <commit_msg>Add EasyOkCallback to the docs<commit_after># EasyCallback
Easier Retrofit callbacks

[![Build Status](https://travis-ci.org/Commit451/EasyCallback.svg?branch=master)](https://travis-ci.org/Commit451/EasyCallback)
[![](https://jitpack.io/v/Commit451/EasyCallback.svg)](https://jitpack.io/#Commit451/EasyCallback)

Many times when using Retrofit, you would probably want your `!isSuccessful()` responses to just fall through into your failure case. That is what this do. It is very reminiscent of Retrofit 1.X callback days

# Usage
Usage is simple:
```java
api.getUsers().enqueue(new EasyCallback<ResponseBody>() {
    @Override
    public void success(@NonNull ResponseBody response) {
        textView.setText("Things worked!");
    }

    @Override
    public void failure(Throwable t) {
        mTextView.setText("Something went wrong");
    }
});
```   

If you actually need to perform different actions depending on the HTTP error status code, you can still do so:
```java
@Override
public void failure(Throwable t) {
    Timber.e(t, null);
    if (t instanceof HttpException) {
        switch (((HttpException) t).getCode()) {
            case 404:
                mTextView.setText("Thingy not found");
                break;
            case 500:
                mTextView.setText("Our server broke :(");
                break;
        }
    } else {
        mTextView.setText("Some generic error message");
    }
}
```
There is also `EasyOkCallback` which is an OkHttp specific flavor of the Callback which also checks `isSuccessful()` and will also by default post the result on the main thread for simplicity

# Note
If your API happens to return a `200` code, but contains an empty body, this will fall through to the `failure` block due to the fact that we check for `null` in the `onResponse` and redirect to `failure` if the response is null. 
{'fraction_non_alphanumeric': 0.10481344346340074, 'fraction_numerical': 0.012532042153232698, 'mean_word_length': 3.25181598062954, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 8, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7331643', 'n_tokens_mistral': 1025, 'n_tokens_neox': 957, 'n_words': 357}