Картинки это не бизнес логика

Картинки это не бизнес логика

Если картинки доступны публично то да. А если они привязываются к авторизации и требуют наличия сессии, то я бы отнес это к логике.

Если картинки доступны публично то да. А если они привязываются к авторизации и требуют наличия сессии, то я бы отнес это к логике.

Я бы добавлял в загрузчик картинок токен в запросы и все равно не относил бы картинки к бизнес логике.

Я бы добавлял в загрузчик картинок токен в запросы и все равно не относил бы картинки к бизнес логике.

Что логично)

@pahakorolev а у glide разве нет метода без ссылки на view? У мвсех загрузчиков вроде есть

@pahakorolev кончено, для более-менее оптимальной загрузки нужны размеры вьюхи, в которой загружаемая картинка будет отображаться и с этим будет гемор

ребята, кто-то работал с HEPE map API Android? на 6.0.1 LGE появляется error MISSING_LIBRARIES, на других работает. LGE на armv8. что можно с этим сделать?

Добавить arm64 версию библиотеки как вариант

Добавить arm64 версию библиотеки как вариант

если она есть )

Собрать если нету и опенсорс:)

Собрать если нету и опенсорс:)

не думаю что HERE MAPS open source )

Тогда хакнуть лмбу чтобы юзала 32 бита либу для 64)))

если мне нужно на протяжении жизни аппа хранить два значения, правильно ли будет засунуть их в shared pref?

привет

Privet)

мне для интерфейса голосовых команд нужно постоянно слушать микро, я так понимаю это весьма затратное в плане батарейки мероприятие, какую стратегию вы бы посоветовали?

если мне нужно на протяжении жизни аппа хранить два значения, правильно ли будет засунуть их в shared pref?

Они будут менятся?

Они будут менятся?

каждый заход в апп я их получаю(каждый раз новые) и нужно хранить

Если это что-то важно, то ты смотри, на рутовых устройствах подменит Shared Preferences - минутное дело

Добавить arm64 версию библиотеки как вариант

похоже что такой библиотеки нет. в .aar который качает есть только armeabi-v7a. может быть в этом проблема?

каждый заход в апп я их получаю(каждый раз новые) и нужно хранить

Тогда не подходит. Ты не узнаешь, когда приложение уничтожилось, чтобы перезаписать новые значения.

Хотя.. в onCreate перезаписываешь и все ок.

Хотя.. в onCreate перезаписываешь и все ок.

перезаписываться будет при каждом логине

думаю должно работать

думаю должно работать

Да. Но токен не стоит хранить в преференсах

а где стоит хранить токен? :)

Да. Но токен не стоит хранить в преференсах

куда тогда его сохранить?

предполагаю что в бд

mode private и достучаться другие аппы не смогут

Я сам то не особо знаю. В шифрованной бд, как вариант. На рутованных устройствах и при mode private вытащат.

ну рутованых да, но это если еще пользователь даст доступ

на стаковерфлоу пишут в shared preff

dropbox так делает

А если аппарат не у пользователя? В общем плохая практика. В подкастах про безопасность что говорили? Я позже буду безопасность усилять у себя.

Я сам то не особо знаю. В шифрованной бд, как вариант. На рутованных устройствах и при mode private вытащат.

На рутованных и из шифрованной БД вытащат, не?

В подкастах говорилось о криптоконтейнерах, но я до сих пор не понял че это

Как раз - шифрованная бд.

Где ключ шифрования хранится?

На рутованных и из шифрованной БД вытащат, не?

Базу то они смогут получить, а расшифровать?

я может глупость скажу, но почему бы тот же ключ не засунуть в sp предварительно его самому "зашифровав", и вытаскивая его "расшифровывать". Пусть его можно и вытащить но какой от него будет толк если не известен заранее алгоритм шифрования?

в keystore, вроде. Я на заметку взял, на потом. Но не вникал.

Где ключ шифрования хранится?

Хотя. Я как-то залез в SQLClipher, там вроде ключ при генерации либы забивается. т.е. он будет только у вас.

У кого "у вас"?

У разработчика

ks.load(fis, password) На клиенте он будет.

