Избавляемся от Context в бизнес логике Как ответить на собеседовании

[@AndroidBroadcast]

🔗 Платная подписка на Boosty abdev.by/oroS и в Telegram abdev.by/lrpW 🔗 Telegram Android Broadcast t.me/+y-LPEB3R5-9mNmRi ✉ Написать Кириллу [e-mail]

[@vladimirpyrkh4422]

Неплохое видео, но осталось какое-то количество вопросов после просмотра. 1. сомнительное утверждение что надо показывать всё что ты знаешь и умеешь. Разве суть задачи не в том, чтобы решить ее максимально оптимальным способом? 2. По поводу разделения слоёв, разве переименование файлов как и работа с файловой системой в целом можно 100% отнести к бизнес логике? 3. если говорить про платформонезависимый код, то очень странно говорить что вполне нормально использовать R класс в таком коде. Да он автогенерируемый и это просто набор интов, но почему он должен быть вообще? А FileRenamer так и продолжает его использовать. 4. Продолжение п.2 но с сущностями Resource, почему используются Int значения в качестве идентификатора ресурса? Откуда уверенность в том, что айди будет именно интом? 5. Самый главный вопрос, почему решение 2 в данном случае хуже чем решение 3? У нас и там, и там есть какой-то класс для предоставление строки из ресурсов. В обоих случаях нам надо писать платформозависимый код для получение ресурсов из конкретной платформа, только в решении 2 это минус, а в решении 3 мы не говорим что это минус. 6. Почему мы говорим что решение 3 более гибкое за счёт того, что мы добавили переменную с ресурсом в сигнатуру метода? В данном конкретном случае у нас не просто переименование файла, т.е. мы не просто меняем имя файла на значение из ресурсов. У нас идёт добавление префикса и это выглядит как более специфическая и узкая задача. Нужна ли нам эта псевдогибкость с параметром префикса вообще? 7. Ну и как уже писали под оригинальным заливом и тут тоже, куда лучше и гибче использовать какие-то константы(енамы, что угодно) и маппер на ресурсы уже непосредственно в UI классе, чтобы что-то рисовать на UI. Как по мне решение 2 сильно лучше чем решение 3 с точки зрения KISS.

[@AndroidBroadcast]

1. сомнительное утверждение что надо показывать всё что ты знаешь и умеешь. Разве суть задачи не в том, чтобы решить ее максимально оптимальным способом? Показал несколько подходов, которые видел как решение

[@stasleonov5196]

Огонь, Кирилл, спасибо большое за материал, очень интересно.

[@AndroidBroadcast]

Пожалуйста. Всегда приятно когда находит своего зрителя материал

[@virtuality_arcade]

Лет 10 назад ещё придумали рабочую активити, сервис или аппликейшн наследовать от resourse manager интерфейса и так инжектить. В контексте выполенения работает на ура

[@A-pe5yy]

Повторюсь еще раз. Зачем все эти доп провайдеры и прочее в бизнес логике? Не правильней было бы: на бизнес слое оперировать модельками бизнес слоя, а в ui уже мапить в строки и прочее, таким образом бизнес логика ничего не знает и не должна знать о строках на ui.

[@hievery9678]

Если речь про то чтобы достать строку, чтобы потом отобразить ее на ui, то соглашусь, использование провайдеров для получения строки из ресурса в бизнес логике - зачастую лишнее. Тем более что если делать это неправильно, то при смене языка на телефоне, текст на экране не сменится. Однако если текст будет использоваться, не для отображения UI, а для каких-либо дальнейших вычислениях, то я не вижу другого выхода. Тот же пример из видео. Как взять новое название файла без констант и провайдеров? Работа с файлами это явно не то, что хочется делать на UI слое.

[@A-pe5yy]

@@hievery9678 по второй части - можно передать текст через параметры функции, например, если название файла задаётся на ui в каком-нибудь поле ввода, то дальше можно прокинуть в бизнес слой с помощью параметров функции.

[@captainsustain]

@@hievery9678 Мне кажется, наиболее подходящее решение - воспринимать R класс как принадлежащий только UI слою, а нужные для бизнес-логики стринги прописывать константами.

[@hievery9678]

@@A-pe5yy Если надо писать название файла в UI, то да, тут без вопросов. Но придет требование чтобы например какие-нибудь бэкап файлы сохранились в локали пользователя и вот уже нет пользовательского поля. Но это уже конечно уж очень редкий случай, в большинстве случаев ресурсы в бизнес логике не нужны

[@hievery9678]

@@captainsustain Будет работать, да. Но ровно до тех пор, пока заказчики не скажут, что нужны локализованные строки в той части бизнес логики о которой мы говорим :) Но как я уже писал на другой коммент, это очень редкий юзкейс и в реальности почти всегда локализованные строки в бизнес логике действительно не нужны.

[@АлександрЯнчеленко]

недавно было что-то подобное в желтый банк, жаль раньше не заметил это видео, можно было бы поумничать )

[@AndroidBroadcast]

Оттуда и была взята задачка

[@ЮкаРазраб]

Не понятно почему вариант с вынесением получения платформозависимого кода из вне вообще не рассматривался. Хотелось бы узнать причину. В видео не раскрыто почему аннотации Res не являются чисто андроидовскими: они есть и на других платформах тоже?

[@AndroidBroadcast]

Весь пакет androidx.annotations уже давно KMP

[@thethirdplace421]

Вчера на ночь посмотрел, что-то на эту тему снилось. Еще раз смотреть?

[@AndroidBroadcast]

Перезалив вынужденный был, а может и знак

[@Wanderspool2807]

Ну, для запоминания как раз лучше вечером перед сном и утром после сна

[@oldg3489]

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

[@AndroidBroadcast]

Абстракции - это не страшно и на большом масштабе кода и команды позволяет строить масштабиремый софт и тестировать его. Оптимизиатор кода R8 потом уберет все лишние прослойки и эффект на код будет минимален. Создавать объекты тоже нестрашно - виртуальная машина ART уже давно нацелена на то что постоянно создается много обёектов

[@Andrey-pu1lv]

а что за клавиатура? Видео тоже крутое)

[@AndroidBroadcast]

Если клавиатура на столе - Logi MX Keyboared

[@sergeykhomichenko1943]

А что делать, если для условных Prefereces для самого их создания нужен контекст? Это же по идее data слой, но туда обычно не хотят контекст закинуть

[@A-pe5yy]

Туда обычно же application context как раз и закидывают )

[@AndroidBroadcast]

Где-то создают экземпляр, обычно в DI, и другие классы смогут его получить

[@maxyablochkin-0505]

На junior такие есть вопросы?

[@AndroidBroadcast]

Вполне могут быть

[@bolnoi8]

Желтый банк - райф?

[@AndroidBroadcast]

Нет )))

[@vahekhachaturian2424]

перезалив?

[@AndroidBroadcast]

Да, перезалив вынужденный

[@alexanderj8981]

А что случилось с первым?

[@AndroidBroadcast]

Удален