Второй аргумент метода ViewGroup.addView
- это ViewGroup.LayoutParams
. Во многих случаях вы хотели бы использовать подкласс, такой как RelativeLayout.LayoutParams
, но досадно, что в сигнатуре метода нет безопасности типа, поэтому следующее компилируется и, по-видимому, работает.Тип безопасности при использовании ViewGroup.LayoutParams
relativeLayout.addView(textView, new ViewGroup.LayoutParams(WRAP_CONTENT, WRAP_CONTENT));
relativeLayout.addView(textView, new RelativeLayout.LayoutParams(WRAP_CONTENT, WRAP_CONTENT));
relativeLayout.addView(textView, new FrameLayout.LayoutParams(WRAP_CONTENT, WRAP_CONTENT));
Это меня очень беспокоит, так как было бы очень просто случайно ввести неправильный тип. (Я не могу понять, почему он был разработан таким образом, но это не мой вопрос).
Очевидно, что, когда выложено ViewGroup
, все детские LayoutParams
должны в какой-то момент быть отнесены к соответствующему типу, чтобы читать какие-либо дополнительные правила. Могу ли я быть уверенным, что для всех стандартных подклассов ViewGroup
все эти приведения проверяются приложением (т. Е. Следуют instanceof
), так что если я поставлю неправильный тип, я никогда не получу ClassCastException
во время выполнения?
Мой вопрос не был "does' addView() 'в подклассах проверять правильный тип?", Но "проверяет ли тип get позже, когда выкладывается' ViewGroup'? ". Однако вы также ответили на это. Это очень раздражает - я уверен, что это могло быть спроектировано лучше, чтобы эти ошибки даже не компилировались. –
@PaulBoddington: «тип будет проверен позже, когда будет отображена группа ViewGroup?» - нет. Иногда из-за недостатка выживает, потому что оказывается, что прохождение макета требует только материала из суперкласса (например, «MarginLayoutParams»). Но, как правило, вы просто взорваетесь. «Я уверен, что это могло бы быть спроектировано лучше, чтобы эти ошибки даже не компилировались», - согласился. В свою защиту сравнительно мало людей катят эти вещи сами, предпочитая вместо этого раздувать ресурсы макета, а затем это становится гораздо менее проблематичным. – CommonsWare