[ CONSULTA ] Canvas en un ScrollView

[mocelet]

Supongamos que tengo una app que pinta toda su interfaz en el método onDraw y cuyo contenido es muy alto (vamos a poner 9000 pixeles) y es necesario scroll. El contenido se genera dinámicamente, no es un mapa de bits (no cabría en memoria gráfica), solo llamadas al canvas con textos, formas y alguna imagen pequeña ya cargada.

En Android, si hago una View personalizada que en el onMeasure devuelva su altura "virtual", es decir los 9000 pixeles y en el Canvas del onDraw pinto sin preocuparme de la parte que se está mostrando, ¿si eso lo meto en un ScrollView funcionará bien, verdad? Es decir, aunque en el canvas pinte fuera del área visible eso no se estará almacenando en ningún sitio y supongo que además los eventos los recibiré en las coordenadas virtuales por así decirlo, ¿no?

Ahora un offtopic, como sé que algunos también programáis en iOS... ¿esto mismo lo podría hacer con el UIView y el UIScrollView, verdad? Todavía voy por el hola mundo, pero para estar seguro de que tampoco tendría problemas por tener una vista con un tamaño "virtual" muy grande. He leído que el drawRect tiene grandes problemas de rendimiento con el scroll incluso estando vacío el método... ¿no es viable entonces hacer una vista muy alta dibujando en el canvas/context)?

¡Gracias!

[kriogeN]

En cuanto a la primera pregunta, la teoría dice que si, una cosa son las dimensiones "virtuales" del Canvas y otra sus dimensiones físicas. Ejemplo: Tengo hecho un juego que sus dimensiones "virtuales" son 1000x1000 píxeles, y efectivamente si pincho en el borde derecho me dice que he pinchado en la posición "1000x1000". Ahora bien, está en en un SurfaceView que es "match_parent" para ambos, y en un MDPI y HDPI ocupa la pantalla entera en ambos, siendo para ambos sus dimensiones "virtuales" 1000x1000 en la esquina, pero 320x240 y 480x800 "físicas" para cada uno de ellos. Así que supongo que con el ScrollView ocurrirá igual.

Creo que me habrás entendido bien.

Y en el caso de IOS, su gestión de la parte visible de una UIView es menos exigente que en Android. Por ejemplo en el caso del iPhone 4 sus dimensiones son 640x960. Pero puedes tener una UIView primaria (la que controla directamente el UIViewController) de 1000x1000, y desplazarte a través de ella en tiempo real sin necesidad de UIScrollView, tanto verticalmente como horizontalmente. También te digo que con IOS nunca he dibujado directamente sobre el UIView primario, sólo controles nativos, así que lo que dices de problemas de rendimiento dibujando directamente no tengo ni idea.

[mocelet]

Entiendo, igual me expliqué mal con lo de "virtual" En tu caso digamos que es una conversión de unidades nada más porque el espacio virtual entero ocupa físicamente el tamaño de la pantalla, en mi caso los 9000 pixeles virtuales se corresponderían uno a uno con la pantalla (por eso hace falta el scroll).

Tocará probar a ver, creo recordar que por defecto Android hace clip del canvas de la vista, así que aunque una vista diga que ocupa 9000x2000 no reserva esa zona gigante de memoria gráfica sino solo la parte visible en ese momento.

Muchas gracias por el apunte de iOS, entre lo que comentas y lo que he buscado ahora, parece que no es tan fácil como en Android. En iOS reserva memoria gráfica para toda la superficie, y si quieres que una vista sea gigante tienes que usar una CATiledLayer y dibujar por fragmentos de 1024x1024. Como realmente yo voy a pintar en el contexto, la vista puede ocupar el tamaño físico de la pantalla, pero tendré que decirle al UIScrollView que haga como si fuera más grande y recibir los eventos de scroll para actualizar el canvas, aunque no sé cómo saldrá. Más adelante entonces cuando me familiarice un poco más.

Es que estoy en plena vena multiplataforma Android/HTML5/iOS y cada cosa que quiero hacer me pregunto cómo se haría nativamente en las tres.

EDITO: Anda, encontré una pregunta en stackoverflow sobre el scroll de iOS, empezó a tener problemas a los 16.000 pixeles, vale, me sobra DD http://stackoverflow.com/questions/7...ew-contentsize