[Soci SLIP] App gestione frigo/dispensa

[lucio a sulweb.org]

Il 2015-08-07 22:51 Luca De Villa Palù ha scritto:
>> Il giorno 7 agosto 2015 19:28, <lucio a sulweb.org> ha scritto:
>> 
>> Io mi metto nel gruppo. Dico subito che se ci mettiamo a farla
>> dobbiamo prevedere un Mbaas per salvare lo stato del frigo (tipo
>> Parse.com), perché le mani nel frigo ce le mette tutta la famiglia
>> e non è pensabile che chiunque, prima di prendere uno yogurt, debba
>> chiedere in prestito il cellulare a chi lo yogurt ce lo ha messo
>> dentro (è già tanto se usa il proprio per tracciare il fatto che
>> ha tolto lo yogurt dal frigo). Così come il frigorifero è
>> condiviso da tutta la famiglia, lo è anche il suo stato, ovvero
>> l'elenco delle cose che contiene con rispettive scadenze.
>> 
>> La app non può quindi salvare lo stato del frigo sul cellulare, ma
>> deve salvarlo su un server.
> 
>> Il giorno 7 agosto 2015 19:36, Alessandro Pasotti
>> <apasotti a gmail.com> ha scritto:
>> 
>> Ma una app web non andrebbe bene?
> 
>> Con django si fa in una serata.
> 
> Per prima cosa: grazie mille per la vostra partecipazione e le vostre
> osservazioni/idee!
> 
> Capisco che il "database dei freschi condivisi" vada tenuto su un
> server sempre a disposizione di tutti gli affamati che frequentano il
> frigo, ma immagino che questo richieda di avere sempre un dispositivo
> locale acceso o in alternativa un hosting internet sul quale eseguire
> il proprio programma server. O ci sono alternative che ignoro?

Parse.com risolve questo problema. È fatto apposta per fare da backend 
alle app. MBAAS significa "Mobile Backend As A Service". È gratis, 
almeno fino a quando la app non diventa famosa ed usata da qualche 
decina di migliaia di persone (ma a quel punto molte altre cose non sono 
gratis). Non è libero. Ha il vantaggio di essere fatto apposta per le 
app per cellulari, quindi offre tutti i servizi necessari a gestire le 
funzioni presenti sui cellulari (notifiche push, sincronizzazione dati, 
geolocalizzazione, restful webservices in json, ...). Esistono anche 
MBAAS liberi, ma ce li si deve installare su un proprio server e 
gestirseli, quindi in quel caso ci sono i costi di hosting anche per una 
app usata solo da una persona.

> 
> In questo momento mi pare che i componenti dell'applicazione siano:
> 
> 	* server che tiene traccia di quante cose ci sono e quando scadono
> (db)

Parse.com o altro MBAAS libero risolve questo problema. Dimenticatevi di 
usare un normale Mysql o altro db classico, non bastano.

> 	* client che aggiungono/tolgono cose dal db e ricevono notifiche se
> qualcosa scade

Direi più dei webservices che offrono accesso al db. Nella app client 
non farei nulla se non l'interfaccia utente e le chiamate json al 
server.

> 
> 	* funzioni di elaborazione di immagine che interpretano i codici a
> barre e riconoscono la data di scadenza senza dover digitare tutto a
> mano

Per questo esistono librerie specifiche, fra cui quelle che hai già 
citato tu nel primo messaggio.

> 
> Con queste tre cose il sistema dovrebbe essere già abbastanza
> usabile.
> 
> In una versione "0.1" mi accontenterei già di riuscire a masticare i
> codici a barre e le date di scadenza tenendo un db locale mono-utente.

Io no. Se parti così, la versione 0.2 dovrà essere una riscrittura da 
zero.

> Nei prossimi giorni vado a vedere cosa si trova in giro come librerie
> di elaborazione di immagine nel mondo di Android.

È l'ultimo dei problemi, fidati. Prima è necessario identificare la 
struttura della app e decidere gli strumenti di sviluppo più 
macroscopici. Se scegli prima la libreria per l'ocr o per i barcode, poi 
ti trovi a dover scegliere tutto il resto in base a dove quella libreria 
può essere usata e ti scontri con limitazioni inaccettabili. Meglio 
prima porre le fondamenta e poi, se proprio non si trova una libreria 
OCR per la propria struttura, se ne prende una per un'altra struttura e 
la si adatta. È un lavoro più semplice e meno rischioso (ed anche meno 
probabile, è più facile che se ne trovi una già fatta o adattata).