Hola
 
Bueno, no sé si es lo que querés, pero aporto algo a ver si sumamos:
basicamente tenes que dividir la cosa en dos partes: usar el Blackberry como
browser de internet o bien usarlo como alojamiento para una aplicación que
corra en el mismo dispositivo.
 
En el primer caso, si intentamos navegar a un sitio normal, el browser del
móvil puede no ser capaz de renderizar correctamente un HTML de última
generación, es decir, pueden haber controles que se muestren mal, o no se
muestren, etc. Es por esta razón que es necesario dotar al extremo fijo -
esto es, HTTP server - de la capacidad de discriminar qué tipo de browser es
el que está haciendo hit contra el server. Esto lo puede hacer porque en el
encabezado HTTP del request del móvil suele venir la información del tipo de
browser que intenta abrir las páginas. Si esto es así, entonces es posible
dotar al server de la capacidad de  "filtrar" los objetos que no puedan ser
entendidos por ese browser en particular, y enviar en el documento HTML de
respuesta, sólo aquellos elementos que pueden ser renderizados sin
problemas.
Es esto justamente lo que hace IIS con ASP.NET y los denominados "Mobile
internet controls". 
En el caso de las PocketPC, el Pocket Internet Explorer envia información
diciendo "solo entiendo HTML 3.2, etc." en la cabecera del mensaje inicial
HTTP. En el codigo generado de tu proyecto en .NET es posible que cada
elemento tenga una serie de tags <choice> donde se van explorando las
distintas posibilidades (es similar a un SELECT CASE). Cuando una condicion
<choice> se cumple, entonces el codigo ASP.NET envía al documento de salida
el control especificado para que se vea bien en el mobile browser. En la
última opcion <choice> (sería cuando ninguna de las opciones anteriores eran
aceptables) generalmente se genera una etiqueta de texto en vez del control,
etc. Los tags <choice> los pone la IDE, en este caso el Visual Studio.
En el caso de las Blackberry, el navegador hace lo mismo. Con lo cual, el
generar con los "controles móviles para internet" de IIS + ASP.NET páginas
para el Blackberry reviste - mas o menos - la misma complejidad que hacerlo
para las Pocket.
 
En el segundo caso, como el sistema operativo del Blackberry no es Windows
Mobile, es prácticamente imposible hacer correr .NET Compact Framework a
bordo de aquél. Lo que si podés es correr Java, y eventualmente incluso
consumir servicios web con Java en el Backberry que sean generados por un
webservice ASP.NET. En este caso, ojo con la latencia de la red GPRS
celular. Si corrés en el microcentro porteño, tenés EDGE, que andaría en la
práctica en el orden de 100 kilobits por segundo (máx. teorico es más de 200
kilobits). En otros casos, vas por GRPS normal, y entonces esa velocidad cae
a la quinta o sexta parte solamente. El Blackberry tiene un GPRS de clase
10, lo que implica que de los cinco canales de datos que componen la norma,
usará cuatro para bajada y uno para subida, esto en teoría es algo asi como
43 kilobits, pero siempre es menos en la realidad. El secreto a voces es en
realidad la gran ventaja del Blackberry es su esquema propietario de
compresión, bastante más efectivo que el de la competencia - Microsoft
incluída, mal que nos pese. En otras palabras, es mucho más veloz para la
percepción del usuario el acceso a datos en el servidor que la contrapartida
en PocketPC + SQL mobile o web services, donde hemos medido tiempos de
rountrip de más de 20 segundos sobre GPRS normal.
 
No sé si eso lo que querías saber, pero espero que sea de ayuda.
 
Carlos
MVP Device Application Development
 

Responder a