Android OnLongClickListener странное / ненадежное поведение - PullRequest
Новая
       39

Android OnLongClickListener странное / ненадежное поведение

2 голосов
/ 26 августа 2010

В настоящее время я борюсь против OnLongClickListener на Android Api Lvl 8.

Возьмите этот код: 

this.webView.setOnLongClickListener(new OnLongClickListener() {
    @Override
    public boolean onLongClick(View v) {
        System.out.println("long click");
        return true;
    }
});

Работает отлично.Я могу нажать в любом месте на WebView, и событие каждый раз срабатывает.

Теперь взгляните на это: 

this.webView.setOnLongClickListener(new OnLongClickListener() {
    @Override
    public boolean onLongClick(View v) {
        final EditText editText = getUrlTextField();

        switch (editText.getVisibility()) {
        case View.VISIBLE:
            editText.setVisibility(View.GONE);
            return true;
        case View.GONE:
            editText.setVisibility(View.VISIBLE);
            return true;
        default:
            return false;
        }
    }
});

Предполагая, что компоненты EditText URL в настоящее время видны, они исчезают издисплей и должен отображаться снова при запуске другого события длинного щелчка.Но если вы запустите это, событие срабатывает только один раз (!), Когда вы выполняете длинный щелчок по любой позиции в WebView.Чтобы усложнить задачу, длинный щелчок снова работает, когда он выполняется по ссылке на веб-сайте ...

Может кто-нибудь объяснить, если это ошибка в SDK и / или есть ли ошибка в моемдумаешь как работает OnLongClickListener?!?: /

РЕДАКТИРОВАТЬ:

Я запустил несколько различных сценариев на Nexus One и пришел к следующему выводу: изменение макета во время выполнения более или менее убиваетOnLongClickListener ... Я не нашел способа заставить его работать надежно на всех ...

Я был бы очень признателен, если бы кто-нибудь мог дать мне подсказку ... Я в своем уме :(

Ответы [ 2 ]

1 голос
/ 19 марта 2012

Лично я переустанавливал слушателя после каждого выхода.

0 голосов
/ 26 июня 2013

Я тоже столкнулся с этой проблемой. Похоже, что если макет представления изменяется таким образом, что необходимо изменить границы дочернего представления (т. Е. TextView имеет ширину wrap_content, и вы устанавливаете для его текста нечто более длинное / более короткое, чем было раньше), представления в иерархии будут иметь onStartTemporaryDetach вызван метод (скорее всего, из-за прохода макета, хотя я не выкопал достаточно глубоко, чтобы узнать наверняка). Если вы посмотрите на источник для View, то onStartTemporaryDetach в конечном итоге отменяет нажатое состояние представления.

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

...