¿ como vincular dos arrays ?

[aquiles777]

Me gustaria saver como se puede vincular dos arrays veran tengo un arra preguntas y otro de respuestas las preguntas se generan aleatoriamente pero mi problema es que no se como hacer para vincular una pregunta del array a una respuesta para que cuando salga esa pregunta este vinculada con la respuesta podrian ayudarme por favor.

[kriogeN]

En primer lugar, esta pregunta no es de Android, es de Java básico, y en segundo lugar, no termino de entenderla.

Por lo que entiendo tienes:

String[] preguntas;
String[] respuestas;

Lo que tienes que hacer es que cuando insertas en preguntas insertes en respuestas la respuesta apropiada en la misma posición que estaba en preguntas (si vas insertando al mismo tiempo en ambas no deberías tener problemas). Y su "vinculación" será por su posición.

De todas formas esa no es la forma más correcta de hacerlo, lo correcto es tener una clase Pregunta que contenga a la pregunta y a la respuesta:


public class Pregunta {
public String pregunta;
public String respuesta;
}


Y luego tener un Array de eso:

Pregunta[] preguntas;

O mejor aún, usar un ArrayList, así puedes ir rellenando sin saber el tamaño a priori:

ArrayList<Pregunta> preguntas;

De todas formas como siempre digo, primero Java, luego Android. Ve, aprende Java, y cuando sepas programar en Java vuelve y empieza con Android.

Y si no Java por lo menos el concepto de POO en cualquier otro lenguaje, una vez que lo domines es más o menos igual en todos los lenguajes.

[mocelet]

Esto más que Android es Java básico, tienes varias formas. La fácil es que el array original de preguntas y el de respuestas tengan el mismo tamaño y el mismo orden. Así sabes que la respuesta a la pregunta N está en la posición N.

Cuando sacas las preguntas aleatorias, simplemente saca índices aleatorios, no la pregunta. Así con el índice consultas la pregunta en su array y la respuesta en el suyo.

EDIT: Se adelantó kriogeN ;) Que además fue menos perezoso que yo para contar la forma buena de hacerlo con objetos

[Braaank]

Otra manera de hacerlo es tener un MAP en el cual la clave sea la pregunta y el valor la respuesta


Enviado desde mi iPad utilizando Tapatalk

[kriogeN]

Otra manera de hacerlo es tener un MAP en el cual la clave sea la pregunta y el valor la respuesta


Enviado desde mi iPad utilizando Tapatalk

Sólo por el placer de discutir de temas de desarrollo.

¿Y cómo buscas al azar ahí? Porque con un Map necesitarías la pregunta para realizar la búsqueda de la respuesta.

Te obligaría a tener que tener otro Array (o Map por indices si lo prefieres, pero para eso caso muchísimo más optimo un ArrayList) para indexar las preguntas.

Es más, ¿Qué haces para buscar?

String respuesta = mapa.get("¿Quién inventó el teléfono?");

Sinceramente no lo veo, muchísimo más optimo tener un modelo que contenga la pregunta y la respuesta, no tienes que buscar 2 veces en 2 colecciones distintas.

[mocelet]

Me ha gustado lo del "placer de discutir" de desarrollo xD

Para el OP, independiente de su adecuación, el map probablemente se escape de su conocimiento. Y el array que tiene al fin y al cabo ya permite obtener el valor a partir de una clave: la posición. En algún sitio tendrá que generar una posición aleatoria, que use eso siempre en vez de la String, cuando le haga falta la String que la lea del array.

Ahora, para un juego más elaborado con preguntas que puedan ser imágenes, respuestas que puedan ir en varios idiomas u obtenidas de un servidor o de un XML... usaría un identificador único por pregunta, no una dupla ni la String. Si hay que pasar algún parámetro o guardarlo que sea el identificador solo. Ahí ya sí tiene sentido usar un map, o incluso una sqlite, y una clave común para preguntas y respuestas que sea el identificador.

En su caso particular, lo más sencillo es que el identificador único sea el índice del array. Usar un hash del texto de la pregunta (lo que haría el map) puede tener efectos adversos, por ejemplo si descubres un error ortográfico y lo corriges pero otra actividad guardó en algún sitio la String antigua. Pasaría lo mismo con los índices del array si cambias algo, pero no con un identificador único.

[Braaank]

Sólo por el placer de discutir de temas de desarrollo.

¿Y cómo buscas al azar ahí? Porque con un Map necesitarías la pregunta para realizar la búsqueda de la respuesta.

Te obligaría a tener que tener otro Array (o Map por indices si lo prefieres, pero para eso caso muchísimo más optimo un ArrayList) para indexar las preguntas.

