Descendantfocusability android что это

Google Android — это несложно

Добро пожаловать на форум сайта

Урок 54. Кастомизация списка. Создаем свой адаптер

Урок 54. Кастомизация списка. Создаем свой адаптер

Сообщение damager82 » 06 фев 2012, 03:00

— создаем свой адаптер на основе BaseAdapter

Re: Урок 54. Кастомизация списка. Создаем свой адаптер

Вы бы не могли объяснить один момент.
((TextView) view.findViewById(R.id.tvPrice)).setText(p.price + «»);

а конкретно вот это: + «», зачем в методе setText к строке с ценой прибавлять еще пустую строку? И почему без этого приложение падает с ошибкой? Спасибо.

Re: Урок 54. Кастомизация списка. Создаем свой адаптер

Сообщение damager82 » 05 мар 2012, 09:53

NobodyCallMeChicken писал(а): Вы бы не могли объяснить один момент.
((TextView) view.findViewById(R.id.tvPrice)).setText(p.price + «»);

а конкретно вот это: + «», зачем в методе setText к строке с ценой прибавлять еще пустую строку? И почему без этого приложение падает с ошибкой? Спасибо.

Re: Урок 54. Кастомизация списка. Создаем свой адаптер

Re: Урок 54. Кастомизация списка. Создаем свой адаптер

Сообщение Vlady » 05 мар 2012, 12:01

Re: Урок 54. Кастомизация списка. Создаем свой адаптер

Re: Урок 54. Кастомизация списка. Создаем свой адаптер

Сообщение damager82 » 06 мар 2012, 13:50

Re: Урок 54. Кастомизация списка. Создаем свой адаптер

Сообщение MeTeOpA » 12 май 2012, 22:31

Скажите, такой вопрос.
Если поменять местами check boх и Image Приложение падает с ошибкой.

05-12 19:29:03.848: E/AndroidRuntime(5278): FATAL EXCEPTION: main
05-12 19:29:03.848: E/AndroidRuntime(5278): java.lang.ClassCastException: android.widget.LinearLayout
05-12 19:29:03.848: E/AndroidRuntime(5278): at ua.m.BoxAdapter.getView(BoxAdapter.java:54)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.widget.AbsListView.obtainView(AbsListView.java:1430)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.widget.ListView.measureHeightOfChildren(ListView.java:1216)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.widget.ListView.onMeasure(ListView.java:1127)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.view.View.measure(View.java:8313)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:3138)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.widget.LinearLayout.measureChildBeforeLayout(LinearLayout.java:1017)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.widget.LinearLayout.measureVertical(LinearLayout.java:386)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.widget.LinearLayout.onMeasure(LinearLayout.java:309)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.view.View.measure(View.java:8313)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:3138)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.widget.FrameLayout.onMeasure(FrameLayout.java:250)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.view.View.measure(View.java:8313)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.widget.LinearLayout.measureVertical(LinearLayout.java:531)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.widget.LinearLayout.onMeasure(LinearLayout.java:309)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.view.View.measure(View.java:8313)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:3138)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.widget.FrameLayout.onMeasure(FrameLayout.java:250)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.view.View.measure(View.java:8313)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.view.ViewRoot.performTraversals(ViewRoot.java:839)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.view.ViewRoot.handleMessage(ViewRoot.java:1859)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.os.Handler.dispatchMessage(Handler.java:99)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.os.Looper.loop(Looper.java:123)
05-12 19:29:03.848: E/AndroidRuntime(5278): at android.app.ActivityThread.main(ActivityThread.java:3683)
05-12 19:29:03.848: E/AndroidRuntime(5278): at java.lang.reflect.Method.invokeNative(Native Method)
05-12 19:29:03.848: E/AndroidRuntime(5278): at java.lang.reflect.Method.invoke(Method.java:507)
05-12 19:29:03.848: E/AndroidRuntime(5278): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
05-12 19:29:03.848: E/AndroidRuntime(5278): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
05-12 19:29:03.848: E/AndroidRuntime(5278): at dalvik.system.NativeStart.main(Native Method)

Не могли бы вы помочь?

Re: Урок 54. Кастомизация списка. Создаем свой адаптер

Сообщение damager82 » 14 май 2012, 11:55

Re: Урок 54. Кастомизация списка. Создаем свой адаптер

