icoloma / appbuilder Goto Github PK

Hay que definir el modelo concreto para la exportación desde openCatalog para que las Apps lo importen de forma genérica teniendo en cuenta los menús, filtros, etc.

El API de Storage de Phonegap, que es básicamente WebSQL, tiene una serie de limitaciones:

• Espacio: no hay un comportamiento consistente, pero se habla de límites tan bajos como 5mb.
• Persistencia: en algunas versiones de iOS hay bugs que hacen que el WebSQL de [el equivalente de] un WebView se almacene en una carpeta temporal sin garantía de que persista.
• Carga inicial: no hay ningún API para inyectar los datos directamente como un fichero SQLite, sino que hay que hacerlo (como hemos hecho hasta ahora) a mano, en el código JavaScript.

Una alternativa que elimina estos tres problemas es usar algún plugin que exponga en PhoneGap un API JavaScript para manipular directamente un SQLite nativo del dispositivo. Cosas a tener en cuenta:

• El plugin tiene que estar disponible para las plataformas objetivo.
• Se ha de "ensamblar" el API que este plugin exponga con el plugin de persistencia WebSQL que estábamos usando hasta el momento. Esto implica modificar o forkear persistence.store.websql.js.
• La configuración en desarrollo vs. producción cambia por completo. Para depurar en un navegador hará falta mockear la base de datos de manera distinta.
• La generación de datos desde el catálogo debe ser en formato SQLite. Quizás sea conveniente mantener un volcado a json para desarrollo.

De momento, el plugin que parece más interesante es https://github.com/pgsqlite.

Por lo pronto, se pueden identificar varios modelos para los datos del catálogo:

1. Mongo/BSON en el propio repositorio OpenData.
2. SQLite en el "backend" de las apps, al almacenar en WebSQL.
3. Las peticiones de persistence.js devuelven un objeto propio de la librería, pero fácilmente manipulable como un POJsO, que será lo que se use en el "frontend", para templating y demás.
4. El formato en el que se exporten del catálogo al app, para que esta los cargue en WebSQL en el primer run, o al cambiar de idioma. En el código ahora se espera un JSON con un cierto formato.

Un 5º item podrían ser los Model de Backbone, pero esto ya es lo suficientemente complicado como para no añadir nada más y 3. lo hace innecesario, de momento.

Mirar si hace falta retomar los POI relacionados (DBRef) eliminados en commit b9fc839

Ej.: POI parque nacional del Teide tiene asociado dos centros de visitantes:

http://www.spain.info/es/disfruta/en_la_naturaleza/espacios-naturales/parque_nacional_del_teide.html

Si se detecta conexión de datos, el usuario de la APP deberá poder integrarse con Facebook / Google+ para consultar, valorar y/o comentar los diferentes contenidos

https://developers.facebook.com/docs/plugins/
https://developers.google.com/+/web/

Add Secuirty using API Key to the REST API

A modo de MVP, de momento se está asumiendo para las apps un sistema de categorías clásico:

• Unas ~7 categorías de nivel superior,
• cada una con su propia lista de subcategorías,
• y un único par categoría/subcategoría para cada poi.

Está por ver si es más interesante otra posibilidad.

Hay que automatizar la configuración de las apps en desarrollo y producción.

Hay que decidir si nos integramos con PhoneGap 3.0 (ahora estamos usando 2.9).

Pros:

• Trae un CLI mucho mejor pensado para proyectos cross-platform, con overrides por plataforma, etc.

Contras (o "marrones"):

