А стоит ли в таком случае создавать глобальную переменную value если, допустим, с этой переменной происходит приведённая ниже манипуляция? Или это будет лишним? Я имею в виду с точки зрения нагрузки на память устройства, процессор и т.д.

   

private fun myfun()
    {
        var value = 5
        value += 10
    }

ну дык что происходит с переменной когда она из под скоупа выходит ?

Она не выходит из скоупа, она локальная.
Она живёт, пока выполняется метод. Потом стирается сама.

GB тут вообще не причём.

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

нет

Опа, вот понятно, спасибо

Если нужно больше инфы, то нужно читать в сторону того как в JVM устроена память.
Конкретно - stack и heap. Где что хранится.

private fun myfun()
    {
        var value = 5
        value += 10
    }

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

вот за эт пасибо )

Да, я в примере привёл прежний код, только добавил примитивную манипуляцию

После ознакомления, мб будет интересна информация по такому поисковому запросу:

https://www.google.com/search?q=does+java+garbage+collector+clean+both+heap+and+stack+memory&oq=java+garbage+collector+stack+and+hea&aqs=chrome.1.69i57j0.9648j0j7&sourceid=chrome&ie=UTF-8

👍

Друзья у меня вопрос.
Ранее писал на джаве по патерну мвп, у меня был репозиторий, интерактор и презентер, вся логика была в интерактре по минимуму в ппежентере. Сейчас перешёл на Котлин и мввм, и вопрос вот в чем, как я понял в мввм интерактор не нужен, нужен репозиторий и сразу вювмодел. Например у меня есть Preferencec он injecti тянется в репозиторий, а репозиторий во вюв модел. Бизнес логику теперь всю делать в репозитории? Или же во вюв модел?. И ещё вопрос если хочу слушателя поставит на Preferencec, то как это сделать?

Интерактор никуда не девается

Тоест интерактор по прежнему должен быть?

У тебя поменялась архитектура слоя представления, но остальное почему должно поменяться ?)

Потому что я запутался))))

@Horun
При переходе с mvp на mvvm у тебя, по сути, презентер заменится viewmodel, которая также будет дергать интеракторы, а вот результат она будет не во вьшку спамить (как это делал презентер), а в свою livedata, а вот вьюшка тупо подпишется на livedata этой viewmodel и будет просто оттуда брать свежие данные для показа. Т.е. теперь вьюшке не диктуют, что показать, а наоборот, она сама знает на че подписаться и как и откуда брать данные.

Все остальное слои data (datasource, repository), domain (usecase/interactor, и прочее) остаются не тронутыми, ибо им пофиг на изменения в слое presentation.

MVP/MVVM/MVI и прочее: это слой presentation, т.е. как че показывать и откуда брать данные, у mvp это презентер, у mvvm - viewmodel (которая сама знает, как пережить тот же поворот экрана), у mvi - будет некий store... но это уже совсем другая история.

Просто визуально нужно открыть clean architecture картинку, и пару картинок с mvp/mvvm, посмотреть как оба способа представления уживаются в клине (CA), станет яснее: https://uploads.toptal.io/blog/image/127608/toptal-blog-image-1543413671794-80993a19fea97477524763c908b50a7a.png

Первые два блока - это твоя view и presenter/viewmodel соответственно