типо 500, 404, ...? Или где это глянуть можно, чтобы не было особых заморочек?
Сейчас у меня такая цепь для данных:
View -> VM -> Interactor -> Repository - > (Retrofit/DB/...)
В репозитории есть метод getEmployees(), который либо возвращает интерактору данные из кеша(лист Employee), либо, если кеш пустой, идёт в сеть посредством метода loadEmployees(), получает ответ, кеширует результаты и после этого возвращает интерактору данные.
Я не могу корректно обработать ситуацию, когда из сети пришла ошибка. Раньше я об этом вообще не думал, а сейчас упало Api, а за ним и апка.
Из сети приходит ResponseResult, который я тупо оборачиваю в try/catch, чтобы не упасть. Первое что я попробовал сделать - добавить в ResponseResult поле errorCode и сеттить его внутри catch в случае ошибки. Только сейчас репозиторий отдаёт лист Employee, и его нужно как - то научить передавать ошибку наверх.
Как вариант - передавать что - то вида List<ErrorCode, List<Employee>>.
Или вообще создать свою модель, типа RepositoryResult, которая будет собираться из ResponseResult, в котором будет errorCode и List<Employee>, возвращать эту модель интерактору, маппить её и снова думать над тем как и в каком виде передать ошибку ещё выше.
В теории это будет работать, но вариант "сеттить какое - то поле в случае ошибки, и передавать данные наверх, пока они не дойдут presenter слоя" кажется мне какой - то дичью, очень много мороки, наверное должен быть вариант правильнее.
Как правильно решить проблему?
*Вот код репозитория, я если что претендую на Джуна, так шо не баньте, я играю как умею ((
https://github.com/KirstenLy/TestTask/blob/master/app/src/main/java/com/example/testtask/data/repository/EmployeeRepository.kt
1. Правильнее всего будет отдавать свою модель ResponseResult. В котлине еще можно отдавать sealed class https://kotlinlang.org/docs/reference/sealed-classes.html С запечатанными классами легче будет работать в презенторе и интеракторе 2. Если это тестовое то почитай про SOLID. У тебя реализация не спрятана за интерфейсы, это всегда сильно бросается в глаза 3. Статический метод для получения контекста это очень плохо. Не используй App.get() Либо прокидывай зависимостью либо добывай из фрагмента или активити 4. Зачем тебе SharedViewModel если итак у тебя репозиторий во первых кеширует данные, а во вторых в di заведен как @Singletone
Обсуждают сегодня