Es más, ¿Qué haces para buscar?

String respuesta = mapa.get("¿Quién inventó el teléfono?");

Sinceramente no lo veo, muchísimo más optimo tener un modelo que contenga la pregunta y la respuesta, no tienes que buscar 2 veces en 2 colecciones distintas.


Perdona no había leído que tenía que buscar una pregunta aleatoriamente, creí que buscaba solo relacionar la pregunta con la respuesta.

De igual manera no estoy del todo seguro ahora mismo si puedes sacar la clave (pregunta) por el index en el arrayMap, si fuera así bastaría con generar un número aleatorio y obtener la pregunta con eso.

Saludos


Enviado desde mi iPad utilizando Tapatalk

[kriogeN]

Perdona no había leído que tenía que buscar una pregunta aleatoriamente, creí que buscaba solo relacionar la pregunta con la respuesta.

De igual manera no estoy del todo seguro ahora mismo si puedes sacar la clave (pregunta) por el index en el arrayMap, si fuera así bastaría con generar un número aleatorio y obtener la pregunta con eso.

Saludos


Enviado desde mi iPad utilizando Tapatalk

Con el ArrayMap puedes sacar la Key (pregunta) de una posición, para luego obtener el Value (respuesta) de esa Key.

Pero siguen siendo 2 búsquedas (una directa y otra por diccionario) para obtener la pregunta y su respuesta.

Es muchísimo más limpio usar un modelo, imagina que en el futuro quieres dar opciones y entonces en vez de "respuesta" tienes "respuestaValida" y "respuestaFalsa".

Usando un modelo los cambios son en su clase, te da igual en que estructura esté montado. Incluso si hoy lees de un fichero y mañana lees de un SQLite, también te da igual, ese trabajo te lo hará el modelo.

Yo desde que descubrí el MVC y los principios SOLID no programo de otra forma.

[mocelet]

Yo desde que descubrí el MVC y los principios SOLID no programo de otra forma.

Primera vez que oigo ese acrónimo :oh: Mirando la wikipedia (https://en.wikipedia.org/wiki/SOLID_(object-oriented_design))... :palomitas: ¡OK! Los principios de OO de toda la vida con nombre chulo. No sé por qué no me extraña que el término se acuñara en una conferencia de Ruby xDD

EDIT:
Usando un modelo los cambios son en su clase, te da igual en que estructura esté montado. Incluso si hoy lees de un fichero y mañana lees de un SQLite, también te da igual, ese trabajo te lo hará el modelo.

Por continuar la discusión nada más, el modelo en efecto representa los datos y es lo mejor para tener un "contrato", no es más que una interfaz. Otra cosa es la estructura que haya detrás para guardar los datos y cómo adaptes la estructura al modelo (ORM, clase auxiliar, etc.). Está claro que eso debe ser transparente para la lógica (es muy feo acceder al array/map/sqlite/fichero directamente porque igual mañana lo cambias), así que lo ideal sería tener no solo el modelo de Pregunta sino una clase que implemente una interfaz que defina métodos tal que "public Pregunta getPreguntaAleatoria()".

El modelo magia no hace, detrás podría tener arrays simples y nadie lo sabría (podría construir el objeto Pregunta al vuelo si quiero a partir del array preguntas[] y respuestas[]), o un ArrayList (en este caso no hay adaptador que tocar porque los objetos Java ya están creados), o tienes un Map si quieres acceder por identificador, o tienes SQLite (que también hará falta un ID salvo que siempre se saquen al azar).

El caso del SQLite ya es más peliagudo. Podrías tener un modelo de pregunta con respuestas donde las preguntas estén en una tabla y las respuestas en otra, o que tengan categorías y las categorías las definas en otras tablas, o puede que lo tengas todo en una súper tabla. Cambiar el modelo ya no sería cambiar la clase Pregunta y el trabajo lo hace el modelo, es cambiar la base de datos y quizá aumentar la complejidad de las consultas, añadir JOINs, etc. Un ORM sí haría el trabajo sucio, el modelo no.

Por otro lado, siempre puede usarse un fichero o un SQLite como almacenamiento en crudo guardando los objetos en JSON o serializados de cualquier modo. Si a la base de datos le importa poco la estructura porque no hay que hacer búsquedas, es una opción igualmente buena. De hecho no sé si era Instagram o Facebook o algún servicio de éstos, usaba BLOB de MySQL (en el servidor, obviamente) para guardar objetos. Exponían un par de atributos en dos columnas y la otra columna era el objeto serializado.