Сообщение Katran » 14 июн 2012, 04:03

Источник

Android: заставить EditText удалить фокус? [дубликат]

этот вопрос уже есть ответ здесь:

Я хотел бы иметь возможность удалить фокус из EditText. Например, если клавиатура появляется, и пользователь скрывает ее с помощью кнопки «назад», я хотел бы, чтобы фокус и курсор исчезли. Как можно ли это сделать?

19 ответов:

Вы можете добавить это onCreate и он будет скрывать клавиатуру каждый раз, когда начинается activty.

вы также можете программно изменять фокус на другой элемент.

вы можете сделать курсор и фокус отпадают сами

но обнаружить, когда скрытие клавиатуры-это тяжелая работа.

добавить LinearLayout до EditText в XML.

или вы можете сделать то же самое, добавив эти строки для просмотра перед вашим «EditText».

снимите фокус, но оставайтесь фокусируемым:

EditText потеряет фокус, но может получить его снова на новом событии касания.

это работает для меня

Edit в ссылке они предлагают использовать LinearLayout, но простой вид будет работать

затем, если этот » вор » помещается в верхней части макета (чтобы быть первым фокусируемым элементом), вызывает clearFocus() будет работать.

добавьте эти два свойства в родительский макет (например: линейный макет, относительный макет)

Это будет делать трюк 🙂

вы также можете включить android: windowSoftInputMode= «stateAlwaysHidden» в разделе манифеста действий.

но в XML-способе.

FYI, вы также можете скрыть клавиатуру с кодами:

Если вы не используете его и все равно та же проблема

пользователей LinearLayout как родитель и установить

надеюсь, что это поможет вам.

попробуйте использовать это на ваш взгляд это сработало для меня:

добавить в родительский макет, где вы положили свой EditText этой android:focusableInTouchMode=»true»

чтобы скрыть клавиатуру при запуске активности.. напишите следующий код в onCreate()..

чтобы очистить фокус и удалить курсор из edittext.

Это мой самый первый ответ на SO, так что не будьте слишком суровы ко мне, если есть ошибки. : D

есть несколько ответов, плавающих вокруг так, но я чувствую желание опубликовать мое полное решение, потому что это свело меня с ума. Я схватил кусочки со всех сторон, так что простите меня, если я не даю соответствующие кредиты всем. 🙂

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

для вашего макета вам нужен родитель ваш EditText и Родительский вид определено что-то вроде этого:

Итак, мне нужно было несколько вещей здесь. Мне нужно было иметь заполнитель для моего EditText-который является то —

это произошло на EditText не быть сфокусированным на входе активность и активность сам при его установке этот параметр помогает, так что вы можете установить onTouchListener на нем, чтобы украсть фокус от EditText.

сейчас в работе:

несколько ответов на биты, которые я нашел на этой странице вопроса, и часть с решением активности, которое я нашел на этом блог. Остальное, что я пропустил, что я должен был выяснить сам, было очищено сосредоточьтесь на EditText который я добавил к обоим внутри setOnEditorActionListener и onTouchLister для Родительский вид.

надеюсь, что это помогает кто-то и экономит их время. 🙂

в комментариях вы спросили, Можно ли сфокусировать другое представление вместо EditText. Да, может. Используйте .requestFocus() метод для представления, которое вы хотите сфокусировать в начале (в методе onCreate ())

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

вы также можете включить android:windowSoftInputMode=»stateAlwaysHidden» в разделе манифест действий.

у меня была та же проблема. Это сделало меня более чем сумасшедшим.

у меня был расширенный диалог с ScrollView, который имел TableLayout с расширенным LinearLayout, который содержал панель поиска и EditText.

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

Я пробовал почти все решения этой темы и ни один не работал для меня.

Так вот мой простое решение: (text = EditText)

кстати я не для его решения использовался любой из следующих фрагментов:

И не используется элемент распорки, как вид с шириной и высотой 1dp.

надеюсь, это поможет кому-то: D

The EditText сможет получить фокус, когда пользователь прикоснется к нему. Когда основной макет (активность, диалог и т. д.) становится видимым EditText не получает автоматически фокус, даже если это первый вид в макете.

Источник

Android UI Gotcha’s — Diagnosis & Cures

Whenever I speak to non-Android Native coders, I always say that Android is tricky! There are so many obscure things that you just have to know and no where is this more evident than in XML layouts.

