Comments 10
UFO just landed and posted this here
А зачем наследоваться от RelativeLayout? FrameLayout все же попроще и побыстрее. Вам же по сути только один компонент в нем отобразить надо — тот RelativeLayout, который задан в xml.
резонное замечание, но если посмотреть, что же возвращает:
то ты увидим что view это RelativeLayout.
Таким образом мы просто связали RelativeLayout из xml с нашим наследником этого класса.
Как альтернативный вариант, можно вообще ChannelFrame ни от чего не наследовать, а передать в него объект-контейнер наших фреймов, и уже внутри него добавлять в контейнтейнер полученные view.
View view = inflater.inflate(R.layout.channel_layout, null, false);то ты увидим что view это RelativeLayout.
Таким образом мы просто связали RelativeLayout из xml с нашим наследником этого класса.
Как альтернативный вариант, можно вообще ChannelFrame ни от чего не наследовать, а передать в него объект-контейнер наших фреймов, и уже внутри него добавлять в контейнтейнер полученные view.
Не раскрыт самый интересный аспект — наследование от ViewGroup и самостоятельная реализация onMeasure и onLayout. Там есть некоторые тонкости въехать в которые только по документации не реально. Мне в свое время пришлось читать исходник LinearLayout — очень помог.
Это ни в коем случае не упрек, но можно было бы так же показать как создаются кастомные свойства у самописных компонентов, как они используются в xml ресурсах и как обрабатываются в коде.
Например, для компонента, который приведен в примере, это могли бы быть и кол-во отображаемых строчек и TextAppearance заголовков и кнопочек и пр.
Например, для компонента, который приведен в примере, это могли бы быть и кол-во отображаемых строчек и TextAppearance заголовков и кнопочек и пр.
Задача данного топика не в раскрытии фишек ViewGroup и его наследников.
В дополненние про интерестные аспекты LayoutInflater можно добавить про метод inflate:
Вызов LayoutInflater без передачи ему root приводит к тому что inflate игнорирует параметры layout (окружения) из xml файла. Вызов же inflate с root != null и attachToRoot=true, загрузит параметры layout, и приведет к возврату root на выходе, но помешает в дальнейшем менять эти параметры в уже загруженном объекте (только если вы не нашли его при помощи findViewById).
В дополненние про интерестные аспекты LayoutInflater можно добавить про метод inflate:
View inflate(int resource, android.view.ViewGroup root, boolean attachToRoot) Вызов LayoutInflater без передачи ему root приводит к тому что inflate игнорирует параметры layout (окружения) из xml файла. Вызов же inflate с root != null и attachToRoot=true, загрузит параметры layout, и приведет к возврату root на выходе, но помешает в дальнейшем менять эти параметры в уже загруженном объекте (только если вы не нашли его при помощи findViewById).
Очень познавательно, спасибо. Пишите еще.
Спасибо за пример.
Но с точки зрения пользователя эта черная полоса справа будет раздражать, а если экран будет больше, тогда линия контента может стать меньше половины экрана, возможно стоит обратиться к дизайнеру.
Чем проще, тем лучше, и тут смотрю этот вариант придерживается.
Но с точки зрения пользователя эта черная полоса справа будет раздражать, а если экран будет больше, тогда линия контента может стать меньше половины экрана, возможно стоит обратиться к дизайнеру.
Чем проще, тем лучше, и тут смотрю этот вариант придерживается.
Как раз возникла необходимость в написании кастомных композитных компонентов.
Скажите, пожалуйста, не тормозит ли скроллинг коллекции таких элементов?
Скажите, пожалуйста, не тормозит ли скроллинг коллекции таких элементов?
Sign up to leave a comment.
Создание композитных компонентов на Android