TheAlisher 21 мая 2022 в 22:20

Запросы в сеть с Clean Architecture и MVVM. Boilerplate ч. 2

11 мин

12K

Разработка мобильных приложений*Разработка под Android*

Туториал

Комментарии 11

anegin 21 мая 2022 в 23:55

Зачем для разового запроса в doRequest возвращается flow (с единственным emit-ом)? почему бы не сделать просто suspend-функцию

TheAlisher 22 мая 2022 в 00:11

Думаю не совсем понял вопрос, но здесь код это просто общий пример как сделать запрос

anegin 22 мая 2022 в 09:29

Если запрос предполагает один ответ, то flow там избыточен

suspend fun <T> doRequest(
		...
): Either<String, T> = withContext(Dispatchers.IO) {
		// ...
    // Either.Left() or Either.Right()
}

К тому же doSomethingInSuccess - это лишний side effect. Зачем возвращать результат (который игнорится) отдельно через функцию и через колбэк

TheAlisher 22 мая 2022 в 10:39

А почему результат игнориться вы внимательно если посмотрите там нужно сохранять определенные данные в SharedPreferences, думаю это не обоснованные придирки ). Насчет flow избытычен можно и без этого return'ить, но как уже добавлялось это самый простой кейс для того чтобы показать сами запросы ;)

-1

xISRAPILx 28 мая 2022 в 14:30

Согласен с комментарием о doSomethingInSuccess, калбэк видится лишним, ведь если запрос упадёт, выпадет исключение и выполнение функции прекратится.

От себя ещё замечу, что наследование BaseRepository так же можно заменить на internal top level функцию или композицию

TheAlisher 28 мая 2022 в 14:36

А хотелось бы узнать почему вам видиться метод doSomethingInSuccess лишним. Я хочу вам дать такой кейс. Сделали мы такую функцию как doRequest окей сделали по нему запрос, но эти данные нам нужно каким-то образом сохранить куда-то в результате как мы можем это все разграничить и правильно написать? Вижу я это вот так в своей реализации:

class SignInRepositoryImpl @Inject constructor(
    private val service: SignInApiService,
    private val userData: UserData
) : BaseRepository(), SignInRepository {

    override fun signIn(userSignIn: UserSignIn) = doRequest(this::setupSignInSuccess) {
        service.signIn(userSignIn.fromDomain()).toDomain()
    }

    private fun setupSignInSuccess(signIn: SignIn) {
        // Сохраняем здесь токен в SharedPreferences или же DataStore для дальнейшего использования
        userData.saveToken(signIn.token)
    }
}

Хотелось бы услышать от вас как бы вы реализовали эту логику?

А насчет internal top функции согласен с вами можно и так вынести, но просто изначально в коде ещё есть такой же метод для запроса с пагинацией. Просто не видел смысла выносить.

xISRAPILx 29 мая 2022 в 02:19

А насчет internal top функции согласен с вами можно и так вынести, но просто изначально в коде ещё есть такой же метод для запроса с пагинацией. Просто не видел смысла выносить.

Для себя выучил, что наследование - последнее, к чему надо прибегать.

Хотелось бы услышать от вас как бы вы реализовали эту логику?

class SignInRepositoryImpl @Inject constructor(
    private val service: SignInApiService,
    private val userData: UserData
) : BaseRepository(), SignInRepository {

    override fun signIn(userSignIn: UserSignIn) = doRequest {
        service.signIn(userSignIn.fromDomain()).toDomain()
        	.also { userData.saveToken(it.token) }
    }
}

TheAlisher 29 мая 2022 в 12:19

Спасибо! Сам что-то не додумался до этого перемудрил тогда получается. Ещё раз спасибо, скорее всего обновлю статейку и добавлю обновление в репозиторий. 😊

А вопрос если захочу кастомно обработать ошибку правильнее ли будет добавить в этот же код ещё раз catch

override fun fetchFoo() = doRequest {
    service.fetchFoo().toDomain().also {
        // do something in success
    }
}.catch { exception ->
    // do something in error
}