I don’t even want to know how many hours & days, I’ve spent banging my head against the wall trying to diagnose symptoms, causes and cures for some layout bugs! In this series, I hope to save you from the head banging I’ve had to endure.

As in medicine, a symptom can have multiple causes, however, the cures/solutions focused on in this article were particularly difficult to diagnose and solve. If I’ve missed an exception, or you think more information in a section could be useful, please drop a comment below and I’ll include it. 🙂

Illness #1: Jerky Scroll/Ghost Scrolling

Symptoms

• Scrolling in a NestedScrollView isn’t smooth — seems jerky/doesn’t have momentum.
• The NestedScrollView is scrolling down without user input. (Layout contains an EditText ).

Cause

Both of the symptoms are related to focus (part of a UI selected by either the user/system):

• Scrolling isn’t smooth because the system is unsure where to focus even if you don’t have any EditTexts in your layout (This typically only occurs on very large layouts of a NestedScrollView that also contains a RecyclerView ). Think about it this way — the system is like someone with ADHD that tries to focus on everything but doesn’t actually focus on anything in particular, and this results in jerky scrolling.
• By default the system will always give focus to the EditText (or focusable element) closest to the top of the layout. If the top-most EditText is toward the bottom of the layout (contained in the NestedScrollView ), the view will scroll upwards (ghost scroll). This ghost scroll may not occur consistently, making this rather tricky to debug.

Cures/Solutions

There are two solutions, but I’d recommend the first one where possible.

1) Tell Android where to focus in your xml. Typically the focus should be placed on the highest level layout contained within the NestedScrollView. Usually, this would be a ConstrainLayout . In some cases, you can set the focus in the parent layout containing the NestedScrollView .

2) Tell Android not to focus on any elements (decedents) below the parent layout. Only do this if the first method doesn’t work because blocking focus means not views can gain focus even if the user clicks on the view i.e. an EditText wouldn’t be editable because it can’t be selected . But here’s the kicker: the keyboard might be displayed even though the EditText can’t be focused and buttons & other views can still register click events.

Other Potential Causes

Doing too much on the MainThread resulting in frames being lost. It’s uncommon to be intentionally doing so much on the MainThread that you lose frames — it’s much more likely that you have a memory leak or you’re doing network calls on the main thread (the latter is very naughty and not in the good way).

Illness #2: CollapsingToolbar — Not Collapsing

Symptoms

You have an activity or fragment containing a CollapsingToolbar and the content below it has variable length. You’re sure that you’ve got the right scroll flags but it just doesn’t scroll occasionally.

Causes

When content below the CollapsingToolbar doesn’t fill more than the visible area available to it, the CollapsingToolbar will only collapse if you scroll on it (not if you scroll by placing your finger on the content & drag up). This behaviour makes sense if your content is a standard size but if it isn’t the user will expect it to scroll.

Cures/Solutions

The easiest way to solve this issue is if you set a minimum height on the NestedScrollView or whatever is the main layout below the CollapsingToolbar . I’ve found a minimum height of android:minHeight=”600dp” to work well for most cases.

Potential Complications

There are some complications that can arise when up use a NestedScrollView in a fragment. If you encounter issues here, you are most welcome to get in touch with me and I’d be happy to help.

Illness #3: Shadows/Elevation Cut Off

Symptoms

Usually cut off at the bottom (can be a CardView or any layout/view with an elevation).

Causes

1. It appears that a parent (to the layout with elevation) layout’s bounds cutoff the shadow of its children for some reason.
2. Shadows set with android:elevation are cutoff by the child’s bounds. Extending the bounds of the view with margin or padding does not have an effect. It appears that they are cut off by the child’s original bounds.
3. It therefore seems that the parent is clipping the child.

Solution

1. Set padding on the parent (if needed) and set android:clipToPadding=»false» on that parent.
2. By default shadow is determined by view’s background, so if there is no background, there will be no shadow. You may therefore also need to set a non-transparent background color on the child layout that has the elevation. Alternatively you can also android:outlineProvider=»bounds» which will provide the color it requires

If you have any suggestions for topics that could covered in a Part II, please drop a comment below and attempt diagnose and put forward cure. Lastly some shameful self-promotion: if you liked this article — give it some claps; if you learned something — give me a follow and you’ll notified when Part II is released.

Источник