• No he conseguido hacer que funcione con el plugin de SQLite (tienen que actualizarse ellos). Da un error absurdo de permisos de GitHub.
• Habría que actualizarlo o parchearlo para poder hacer un prepopulate (ref #44).
• La gestión de plugins es mejorable: se descargan cada vez que se hace el build.
• Los metadatos de la aplicación aún tienen que hacerse a mano: el CLI toma un config.xml, pero no hace nada con él...

Actualmente solo soporta una única imagen

Hay que implementar los controles de navegación y menús.
En particular, hay que usar el API nativa de PhoneGap, navigator.notification.

Ahora mismo, exceptuando la carga inicial de la BDD, apenas hace falta persistir nada, salvo el estado de favorito de un POI starred.

En el futuro puede ser necesario sobrescribir Backbone.sync.

Add web interface for CRUD POI

Hay que paginar los resultados en poisview. Esto debería mejorar el rendimiento de las transiciones.

Actualmente al acceder a /api/poi/ nos devuelve todos los Poi

Contexto:

• http://stackoverflow.com/questions/4642481/android-launch-google-map-via-web-url
• http://stackoverflow.com/questions/8055890/how-to-link-to-native-google-maps-ios-app-from-mobile-safari-browser

Por hacer:

• Testear funcionamiento en iOS (y en particular, que se añada el marker).
• Investigar si puede añadirse un marker al punto cuando se muestra en el mapa.
• Encontrar una manera de embeber un mapa con múltiples puntos.

Como se detalla en #34 (comment), el soporte para position: fixed (necesario para la barra de navegación topbarview) dista de ser perfecto.

Hay que considerar incluir un polyfill para esto.

Añadir al repositorio funciones de búsqueda geolocalizada

Con determinadas imágenes el borde sobresale por la derecha:

Para reproducir el ejemplo, cambiar en poi.html no_image.png por extremaSistemas.jpg

Crear tabla intermedia entre POI y Tags (relación n:m) para facilitar las búsquedas

La aplicación necesita una splash image, especialmente en la primera ejecución (o tras un cambio de idioma), en la que se carga la BDD.

Ref:

• appbuilder/template/js/main.js

  Line 6 in af72068

  // TODO: mostrar splash image

• appbuilder/template/js/main.js

  Line 19 in af72068

  // TODO: quitar splash image

Actualmente la búsquedas tienen en cuenta las mayúsculas/minúsculas y deberían ser ignoradas

El plugin pgsqlite solo habilita un API para acceder al SQLite nativo, no permite utilizar un .db empaquetado en la aplicación para inicializar la BDD.

De momento estamos usando una versión cocinada en casa, resultado de mezclar el plugin original con este fork.

• Testear en iOS.
• Para nota, hacer un merge en el plugin original.

Actualización: el plugin ha cambiado de sitio.

Algunos aspectos de la aplicación dependen o pueden depender de la plataforma. Un asunto a considerar es si distinguir mediante código o configuración.

• Enlace de un POI a aplicación de mapas: en código.
• CSS: está por ver si hará falta un CSS distinto para cada plataforma, por aquello de las guidelines de cada market.
• backbone-historytracker: un plugin que arregla un bug de router.navigate en Android.

jQuery Mobile es un framework enorme que abarca la infraestructura de una aplicación one-page. Se ha intentado meter sólo su módulo de eventos táctiles, pero no funciona muy bien, y no elimina el problema de los ghost clicks (eventos click que se disparan 300ms tras un evento táctil).

Añadir a los encabezados de las tablas la posibilidad de ordenarlas por columnas a través de los parámetros page.sort y page.sort.dir

Para implementar geolocalización en las apps, necesitamos una manera sencilla de hacer búsquedas en la BDD WebSQL. Si nos restringimos a España, que está bastante lejos del polo y del meridiano 180, se puede aproximar la distancia por una fórmula sencilla:

d = (dif. latitud)^2 + seno(latitud)^2*(dif. longitud)^2

El error al hacer esto es menor que el 1%, lo cual nos sobra. Para hacer las queries a la BDD, es incluso mejor pedirle un "rectángulo" en lugar de un círculo, es decir, algo así como:

find x 
  where x.lat > poi.lat - dist.lat
  where x.lat < poi.lat + dist.lat
  where x.lon * sin(x.lat) > (poi.lon - dist.lon) * sin(poi.lat)
  where x.lon * sin(x.lat) < (poi.lon + dist.lon) * sin(poi.lat)

Dependiendo de la precisión que queramos, con los resultados de esta query podría utilizarse la fórmula complicada para descartar los resultados de las esquinas del rectángulo, que estarán más lejos de lo deseado.

Para optimizar esta búsqueda, sería conveniente almacenar latitud, longitud y un campo extra de "longitud normalizada" tal que:

x.norm = x.lon * sin(x.lat)

Esto toma algo más de espacio en la BDD, pero acelera la búsqueda.

Actualmente en el POI se muestran todos los datos en RAW,
Habría que agruparlos en función del 'key' usando el ":" como separador y teniendo en cuenta los posibles subgrupos
Ej.:
"cota-maxima"
"pistas:alpino:numero-pistas-verdes"
"pistas:alpino:numero-pistas-azules"
"pistas:alpino:numero-pistas-rojas"
"pistas:otros:km-esqui-fondo"
"pistas:otros:numero-pistas:fondo"
"pistas:otros:numero-pistas:trineos"

COMÚN (Sección nivel 1)
   cota-maxima
PISTAS (Sección nivel 1)
     ALPINO (Sección nivel 2)
         "pistas:alpino:numero-pistas-verdes"
         "pistas:alpino:numero-pistas-azules"
         "pistas:alpino:numero-pistas-rojas" 
     OTROS (Sección nivel 2)
          "pistas:otros:km-esqui-fondo"
          NUMERO-PISTAS (Sección nivel 3)
             "pistas:otros:numero-pistas:fondo"
             "pistas:otros:numero-pistas:trineos"

Las peticiones con persistence.js no están teniendo en cuenta posibles errores de "backend". Esto hay que mirarlo.

API Key must be associated with an email and optionally with a list of zones

Actualmente y para MVP los POI contienen información mínima, habrá que tener en cuenta que determinados POI tienen información específica.

Ej.:

• Longitud / Anchura de una playa
• Tipo de construcción : Castillo
• Origen : siglo XIII
• Periodo artístico : Gótico
• Periodo histórico: Siglo XIII

persistence.js tiene un plugin, pero es bastante pobre y no está pensado para i18n. (desfasado por 1594dbe)

Los componentes de la dirección se solapan antes de pasar cada uno a una línea

Eso ocurre tanto en poi.html como en zone.html

export.html

• De momento hay que arrancar la aplicación para que funcione el autocomplete, por tanto se puede aprovechar y cambiar el código para que también funcione en local

(Corriendo nativa en Android)

Después de marcar o desmarcar como favorito un POI, el swiper de fotos no funciona.

Parece que el diálogo no se lleva bien con el position: absolute o las transformaciones 3D.

Está por ver si es un gran número de imágenes o assets en general puede afectar al rendimiento de la app al acceder al sistema de archivos.

Una posible solución es parecido a lo que hace git: la carpeta assets se subdivide en <256 carpetas. Para colocar cada fichero, se calcula su hash SHA-1 y se copia en assets/{Byte más significativo del hash}/.

A pesar de que se puede acceder a través del API PoiAPITest.tesFindByLocationWithIn() no aparecen en los links HATEOAS.

Mirar como exportar este finder a /poi/search, actualmente no aparece

PoiRepositoryImpl.java

        @RestResource(path = "within", rel="within")
        public List<Poi> findWithIn(@Param("lat") double lat, @Param("lng") double lng, @Param("radius") double radius) {

> GET http://localhost:8080/opencatalog/api/poi/search/

< 200 OK
< Server: Apache-Coyote/1.1
< Content-Type: application/json
< Transfer-Encoding: chunked
< Date: Thu, 23 May 2013 10:12:10 GMT
< 
{
  "links" : [ {
    "rel" : "pois.byName_en",
    "href" : "http://localhost:8080/opencatalog/api/poi/search/byName_en"
  }, {
    "rel" : "pois.byName_de",
    "href" : "http://localhost:8080/opencatalog/api/poi/search/byName_de"
  }, {
    "rel" : "pois.byName_it",
    "href" : "http://localhost:8080/opencatalog/api/poi/search/byName_it"
  }, {
    "rel" : "pois.locationNear",
    "href" : "http://localhost:8080/opencatalog/api/poi/search/locationNear"
  }, {
    "rel" : "pois.byName_es",
    "href" : "http://localhost:8080/opencatalog/api/poi/search/byName_es"
  }, {
    "rel" : "pois.byName_fr",
    "href" : "http://localhost:8080/opencatalog/api/poi/search/byName_fr"
  } ],
  "content" : [ ]
}

Añadir autocomplete en el campo de búsqueda
PoiList.html
ZoneList.html

Cuando la zona es grande, por ejemplo una comunidad autónoma entera aparecen demasiados Markers en el mapa (zonePoi.html).
Añadir un marker cluster como en el siguiente ejemplo http://gmaps-samples-v3.googlecode.com/svn/trunk/toomanymarkers/toomanymarkers.html

Add Security to Web UI

Hace falta definir las páginas 404 y 500

Define a Zone as a city and/or a polygon of points

Para la creación de tags se utiliza la librería jquery.tagedit.js.

Los estilos utilizados por defecto por esta librería están en jquery.tagedit.css y este CSS no casa con el look&feel seguido por la aplicación.

Como workaround he comentado la línea 21 del fichero jquery.tagedit.css y he añadido los estilos a main.css para .tagedit-list. Lo ideal sería dejar intacto el jquery.tagedit.css y hacer todos los cambios en main.css.

Habría que ver cómo hacer que el ancho de la caja se adapte al máximo posible. El problema es que si ponemos .tagedit-list { widht:100% } sobrepasa el ancho del div contenedor (#tags)

El fichero a mostrar para las pruebas:
/appbuilder/openCatalog/src/main/webapp/WEB-INF/thymeleaf/admin/poi/poi.html

Los ficheros a modificar:
main.css
jquery.tagedit.css

Actualmente se está exportando las fechas created y updated como una representación Joda:

"createdDate": {
                "weekOfWeekyear": 25,
                "weekyear": 2013,
                "monthOfYear": 6,
                "yearOfEra": 2013,
                "yearOfCentury": 13,
                "centuryOfEra": 20,
                "millisOfSecond": 800,
                "millisOfDay": 58298800,
                "secondOfMinute": 38,
                "secondOfDay": 58298,
                "minuteOfHour": 11,
                "minuteOfDay": 971,
                "hourOfDay": 16,
                "year": 2013,
                "dayOfMonth": 17,
                "dayOfWeek": 1,
                "era": 1,
                "dayOfYear": 168,
                "chronology": {
                    "zone": {
                        "uncachedZone": {
                            "cachable": true,
                            "fixed": false,
                            "id": "Europe/Madrid"
                        },
                        "fixed": false,
                        "id": "Europe/Madrid"
                    }
                },
                "millis": 1371478298800,
                "zone": {
                    "uncachedZone": {
                        "cachable": true,
                        "fixed": false,
                        "id": "Europe/Madrid"
                    },
                    "fixed": false,
                    "id": "Europe/Madrid"
                },
                "afterNow": false,
                "equalNow": false,
                "beforeNow": true
            },

ApiRestTest.postPoi()

Caused by: com.fasterxml.jackson.databind.JsonMappingException: Can not deserialize instance of java.lang.String out of FIELD_NAME token
 at [Source: org.springframework.mock.web.DelegatingServletInputStream@1a3b1e79; line: 1, column: 17]
    at com.fasterxml.jackson.databind.JsonMappingException.from(JsonMappingException.java:164)
    at com.fasterxml.jackson.databind.DeserializationContext.mappingException(DeserializationContext.java:599)
    at com.fasterxml.jackson.databind.deser.std.StringDeserializer.deserialize(StringDeserializer.java:41)
    at com.fasterxml.jackson.databind.deser.std.StringDeserializer.deserialize(StringDeserializer.java:11)
    at com.fasterxml.jackson.databind.ObjectMapper._readValue(ObjectMapper.java:2769)
    at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:1478)
    at com.fasterxml.jackson.core.JsonParser.readValueAs(JsonParser.java:1285)
    at org.springframework.data.rest.repository.json.PersistentEntityJackson2Module$ResourceDeserializer.deserialize(PersistentEntityJackson2Module.java:234)
    at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:2797)
    at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2003)
    at org.springframework.http.converter.json.MappingJackson2HttpMessageConverter.readJavaType(MappingJackson2HttpMessageConverter.java:168)

~

Modelar las rutas

Una posibilidad:

• nombre (i18n)
• descripción (i18n)
• ubicación // área administrativa
• categoría // histórica | monumental | gastronómica | ...
• poi[]
• info extra // web, ...

Ej,:

http://www.spain.info/es/conoce/grandes-rutas/caminodesantiago/camino-norte/
http://www.spain.info/es/conoce/grandes-rutas/rutas_culturales/ruta_real_navarra.html

position: fixed no funciona demasiado bien en móviles, y directamente no está soportado en versiones antiguas.