Половину(если не больше) ui рисую программно через anko. Вот там реально хардово, когда у тебя никакого preview нет)

Так anko DSL preview плагин есть

На Studio 2.2 нет

А на 2.2 я сижу с Preview 1

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

а это что http://screencast.com/t/f5sPT0vJ

блин, телеграм ведь умеет картинки передавать, зачем screencast-com? :)

Лень было человеку картинку скопировать)

я прикипел к monosnap – скриншотит и рисует на картинке, а потом можно схватить за уголок и дропнуть в нужное приложение (=

У меня ножницы из onenote

в буфер копируют

я прикипел к monosnap – скриншотит и рисует на картинке, а потом можно схватить за уголок и дропнуть в нужное приложение (=

Monosnap говоришь... Надо глянуть

угу. и на маке и на винде

хотя на маке еще одну штуку держу – snappy-app, она тоже скриншотит, но оставляет захваченное в виде стикеров на экране, и библиотеку их ведет

удобно пиксели сверять)

Спасибо

Joxi ещё есть

Я сейчас пользуюсь Jing

Так MVP нифига не решает проблемы поворота

Опять наброс?

Каким боком способ композиции кода к жизненному циклу?

Ну тут просто говорили что решает

Это тоже самое что написать венгерская аннотация не решает проблемы поворота

Каким боком способ композиции кода к жизненному циклу?

Если презентер ЗАИНЖЕКТИТЬ СИНГЛТОНОМ, то решает

Ок... И при чем тут презентер, можно любой объект так держать в памяти

Или отключить пересоздание активити при повороте

Хотя это уже больше на костыли похоже. Так как есть еще много вариантов при которых активити будет пересоздаватся

Ок... И при чем тут презентер, можно любой объект так держать в памяти

Нельзя! Утечка будет

Так вью надо обнулить а потом прибаиндить снова новую )

))))))))) где ты ее обнулишь?

)))))

И не только из-за вью утечет

))))))))) где ты ее обнулишь?

В методах жизненного цикла

От чего утечет?

От чего утечет?

Из-за контекстов, активити, которые захватил этот ЛЮБОЙ ОБЪЕКТ, который заинжекчен

Если презентер ЗАИНЖЕКТИТЬ СИНГЛТОНОМ, то решает

А если у тебя в презентере что-то отработает пока вьюха не создалась и призентер ещё никуда не присоединился?)))

А если у тебя в презентере что-то отработает пока вьюха не создалась и призентер ещё никуда не присоединился?)))

Присоединится и заберет результат закешированный

Присоединится и заберет результат закешированный

Вот это и есть проблема переворотов. Такую систему надо запилить, чтобы она работала. Чтобы оно само всё доставило куда и когда надо

Вот это и есть проблема переворотов. Такую систему надо запилить, чтобы она работала. Чтобы оно само всё доставило куда и когда надо

Ну да, легче много бесполезного кода MVP напилить, чем полезный код, который реально решает проблему

Из-за контекстов, активити, которые захватил этот ЛЮБОЙ ОБЪЕКТ, который заинжекчен

Насчет даггера не скажу, не работал с ним

Ну да, легче много бесполезного кода MVP напилить, чем полезный код, который реально решает проблему

При чём тут MVP?

Ну путай теплое с мягким

При том что везде пишут какое оно крутое и решает проблемы

Тотже Mosby moxy

Ничего оно не решает. Самая большая проблема - момент когда что-то в презе отработало, а вьюха ещё не пересоздалась

Схемы у них нарисованы как вью атачится и забирает кеш

забей, пиши как раньше

Ахаха

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

о MVVM

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

Мимо

Тк observablefield

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

всегда так делаю, кстати

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

Логика в xml? Не, не употребляем

я просто в уме верстаю, ну может еще в тетрадке

Логика в xml? У вас MVP головного мозга

Указать android:text="@={vm.text}" вместо горы кода конечно печально да

Логика в xml? У вас MVP головного мозга

Если у всех мвп головного мозга, а у тебя нет, значит с тобой что-то не так?

я просто в уме верстаю, ну может еще в тетрадке

Хмм лично я обычно хмл наверстаю потом в дизайнере смотрю что получилось

MVP, которое решает проблемы жизненного цикла - это Moxy ?

Moxy хранит презентеры в статической мапе, поэтому ненужен он

И что что в статичной мапе?

то что утечки могут, да и так жрать озу будет

Да грянет холивар)

какие утечки? когда view финиширует, презентер уничтожается. утеек нет, потому что ссылок на View в презентере нет

какие утечки? когда view финиширует, презентер уничтожается. утеек нет, потому что ссылок на View в презентере нет

Статическая мапа нафига? Ниче не убивается

Там так сделано: конечно сама мапа никого не удаляет. Но когда View финиширует(т.е. например пользователь ушел по бэк стеку назад), она сообщает в делегат, что она финиширует. Тогда он идёт в это статичное хранилище и убирает из него Presenter. Получается, ссылкок на Presenter нигде не остаётся. И GC его успешно собирает. А на случай, если вы сохраняете ссылку на Presenter где-то в асинхронщине, будет вызван метод презентера onDestroy. Там и можете удалить эту ссылку. Например, сделать Subscription.unsubscribe(), но и то только если это критично

