Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 10
А зачем наследоваться от 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).
Очень познавательно, спасибо. Пишите еще.
Спасибо за пример.
Но с точки зрения пользователя эта черная полоса справа будет раздражать, а если экран будет больше, тогда линия контента может стать меньше половины экрана, возможно стоит обратиться к дизайнеру.
Чем проще, тем лучше, и тут смотрю этот вариант придерживается.
Но с точки зрения пользователя эта черная полоса справа будет раздражать, а если экран будет больше, тогда линия контента может стать меньше половины экрана, возможно стоит обратиться к дизайнеру.
Чем проще, тем лучше, и тут смотрю этот вариант придерживается.
Как раз возникла необходимость в написании кастомных композитных компонентов.
Скажите, пожалуйста, не тормозит ли скроллинг коллекции таких элементов?
Скажите, пожалуйста, не тормозит ли скроллинг коллекции таких элементов?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создание композитных компонентов на Android