Koin в Android на практике c MVVM 

Ролики по образованию в целом не особо популярная тема.

Аналогично. Учусь и разбираю, объяснение просто замечательные

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

👍

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

Ребята, спасибо большое, что пишите про ошибки в комментариях. Прям очень помогли. У меня та же ошибка

А у меня крашилось с Found interface kotlin.time.TimeMark, but class was expected .... Спасибо, натолкнули на мысль Debug поменял на Error, и запустилось.

Да, будет обязательно пример на более сложном проекте.

factory используют, когда необходимо создавать разные инстансы (экземпляры) одних и тех же зависимостей. single - когда необходимо иметь один и тот же экземпляр класса, в разных частях/экранах вашего приложения. Допустим у вас есть два экрана в приложении и один какой-нибудь объект, который может хранить в себе какое-нибудь состояние/данные. Возмем к примеру ту же самую вьюмодель. На одном экране вы подписываетесь на какую-нибудь livedata из вашей вьюмодели. И на другом экране проделываете тоже самое. Если вы отметили вашу вьюмодель как single, то на двух ваших фрагментах(экранах), в случае восстановления/ перевороте экрана, вы будете получать одно и то же состояние и одни и те же данные. Если вы отметили вашу вью модель как factory, то на двух фрагментах у вас будет создано два разных экземпляра вьюмодели. И весь ваш стейт будет различный. Ваш первый фрагмент будет иметь свой экземпляр вьюмодельки и никак не влиять на другой второй фрагмент. Конечно у коина так же есть скоупы, которые позволяют разрулить жизненный цикл ваших зависимостей, относительно того, жив ли допустим ваш экран или нет. При этом сценарии, зависимости указанные как single и привязанные к какому то скоупу, будут все равно уничтожаться и пересоздаваться, ровным счётом также, как factory.

Ага. Если только ваше приложение состоит из одного экрана и 1-го модуля ) Когда вы решите сделать многомодульное приложение, с десятками экранов, то это уже не будет выглядеть как отличная замена. Особенно когда начнёте получать ошибки предоставления зависимостей в рантайме, а не на момент компиляции кода =)

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

Стараюсь всем отвечать, но уж очень много заявок, физически не успеваю всем быстро ответить.

Да, просто поделите папками и все.

Ошибаетесь. В Koin тоже можно делать отдельные компоненты для экранов или фичей и загружать/выгружать их по необходимости

У всех свои плюсы есть, мне лично koin больше нравится)

Paging 3 это либа из androidx, в домене ее не должно быть. Поэтому тут нужно использовать свои объекты в домене и пейджинг использовать только на presentation. Я бы ее вообще не использовал, реализовать пейджинг задача не сложная и вполне можно обойтись своим кодом.

Да, все должно быть в models{}. В целом, мне лично, подход с явным объявлением провайдеров больше нравится, можно легко найти все провайдеры для моделей в одном месте. Но приходится платить за это размером кода. Такого как в Hilt в Koin нет.

@@TimofeyKovalenko Спасибо за ответ. Тогда какие best practices в случае много модульного проекта? Например: ест модуль UI в нем есть models{}, модуль UI видит модуль app. Как передают models из UI в app для выполнения startKoin()?

app модуль ничего не должен знать про UI модуль. Зачем вам в app передавать зависимости ViewModel?

Вот вот, уже в процессе).

У меня та же ошибка, тоже не могу понять, почему ее выдает

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

В том то и суть, что каждый слой может добавить туда что-то, не затрагивая другие зависимости. Тоесть работает только со своим объектом. А если глобально что то нужно будет добавить, то да, нужно будет добавить на всех уровнять, точнее добавить поддержку в каждой из частей индивидуально.

BaseFragment и BaseRepository - очень плохая практика. Особенно BaseFragment -, от этого лучше избавиться, что-бы у вас не было базовых классов для фрагментов или активити. Ну а если без этого никак, то у вас должен быть какой-то core модуль, например core-presentation где будут находится общие ресурсы для ваших модулей.

@@TimofeyKovalenko а по какой причине BaseFragment и ему подобные это плохая практика?

В течении жизни проекта в них копиться очень много кода, и в итоге получается так, что все экраны очень жестко зависят от кода базового фрагмента. Истории про то, что все мы умные и ничего туда лишнего закидывать не будет полная ерунда ;), через пару лет базовый фрагмент в проекте превратиться в спагетти.Да и наследование само по себе усложняет код, поэтому лучше этого избегать.

@@TimofeyKovalenko Здравствуйте,Тимофей.Почему BaseFragment - плохая практика?Да и вообще,почему базовые классы с общней логикой являются плохой практикой,когда они позволяют нам избегать повторяющегося кода?(DRY - Don't repeat yourself). К тому же базовые классы помогают в инкапсуляции,позволяют не открывать наружу константы,чтобы делать их доступными для всех,можно сделать константы protected и там,где они будут нужны унаследоваться от Base класса.

@@TimofeyKovalenko особенно когда нужен простой фрагмент, а описывать вроде бы всё заново лень.. Смотришь, ого - есть же BaseFragment, и наследуешься от него. А потом у нас все фрагменты живут по принципу: И жнец и швец и на дуде игрец ))

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

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

Тоже самое, import правильный

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

Для Koin вполне подходят файлы, это же по сути тот же статик будет только без объекта, нет необходимости именно object писать. И так и так можете делать.

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

А где вы используете androidLoggin? Так же как в примере?

@@TimofeyKovalenko (опечатался, Logger). Да, верно, полностью копирую Ваш пример. Стоит закоментить строчку androidLogger(Level.Debug) (которая на 23:15) и все работает. Странно, может какой-то глюк AndroidStudio.

Хм, я думаю дело не в Logger. Из за этой строчки не должно падать, скорей всего проблема не здесь.

Так же как и сейчас ;), или что вас смущает в сompose?

@@TimofeyKovalenko это тонкий намек на то что вы осветили лишь императивный ui в compose нужна udf архитектура. И Koin там чуть по другому работает. P. s. Хотелось бы увидеть просветление этой темы.

Да, сделаю такое видео).

Такая же беда, все как в видео, но крашится бесконечно.

Попробуй поставить Level.None, тогда ничего не крашится.

@@alexandralban5682 Попробуй поставить Level.None, тогда ничего не крашится.