Pull to refresh
13
0
Артур @forceLain

Пользователь

Send message
Буквально вчера достал макбук, который просто пролежал в тумбочке 2 выходных дня: на моей учетке слетел пароль, к wi-fi не коннектится, сброс пароля в recovery mode тоже не помог.
И вот сижу я в начале рабочего дня у разбитого корыта и думаю, ну камон, ты ж просто лежал 2 дня в тумбочке, как ты умудрился так сломаться, я ж с линукса на макос ушел именно для того, что бы не решать эти внезапные проблемы.
Не умеет. Да и стоит ли оно того? Разобфусцировать такие классы глядя в манифест будет не очень трудно :)
Кстати, я не знал куда добавить это в статье, но раз есть такое мнение — напишу в коммент:
Я все больше убеждаюсь, что с прогурадом можно влезть в пресловутые 65к практически с любыми зависимостями. Например, у меня есть проект в котором: google-play-services(локация, реклама, in-app покупки, аналитика), пуши от одно знаменитого сервиса (работает поверх firebase), rxjava, kotlin, okhttp, retrofit, picasso, commons-io, exoplayer и еще горстка третесторонних sdk и мы все еще держимся на уровне ~55k. Просто нужно очень тщательно и аккуратно проинспектировать keep-правила :)
до тех пор пока в проекте не появляются Google Play Services

убедитесь, что вы используете конкретную часть сервисов, а не весь фрэймворк целиком (https://developers.google.com/android/guides/setup)


Можно об этом поподробнее? Это плагин для Android Studio или то что загружает SDK Manager?

Это тот плагин, который вы подключаете последней строчкой в build.gradle:
apply plugin: 'com.google.gms.google-services'


Раньше этот плагин добавлял конфиг, прада сейчас, судя по всему, они просто распространяют свои библиотеки сразу со вшитыми конфигами, так что плагин почти ни при чем. Сейчас плагин просто проверяет корректность настройки, версии библиотеки и наличие google-services.json

Не очень понял, зачем обфусцировать эти имена, системе нужно знать пакет/имя-класса активити, фрагментов, вьюшек и т.п. именно так, как они записаны в манифесте и других xml-файлах, потому что они запускаются через reflection (proguard не умеет изменять содержимое xml-файлов). По той же причине нужно сохранить некоторые «зарезервированные» имена методов (например `onCreate`), если это все поменять — приложение просто не будет работать. Но это не значит, что содержимое этих классов не будет обфусцированно — будет, но по возможности. Вот, например, кусок кода одной из моих активити после обработки:
```
protected void onCreate(Bundle bundle) {
super.onCreate(bundle);
setContentView(R.layout.activity_login);
m18099a((C1594i) new C1594i(null, this));
((C3371b) mo2290t()).m15997c();
}
```
Если все-таки и правда хочется все сломать, то можно:
— НЕ добавлять дефолтный конфиг андроида `getDefaultProguardFile('proguard-android.txt')`
— каким-то образом не добавлять конфиги, сгенерированные aapt, библиотеками и сторонними плагинами — думаю этого можно добиться модификацией gradle-тасок, которые создаются `gradle-android` плагином, но я не пробовал
О, я совсем проглядел IT в предложении :) Тогда да, все правильно в статье
“I graduated in IT from Moscow State University”.

На сколько я знаю, правильно говорить I graduated from IT from Moscow State University
Пока единственное убедительное доказательство вредности телефонов это взрывы их батарей и удары током от их зарядок. И в этом контексте «носить телефон в сумочке или рюкзаке вместо того, чтобы засовывать его в карман одежды» и «Не держать телефон поблизости от головы во время сна» имеют даже больше смысла, чем в оригинальном.
Поддерживаю, RecyclerView + кастомный LayoutManager точно решит эту задачу. Мы как то писали материал на эту тему habrahabr.ru/company/eastbanctech/blog/267497
Спасибо за поздравление, конечно, но мы изобрели это еще в конце 2015-го, если включить режим занудства :)
Концептуально, это разные вещи. В Moxy это хоть и называется ViewState, но по сути представляет собой список вызовов методов view с параметрами и какой-нибудь стратегией, и нужна, судя по всему, лишь для отложенного вызова методов активити/фрагмента, когда они будут доступны. В эту ViewState нельзя просто заглянуть и посмотреть на контент. В Reamp используется в прямом смысле ViewModel, её можно проверить, передать в DataBinding, сохранить куда угодно и много чего еще. У каждого подхода есть плюсы и минусы.

Попробуйте, вам понравится.

