Tecnologia

Articulos relacionados con Tecnologia: Opinión, Tutoriales, Novedades,..

Obtener drivers USB Samsung sin instalar Kies

Los que desarrollamos para Android en sistemas operativos como GNU/Linux o MacOs X no solemos tener problemas para acceder a los teléfonos a través de USB, bien para instalar aplicaciones o acceder a los logs a través de ADB. El problema lo tenemos cuando queremos hacer esto mismo en sistemas Windows y nos encontramos que al conectar el móvil al PC nos aparece un mensaje de dispositivo desconocido o que no encuentra los drivers.

En mi caso, hace poco he me hecho con un Samsung Galaxy SI II con el que estoy haciendo unas pruebas. Y lo primero que hice fue buscar los drivers para poder conectarme vía ADB. Mi sorpresa fue encontrar un montón de referencias a un paquete instalador de drivers para dispositivos Samsung que no me funcionaba. Otras referencias me indicaban que instalara Kies, un software de Samsung para acceder al dispositivos, sincronizar y demás herramientas que suelen ofrecer las empresas fabricantes de teléfonos móviles. Por supuesto, no estaba dispuesto a instalar todo una suite para instalar unos drivers USB, por lo que pensé que quizás seria posible obtener los driver del propio paquete de instalación de Kies.

Por lo tanto, lo primero que hice fue buscar Kies en Google y acceder a la pagina oficial de Kies donde descargué el software para Windows

http://org.downloadcenter.samsung.com/downloadfile/ContentsFile.aspx?CDSite=UNI_ES&CDCttType=SW&ModelType=N&ModelName=FM_UPDATE&idyn=N&VPath=SW/201105/20110512115717796/Kies_2.0.2.11071_128_2.exe

Por otro lado me descargué también el UniversalExtractor, el cual es un software capaz de desempaquetar instaladores, y ya que al fin y al cabo un instalador no es mas que un contenedor de binarios con instrucciones de donde copiarlos, no tiene mayor misterio acceder a su interior (la otra opción es instalar Kies coger el driver y desinstalarlo después).

http://legroom.net/scripts/download.php?file=uniextract161

Une vez instalado el UniversalExtractor, accedemos a nuestro directorio de descargas y extraemos el instalador de Kies seleccionando la opción “Instalshield /b Interconector“

Lo que hará que se nos cree una carpeta Kies_XXXXXX\ uni_xuemcfc\

Dentro de esta carpeta tendremos otro instalador MSI “Samsung Kies.msi“. Que volveremos a extraer de manera parecida pero esta vez con la opción “MSI Instalador Administrativo“.

Al desempaquetar el MSI obtendremos el contenido del instalador de Kies y si indagáis encontrareis que el instalador de los Drivers USB esta en Samsung Kies\program files\Samsung\Kies\USB Driver con el nombre de SAMSUNG_USB_Driver_for_Mobile_Phones.exe

Ejecutáis el instalador y pronto veréis como Windows va reconociendo vuestros dispositivos móviles.

El nombre del instalador de drivers es el mismo que el que en foros anteriores había encontrado e instalado pero que no me funcionaban. Esto se debía a que eran versiones anteriores del instalador de drivers que no contenían los drivers compatibles con el Samsung Galaxy S II. Por tanto en vez de alojar el instalador en un repositorio y enlazarlo en foros, he creído mas interesante mostrar como obtener la ultima versión del instalador de drivers a partir del instalador de Kies.

Espero que os haya sido de utilidad.

Empezando con Windows Phone 7

Estos días me ha dado por intentar probar a desarrollar algo para Windows Phone 7. Más concretamente, quería probar las implementaciones BETA que existían de PhoneGap para Windows Phone 7, por lo que rápidamente me hice con una versión de Visual Studio 2010.

Me baje el código fuente de los ejemplo de PhoneGap y lo primero que me di cuenta era que la instalación de VS 2010 no viene con las herramientas de desarrollo de aplicaciones para terminales móviles. Al final, encontré que lo que necesitaba era un complemento llamado “Windows Phone 7 Developer Tools“, que encontré en esta dirección:

