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

https://developer.android.com/training/data-storage/app-specific?authuser=1#internal-create-cache вот тут внизу caution

спасибо

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

окей,большое спасибо за инфу

Доброе утро, подскажите пожалуйста, по вопросу https://ru.stackoverflow.com/questions/1264296/%d0%9d%d0%b5-%d0%bf%d1%80%d0%b8%d1%85%d0%be%d0%b4%d1%8f%d1%82-%d0%b0%d0%b2%d1%82%d0%be%d0%bc%d0%b0%d1%82%d0%b8%d1%87%d0%b5%d1%81%d0%ba%d0%b8-%d1%80%d0%b5%d0%b3%d0%b8%d1%81%d1%82%d1%80%d0%b8%d1%80%d1%83%d0%b5%d0%bc%d1%8b%d0%b5-%d1%81%d0%be%d0%b1%d1%8b%d1%82%d0%b8%d1%8f-%d0%b2-firebaseanalytics

Добрый день. Подскажите, пожалуйста, как решить проблему запуска эмулятора "Error while waiting for device: Could not start AVD" после обновления студии

У меня есть фрагмент в котором в список загружаются фотографии из галереи для того, чтобы пользователь мог приложить их к посту в соцсети. И еще хочу реализовать возможность загружать аватар, выбирая фото из галереи. Что в таком случае выбирать для реализации загрузки аватара: дублирование кода или нарушение сингл респонсибилити?

Что то мне кажется, вы напутали. Фрагмент это всего лишь фрагмент, ViewModel это ViewModel
дублирование кода или нарушение сингл респонсибилити?  А это относиться уже к вашим классам, которые реализуют те или иные задачи и зачем это нарушать и для чего не понятно.
То что экран может разные вещи, не означает что логика должна быть в 1-ном классе.

На данный момент логика загрузки фотографий в вьюмодели. Вы имеете в виду, что логику загрузки фотографий стоит вынести в общий класс?

Проверь свободное место на диске. У меня он так не запускался от нехватки места. Либо если эмулятор запускать через консоль, то он напишет конкретную ошибку (почему-то в студию до сих пор не прокидываются его ошибки)

ViewModel всего лишь собирает в себе классы с различной логикой.
Логика загрузки картинок
Логика получение данных Rest API
Логика шаринга в разные места
Это все отдельные классы предоставляющие возможности

Ну хорошо, в данном случае достаточно вынести в другой класс, понял, спасибо

Тогда еще другой вопрос: есть аналогичная ситуация с фрагментом с гугл картой, но логику определения локации пользователя вроде как нельзя вынести куда-либо. В таком случае что делать?

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

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

Не кто не запрещает использовать в классе сохранения, класс резать картинки, просто что бы это разные классы были.

Опять же сами поставили задачу не правильно
1) Фрагмент карт всего лишь отображает карту и показывает то что надо
2) Класс определяющий место положение это вообще то большой скоуп задачи, который к картам не какого отношения не имеет
3) Класс определяющий место положение, может прокинуть слушателем (что для этого используется, это опять же ваш выбор, своя реализация, LiveData, RxJava) и по уведомлению вставляются данные в карту

В скоупе место положения то же будет куча классов, запрос разрешений на определения локаций, реакция на получил/отказал, по хорошему там еще префы вести.
Затем сама логика получение, расчетов, уведомления, старт стоп, возможное еще кэширование. Тут будет то же много классов.
ViewModel свяжет Фрагмент с картой, с данными из определение место положения и других реакций.

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