Android: отрицательные координаты в ViewGroup и сенсорные прямоугольники

Я работаю с ActionScript/Flash/AIR и плохо знаком с иерархией Android View. Учитывая это, я нашел что-то очень странное в ViewGroup и ее системе координат.

Допустим, у нас есть следующие отношения родитель/потомок внутри основного представления действий, которое расширяет RelativeView (или, по сути, некоторый групповой макет, допускающий абсолютные координаты и масштаб):

circle1 = new ImageView(context);
circle1.setImageBitmap(...);
circle2 = new ImageView(context);
circle2.setImageBitmap(...);
cont = new RelativeView(context);

cont.addView(circle1);
cont.addView(circle2);
this.addView(cont);

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

cont.setX(getWidth() / 2);
cont.setY(getHeight() / 2);
circle1.setX(-circle1.getWidth() / 2);
circle1.setY(-circle1.getHeight() / 2);
circle2.setX(-circle2.getWidth() / 2);
circle2.setY(-circle2.getHeight() / 2);

Выполняя отрицательные координаты внутри ViewGroup, я сразу заметил, что 'cont' обрезает их по координате [0, 0] и cont.setClipChildren(false); надо позвонить. Я предполагаю, что это плохая идея, потому что это похоже на оптимизацию для области invalidate(). После отключения обрезки результат отображается так, как ожидалось, но есть еще одна проблема:

иллюстрация

Добавление прослушивателя события касания к кругу2 возвращает поддельный прямоугольник касания (отмечен фиолетовым) вместо ожидаемого (отмечен голубым), который должен смотреть на отрицательное смещение [X, Y] круга2. Результирующий прямоугольник начинается с [0, 0] из «cont» и заканчивается в [circle2X + circle2W, circle2Y + circle2H], как если бы он был обрезан в [0, 0] из «cont».

Я знаю, что вы можете решить проблему, не используя отрицательные координаты, но это не очень хорошее решение, если вы переносите из ActionScript, где отрицательные координаты имеют смысл (как в любой системе координат реального мира), а сенсорные прямоугольники правильно рассчитываются в Класс DisplayObjectContainer.

Итак, какие еще решения существуют?

  • Нужно ли создавать собственный класс ViewGroup и что там нужно делать?

  • Есть ли волшебная настройка, которая позволяет не обрезать сенсорные прямоугольники дочерних представлений в [0, 0] родительской ViewGroup?

  • Что-то другое?

Спасибо.


person lobolmart    schedule 20.10.2015    source источник
comment
Это связано с android: clipchildren, который по умолчанию является ложным?   -  person Ben Neill    schedule 21.10.2015
comment
Дерп, неважно, умудрился замазать часть вопроса   -  person Ben Neill    schedule 21.10.2015
comment
когда я делаю: Rect out = new Rect(); круг2.getHitRect (выходит); out содержит правильные значения hitRect для circle2. (т.е. отрицательные значения для левого и верхнего). кажется, что родительская ViewGroup просто не разрешает касания с отрицательным смещением.   -  person lobolmart    schedule 21.10.2015


Ответы (1)


Вы можете использовать View#scrollTo для перемещения источника, чтобы ваш контент полностью отображался в ограничивающем прямоугольнике представления.

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

person adamp    schedule 21.10.2015
comment
благодаря. ваше решение действительное, поэтому я отмечаю его как таковое. после применения scrollTo() прямоугольник касания действительно работает, но побочным эффектом, конечно, является то, что все содержимое ViewGroup перемещается (прокручивается). поэтому, чтобы компенсировать это, необходимо также настроить [X, Y] для «cont». это близко к сложности, но менее сложно (с точки зрения LOC) по сравнению с одним из решений, о котором я уже знал и уже упоминал в OP, - позиционировать «cont» на основе размера его более крупного дочернего элемента и не использовать отрицательные координаты. к сожалению, такие шаблоны проектирования делают его более привлекательным для конечного разработчика. - person lobolmart; 21.10.2015