http://download.microsoft.com/download/1/7/7/177D6AF8-17FA-40E7-AB53-00B7CED31729/vm_web.exe

Lamentablemente al intentar instalarlo me decía que no era posible, ya que era necesario tener Windows Vista o 7 instalado. Al final conseguí hacerlo funcionar en XP realizando los siguientes pasos:

  • Descargamos Windows Phone 7 Developer Tools (vm_web.exe)
  • Extraemos el contenido de el instalador, lanzado una consola, posicionándonos en el directorio donde se encuentra la aplicación vm_bex.exe y ejecutándola de la siguiente manera: vm_web.exe /x <directorio_donde_lo_extraeremos>
  • Abrimos <directorio_donde_lo_extraeremos>\baseline.dat con un editor de texto
  • Buscamos la sección [gencomp7788]
  • Cambiamos los valores de la sección InstallOnLHS y InstallOnWinXP a 0.
  • Guardamos y cerramos <directorio_donde_lo_extraeremos>\baseline.dat
  • Ejecutamos el instalador lanzando el siguiente comando: <directorio_donde_lo_extraeremos>\setup.exe /web

De esta manera se nos lanzara el instalador y podremos instalar las herramientas de desarrollo móvil a nuestros VS 2010.

NOTA: En Windows XP no es posible ejecutar el emulador, pero si compilar y desarrollar. En caso de querer probar la aplicación, deberéis disponer de un terminal con Windows Phone 7 y a la hora de Debugear seleccionar “Windows Phone / Device”.

XML, JSON… Protocol Buffers

El intercambio de información en los sistema distribuidos o en cualquier tipo de servicio, es un tema clave, para lo cual, a lo largo de los años han surgido un montón de soluciones y tecnologías. Hasta ahora la formula mas utilizada era el formato XML, en muchos caso envueltos de una capa extra de gestión, como son el caso de SOAP o WCF impulsados por Microsoft. En general XML sigue siendo claro dominador a la hora de proveer información estructurada. Los feeds de nuestra Web, Sitemaps o muchos proyectos de OpenData proporcionan información en este formato.

A pesar de ello, XML para muchos es un formato engorroso, su interpretación o extracción de la información, a pesar de que existen muchas librerías que lo facilitan, suele traer de cabeza a muchos desarrolladores y cada vez, tiene mas presencia la tecnología JSON a la hora de acceder a servidores de datos, APIs, etc.. la facilidad para generar y recuperar la información que ofrece JSON esta haciendo que sea estándar de facto en prácticamente todos los servicios que permiten interactuar con servicios terceros. Empresas como Facebook o WOT, apuestan por JSON para el acceso a la información, sobre todo cuando esta se genera de forma dinámica. Aun así en la mayoría de los casos sigue estando opcional el acceso s los datos en XML.

En este articulo trato de presentar Protocol Buffers, una solución que pretende ser mas optima, en lo que respecta a trafico de datos, y mas opaca, si lo que interesa es que la información no viaje de forma totalmente visible. Personalmente, creo que lo mas interesante de este sistema es que reduce considerablemente el volumen de trafico generado en cada petición de información, lo cual es muy interesante si lo que queremos es desarrollar un servicio explotado por aplicaciones móviles, donde podemos conseguir aplicaciones mas fluidas, si conseguimos que el tiempo de conexión sea el menor posible.

En mi caso, Protocol Buffers me parece una solución interesante, ya que suelo usar Google App Engine, como web service generador de datos, y para terminales móviles suelo trabajar con Android, para el cual existen librerias. Además hay que tener en cuenta que muchas de las aplicaciones de serie en Android como el Market usan Protocol Buffers internamente (a pesar de que oficialmente la SDK de Android no ofrece acceso a dichas librerías).

En próximos post explicare como manejar Protocol Buffers en python.

Curso de Iniciación de Google App Engine

Este sábado dentro de las iniciativas llevadas a cabo por GTUG (Google Technology User Group) Bilbao, se va a llevar a impartir un curso de iniciación a la plataforma Google App Engine. El curso será este Sábado 19 de Febrero en la sede de Creativity Zentrum Bilbao a las diez de la mañana.