Там так сделано: конечно сама мапа никого не удаляет. Но когда View финиширует(т.е. например пользователь ушел по бэк стеку назад), она сообщает в делегат, что она финиширует. Тогда он идёт в это статичное хранилище и убирает из него Presenter. Получается, ссылкок на Presenter нигде не остаётся. И GC его успешно собирает. А на случай, если вы сохраняете ссылку на Presenter где-то в асинхронщине, будет вызван метод презентера onDestroy. Там и можете удалить эту ссылку. Например, сделать Subscription.unsubscribe(), но и то только если это критично

private Map<Class<? extends MvpPresenter>, Map<String, MvpPresenter>> mGlobalPresenters = new HashMap<>(); private Map<Class<? extends MvpPresenter>, Map<String, MvpPresenter>> mWeakPresenters = new WeakValueHashMap<>(); врятли они убиваются

ERROR: S client not available

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

private Map<Class<? extends MvpPresenter>, Map<String, MvpPresenter>> mGlobalPresenters = new HashMap<>(); private Map<Class<? extends MvpPresenter>, Map<String, MvpPresenter>> mWeakPresenters = new WeakValueHashMap<>(); врятли они убиваются

public MvpPresenter remove(PresenterType type, String tag, Class<? extends MvpPresenter> clazz) { Map<String, MvpPresenter> tagMvpPresenterMap = getPresenters(type).get(clazz); if (tagMvpPresenterMap == null) { return null; } return tagMvpPresenterMap.remove(tag); }

public MvpPresenter remove(PresenterType type, String tag, Class<? extends MvpPresenter> clazz) { Map<String, MvpPresenter> tagMvpPresenterMap = getPresenters(type).get(clazz); if (tagMvpPresenterMap == null) { return null; } return tagMvpPresenterMap.remove(tag); }

и где вызывается?

вот этот метод вызывается тогда, когда надо

сек :D

https://github.com/Arello-Mobile/Moxy/blob/master/moxy/src/main/java/com/arellomobile/mvp/MvpDelegate.java#L166

if (presenter.getPresenterType() == PresenterType.LOCAL)

да, а глобальные это специальные презентеры, которые живут всегда

А по поводу скриншотилок - на винду лучшая по мне это ShareX. Опенсорс программа с возможностью подключения различных хостингов изображений. (Ну и еще куча функций, скриншот за 1 клик делается, но можно т рисовать на нем). Из хостинга пользуюсь puush.me - порой подтормаживает, но зато выдает прямую ссылку на изображение, а не ссылку на страницу с картинкой среди рекламы

а weak-презентеры живут в WeakValueHashMap и поэтому когда ни одна View на него не ссылается, он дестроится

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

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

mosby лучше

mosby лучше

ok =) нам не понравилось то, что нужно руками делать сохранение/восстановление стейта, но на вкус и цвет фломастеры разные :D

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

Ну да, когда в коде каша тоже не особо приятно поддерживать

ok =) нам не понравилось то, что нужно руками делать сохранение/восстановление стейта, но на вкус и цвет фломастеры разные :D

moxy без написания класса вьюстейта чтоли восстанавливает?

так ведь да :D достаточно пометить класс презентера аннотацией @InjectViewState

так ведь да :D достаточно пометить класс презентера аннотацией @InjectViewState

в каком приложении посмотреть?

например в https://github.com/Arello-Mobile/MoxySample

продакшен хотел

у нас пока 2 проекта на мокси ждут релиз

так ведь да :D достаточно пометить класс презентера аннотацией @InjectViewState

а после убийства аппы восстанавливает стейт?

у мосби в 11раз больше звезд

нет, презентер не умеет восстанавливаться. если оень нужно, то придётся передать bundle saveState в презентер, сохранить нужны параметры и затем восстановить из того же bundle

ну да, про moxy только одна статья на аглийском, не очень большая. а про мосби Дорфмэн много написал. Кстати, очень хорошие статьи у него, чтобы понять, как пользоваться MVP вцелом =)

нет, презентер не умеет восстанавливаться. если оень нужно, то придётся передать bundle saveState в презентер, сохранить нужны параметры и затем восстановить из того же bundle

@InjectViewState же должен помочь в востановлении после убийства

@InjectViewState создаёт класса ViewState, который в себе запоминает команды, которые уходили из Presenter → View. А не само состояние View. И когда View аттачится к презентеру, эта очередь команд уходит во View, благодаря чему она принимает нужное состояние.

самое время забить себе юзернейм @InjectViewState

И если схоранить этот ViewState в Bundle saveState, то получается легко может быть ситуация, что будет сохранена команда "показать прогресс", а когда процесс будет восстановлен, View покажет этот прогресс. Но Presenter и думать не думал начать что-то грузить =) поэтому лучше сперва передать бандл в презентер, а потом ре-инициализировать презентер тем же бандлом. Тогда и View будет максимально простая, и логика восстановления состояния View-Presenter после уничтожения процесса будет лежать в Presenter, который как раз является самым подходящим для этого местом :D

самое время забить себе юзернейм @InjectViewState

@BindView всё ещё свободно

а

не, обманул

Обманул