Android: un método findViewById () que devuelve valores que no necesitamos emitir
Como estoy cansado de escribir un operador de cast para CADA Activity.findViewById() que devuelve View crudo, finalmente traté de una manera que fue sugerido por Internet .
public abstract class MyActivity extends Activity { @SuppressWarnings("unchecked") protected <T extends View> T findViewByID(int id) { return (T) this.findViewById(id); } }
Tenga en cuenta que esto no está sobrecargado (el último "D" es mayúsculas). El compilador dice que no podemos lanzar View en T ¿Hay algo malo en mi implementación? Curiosamente, esta sugerencia apenas se veía en los sitios web en inglés (por ejemplo, incluso en nuestra encantadora desbordamiento de pila), y la excepción era el sitio publicado anteriormente.
- NullPointerException al llamar a findViewById () para obtener la vista de un fragmento
- Intenta invocar el método virtual 'android.view.Window $ Callback android.view.Window.getCallback ()' en una referencia de objeto nulo
- FindViewById dentro de un método estático
- FindViewById en una vista personalizada para encontrar la vista secundaria
- Android: ¿Cómo usar mediaController en la clase de servicio?
- FindViewById () devuelve null - intentado TODO
- Fragmento de Android: findViewById devuelve null
- Puntero nulo Excepción - findViewById ()
- View.findViewById () devuelve null
- (Barra de herramientas) findViewById (R.id.tool_bar) devuelve NULL
- Cómo encontrar id de diseño en un botón de mapa de bits java fuente que he hecho
- FindViewById (int) devuelve null en un botón específico en Android 3.1 otras versiones su multa
- No se puede resolver el método 'findViewById (int)'
Esto funciona bien en mi proyecto de prueba. No hay error de compilador: 
Para ser honesto, este enfoque añade una sutil complejidad sobrecarga para el próximo mantenedor de Android (que estaría acostumbrado al método de casting) para guardar algunos caracteres en los archivos de código.
Propondría lanzar las vistas de la manera tradicional, o optar por una solución basada en la reflexión como Roboguice .
Solucioné esto usando un eclipse-builder personalizado que genera clases con referencias para cada archivo de diseño, porque:
- Es de tipo seguro y fácil de usar
- RoboGuice y todas las demás API basadas en la reflexión son muy lentas en Android.
En mi opinión, esta es la manera más limpia y más eficiente de resolver este problema.
Vea mi esencia aquí para el constructor: https://gist.github.com/fab1an/10533872
Diseño: test.xml
<?xml version="1.0" encoding="utf-8"?> <merge xmlns:android="http://schemas.android.com/apk/res/android" > <TextView android:id="@+id/text1" android:layout_width="wrap_content" android:layout_height="wrap_content" /> <TextView android:id="@+id/text2" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_below="@id/text1" /> <ScrollView android:id="@+id/scroll" android:layout_width="match_parent" android:layout_height="350px" android:layout_below="@id/text2" android:layout_marginTop="50px" /> </merge>
uso: TestView.java
public final class TestView extends RelativeLayout { //~ Constructors --------------------------------------------------------------------------------------------------- private final ViewRef_test v; public TestView(final Context context) { super(context); LayoutInflater.from(context).inflate(R.layout.test, this, true); this.v = ViewRef_test.create(this); this.v.text1.setText(); this.v.scroll.doSomething(); } }
archivo generado (en gen/ ): ViewRef_test.java
package org.somecompany.somepackage; import android.view.*; import android.widget.*; import java.lang.String; @SuppressWarnings("unused") public final class ViewRef_test { public final TextView text1; public final TextView text2; public final ScrollView scroll; private ViewRef_test(View root) { this.text1 = (TextView) root.findViewById(R.id.text1); this.text2 = (TextView) root.findViewById(R.id.text2); this.scroll = (ScrollView) root.findViewById(R.id.scroll); } public static ViewRef_test create(View root) { return new ViewRef_test(root); } }