AD
Fly N
Подскажите плагин для Android Studio для нарезки картинок - hdpi. mdpi и т.д
Android asset studio сайт обычно используют
Size: a a a
2017 January 31
ЫК
Android Drawable Importer
sm
Android asset studio сайт обычно используют
Сайт? В самой студии есть что-то похожее.
ЫК
👆плагин
FN
Android asset studio сайт обычно используют
Спасибо
sm
👆плагин
Ну может и плагин, я поставил студию, и, он в ней уже был, а вот для котлина и для даггера пришлось ставить плагин.
sm
Плагин даггера мечом показывает зависимости, про него Дима из яндекса в подкасте рассказывал, или не в подкасте)
М
Плагин даггера мечом показывает зависимости, про него Дима из яндекса в подкасте рассказывал, или не в подкасте)
он ваще дает какого-то удобства?
М
я обычно на ctrl + click навигируюсь
sm
он ваще дает какого-то удобства?
Ну можно кликнуть на меч и перейти в модуль откуда инжектится.
sm
Ну как контрол+ би в обычных случаях.
AK
Fly N
Подскажите плагин для Android Studio для нарезки картинок - hdpi. mdpi и т.д
Material Icon Generator его юзаю
D
для винды
D
могу скинуть экзешник
D
хотя мне кажется это немного оффтоп..
I
Чем студия плоха?
I
Тоже самое ведь делает
AZ
@eugene_matsyuk Здесь уже кажется обсуждали ваши архитектурные решения, но я хотел дополнительно задать вам вопрос.
В большинстве литературы и опенсорсах трехуровневая архитектрура (слой пользовательского интерфейса (представления), слой бизнес-логики, слой доступа к данным) представлена следующей схемой зависимостей: слой пользовательского интефейса зависит от слоя бизнес - логики, слой доступа к данным зависит от слоя бизнес-логики, бизнес-логика не зависит ни от одного слоя (presentation -> domain <- data). Если говорить об андроиде, то слой пользовательского интерфейса (представления) будет знать о всех слоях, которые есть в приложении, так как в этом слое происходит связываение всех зависимостей в приложении.
Профит от такого подхода, конечно в реалиях, это возможно будет не настолько просто, но усилий нужно приложить меньше, чем при других подходах:
1. Можем заменить пользовательский интерфейс не затронув другие слои
2. Можем заменить библоиотеку доступа к данным не затронув другие слои
3. Бизнес-логика является ядром приложения и без лишних зависимостей может быть перенесена куда угодно, другое приложение, другая платформа и т.д.
Насколько я понял из доклада, у вас IRepository и Repository в слое доступа к данным, получается инверсии зависимостей между слоями нет и бизнес-логика зависит от слой доступа к данным. В вашей схеме интеракторы занимаются маппингом в UI модели, получается, что они знают про слой пользовательского интерфейса.
В итоге схема зависимостей у вас примерно такая presentation <--> domain -> data. Что теоретически лишает вас некоторых вышеперечисленных профитов.
Расскажите о том, что послужило поводом для такого решения, какие преимущества у вашего подхода и почему не используете вышеупомянутую схему зависимостей? Должен признаться, пока ни одним из профитов архитектуры, которые перечислил не приходилось воспользоваться, но это стандартное решение.
В большинстве литературы и опенсорсах трехуровневая архитектрура (слой пользовательского интерфейса (представления), слой бизнес-логики, слой доступа к данным) представлена следующей схемой зависимостей: слой пользовательского интефейса зависит от слоя бизнес - логики, слой доступа к данным зависит от слоя бизнес-логики, бизнес-логика не зависит ни от одного слоя (presentation -> domain <- data). Если говорить об андроиде, то слой пользовательского интерфейса (представления) будет знать о всех слоях, которые есть в приложении, так как в этом слое происходит связываение всех зависимостей в приложении.
Профит от такого подхода, конечно в реалиях, это возможно будет не настолько просто, но усилий нужно приложить меньше, чем при других подходах:
1. Можем заменить пользовательский интерфейс не затронув другие слои
2. Можем заменить библоиотеку доступа к данным не затронув другие слои
3. Бизнес-логика является ядром приложения и без лишних зависимостей может быть перенесена куда угодно, другое приложение, другая платформа и т.д.
Насколько я понял из доклада, у вас IRepository и Repository в слое доступа к данным, получается инверсии зависимостей между слоями нет и бизнес-логика зависит от слой доступа к данным. В вашей схеме интеракторы занимаются маппингом в UI модели, получается, что они знают про слой пользовательского интерфейса.
В итоге схема зависимостей у вас примерно такая presentation <--> domain -> data. Что теоретически лишает вас некоторых вышеперечисленных профитов.
Расскажите о том, что послужило поводом для такого решения, какие преимущества у вашего подхода и почему не используете вышеупомянутую схему зависимостей? Должен признаться, пока ни одним из профитов архитектуры, которые перечислил не приходилось воспользоваться, но это стандартное решение.
I
@eugene_matsyuk Здесь уже кажется обсуждали ваши архитектурные решения, но я хотел дополнительно задать вам вопрос.
В большинстве литературы и опенсорсах трехуровневая архитектрура (слой пользовательского интерфейса (представления), слой бизнес-логики, слой доступа к данным) представлена следующей схемой зависимостей: слой пользовательского интефейса зависит от слоя бизнес - логики, слой доступа к данным зависит от слоя бизнес-логики, бизнес-логика не зависит ни от одного слоя (presentation -> domain <- data). Если говорить об андроиде, то слой пользовательского интерфейса (представления) будет знать о всех слоях, которые есть в приложении, так как в этом слое происходит связываение всех зависимостей в приложении.
Профит от такого подхода, конечно в реалиях, это возможно будет не настолько просто, но усилий нужно приложить меньше, чем при других подходах:
1. Можем заменить пользовательский интерфейс не затронув другие слои
2. Можем заменить библоиотеку доступа к данным не затронув другие слои
3. Бизнес-логика является ядром приложения и без лишних зависимостей может быть перенесена куда угодно, другое приложение, другая платформа и т.д.
Насколько я понял из доклада, у вас IRepository и Repository в слое доступа к данным, получается инверсии зависимостей между слоями нет и бизнес-логика зависит от слой доступа к данным. В вашей схеме интеракторы занимаются маппингом в UI модели, получается, что они знают про слой пользовательского интерфейса.
В итоге схема зависимостей у вас примерно такая presentation <--> domain -> data. Что теоретически лишает вас некоторых вышеперечисленных профитов.
Расскажите о том, что послужило поводом для такого решения, какие преимущества у вашего подхода и почему не используете вышеупомянутую схему зависимостей? Должен признаться, пока ни одним из профитов архитектуры, которые перечислил не приходилось воспользоваться, но это стандартное решение.
В большинстве литературы и опенсорсах трехуровневая архитектрура (слой пользовательского интерфейса (представления), слой бизнес-логики, слой доступа к данным) представлена следующей схемой зависимостей: слой пользовательского интефейса зависит от слоя бизнес - логики, слой доступа к данным зависит от слоя бизнес-логики, бизнес-логика не зависит ни от одного слоя (presentation -> domain <- data). Если говорить об андроиде, то слой пользовательского интерфейса (представления) будет знать о всех слоях, которые есть в приложении, так как в этом слое происходит связываение всех зависимостей в приложении.
Профит от такого подхода, конечно в реалиях, это возможно будет не настолько просто, но усилий нужно приложить меньше, чем при других подходах:
1. Можем заменить пользовательский интерфейс не затронув другие слои
2. Можем заменить библоиотеку доступа к данным не затронув другие слои
3. Бизнес-логика является ядром приложения и без лишних зависимостей может быть перенесена куда угодно, другое приложение, другая платформа и т.д.
Насколько я понял из доклада, у вас IRepository и Repository в слое доступа к данным, получается инверсии зависимостей между слоями нет и бизнес-логика зависит от слой доступа к данным. В вашей схеме интеракторы занимаются маппингом в UI модели, получается, что они знают про слой пользовательского интерфейса.
В итоге схема зависимостей у вас примерно такая presentation <--> domain -> data. Что теоретически лишает вас некоторых вышеперечисленных профитов.
Расскажите о том, что послужило поводом для такого решения, какие преимущества у вашего подхода и почему не используете вышеупомянутую схему зависимостей? Должен признаться, пока ни одним из профитов архитектуры, которые перечислил не приходилось воспользоваться, но это стандартное решение.
Разве с обычным мвп у нас будут проблемы при замене каких-то частей?