Ну нахрен короче(

какой то дополнительный эндпоинт на сервере и при запуске аппы проверять?

Да, сверять версии и уведомлять, если принудительно, то не пускать дальше в приложение, если нет, то просто как уведомление

При чем тут php?

Локально работает, из удаленного сервера не работает

Ну так чат все таки по андроиду) а тут вопрос по php

народ, можно ли в анимации созданной с помощью constraint motion layout менять атрибуты TextView(textColor, maxLines, textSize)? пытался использовать PropertySet но он не поддерживает эти атрибуты(

подскажите лучшие практики по обработке ошибок. 1. Кто отвечает за проектирование обработки ошибок? Архитекторы, дизайнеры или разработчики? 2. С чего начинать проектирование? Приходит архитектор или разработчик к дизайнеру и рассказывает какие могут быть ошибки, а тот придумывает как мы на них реагируем? Или все на дизайне есть только благоприятный сценарий, а разработчик сам придумывает что ему делать с ошибками? Просто уже не раз попадал в ситуацию, когда приходится на ходу придумывать что делать. А потом синхронизировать с тем, что придумали iOS-разработчики 3. Хорошая практика делать обработку ошибок и оборачивание их в свои эксепшены для пробрасывания дальше по цепочке? Например сделать ErrorInterceptor для okhttp.

Привет. Есть подход обрабатывать исключения делегатами. Можно создавать разные делегаты для разных случаем. Внутри обычный if..else или when. Реакцию на исключение можно передавать в лямбду например. errorHandler.handle(error, {message -> view.showError(message})

а делегатов держать в презентере/вьюмодели?

Да, инжектить туда экземпляры

Я передаю список с этим классом в другое активити

Передаете список с _экземпляром класса_ же?

/spam

хз как она работает, но я забанил

подскажите лучшие практики по обработке ошибок. 1. Кто отвечает за проектирование обработки ошибок? Архитекторы, дизайнеры или разработчики? 2. С чего начинать проектирование? Приходит архитектор или разработчик к дизайнеру и рассказывает какие могут быть ошибки, а тот придумывает как мы на них реагируем? Или все на дизайне есть только благоприятный сценарий, а разработчик сам придумывает что ему делать с ошибками? Просто уже не раз попадал в ситуацию, когда приходится на ходу придумывать что делать. А потом синхронизировать с тем, что придумали iOS-разработчики 3. Хорошая практика делать обработку ошибок и оборачивание их в свои эксепшены для пробрасывания дальше по цепочке? Например сделать ErrorInterceptor для okhttp.

отвечай !спам на сообщение, тогда улетает в бан во многих группах сразу + сохраняется в логи

полагаю только от админа работает?)

ого, это ещё и проектируют, а я просто делал интерфейс с двумя колбэками, onSuccess и onError

Горит, что onSuccess и onError Если бы был onFailure, то хотя бы длина была бы одинаковой

это прям так же важно, как и есть ли в ЯП точки с запятой в конце строки

это прям так же важно, как и есть ли в ЯП точки с запятой в конце строки

о, ну всё, можно начинать срач (нет)

Говорят, это псих.расстройство

ого, это ещё и проектируют, а я просто делал интерфейс с двумя колбэками, onSuccess и onError

подскажите лучшие практики по обработке ошибок. 1. Кто отвечает за проектирование обработки ошибок? Архитекторы, дизайнеры или разработчики? 2. С чего начинать проектирование? Приходит архитектор или разработчик к дизайнеру и рассказывает какие могут быть ошибки, а тот придумывает как мы на них реагируем? Или все на дизайне есть только благоприятный сценарий, а разработчик сам придумывает что ему делать с ошибками? Просто уже не раз попадал в ситуацию, когда приходится на ходу придумывать что делать. А потом синхронизировать с тем, что придумали iOS-разработчики 3. Хорошая практика делать обработку ошибок и оборачивание их в свои эксепшены для пробрасывания дальше по цепочке? Например сделать ErrorInterceptor для okhttp.

Говорят что в яндексе за необр.исключение увольняют нах. (2) на этой стадии списка ошибок может не быть. Но когда при написании реализации он появится окончательно - неплохо бы вернуться и обсудить. (3) если метод пробрасывает свои ошибки выше - то для нескольких разных но схожих методов можно сделать общий обработчик. К примеру у нас есть общий метод шифровать/дешифровать из него несколько для шифрования с разными параметрами - эксепшн "шифрование не подерживается" обрабатываем в одном месте

Говорят, что в Яндексе есть много разных команд со своими руководителями и местными правилами.

не может быть

люди, кажется, реально думают, что нет

а что реально есть такие команды в которых увольняют за ошибку?

никогда о таком не слышал

ты же в яндексе работаешь?

Говорят что в яндексе за необр.исключение увольняют нах. (2) на этой стадии списка ошибок может не быть. Но когда при написании реализации он появится окончательно - неплохо бы вернуться и обсудить. (3) если метод пробрасывает свои ошибки выше - то для нескольких разных но схожих методов можно сделать общий обработчик. К примеру у нас есть общий метод шифровать/дешифровать из него несколько для шифрования с разными параметрами - эксепшн "шифрование не подерживается" обрабатываем в одном месте

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

ого, это ещё и проектируют, а я просто делал интерфейс с двумя колбэками, onSuccess и onError

Ну тут уж хз, у меня в ВК это было достаточно просто сделано. С тех пор, конечно, это всё наверняка переписали на говнокод котлин, ну да ладно. Есть, по сути, 2 вида запросов в апи: которые загружают данные для отображения на экране и которые совершают какие-то действия, опционально с блокирующим прогрессом. Первые показывают ошибку вместо содержимого экрана с кнопкой "повторить попытку", или, если это была подгрузка, плашку внизу списка. Вторые показывают toast. Для первых у меня был готовый фрагмент, где надо реализовать несколько методов и адаптер. Дальше всё само — подгрузка при прокрутке, обработка ошибок, pull to refresh, вот это всё. У вторых это было встроено в саму систему взаимодействия с апи. Честно, не могу даже начать представлять, что тут надо "проектировать". Для некоторых ошибок у меня были локализуемые описания, для всех сетевых отдельное ("при загрузке данных произошла ошибка"), для остальных — просто "ошибка". Были ещё локализованные сервером ошибки, в этом случае надо просто показать строку, которая пришла с сервера.

а если надо дернуть несколько методов чтобы получить все нужные данные. Будешь в onSuccess каждого дергать следующий и так получится лапша из колбэков?

Поскольку это ВК, я это делал через хранимые процедуры или execute :D

а представь что нет такой штуки)

а представь что нет такой штуки)

а представь что нет джавы и писать надо на ассемблере

не, слишком грустно не могу я так

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

вложить колбэки друг в друга вот это и есть самое гавнище, которое превращается в лапшакод. Вот синхронно вариант в принципе...

Вот не надо ничего вкладывать, склеивай фьючи

што

j.u.c.Future

j.u.c.Future

я видел этот класс, но так и не понял, как им предполагается нормально пользоваться