когда это не имеет значения, пишу loaderManager.getLoader<Nothing>(0).doSomething()

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

Товарищи, такой вопрос. Гугл говорит, что то, что на картинке, может быть заменено на RelativeLayout, и тогда иерархия станет более плоской и эффективной. Но мне кажется, что не всегда, ведь в RelativeLayout всё зависит от всего и может мериться дольше и мучительнее. У кого какой опыт с этим? https://developer.android.com/images/training/hierarchy-linearlayout.png

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

"нормально" — это сколько, если в кадрах в секунду на девайсах 2012 года, например? =)

"нормально" — это сколько, если в кадрах в секунду на девайсах 2012 года, например? =)

а ты меришь кадры?

а ты меришь кадры?

Я когда-то собирался, но потом меня ещё и спровоцировали на это в соседнем чате. :)

Каждая выложенная вьюха сильно бьет по производительности

Товарищи, такой вопрос. Гугл говорит, что то, что на картинке, может быть заменено на RelativeLayout, и тогда иерархия станет более плоской и эффективной. Но мне кажется, что не всегда, ведь в RelativeLayout всё зависит от всего и может мериться дольше и мучительнее. У кого какой опыт с этим? https://developer.android.com/images/training/hierarchy-linearlayout.png

Поэтому в этом случае будет лучше использовать RelativeLayout

Если вьюхи расположены по углам, можно и FrameLayout, но прироста производительности от этого практически не будет

Если вьюхи расположены по углам, можно и FrameLayout, но прироста производительности от этого практически не будет

Т.е. с помощью gravity все раскидать

Поэтому в этом случае будет лучше использовать RelativeLayout

так уже Constraint сделали (как заметили выше)

Не могу на его счет что-то сказать, т.к. сам лично не тестировал

А то что говорят, что он лучше — не знаю, не внушает доверия, где-то может и да, а где-то нет

И пихать везде, уверен, его точно не стоит

везде - нет, для flat view - самое то

Может быть, не спорю. Но вопрос был в том, влияет ли вложенность вьюх на производительность

Ответ — да, еще как

Вопрос — что быстрее, relativeLayout { 3 views } или linearLayout { view, linearLayout { 2 views } }, и какие есть corner cases, связанные с этим.

тут еще нужно учитывать факт как изменение размера вюхи во 2м linearLayout (и как это повлияет на множественные вызовы циклов measure/layout

Лол. У ВКонтакте в списке сообщений — UsableRecyclerView, внутри которого — DialogEntryView. Вот почему он не так тупит при скролле :)

Flat view же

http://lucasr.org/2014/05/12/custom-layouts-on-android/ статья на эту тему

Flat view же

Да, понятно. Я просто немного не ожидал.)

http://lucasr.org/2014/05/12/custom-layouts-on-android/ статья на эту тему

Годная статья, недавно в @shitty_android скидывали.

Парни, я понимаю что вопрос упадет в пустоту, но все же спрошу. Имел кто дело со сборкой AOSP? Интересует как и в чем ковырять некоторое вендорское приложение. Там все конфигурации через android.mk файлы

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

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

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

бродкаст BOOT_COMPLETED?

если вместо рабочего стола, то сделать его лаунчером и поставить по умолчанию

У boot_completed все же есть задержка и видно сначала рабочий стол, а потом уже стартует само приложение

так а какая цель?

сделать киоск?

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

По моему ничего кроме пользовательского лаунчера. Ну и да - лучше не надо так, это жесткое нарушение архитектуры. Если это не вирус конечно :₽

я вот потому и спрашиваю, зачем это надо

если это приложение для пользователей, то так делать, естественно, нельзя

сделать киоск?

Да

тогда просто сделать его лаунчером и не париться)

Так есть же kiosk mode

А ещё есть cosu

http://www.andreas-schrade.de/2015/02/16/android-tutorial-how-to-create-a-kiosk-mode-in-android/

Я интересуюсь ради Best practice

В статье все типы анального огораживания

@grishka а как ты со своим подходом в "лоб" решаешь проблему, что ты типо такой получил что-то из сети, хочешь это во вьюхи вставить, а тут юзер начал сворачивать приложение, и оно все стало null? Тупо проверка на null ?

