По мне так полезная статья, если столкнусь с задачей оптимизации на подобных экранах. Видно что времени нормально так потрачено на эту тему и, самое главное, указано куда копать. Спасибо! )
бедняга автор. Дайте код пописать ему! )) Слушайте, ну у Вас же есть команда — если Вы у себя не можете что то поменять — неужели Вы думаете что после этой статьи все разом изменится у нас?
Подсказка: Я несколько раз менял работу, прежде чем найти те условия, которые меня более чем удовлетворяют.
Это не значит что сейчас все идеально, бывают свои моменты, но кстати тех ужасов совещания у меня практически нет. Я не ругался с бывшим начальством, просто если видел невозможность изменения ситуации — менял окружение. Нет незаменимых специалистов, да и мало ли, может кому то нравится сидеть и попивать кофеек под тихое бормотание РП? Вкидывать идеи и чувствовать себя таким образом более важным. А, может быть — кого то и слушают. Каждому — свое… )
Спасибо за отзыв. PreferenceFragment, стандартное решение от гуглов, точно также анимирован по свайпу — что в этом такого? Экран использован как пример, потому что часто встречаются элементы не просто с заголовками, а какие то из них интерактивны, требуют разных обработок — свитч, всплывающие окна, переходы на новые экраны. Все это обрабатывается в Rv, на мой взгляд, быстро и без проблем. Плюс, дает вам возможность быстро переиспользовать тот элемент, который вы реализовали. Датабайдинг упрощает эту возможность.
Не волнуйтесь особо за перерисовку экрана. Устройства на нашем веку уже вполне могут быстро перерисовать список. По крайней мере для фрагмента с найстройками. =) А преждевременная оптимизация — это зло (с).
Да собственно можно и LinearLayout использовать, но что если у вас количество элементов зайдет за рамки экрана? Будете ставить ScrollView? Rv обеспечит вам прокрутку, поэтому даже в стандартном PreferenceFragment она сразу же заложена. Насчет обработчиков по типу элементов — при инициализации Item вы можете указать разные callbacks, пример в этой статье на элементе со свитчем.
Ответом на последний абзац будет — можно использовать DataBinding, чтобы уйти от разных адаптеров. Да это возможно и без него! В разделе ссылок есть доклад от Lisa Wray, там есть об этом. Посмотрите обязательно!
Можно всегда поправить мою реализацию в темплейте. ) Согласен, местами можно сделать более продумано. Если честно, у меня в разных проектах везде что-то меняется, то я открываю items, то делаю их приватными и доступными только по геттеру и сеттеру. protected тоже раньше ставил, тут в примере забил.
Дело не в реализациях, а в общем подходе. Единая реализация важна, если у вас команда и есть какие то общие рекомендации и гайдстайлы.
А почему data binding адское зло? Хотелось бы послушать развернутый ответ. Она много кому не нравится, но объяснить не могут позицию. Часто люди пробовали ее сырой, в то время как гуглы потихоньку делают ее лучше.
Подсказка: Я несколько раз менял работу, прежде чем найти те условия, которые меня более чем удовлетворяют.
Это не значит что сейчас все идеально, бывают свои моменты, но кстати тех ужасов совещания у меня практически нет. Я не ругался с бывшим начальством, просто если видел невозможность изменения ситуации — менял окружение. Нет незаменимых специалистов, да и мало ли, может кому то нравится сидеть и попивать кофеек под тихое бормотание РП? Вкидывать идеи и чувствовать себя таким образом более важным. А, может быть — кого то и слушают. Каждому — свое… )
PreferenceFragment, стандартное решение от гуглов, точно также анимирован по свайпу — что в этом такого? Экран использован как пример, потому что часто встречаются элементы не просто с заголовками, а какие то из них интерактивны, требуют разных обработок — свитч, всплывающие окна, переходы на новые экраны. Все это обрабатывается в Rv, на мой взгляд, быстро и без проблем. Плюс, дает вам возможность быстро переиспользовать тот элемент, который вы реализовали. Датабайдинг упрощает эту возможность.
Не волнуйтесь особо за перерисовку экрана. Устройства на нашем веку уже вполне могут быстро перерисовать список. По крайней мере для фрагмента с найстройками. =) А преждевременная оптимизация — это зло (с).
Да собственно можно и LinearLayout использовать, но что если у вас количество элементов зайдет за рамки экрана? Будете ставить ScrollView? Rv обеспечит вам прокрутку, поэтому даже в стандартном PreferenceFragment она сразу же заложена. Насчет обработчиков по типу элементов — при инициализации Item вы можете указать разные callbacks, пример в этой статье на элементе со свитчем.
Ответом на последний абзац будет — можно использовать DataBinding, чтобы уйти от разных адаптеров. Да это возможно и без него! В разделе ссылок есть доклад от Lisa Wray, там есть об этом. Посмотрите обязательно!
Дело не в реализациях, а в общем подходе. Единая реализация важна, если у вас команда и есть какие то общие рекомендации и гайдстайлы.
А почему data binding адское зло? Хотелось бы послушать развернутый ответ. Она много кому не нравится, но объяснить не могут позицию. Часто люди пробовали ее сырой, в то время как гуглы потихоньку делают ее лучше.