Restaurante puede estar cerrado

[luisotero]

Hasta ahora, las llamadas a PUT y POST (/order) retornan el objecto de la orden completo. Gianko, un feature que nos han pedido, es que el restaurante pueda "cerrar" en el sentido que rechace todos los pedidos.

Esta funcionalidad funciona bien en el servidor -- el problema es, que la applicacion "piensa" que la llamada fue exitosa, y por eso muestra el mensaje Plate Ordered! o Your order has been confirmed.

Hay alguna manera en que puedas detectar si la llamada a PUT o POST fue exitosa?

[luisotero]

Con esta funcionalidad, el restaurante tiene un flag que se llama is_open. Dejame saber si mandar ese flag es una buena opcion.

[gianko]

mmm... si es buena idea.

si is_open is false, no muestro el boton de ordenar. y así la gente puede ver el menu si quiere

Aunque si no está abierto no debería aparecer en la lista de restaurantes cercanos

[luisotero]

Un resumen:

1. Cuando llamas a /venue_list cada restaurante tendra una bandera is_open. Si es False, entonces no se mostraran los botones de ordenar (buena idea, Gianko).
2. Si is_open es False el restaurante seguira siendo mostrado en la aplicacion.
3. Importante: despues de que el restaurante "cierre", todas las llamadas a POST para confirmar y mandar ordenes a la cocina van a fallar. Tenemos que tomar en cuenta este escenario. Si eso pasa habria que abrir un pop-up que lo mencione al usuario.

Cuando ocurra (3) deberiamos remover todos los platos que no fueron confirmados? que opinan? @manuelgodoy

[gianko]

Ahora tengo un pop up con un mensaje hardcoded

title: 'Confirmed',
subTitle: 'Your order has been sent to the kitchen'

Podrias en la respuesta enviarme esos datos y que se muestre segun el caso.

o un error y si es true muestro otro popup

[luisotero]

OK. Tienes razon, me gustaria que el subtitle lo pudiese escribir el servidor. De tu lado puedes asumir que solo habra dos casos: confirmed y error.

Ahora, hoy en dia ese API retorna la orden completa. Como hacemos para empatar las dos? Todavia necesitas que te mande la orden en los dos casos de confirmed y error?

[gianko]

Si, creo que si... porque así se actualiza el estado de la app.

yo guardo un Order con la cantidad de platos y si está paid, etc..

Como sería la orden del error? creo que lo que necesito es que en el error el is_paid sea true

[luisotero]

A que te refieres con is_paid? Este APi es el de /order, no? Cuando los platos se estan pidiendo.

Ok, si necesitas la orden siempre, pudieramos devolver algo asi:

response = {
                     'status':  { 'title':   ....  ,  'subtitle': ....  }
                     'order' :  {   .....   }
}

Que opinas? Aunque en el caso de error me parece redundante mandar la orden (ya que es la misma y no cambio). Eso podriamos hacerlo mas eficiente.

En otras palabras, de tu lado podrias hacer:

if response.status.title == `confirmed`:
   update_app (response.order)
else if response.status.title == `error`:
   no_need_to_update_app(use_old_order)

Te sirve?

[gianko]

Lo que pasa es que el objeto order que tiene la app se va a quedar con unos platos porque ese es el ultimo estado que tuvo antes de Confirmar.

No vas a poder pedir de otro restaurant y en el header (al lado del carrito) te van a aparecer la cantidad de items de la orden sin confirmar.

Tengo un if (order.data.is_paid) que si es true hace que los items del header se pongan en cero. Podría usar algun otro, cual se les ocurre?

[luisotero]

Entiendo que la orden se va a quedar "trancada" con los platos que no fueron confirmados.

No me gustaria vaciarle el carrito al usuario sin su autorizacion. Si el /order/POST falla habria alguna manera de preguntarle para que se quiten los platos? Capaz tu puedas llamar remove cuando el usuario lo autorice.

Algo como que "This restaurant has closed, would you like to discard the unconfirmed plates?". O si quieres que lo haga el usuario, dejar el boton de remove y decir "This restaurant has closed, you should remove your unconfirmed plates".

[gianko]

Mmm...

Y que pasa si ya tienes platos ordenados y agregaste unos nuevos?

Hay alguna forma de enviar el is_open en el order? On Jan 25, 2016 3:36 AM, "luisotero" notifications@github.com wrote:

Entiendo que la orden se va a quedar "trancada" con los platos que no fueron confirmados.

No me gustaria vaciarle el carrito al usuario sin su autorizacion. Si el /order/POST falla habria alguna manera de preguntarle para que se quiten los platos? Capaz tu puedas llamar remove cuando el usuario lo autorice.

Algo como que "This restaurant has closed, would you like to discard the unconfirmed plates?". O si quieres que lo haga el usuario, dejar el boton de remove y decir "This restaurant has closed, you should remove your unconfirmed plates".

— Reply to this email directly or view it on GitHub https://github.com/manuelgodoy/Bitely_Mobile/issues/63#issuecomment-174432286 .

[luisotero]

Si, el is_open puedo mandarlo en el order.restaurant. Aunque solo chequeo la base de datos durante el primer PUT y durante cada POST.

[luisotero]

Es decir, hay tres (3) sitios donde se puede chequear is_open.

1. En /venue_list.
2. En el primer /order PUT -- es decir, cuando alguien esta empezando una orden.
3. En /order POST -- cuando se estan mandando platos a la cocina.

Casos (1) y (2) estan faciles. El problema es cuando falla en (3). Habria que darle la opcion al usuario para que no se quede "atascado" con esos platos que no fueron a la cocina.

Yo diria que lo mejor es dejarle la orden al usuario, darle un warning de que el confirm fallo, y darle la opcion de quitar esos platos que no fueron confirmados.

[luisotero]

Quizas en la misma pagina de confirm podriamos dejar los botones de "-" (remove) para que el usuario los quite todos.

Por cierto, que ese formato de {status: "...", order: "..."} tambien serviria para las llamadas de /order PUT que fallan por otras razones (por ejemplo, que esta pidiendo de un restaurante distinto, o que la tarjeta de credito ha vencido).

[gianko]

Ok... actualizas el API y me avisas como van a ser los JSON

[gianko]

@luisotero acuerdate del is_open dentro del restaurant en el /item

[luisotero]

Ok, te aviso.

[luisotero]

@gianko En vez de cambiar el API completo, decidimos hacer unas pruebas previas. Cree un nuevo enpoint que se llama /bitely/api/v3.0/order_tmp. Funciona igual a order para todos los llamados a GET, POST, y PUT. La diferencia entre los dos es la respuesta.

Esto es lo que retorna /order_tmp:

{
    'header':    {    'status':   "<status_text>",
                      'message':  "<message_text>",
    },
    'object':    {    'order':  { ..... }
    }
}

Lo importante es que response['header']['status'] puede tener solo dos valores, "success" o "error" dependiendo de si la llamada fallo o no.

En cuanto a response['object']['order'], siempre esta presente en la respuesta -- igual que hemos hecho con order hasta ahora. Esto es mientras tanto; en el futuro quisiera mandar object vacio si el status es de error.

No he podido probarlo y es posible que haya errores. Avisame cuando puedas montar un .apk y yo me encargo de testearlo.