@grishka а как ты со своим подходом в "лоб" решаешь проблему, что ты типо такой получил что-то из сети, хочешь это во вьюхи вставить, а тут юзер начал сворачивать приложение, и оно все стало null? Тупо проверка на null ?

что значит стало null?

что значит стало null?

ну когда юзер сворачивает приложение, у тебя все вьюхи дестроятся

вьюхи не могут дестроиться отдельно от активити ни при каких условиях

во фрагменте том же onDestroyView

во фрагменте том же onDestroyView

я это не поддерживаю

это вы любите пересоздавать вьюхи на каждый чих, но я-то так никогда не делаю ;)

это вы любите пересоздавать вьюхи на каждый чих, но я-то так никогда не делаю ;)

да я знаю что ты юзаешь onConfigChanges

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

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

то никакие колбэки не придут, потому что оно умерло

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

ну а что тогда, только из сети загрузить заново, или из базы какой-нибудь

а, ну да точно

это вот как раз плюс отсутствия архитектуры — меньше кода и меньше багов :)

а с COnfigChanges вьюхи не дестроятся во фрагменте когда сворачиваешь приложение?

нет

дестроятся, если использовать back stack, поэтому я его больше не использую

дестроятся, если использовать back stack, поэтому я его больше не использую

а если в бэк стек не класть то onDestroyVIew не будет?

окей, если не кладешь в бэк стек как тогда навигацию делаешь?

на стеке активити

а если в бэк стек не класть то onDestroyVIew не будет?

будет при дестрое активити

на стеке активити

т.е. ты никогда не делал навигацию на фрагментах?

т.е. ты никогда не делал навигацию на фрагментах?

я попробовал один раз, ran away screaming

столько багов из-за сломанных состояний у меня ещё в жизни не было

Это ж неудобно ппц

ERROR: S client not available

столько багов из-за сломанных состояний у меня ещё в жизни не было

ну да, фрагменты боль

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

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

а shared elements не юзал?

сам использовал в приложении для часов, Ильнар вроде тоже где-то у себя пробовал

а shared elements не юзал?

не, оно всё кривое какое-то)

но выглядит прикольно.)

ну да, фрагменты боль

но почему ты всё ещё их используешь?...

а shared elements не юзал?

а для диалогов так и не зипилили, насколько я знаю

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

но почему ты всё ещё их используешь?...

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

а для диалогов так и не зипилили, насколько я знаю

ну вот на часах я сам запилил для диалогов

ну вот на часах я сам запилил для диалогов

на часах == wear?

на часах == wear?

да

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

ты же сказал что навигация на активитях

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

разница только в том, что я вместо back stack использую кучу этих активити в системном стеке

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

ох блин, мне когда-то попадалось startMainActivity(SomeFragment.class.getName()) :)

ох блин, мне когда-то попадалось startMainActivity(SomeFragment.class.getName()) :)

я себе сделал обёртку для этого, поэтому просто Nav.to(this, SomeFragment.class, extras);

я себе сделал обёртку для этого, поэтому просто Nav.to(this, SomeFragment.class, extras);

да, так ок

ещё при моей схеме прокидывать результаты можно через просто startActivityForResult

не какие-то колбэки которые работают через жопу, а true android way :)

ещё при моей схеме прокидывать результаты можно через просто startActivityForResult

у фрагментов есть setTargetFragment, пока вроде работает.)

у фрагментов есть setTargetFragment, пока вроде работает.)

а вот об этом я не знал

а вот об этом я не знал

сам не давно узнал, используя для получения результата из фрагмента

но всё равно мне больше нравится идея, что на каждый шаг навигации отдельное окно на уровне системы

но всё равно мне больше нравится идея, что на каждый шаг навигации отдельное окно на уровне системы

так активити != окно. Ибо окно это getWindow()

есть у активити

активити это абстракция над окном ;)

активити это абстракция над окном ;)

ну типо

но да, она особым образом реализована на уровне системы, я смотрел

достаточно глубоко зарылся в AOSP из любопытства

достаточно глубоко зарылся в AOSP из любопытства

она сделана так что нельзя просто взять и сделать Activity a = new Activity()

там окно тебе создаёт система, а не ты сам через WindowManager