Не хочется, что б это выглядело как бросание помидороами, но с прагматичной точки зрения, не очень нравится. Выглядит так, что Moxy удобный до тех пор, пока используешь его по протоптаной дорожке. Пара примеров, которые сразу можно найти:
  • Выглядит так, что в Moxy нельзя сделать CustomView, не используя moxy-родителя активити или фрагмент. CustomView требует mParentDelegate, а откуда его взять?
  • В Moxy странный подход к менеджменту презентеров. Если использовать Moxy-фрагменты внутри ViewPager+FragmentStatePagerAdapter, то при пролистывании фрагментов их презентеры никогда не будут уничтожены, даже если закрыть activity
  • Исходники MvpAppCompatActivity и MvpAppCompatFragment очень разные. Логика связывания фрагмента/активити с презентером отличается (не говоря уже про обычную View). Это значит, что в том случае, когда я использую свою реализацию базовой активити, мне нужно постоянно при обновлении либы сверяться с кодом из фреймворка. Это сложно поддерживать и дебажить.


допускает рассинхронизацию вьюхи и презентера после восстановления приложения.

Презентер получит восстановленное состояние раньше View, у него как раз есть все возможности, что бы понять, что у нас уже есть и что еще нужно сделать (если нужно). Это, пожалуй, одно из основных отличий от Moxy, в котором что бы восстанавливаться после перезапуска все равно придется писать какой-то код по сохранению/восстановлению состояния.
Такая схема позволяет, с одной стороны, мгновенно доставлять push-уведомления всем приложениям (не дожидаясь следующего периода синхронизации), с другой стороны, не держать множество приложений одновременно запущенными.

Простите за офф-топик, но такая схема еще позволяет доминировать на рынке прошивок. На самом деле, телефон без установленных на нем Google Play Services лишается практически всех нужны для нормальной работы приложения механизмов: пушей, карт, локации, activity recognition и т.п.
Согласен, выглядит необычно. Основное намерение этих тестов – проверить, что View (чем бы она ни была) получает правильный state при разных событиях. Другими словами, если логин прошел успешно – state.showSuccessLogin() должен быть true, если результат еще не пришел, state.showProgress() должен быть true, а state.isLoginActionEnabled() – false, и т.д. Вручную вызывается processLoginResult с нужным результатом для того, что бы исключить реальную операцию логина, какой бы она ни была. По хорошему, нужно вынести операцию логина в отдельную сущность и в тестах предоставлять mock-логин (думаю, так и сделаем), просто не хотелось отвлекать от идеи :)

Т.е. если вы забудете реализовать функцию login — то тест все равно будет проходить. Это нормально?

Как раз stateChecks свалится, потому что state не перейдет в ожидаемое состояние.
Там два примера с таймером: Life Cycle 1 и Life Cycle 2. Кажется Вы смотрите на первый. Второй должен вести себя так, как Вы описали.
P.S. на самом деле первый пример тоже сохраняет значение таймера, просто он специально сбрасывается при старте
если у него есть правильные ответы

Такие ответы есть, как правило, у людей с опытом. Как задача для стенда, что бы получить футболку/кружку вполне ок. Как задача для собеседования – не ок. Зачем нужны такие задачи можно найти в книге Java Puzzlersю
Во всем всегда виновата какая-то девочка
забыли вот еще
image
А что на счет setRepeatingRequest и backpressure? Разве не нужно это обрабатывать? Как часто будут прилетать эти события?
все активити остаются висеть в памяти в активном состоянии.

Почему все? Только активная и предыдущая
Плюс при повороте будет создаваться весь стек активити

Как и активных фрагментов
и это заметно

Если это заметно, скорее всего активити/фрагмент делают больше, чем им положено
отсутствие вызова онСтоп не позволяет впрямую обработать переход на новый экран (остановить какой-нибудь поллинг)

Для этого есть onPause
Есть компромиссное решение — делать скриншот экрана

Был и такой вариант :) Под кодовым названием План Y :)
так как они в любом случае остаются видимыми

Это зависит от того, как мы совершаем транзакцию: add или replace. Replace нам удалит предыдущий фрагмент с экрана, так что он тоже не будет видимым и работать это не будет. Add добавит фрагмент поверх предыдущего, однако предыдущий фрагмент не получит onPause()/onResume() колбэков, в отличие от примера с activity. Если использовать подход с фрагментами, то лучше сразу использовать BottomSheetFragmentDialog из дизайнерской либы.

Я бы сказал, что в общем случае лучше руководствоваться здравым смыслом. Если контент фрагментов слишком разный (стили, цвета, набор иконок в тулбаре, наличие и отсутствие бокового меню, интеграция с context), то объединение их в одну активити ради scroll-to-dismiss принесет больше проблем, чем профита.

Information

Rating
Does not participate
Location
Новосибирск, Новосибирская обл., Россия
Date of birth
Registered
Activity