El curso básicamente va a ser una introducción a la plataforma y se realizará la guía “Getting Started” de forma interactiva, mientras se resuelven dudas realizando todos los ejemplos y alguna prueba mas que pueda ser de interés. Se supondrá que los usuarios tienen cierto conocimiento en Python, aunque al tratarse de un lenguaje muy sencillo con tener conocimientos en lenguajes orientados a objetos seria suficiente.

Así que si no tenéis planes para este sábado a la mañana y siempre habéis tenido ganas de hincarle el diente a este servicio de Google no lo dudéis y confirmar vuestra asistencia en el siguiente enlace: http://doodle.com/wm7a4ucbaf4xhmxi

Asociacion Creativity Zemtrum Bizcaya


Ikusi mapa handiagoa

Archivos DEX (Dalvik Executable): La Tabla de Tipos

Seguimos desenmarañando la estructura de los archivos Dex y ahora nos toca la tabla de tipos, es decir, los diferentes tipos de datos que utiliza nuestra aplicación a analizar. En este caso al igual que hicimos con la tabla de strings, obtenemos el offset y numero de elementos en la tabla de tipos de la cabecera. En el caso que estamos analizando la tabla de tipos comienza en 0x000001AC y tiene 28 (0x0000001C) elementos. Recorriendo de 4 en 4 bytes obtenemos las posiciones en la tabla de strings que identifican los tipos a usar: 2,7,8,9,10..

  1. elemento 2 de la lista de STRINGS: I
  2. elemento 7 de la lista de STRINGS: Landroid/app/Activity;
  3. elemento 8 de la lista de STRINGS: Landroid/os/Bundle;
  4. elemento 9 de la lista de STRINGS: Landroid/text/Editable;
  5. elemento 10 de la lista de STRINGS: Landroid/view/View$OnClickListener;
  6. elemento 11 de la lista de STRINGS: Landroid/view/View;
  7. elemento 12 de la lista de STRINGS: Landroid/widget/Button;
  8. elemento 13 de la lista de STRINGS: Landroid/widget/EditText;
  9. elemento 14 de la lista de STRINGS: Landroid/widget/TextView;
  10. elemento 15 de la lista de STRINGS: Lcom/marakana/NDKDemo$1;
  11. elemento 16 de la lista de STRINGS: Lcom/marakana/NDKDemo;
  12. elemento 17 de la lista de STRINGS: Lcom/marakana/NativeLib;
  13. elemento 18 de la lista de STRINGS: Lcom/marakana/R$attr;
  14. elemento 19 de la lista de STRINGS: Lcom/marakana/R$drawable;
  15. elemento 20 de la lista de STRINGS: Lcom/marakana/R$id;
  16. elemento 21 de la lista de STRINGS: Lcom/marakana/R$layout;
  17. elemento 22 de la lista de STRINGS: Lcom/marakana/R$string;
  18. elemento 23 de la lista de STRINGS: Lcom/marakana/R;
  19. elemento 24 de la lista de STRINGS: Ldalvik/annotation/EnclosingClass;
  20. elemento 25 de la lista de STRINGS: Ldalvik/annotation/EnclosingMethod;
  21. elemento 26 de la lista de STRINGS: Ldalvik/annotation/InnerClass;
  22. elemento 27 de la lista de STRINGS: Ldalvik/annotation/MemberClasses;
  23. elemento 28 de la lista de STRINGS: Ljava/lang/CharSequence;
  24. elemento 29 de la lista de STRINGS: Ljava/lang/Integer;
  25. elemento 30 de la lista de STRINGS: Ljava/lang/Object;
  26. elemento 31 de la lista de STRINGS: Ljava/lang/String;
  27. elemento 32 de la lista de STRINGS: Ljava/lang/System;
  28. elemento 37 de la lista de STRINGS: V

Estos strings usan una sintaxis concreta y pueden traducirse a una forma mas común de definir los tipos mediante la siguiente tabla.

