Должна ли быть опция для фрагментов для сохранения событий щелчка в их иерархии представлений?

Увидев пару вопросов здесь, о том, что Fragments «передают» свои события кликов вплоть до кликов « Views в базовых Fragments , я напомнил, что однажды столкнулся с этой проблемой. На самом деле происходит то, что если пользователь нажимает на пустую область самого ViewGroup Fragment , так как его ViewGroup не может быть ViewGroup , событие будет обрабатываться с помощью Button View (т.е. Button ), которая удобно расположена чуть ниже пальца пользователя. Я исправил его, сделав ViewGroup Top Fragment ViewGroup . В то время я не думал об этом, но это решение кажется немного «взломанным».

Я понимаю, что это нормальное поведение для представления, которое по умолчанию не кликается, чтобы не перехватывать события кликов, но можно подумать, что, учитывая, что одно большое использование для Fragments – это отображение иерархии представлений (задача, выполняемая только Activity ) Что в этом смысле он будет напоминать Activity . Когда одно действие запускает Intent чтобы создать новое действие, а затем это действие находится на экране, никакие события кликов не будут переданы в основное действие. Я понимаю, что Activity может содержать много Fragments которые могут не заполнять весь экран или даже не содержать xml, но иногда события click предназначены только для того, чтобы удерживать верхнюю часть Fragment .

При всем сказанном здесь возникают вопросы:

1) Устанавливает ли ViewGroup в самом верхнем Fragment кликабельный лучший способ решить эту проблему?

2) Существует ли эта особенность, и я не знаю об этом? А если нет, не так ли?

Устанавливает ли ViewGroup в верхней части Fragment лучший способ решить эту проблему?

Предполагая, что ваш пользовательский интерфейс сродни пользовательскому интерфейсу от вопроса, с которым вы связаны, пользовательский интерфейс написан ненадлежащим образом.

Я беру на себя интерфейс от этого вопроса, так это то, что у разработчика есть два фрагмента: A и B, каждый из которых заполняет экран. A есть первоначально, с тремя кнопками внизу. Затем разработчик вызывает add() для отображения B, где B имеет непрозрачный черный фон.

Это глупо на нескольких уровнях. Вы не только сталкиваетесь с этой проблемой распространения сообщений, но у вас проблемы с перегрузкой, потому что Android будет отображать кнопки, а затем отображать черный фон поверх них.

Правильный ответ здесь – replace() B replace() A.

(Я понимаю, что у разработчика фактически нет фрагмента A, но есть эти виджеты в активности, что добавляет еще один уровень отрывочности к этому пользовательскому интерфейсу)

В более общем плане, у меня не было бы фрагментов или чего-то еще выше на оси Z с намерением скрыть основные виджеты. Так, например, наличие полноэкранного VideoView с всплывающим MediaController выше на оси Z является прекрасным, потому что сенсорные события, предназначенные для контроллера, будут подбираться контроллером, но пользователь все равно может нажимать на части VideoView не заблокирован контроллером. И наоборот, я бы не реализовал веб-браузер с вкладками, если один WebView наложил другой WebView на ось Z – либо будет только один WebView , либо будет только один видимый WebView (с другим удаленным из иерархии представления или отмеченным Как View.GONE ).

Когда одно действие запускает намерение, чтобы создать новое действие, а затем это действие находится на экране, никакие события кликов не будут переданы в основное действие.

Это связано с тем, что в отношении иерархии представлений нет «основной деятельности». Более технически каждое действие находится в своем собственном Window , и поэтому даже если верхнее Window не заполняет экран (например, диалоговое действие), «основное действие» видимо, но не может получать события касания.

Я понимаю, что Activity может содержать много фрагментов, которые могут не заполнять весь экран или даже не содержать xml, но иногда события click предназначены только для того, чтобы удерживать верхнюю часть Fragment.

Тогда не должно быть ничего под «самым большим фрагментом», ИМХО. Используйте replace() , а не add() , когда вы делаете этот тип переключателя пользовательского интерфейса. Или, используйте DialogFragment , если вы хотите временно использовать что-то модальное для ввода переднего плана (поскольку диалоговое окно получает свое собственное Window , если я правильно понимаю). Не просто нарисовать сплошной фон и притвориться, что другие виджеты, которые теперь написаны, не существуют.

Существует ли эта особенность, и я не знаю об этом?

Нет, поскольку фрагменты не являются ViewGroups и поэтому не участвуют в управлении маршрутизацией событий касания.

А если нет, не так ли?

ИМХО, нет, хотя вы можете подать на него вопрос.