Tras unos días leyendo y trasteando, y sin ser para nada un entendido (seguramente tenga que ir corrigiendo cosas conforme las descubra), he preparado un "diccionario" con ejemplos duales delphi-android para intentar aclarar los conceptos a los delphi-boys del lugar.
Activity:
Representa una "unit" de pascal, un .pas que declara un objeto, descendiente de la clase "Activity" (algo así como TCustomForm)) para hacer "algo", con o sin un formulario visible (Layout) asociado. Cada activity tendrá su fichero java asociado (el .pas), y se comporta como un objeto, sea visual o no.
Todas las activity de tu aplicación se crean al principio, como los "auto create forms" en delphi, o mejor dicho, se crean la primera vez que hagan falta de forma transparente. Solo puede existir una instancia de cada activity, así que no tiene sentido darle un nombre a la clase (TFichaCliente) y otra a la variable (FichaCliente), porque son la misma cosa, el activity se puede decir que define y contiene a la misma vez al objeto nuevo.
Normalmente, al definir tu aplicación, se declara -queda guardado en el fichero AndroidManifest.xml- una actividad como la principal (MAIN), con lo que se convierte en tu Application.MainForm y se muestra al entrar a la aplicación.
El resto de las activity que tengas creadas en el proyecto también han de salir listadas en este fichero: si no aparecen, digamos que ese form no se "linka" con tu aplicación, "el optimizador las elimina" diríamos en delphi.
Puedes incluir actividades a tu app bien editándo el fichero AndroidManifest y poniendo una linea adicional debajo de la que declara la activity main, o mejor desde ecilpse: al elegir el AndroidManifest en el editor, tienes lengüetas abajo, usando la que pone "Application" veras la lista de activities declaradas con un botón de añadir.
Una activity (unit .pas) no puede acceder directamente a los datos, edits, etc. del layout (DFM del form) de ninguna activity de la app, ni siquiera de su propio layout (o .DFM) como veremos más adelante.
Es decir, desde MyForm no podrás poner ni MyForm.MyLabel.Text:= 'Hola' ni tampoco OtroForm.EditNombre.Text:= 'Hola', ni para leer su contenido ni para modificarlo... que bueno es el IDE de Delphi, eh?
La comunicación entre un form -Activity- y otro de tu aplicacion se hace siempre mediante el envio de un mensaje -Intent- que contiene parejas de valores al estilo StringList.Values -llamado boundle- es decir, cosas del estilo "Cliente = Pepe".
Layout:
Las "Activity" visuales (units del tipo TForm) son las que tienen asociado un "Layout", es decir, un fichero .DFM en delphi. Ese layout es internamente muy parecido a un .DFM guardado en modo texto, solo que en XML, como no podria ser de otro modo en Android.
El layout lista los controles visuales -views- que van a aparecer en la pantalla (son como los "window" de las Win32). Puedes editarlo visualmente o en XML, igual que en Delphi "As form" o "As text".
Una diferencia importante con delphi es que la posición de estos controles (views), se puede hacer en varias formas. Por ejemplo, tienes varios tipos de pixeles, no solo en pixeles reales: Puedes usar pixeles que tengan un tamaño siempre igual entre dispositivos (tienen en cuenta los dpi, densidad de puntos por pulgada), porcentajes, etc., pero la diferencia más importante es que se puede optar por definir las posiciones al estilo "a la derecha del anterior, con un peso de 4".
Así, los views/componentes se "caen" a una posición u otra según su "peso" y el tamaño de la pantalla, y se acoplan como fichas del tetris según sus pesos y posiciones relativas: Nuestro form al final se ve perfectamente en un tablet o en un teléfono pequeñito, porque los views -componentes- se adaptan de forma automática.
También se pueden colocar los controles como en un "table" de HTML, con lo que en cierto modo un layout es una mezcla de DFM, HTML y CSS.
La diferencia MÁS importante respecto de delphi, es que el objeto MyForm -la activity- es una cosa, y su DFM -Layout- es otra *casi* totalmente desconectada, al menos para los estándares de delphi: En el código del Form no podemos usar MyEdit.Text, porque MyEdit existe en el Layout asociado, así que ojo, el código del form -activity- no ve los componentes -views- definidos en el .DFM -layout-
Es como si en nuestro TForm1.pas eliminásemos la declaración de todos los TComponents que hemos pegado en el DFM y perdiésemos estos punteros.
Conexion Activity-Layout:
En Delphi el .pas y el .dfm están muy unidos, en el .pas están declarados los componentes del .dfm, de forma que el código del .pas puede hacer algo como "EdNombre.Text:= 'Pepe';", pero en una activity con su layout, no existe esta conexión: Los views -TComponents- están definidos en el layout, que es como un resource convertido en objeto, totalmente aparte de la activity, y desde esta has de localizar el puntero al TEdit buscándolo en los resources de la aplicación.
Esto es un poco lioso al principio, y se parece más a la programacion en Visual C que a delphi.
Así se recupera desde una activity (el .pas del form) el puntero a un TEdit que pusimos en su layout (su .dfm) con nombre "textView1":
[java]TextView txtMensaje = (TextView)findViewById(R.id.textView1);[/java]
A nivel de asociar eventos la cosa es algo mejor, pero no mucho: El TComponent (View) donde se produce el evento esta definido en el Layout (.DFM), pero el código que se ha de ejecutarse está en la Activity (la unit .pas), y ya sabemos que no hay "casi" conexión entre ambas.
Desde el editor visual del layout (DFM) podemos seleccionar el botón y decirle que en el evento onClick ha de llamar a la función llamada "onClick" dentro de la actividad, pero ni te va a crear la funcion onClick en el código de la actividad (el .pas) ni, por supuesto, desde ese evento tendrás acceso a la variable "MyBoton".
Esa es la forma "fácil": Desde el editor del layout, seleccionas el botón, y en el evento "OnClick" le dices que llame a "MyBotonOnClick" del activity, y luego te acuerdas de crear ese MyBotonOnClick" editando el activity porque el sistema no lo va a crear para tí.
En este ejemplo empezaremos haciéndolo un poco más a mano (incluso) que esto: En el OnCreate del Form2 (la activity no visual), localizaremos el botón dentro del layout (.dfm) y le asignaremos, por código, un código al evento, que por cierto lo creamos "sobre la marcha".
Este ejemplo es más didáctico que práctico, es mejor usar el sistema "fácil", pero ilustra como funcionan las cosas en android (más adelante, en el ejemplo, se comenta línea a línea):
[java]
public class Form1Activity extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState); //inherited;
setContentView(R.layout.main); //form.show
final EditText txtNombre = (EditText)findViewById(R.id.edNombre); //una const que apunta el TEdit
final Button btnEcho = (Button)findViewById(R.id.btnEcho); //una const que apunta al TButton
btnEcho.setOnClickListener(new OnClickListener() {
public void onClick(View arg0) {
//Aqui el codigo que queramos ejecutar en el evento, comentado mas abajo
Intent intent = new Intent(HelloWorldActivity.this, FrmEchoActivity.class);
Bundle bundle = new Bundle();
bundle.putString("NOMBRE", txtNombre.getText().toString());
intent.putExtras(bundle);
startActivity(intent);
//Fin del codigo en si del evento
}
});
}
}
[/java]
La "R" de los Resources:
Si os fijáis en el ejemplo anterior, cuando el activity (unit) necesitaba localizar un botón pegado en su propio layout (.DFM), lo hacíamos con esta línea de código:
[java]
final EditText txtNombre = (EditText)findViewById(R.id.edNombre); //una const que apunta el TEdit
[/java]
En delphi podríamos hacer lo mismo así:
delphi
La gran diferencia -aparte del orden y sintaxis y de que en delphi esto no sería necesario- es que en delphi el propio Form sabe encontrar un componente por su nombre, y si necesitamos localizar otro Form, se lo pediríamos a la Application también por su nombre, pero en Android, no tenemos ni un TApplication ni un TForm al que pedirles que busquen algo por su nombre.
En su lugar tenemos a "R", un objeto que se crea automáticamente y que contiene la lista de todos los componentes (views) que se añadan al layout (.DFM) de nuestra activity (TForm), o como se diría en java/android, los "resources" de la aplicación. A este objeto es al que le pedimos que busque algo -un View/Component- por su nombre (su id) usando la sintaxis que veis en el ejemplo.
Nota: en delphi uno puede localizar y referenciar a un componente de otro form de la aplicación sin mayor problema, e incluso meternos en el y cambiarle lo que queramos. Incluso a nivel de API de win32 puedes localizar un edit de cualquier otra aplicación por su nombre y cambiarle el texto, "hackenado" de alguna forma otras aplicaciones. En Android eso no se puede hacer: puedes localizar por su nombre (id) solo los componentes (Views) del .DFM (layout) de tu form (Activity), el del resto de activities están vedados.
También en esta "R" se listan otras cosas aparte de los Views (componentes) por su id (nombre), también están los layouts (como un Application.Forms en delphi) como veremos más adelante en el "ejemplo real". En general es la lista de todo lo que nuestra aplicación lleva dentro y que está accesible desde nuestra activity.
Intent:
Cuando una activity quiere hacer algo con otra activity (desde tu lista de clientes quieres llamar a la ficha de cliente para visualizar a uno concreto), no haces nada del estilo "FichaForm.create(self).ShowModal", en lugar de eso lanzas un mensaje, tipo los mensajes de windows o los "Pipe" de unix, dirigido a una activity de tal tipo, que puede o no ser parte de tu app: lo mismo da llamar a la ficha de editar un cliente en tu aplicacion que llamar a la aplicación del teléfono para que llame al teléfono de ese cliente.
El sistema Android es el que decide a que activity concreta va a "despertar" para realizar la acción que intentas/pretender (Intent) llevar a cabo. Si el sistema ve que existen dos activity instaladas capaces de realizar ese tipo de acción (Intent), preguntara al usuario, igual que cuando instalas un segundo browser y el sistema te pregunta cual quieres usar al pinchar por primera vez en un link.
La idea es similar a como en windows defines que la acción "abrir" aplicada sobre un fichero tipo ".pdf" se le ha de enviar al programa "adobe reader.exe" pero expandiendo ese concepto a todo el funcionamiento de las aplicaciones: defines que activity recibirá los mensajes de tal tipo y ese mecanismo te sirve para casi todo, no solo abrir tal tipo de fichero.
También es similar a los conduits de la fallecida Palm, para los nostálgicos, pero no solo para sincronizar con el PC, también se usaría internamente para pasar datos y hacer llamadas desde una pantalla a otra.
Un ejemplo sería una lista de clientes que pide que un cliente sea editado, y la activity que recibe esa petición seria del tipo "ficha de cliente". Otro ejemplo es cuando quieres abrir un tipo de fichero, visualizar una web, editar un contacto de la agenda, enviar un sms... todo funciona del mismo modo.
La activity receptora recibirá el intent en un evento tipo OnFormCreate y obrará en consecuencia.
Si os fijáis, al lanzar una aplicación android desde eclipse, se hace mediante un "intent" enviado al launcher instalado en tu android (el programa que aparece al pulsar "home") pidiéndole que lance (abra la actividad "MAIN" o MainForm) de tu app:
ActivityManager: Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=net.hcsoft.adrian/.HelloWorldActivity }
Es decir, enviamos un mensaje (Intent) con los siguiente datos (Boundle) entre llaves: accion = llamar al MAIN form de la app, categoria "LAUNCHER" (esto define que programa lo va a recibir), cmp -supongo que es el componente a llamar- igual al nombre interno (y único) de la activity de nuestra aplicación que ha de recibir el encargo.
Nota: Como veis, la activity lleva un nombre largo que la diferencia de cualquier otra: "net.hcsoft.adrian/.HelloWorldActivity" donde net.hcsoft.acrian es un nombre que Adrian, compañero en la empresa, ha decidido ponerle como inicio del nombre a todas sus activities para evitar que nunca se llamen igual que otras de otros programas y fabricantes.
Este mensaje lo recibirá la aplicación "Launcher" definida en nuestro android, bien el launcher que trae de fabrica o en mi caso "GO Launcher EX", que es la app que aparece al pulsar el botón home en tu android, y este abrirá la aplicación pedida, por su activity incial o main.
Boundle:
Cuando se crea un intent para llamar/comunicarse con otro objeto/ventana (activity), se ha de pasar un mensaje, que en Android se llama "boundle", y que internamente es un fichero XML con pares "nombre = valor", como un TStringList.values.
La idea es que el form (activity) receptora del intent (llamada) no tiene acceso al form (activity) que lo llama, no hay un sender como en delphi, así que todo lo que deba saber el receptor, ha de ir "empaquetado" en un boundle (stringlist).
Un ejemplo "real":
Hasta aquí el diccionario Android-Delpih, pero para aclarar todo un poco, lo mejor es ver un ejemplo sencillo pero "realista"...
Supongamos un programa con dos forms (activities con sus correspondientes layouts). En nuestro Form1 (el "Application.mainform") se pregunta en un TEdit por un nombre (por ejemplo escribes "PEPE") y al pulsar un botón, se llamará a un segundo Form (activity) donde aparecerá un texto del estilo "Tu nombre es PEPE".
En delphi podríamos hacer en el evento OnClick del botón algo del estilo:
delphi
En Android cada form (activity) es un mundo independiente del resto, aunque "vivan" en la misma App: Un form -activity- no tiene acceso al otro, ni tampoco es necesario -ni posible- que el Form1 cree una instancia de Form2, ni siquiera pueden existir dos instancias de una activity (y por eso ni se menciona la instancia, porque activity es a la vez la definición del form y el form mismo ya creado, la instancia o variable).
Este sería el código del evento, notar que la forma de conectar botón del layout con evento del activity se comentó más arriba en "Conexion Activity-Layout", y que hay básicamente dos formas de hacerlo, la fácil y la difícil.
Si usáis la forma difícil, el código sería el que veis, pero si optáis por lo más normal (definir visualmente que en el onclick del botón se llame a este procedimiento del activity) en ese caso las lineas 1 y 9 las eliminaríais.
Nota: Numero "artificialmente" las lineas para comentarlas una a una más abajo:
[java]
1 btnEcho.setOnClickListener(new OnClickListener() { //Esta linea no aparece en el metodo "facil"
2 public void onClick(View arg0) {
3 Intent intent = new Intent(HelloWorldActivity.this, FrmEchoActivity.class);
4 Bundle bundle = new Bundle();
5 bundle.putString("NOMBRE", txtNombre.getText().toString());
6 intent.putExtras(bundle);
7 startActivity(intent);
8 }
9 }); //Esta linea no aparece en el metodo "facil"
[/java]
Traducido a delphi:
1) Se asigna un objeto "listener" (un event handler en delphi) al botón btnEcho a la misma vez que se define el propio objeto listener, con su procedure onClick dentro. En delphi el "event handler" no es un objeto en si, porque nuestro TApplication los maneja todos como una lista, pero en Android es un objeto. Si optamos por la opción fácil, editaríamos el botón del layout (DFM) y le diríamos que llame al "onClick" de la actividad escribiéndolo a mano (no aparece en un desplegable ni nada así) con lo que esta línea no aparecería, ya que no sería necesario conectar botón y evento a mano.
2) Se añade la función "onClick" al objeto tipo "listener" de la linea 1. En el método fácil simplemente creamos la función sin pertenecer a ningún objeto, solo pertenecería a la actividad en si.
Esta función es lo mas parecido a nuestro "Event Handler" de delphi. El "sender: TComponent" de delphi aquí es "View arg0", donde un View es como un TComponent de delphi.
Fijaos que el objeto listener (o la función onClick) está dentro de nuestro unit (activity), por lo que en este código no tenemos acceso ni al propio botón (excepto porque me llegarái como parámetro arg0): el botón y el TEdit son objetos del layout, pero la función "onClick" esta en la actividad.
3) Con la intención de llamar al segundo activity (un unit con su Form en este caso) necesitamos un Intent (ojo al juego de palabras intención = intent).
En la creación del intent declaramos la activity de origen, que es la actividad actual donde estamos trabajando (this = self, es decir, el Form1 de nuestra app "HelloWorldActivity") y lo más importante, el nombre de la activity destino, que en este caso es el class name del otro form de nuestra aplicación, pero podría ser otra cosa de otra aplicación instalada o del propio sistema.
Fijaos que no decimos Application.ActiveForm, en lugar de llamar genéricamente a la aplicación "Application" tenemos que usar su nombre interno, ya que el receptor puede ser una activity externa a nuestro app (puede que estemos creando un intent para que el dialer del teléfono llamé a un cierto número, en ese caso la actividad destino es propia de android y tiene un nombre fijo, peor si queremos hacer que un PDF se abra, entonces el destino llevará el nombre que adobe se inventase en su día para hacerlo).
En el segundo parámetro declaramos la activity receptora. Usamos directamente la clase del Form2 de nuestra aplicación, algo así como usar "Form2.ClassName", pero ojo, internamente todas estos nombres de activity llevan delante la empresa o la aplicación "propietaria". Podría ser algo como "www.adobe.com/openPDFfileActivity" si se trata de abrir un PDF, o más ligado al sistema como "Tel" para llamar por teléfono a un número (no son ejemplos reales, es solo para entender la idea).
4) Ahora creamos un "boundle", algo como un TStringList que llevara las parejas de "values" para pasarselas al Form2.
5) Añadimos el parámetro a pasarle, que sería algo como "MyStringList.Add('NOMBRE = ' + MyEdit.Text);"
6) Asociamos el intent con este boundle antes de lanzar el mensaje.
7) Lanzamos el mensaje. Esto hará que:
- 7a.- Se crea un form (activity) del tipo declarado en el punto 3 (Form2 en nuestro delphi), o si ya existe uno creado, se usará el existente (nunca hay dos activities del mismo tipo a la vez, no podemos por ejemplo abrir dos PDF en un Android usando dos instancias del activity "visor de PDFs de adobe").
- Se lance el evento "OnGetIntent" de la actividad destino (en delphi seria el evento OnFormCreate ya que la actividad -form- se crea automáticamente cuando se recibe un intent destinado a ella).
- El evento recibe como parámetro un "boundle" con los datos que precisa mostrar/procesar.
Veamos ahora la acción desde el activity receptor, nuestro Form2: en este caso copio tanto la definición del form2 como el event handler que recibirá el Intent (el onFormCreate):
[java]
1 public class FrmEchoActivity extends Activity {
2 /** Called when the activity is first created. */
3 @Override
4 public void onCreate(Bundle savedInstanceState) {
5 super.onCreate(savedInstanceState);
6 setContentView(R.layout.echo);
7 TextView txtMensaje = (TextView)findViewById(R.id.textView1);
8 Bundle bundle = this.getIntent().getExtras();
9 txtMensaje.setText("Hola " + bundle.getString("NOMBRE"));
10 }
11 }
[/java]
Veamos la traducción:
1) Se define la clase form2 (FrmEchoActivity) que deriva/hereda/extends de la clase base "Activity" (una unit, vamos).
2) Este comentario se añade solo y nos dice que estamos ante el OnFormCreate.
3) El onCreate es un override del onCreate original del TForm/Activity. Notar que siempre se recibe un Boundle al crear/activar una activity.
4) El nombre del boundle recibido es "savedInstance", lo decide el SDK, porque en teoría abrimos un form para ver un cierto estado anterior (como si minimizamos y luego maximizamos), aunque en realidad solo recibe un nombre... claro que el estado de este form se define solo sabiendo el nombre, así que es un nombre acertado.
Nota: Cuando en android pasamos a otra aplicación, la anterior se "minimiza", y si android ve que no se usa y necesita espacio, la matará el solo, pero se guarda antes su "estado actual", de forma que si la reactivas, está recibe como boundle el estado donde se minimizó, y tu ves el programa que reaparece donde lo dejaste. El programador nunca sabe si nuestro objeto (la activity, sea esta un objeto no visual -unit- o visual con layout) está viva o muerta, android se preocupa de esto.
5) Equivale exactamente a un "inherited" de delphi puesto en el OnFormCreate. En java "super" es la clase "padre" de la que heredamos/derivamos nuestra activity, en nuestro caso es un "activity" generíco, por lo que el inherited llamará a la incialización por defecto de ese objeto.
6) El evento llama al Form.Show, bueno, más bien hace un Application.ActiveForm(Form2). Esto no es necesario en delphi, pero aquí todo cambia: La actividad (una unit tipo .pas) no es lo mismo realmente que el form (layout, el .DFM), así que el código del evento de creación de la activity (unit) ha de llamar explícitamente a la visualización del .DFM (Layout) asociado.
Como la activity (el Form2) se llama "EchoActivity" (bueno, desde fuera de la aplicación se añadiría delante un id del tipo www.hcsoft.net o como cada cual quiera "rotular" sus aplicaciones), el form asociado (Layout) se llama automáticamente "Echo", por eso se utiliza R.layout.echo (R es un objeto que se crea solo con referencias a todos los resources de nuestra aplicación como ya vimos, incluidos los layouts que tengamos asociados a diferentes activities, o los componenetes (Views) de los layout por su nombre/id, etc.).
7) Declaramos un puntero tipo TLabel (TextView, recordar que un View es como un TComponent, asi que la traducción podría ser TextComponent, es decir, TLabel) llamado txtMensaje que apuntará al TLabel que pusimos en el layout (form), que son dos cosas diferentes, por eso de nuevo le pedimos a R (la lista de resources disponibles en nuestra app, algo así como un Application.FindComponentByName) que nos de el puntero a un TComponent (View) que al crearlo el en layout le llamamos (le pusimos un Id) "textView1".
NOTA: No se puede poner el nombre de un edit de otro layout y obtener un puntero a un objeto de otra actividad del proyecto, está prohibido. Si quieres comunicarte con otro activity, tienes que crear un intent que "apunte" a ese otro activity y pasarle como "boundle" la información que quieras en el formato que esa activity vaya a entender, pero lo que se haga con esos datos es cosa interna del activity al que llamas, no puedes interferir.
Es como si en delphi se obligase a programar los forms "orientados a objetos" estrictamente sí o sí: No puedes acceder a variables ni componentes de los otros forms, solo puedes llamar al su FormCreate pasándole los datos que quieras y confiar en que el form sabrá qué hacer con tus datos.
En delphi esto seria algo así:
delphi
Claro que esto no es necesario en delphi, ya que .pas y .dfm estan unidos y MyLabel y Label1 son la misma cosa.
8) Declaramos un objeto tipo Boundle (TStringList con pares de name y value) llamado boundle, y lo hacemos apuntar al boundle que esta activity (this = self) ha recibido dentro del Intent que la llamó (como el sender que recibimos como parámetro en el onCreate, aunque en este caso son listas de datos y no punteros a otros objetos) y que dentro del intent se llama "extras".
Personalmente vería mas lógico haberlo llamado .getBoundle que .getExtras, pero bueno, "Extras" es el "Boundle" que va dentro del "Intent" que nos llega en el "OnCreate" de nuestra "Activity"... parece un trabalenguas.
9) En delphi seria esto:
delphi
Y esto es todo, seguro que me tocará pulir este post de vez en cuando, así que cualquier errata, error de concepto, duda que os surja, mentira u olvido que encontréis, comentadlo y lo iré corrigiendo.
pero ojo, comparto conocimientos casi "del dia", así que puede que algo no sea del todo correcto!