ks.load(fis, password) На клиенте он будет.

Шифровать базу пином пользователя, который хранится только у него, а не где то в приложении. и каждый раз его запрашивать

Разве что так.

Шифровать базу пином пользователя, который хранится только у него, а не где то в приложении. и каждый раз его запрашивать

В сбере может и норм. Но не везде же будешь пароль просить. В телеграме же не просит пароль каждый раз.

ConstraintLayout юзает кто-нибудь в проде?

ks.load(fis, password) На клиенте он будет.

Про keystore понятно. Я же про SQLClipher писал, что ключ у разраба.

Про keystore понятно. Я же про SQLClipher писал, что ключ у разраба.

Как он расшифровывает/зашифровывает на клиенте без ключа? :)

Ключ может в нативе забит? Или я ошибаюсь)

@pahakorolev а по отдельный слой. Тут в ишюзах, смотрю, поднято обсуждение по этой теме. Там он объясняет, почему он так не считает https://github.com/android10/Android-CleanArchitecture/issues/64

Спасибо, перечитал, там и продолжение есть (https://github.com/android10/Android-CleanArchitecture/issues/182). Вот я как раз в одном из проектов столкнулся с такой же проблемой и думаю над решением. Сначала это были просто картинки, потом еще добавились файлы (пришлось допиливать glide), потом они начали использоваться на нескольких экранах, а сейчас еще в недалеком будущем появляется задача загрузки содержимого по запросу пользователся. Так же последовала куча багов, решение которых ну никак не ложится в слой presentation.

Привет! Не подскажите как решить мою проблему? Я использую retrofit +rx есть гет запрос которы возвращает при успехе {}

а в чем вопрос то?

Привет! Не подскажите как решить мою проблему? Я использую retrofit +rx есть гет запрос которы возвращает при успехе {}

А человек который бэк писал где-нибудь рядом? =)

чтобы ударить его?)

зачем сразу бить? можно провести бесседу

{success: true} бывают и такие

204 No Content!

{success: true} бывают и такие

success: failed ещё бывает

ERROR: S client not available

{ “flag”: true, “data”: “p1” } и при неудаче { “error”: “someerror”, “error_description”: “Here error” } в обоих случаях ответы приходят http code 200 соответсвенно Observable<ResponeSwitch> responseSwitchObservable = apiServiceProvider.initSwitch(value); Subscription subscription = createAuthObservable .observeOn(AndroidSchedulers.mainThread()) .subscribe(responseSwitch -> { response.isSuccessful(); hideProgress(); }, throwable -> { hideProgress(); if (throwable instanceof IOException) { getViewState().showError("Network error. Please check your internet connection"); } });

```

```

pastebin

как отловить error если http code 200

response.isSuccessful()

response.isSuccessful() http code 200

напиши интерсептор и в нем смотри.

Ребят, вы сейчас делаете большую ошибку

В поисках выхода из такой ситуации прогер бекенда вешается на шею

И делает анархию

Если запрос имеет ошибку в ответе, то уж 200 нельзя отдавать просто по логике

ну если нет способа попросить поменять его что то

есть OpenWeatherAPI - там все запросы 200

Тут еще проблема в чем

У нормальных ответов есть отдельное место под статус и отдельное под контент

есть ведь люди, которые REST не любят.

Т.е. не то или то или вообще массив

У нормальных ответов есть отдельное место под статус и отдельное под контент

это да.

это да.

В таком случае соглашусь на 200

есть ведь люди, которые REST не любят.

Знаю таких. Сидят на SOAP

Брр

Ну как, запросы так то тоже по базовому протоколу, но мути под капотом больше чем с классическим JSON

У нормальных ответов есть отдельное место под статус и отдельное под контент

???

???

Что?

Место под статус — это HTTP-код, не?

В теле должен быть только ответ

Это протокольная часть

У нас кастомный Subscriber для этого используется

Теоретически, там должна быть ошибка в случае ошибки протокола, а не ошибки обработки данных к примеру

Т.е. "Я сервер, я понял что ты просил список абонентов, но их пока нет, держи 200 с жсон в котором еррор"

Только вот надо структуру ответа тож соблюдать