Syntax Meaning
V void
Z boolean
B byte
S short
C char
I int
J long
F float
D double
Lnombre/completo/Clase; la clase nombre.completo.Clase
[descriptor Array de elementos descriptor, es posible crear arrays de arrays, con limite de profundidad 255
Ejemplo: [I ~ array de ints (int[])

Por tanto, la tabla, nos quedaria de esta manera:

  1. int
  2. android.app.Activity
  3. android.os.Bundle
  4. android.text.Editable
  5. android.view.View.OnClickListener
  6. android.view.View
  7. android.widget.Button
  8. android.widget.EditText
  9. android.widget.TextView
  10. com.marakana.NDKDemo.1
  11. com.marakana.NDKDemo
  12. com.marakana.NativeLib
  13. com.marakana.R.attr
  14. com.marakana.R.drawable
  15. com.marakana.R.id
  16. com.marakana.R.layout
  17. com.marakana.R.string
  18. com.marakana.R
  19. dalvik.annotation.EnclosingClass
  20. dalvik.annotation.EnclosingMethod
  21. dalvik.annotation.InnerClass
  22. dalvik.annotation.MemberClasses
  23. java.lang.CharSequence
  24. java.lang.Integer
  25. java.lang.Object
  26. java.lang.String
  27. java.lang.System
  28. void

Otro recurso mas, que sera utilizado junto a la tabla de strings para desensamblar el resto de estructuras de nuestra aplicación.

Entrevista en NickDutNik

Como anuncié a bombo y platillo semanas antes y publiqué (no lo suficiente) en las redes sociales, el día 2 de Febrero (2011) aparecía en el programa NickDutNik de ETB producido por Factoria Crossmedia. En la entrevista presentaba mi aplicación de Bizkaibus para Android y además explicaba las razones y motivaciones que me llevaron a desarrollar esta aplicación. Pinchando en la imagen podéis ver el video de la entrevista.

Archivos DEX (Dalvik Executable): La Tabla de Strings

La tabla strings, es una estructura que contiene las posiciones de los recursos string que utiliza nuestra aplicación. En esta lista de strings tendremos desde nombres de clases, métodos, variables o constantes que nos indicaran el tipo de los datos. Es una lista ordenada ya que desde otras estructuras se hará referencia a los strings en función de su posición en la lista. Es decir, en el proceso de compilación, se extraen los strings de todas las estructuras y código, se eliminan duplicados y se meten en una lista ordenada, por lo que a partir de entonces, ahí donde había un string ahora hay un entero que hace referencia a la posición del string en la lista. Con esto se consigue reducir el tamaño de la aplicación evitando la redundancia de recursos.

Para entenderlo mejor, a partir de este momento vamos a desensamblar, paso a paso, un archivo .dex de ejemplo que hemos obtenido a partir de este ejemplo http://marakana.com/forums/android/examples/49.html que es pequeño y usa la NDK (de cara a ser un ejemplo relativamente completo).

Analizando la cabecera como explicamos en el artículo anterior obtenemos el offset o desplazamiento desde el inicio del fichero donde empieza la tabla de posiciones de los strings, y el numero de strings. Por tanto obtenemos que la tabla de strings empieza en la posición 0×00000070 y que tiene 79 (0x0000004F) elementos. Por tanto deberemos recorrer el archivo desde la posición 0×00000070 en bloques de 32bist, 79 veces para obtener la posición de los 79 strings.

En el ejemplo de la imagen superior recorremos los tres primeros strings. La estructura de cada string es, un byte que indica la longitud del string y a continuación el string, por tanto, el primer string esta en la posición 0x0000084E, su longitud es de 0×08 caracteres y su valor es “<clinit>”. El segundo string esta en la posición 0×00000858, es de longitud 0×06 y valor “<init>”, el tercero esta en la posición 0×00000860 es de longitud 0×01 y valor “I”. Seguiríamos así con los 79 strings, con lo que en el ejemplo de la imagen obtendríamos la siguiente lista.

  1. <clinit>
  2. <init>
  3. I
  4. III
  5. IL
  6. L
  7. LI
  8. Landroid/app/Activity;
  9. Landroid/os/Bundle;
  10. Landroid/text/Editable;
  11. Landroid/view/View$OnClickListener;
  12. Landroid/view/View;
  13. Landroid/widget/Button;
  14. Landroid/widget/EditText;
  15. Landroid/widget/TextView;
  16. Lcom/marakana/NDKDemo$1;
  17. Lcom/marakana/NDKDemo;
  18. Lcom/marakana/NativeLib;
  19. Lcom/marakana/R$attr;
  20. Lcom/marakana/R$drawable;
  21. Lcom/marakana/R$id;
  22. Lcom/marakana/R$layout;
  23. Lcom/marakana/R$string;
  24. Lcom/marakana/R;
  25. Ldalvik/annotation/EnclosingClass;
  26. Ldalvik/annotation/EnclosingMethod;
  27. Ldalvik/annotation/InnerClass;
  28. Ldalvik/annotation/MemberClasses;
  29. Ljava/lang/CharSequence;
  30. Ljava/lang/Integer;
  31. Ljava/lang/Object;
  32. Ljava/lang/String;
  33. Ljava/lang/System;
  34. NDKDemo.java
  35. NativeLib.java
  36. R.java
  37. TextView01
  38. V
  39. VI
  40. VL
  41. accessFlags
  42. add
  43. app_name
  44. attr
  45. buttonCalc
  46. drawable
  47. findViewById
  48. getText
  49. hello
  50. helloText
  51. icon
  52. id
  53. layout
  54. loadLibrary
  55. main
  56. name
  57. nativeLib
  58. ndk_demo
  59. onClick
  60. onCreate
  61. outText
  62. parseInt
  63. res
  64. result
  65. savedInstanceState
  66. setContentView
  67. setOnClickListener
  68. setText
  69. string
  70. textOut
  71. this
  72. this$0
  73. toString
  74. v
  75. v1
  76. v2
  77. value
  78. value1
  79. value2

A partir de ahora las siguientes estructuras que vayamos desensamblando harán referencia a esta lista de strings.

Archivos DEX (Dalvik Executable): La Cabecera

La cabecera es como cabe de esperar, una de las partes mas importantes de la estructura el archivo .dex. Contiene el magic que nos permite identificar el formato de archivo, además de diferentes chechsums y hashes para comprobar la integridad del propio archivo. Pero lo que es mas importante, en la cabecera se encuentra el “mapa” para entender y descomponer el formato .dex en sus diferentes partes, ya que contiene una lista con los offsets y longitud de las diferentes parte de el archivo que comentábamos en el artículo anterior.

  • Tabla con las posiciones de los Strings
  • Tabla con las posiciones de los Tipos
  • Tabla con las posiciones de las estructuras/Prototipos de los métodos
  • Tabla con las posiciones de las Propiedades de las clases o Campos de los métodos
  • Tabla con las posiciones de los Métodos
  • Tabla con las posiciones de las Clases
  • Datos



Name Format Description
magic ubyte[8] Este valor es el que identifica el tipo de fichero.
checksum uint Checksum (adler32) calculado en base a todo el fichero, menos magic y checksum.
signature ubyte[20] Firma HashSHA-1 de todo el fichero menos magic, checksum y la propia firma.
file_size uint Tamaño de todo el fichero incluida la cabecera (en bytes).
header_size uint Tamañode la cabecera (en bytes). Actualmente siempre toma el valor de 0×70 (112)
endian_tag uint Nos indica que tipo de formato endian usa el fichero. Importante de cara a interpretar los valores de los datos del archivo, pero defecto es litle-endian. [aclaración]
link_size uint Indicael tamaño de la sección de enlace (link section) o 0, si elfichero es enlazado de forma dinámica.
link_off uint Desplazamientoal comienzo de la sección de enlace desde el inicio del ficheroo 0 si link_size == 0.
map_off uint Desplazamientoal map_list en caso que éste exista o 0 en caso contrario. Elmap_list es una lista con todo el contenido del fichero. Estaestructura de datos puede contener datos redundantes, pero laintención de la misma es el poder recorrer el contenido delfichero de una forma más cómoda. Esta lista está ordenada.
string_ids_size uint Númerode elementos en la lista de strings.
string_ids_off uint Desplazamientoa la lista de strings o 0 en caso que dicha lista este vacía,circunstancia que raramente se va a dar.
type_ids_size uint Númerode elementos en la lista de tipos (type).
type_ids_off uint Desplazamientoa la lista de tipos o 0 en caso que dicha lista este vacía. Casoque raramente también se dará.
proto_ids_size uint Númerode elementos en la lista de prototipos.
proto_ids_off uint Desplazamientoa la lista de prototipos. 0 en caso que dicha lista este vacía.De nuevo, situación que raramente se dará.
field_ids_size uint Númerode elementos en la lista de campos.
field_ids_off uint Desplazamientoa la lista de campos o 0 en caso que dicha lista esté vacía.
method_ids_size uint Númerode elementos en la lista de métodos.
method_ids_off uint Desplazamientoa la lista de métodos. 0 si la lista está vacía.
class_defs_size uint Númerode elementos en la lista de clases.
class_defs_off uint Desplazamientoa la lista de clases. 0 en caso dicha lista este vacía,situación poco probable.
data_size uint Tamañoen bytes de la sección de datos. Debe ser un número parmúltiplo del tamaño de un uint (sizeof(uint)).
data_off uint Desplazamientoa la sección de datos.


ENDIAN_CONSTANT y REVERSE_ENDIAN_CONSTANT

En caso de que el valor se el campo endian_tag sea igual a REVERSE_ENDIAN_CONSTANT (0×78563412), consideraremos que el archivo esta en formato litle-endian, lo cual es el estandar y lo mas común. A pesar de ello, es posible usar otras configuraciones, tipo big-endian, en tal caso el campo endian_tag tomara el valor ENDIAN_CONSTANT (0×12345678).

Fuente: http://www.netmite.com/android/mydroid/dalvik/docs/dex-format.html

Archivos DEX (Dalvik Executable): Introducción

En los entornos Java estándar, el código fuente de Java es compilado en bytecode de Java, y almacenado en archivos .class. Los archivos .class son leídos por la máquina virtual Java en tiempo de ejecución. Cada clase en tu código Java se traducirá en un archivo .class. Esto significa que si tienes, por ejemplo, un archivo .java (código fuente) que contiene una clase pública, una clase interna estática, y tres clases anónimas, el proceso de compilación (javac) nos generará 5 archivos .class.

En la plataforma Android, el código fuente de Java también se compila en archivos .class. Pero después de generar los archivos .class, mediante la herramienta “dx“ son convertidos a un único archivo dex (Dalvik Executable). Mientras que un archivo .class contiene una sola clase, un archivo .dex contiene múltiples clases. Es el archivo .dex el que se ejecuta en la máquina virtual Dalvik.

El archivo .dex ha sido optimizado para el mínimo consumo de memoria y el diseño esta condicionado por la reutilización de datos. El siguiente diagrama compara el formato de los archivos .class utilizado por la JVM con el formato de .dex utilizado por la máquina virtual Dalvik.

.jar vs .dex

A grandes rasgos las estructura de un Archivo .dex consta de las siguientes partes:

  • Cabecera
  • Tabla con las posiciones de los Strings
  • Tabla con las posiciones de los Tipos
  • Tabla con las posiciones de las estructuras/Prototipos de los métodos
  • Tabla con las posiciones de las Propiedades de las clases o Campos de los métodos
  • Tabla con las posiciones de los Métodos
  • Tabla con las posiciones de las Clases
  • Datos

Salvo la tabla de Strings (que es a la que hacen referencia todas las tablas ya que es en esta parte donde se almacenan todos los nombre de clases, métodos, funciones, variable y tipos de datos), el resto sigue un orden jerárquico inverso, es decir, si quisiéramos desensamblar el archivos dex, tras obtener el listado de Strings, obtendríamos el listado de Clases, sus métodos, sus propiedades y campos de los métodos, la estructura de dichos métodos – que relaciona métodos y campos – y por ultimo los tipos, que nos indicaría los tipos de los campos de los métodos y los tipos que devuelven los métodos. Es decir, es una estructura relacional, que tiene como objetivo el reaprovechamiento máximo de la información, evitando redundancias y así conseguir un formato optimo para terminales móviles.

Como he indicado, son tablas donde se indica la posición donde esta la información que compone dicha tabla, normalmente mediante un Offset y opcionalmente una longitud. Estos datos junto con el código maquina están en la sección de datos.

En próximos artículos iremos desgranando con mas detalle, cada parte de la estructura del formato Dalvik Executable.

Fuente 1:http://davidehringer.com/software/android/The_Dalvik_Virtual_Machine.pdf
Fuente 2:http://www.scribd.com/doc/17194679/DalvikVMInternals#

Posibilidad de Cross-Site Scripting mediante Jquery.getJson() para OpenBizkaibus API

He actualizado la API de OpenBizkaibus para que sea posible realizar peticiones getJson() desde otras paginas. A continuación se muestra un ejemplo de cómo realizar esta petición. En el ejemplo se muestra como completar un selectbox con el listado de municipios de la consulta Consultar_FamiliasCentros y una vez seleccionado un municipio se completará otro selectbox con las lineas mediante LineasMunicipio.

<br />
&lt;!DOCTYPE html&gt;<br />
&lt;html&gt;<br />
&lt;head&gt;<br />
  &lt;style&gt;img{ height: 100px; float: left; }&lt;/style&gt;<br />
  &lt;script src=&quot;http://code.jquery.com/jquery-1.4.4.js&quot;&gt;&lt;/script&gt;<br />
&lt;/head&gt;<br />
&lt;body&gt;</p>
<p>&lt;p&gt;<br />
	&lt;select name=&quot;town&quot; id=&quot;townsel&quot;&gt;<br />
	&lt;/select&gt;<br />
&lt;/p&gt;<br />
&lt;p&gt;<br />
	&lt;select name=&quot;lines&quot; id=&quot;linesselsel&quot;&gt;<br />
	&lt;/select&gt;<br />
&lt;/p&gt;<br />
&lt;script&gt;</p>
<p>$(document).ready(function(){ </p>
<p>	//Get Town list<br />
	$.getJSON(&quot;http://openbizkaibus.appspot.com/api/Consultar_FamiliasCentros?jsoncallback=?&quot;,<br />
  {},<br />
  function(data) {<br />
    $.each(data, function(i,object){<br />
    	$.each(object.Registros, function(i,registro){<br />
    		$(&#8216;#townsel&#8217;).append(new Option(registro.DescripcionElemento, registro.CodigoElemento, true, true));<br />
    	});<br />
    });<br />
  });</p>
<p>  //<br />
  $(&quot;#townsel&quot;).change(function()<br />
    {<br />
        var CodigoElemento<br />
        var DescripcionElemento</p>
<p>        CodigoElemento = $(&quot;#townsel&quot;).val();<br />
        DescripcionElemento = $(&quot;#townsel option:selected&quot;).text();</p>
<p>        if(CodigoElemento.length &lt; 2){<br />
        	CodigoElemento = &quot;00&quot;+CodigoElemento;<br />
        }<br />
        if(CodigoElemento.length &lt; 3){<br />
        	CodigoElemento = &quot;0&quot;+CodigoElemento;<br />
        }</p>
<p>        $.getJSON(&quot;http://openbizkaibus.appspot.com/api/LineasMunicipio?jsoncallback=?&quot;,<br />
	{<br />
		codmunicipio: CodigoElemento,<br />
		descmunicipio: DescripcionElemento<br />
	},<br />
	function(data) {<br />
	  	$(&#8216;#linesselsel&#8217;).find(&#8216;option&#8217;).remove().end();<br />
	  	$.each(data, function(i,object){<br />
	  	 	$(&#8216;#linesselsel&#8217;).append(new Option(object.DenominacionLinea, object.CodigoLinea, true, true));<br />
	 	});<br />
	});<br />
    });<br />
});<br />
&lt;/script&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;<br />

Para ver el ejemplo funcionando pulsar aquí.

1 2 3 4  Scroll to top