La posizione di Deliveryman (latitudine + longitudine) sulla gestione lato server PHP dall'app Android

1. Recupero della posizione del fattorino

Hai ragione. I server che tirano i clienti è un po 'poco naturale. Ma non impossibile. Ecco alcune alternative.

• WebSockets ¹

  Il server controlla periodicamente il rapporto di ubicazione più recente e raccoglie quei fattorini che non hanno segnalato per un po '(diciamo 5 min). Quindi spinge un evento da Websocket chiedendo ai clienti di riprendere la loro posizione corrente.

  I client gestiscono l'evento e inviano il percorso al server. Il report può essere inviato tramite HTTP se lo preferisci. A questo punto, possiamo combinare REST e WS.

  Il server conferma la ricezione, aggiorna i report e riavvia il timeout per il controllo successivo.

  Di solito, questo approccio dovrebbe implementare anche un broker di messaggi.

  La soluzione è, più o meno, un watchdog .

  Potremmo costringere i clienti a segnalare la loro posizione riavviando i rapporti più recenti o forzando l'evento.

• Notifiche push silenziose

  Android supporta le notifiche push silenziose. Queste notifiche non compaiono sullo schermo.

  Come il WS. Il server invia una notifica push e i client reagiscono in base alla notifica.

Comunque, sono d'accordo con @Dan, mantieni la semplicità . Fai in modo che i clienti inviino la loro posizione periodicamente. In ultima analisi, questo è un esercizio per l'apprendimento.

2. Pronto per lavoro

L'unico che conosce lo stato del fattorino (in qualsiasi momento) è il fattorino stesso. Metti i pulsanti nell'applicazione client per riportare lo stato. Ad esempio

• Consegna avvenuta!

  • Pronto per più lavoro
  • Consegna dell'ordine successivo

• Non può essere consegnato!

  • Pronto per più lavoro
  • Consegna dell'ordine successivo

Se lui / lei preme Ready for more work , il server può rispondere con un elenco di ordini in sospeso, permettendogli di scegliere il più vicino alla sua posizione.

3. Di nuovo la posizione corrente

Se implementiamo il n. 2, possiamo inviare la posizione insieme allo stato. Questo genererà una pietra miliare. Ero proprio qui quando ho finito il lavoro e ho iniziato il prossimo .

4. Percorsi

Se implementiamo # 1 e # 2, il server sta già raccogliendo un buon numero di posizioni.

Per una maggiore precisione, il client può tracciare frequentemente la posizione, archiviarla nella memoria locale (diciamo un file per percorso) ma inviare solo 1 / X al server, per risparmiare risorse come batteria e piano dati.

Alla fine della giornata lavorativa, il fattorino invia i percorsi premendo un pulsante o il cliente li invia automaticamente quando è vicino (o dentro) al negozio. Quest'ultimo è ciò che chiamiamo geofencing.

D'altra parte, sappiamo che Google traccia già la nostra posizione e i tempi. Quindi potremmo fare affidamento su Google per questa funzione. Forse Google non permetterà agli utenti di estrarre queste informazioni per motivi legali come privacy e sicurezza, ma non vale la pena dare un'occhiata alla documentazione.

Conclusioni

Pensa prima come sarebbe Express Food nella vita reale. O come vorresti che fosse. Pensa allora all'interazione tra il negozio e i fattorini. I flussi di lavoro. Questi flussi di lavoro sono i protocolli dell'azienda. La risoluzione di questi protocolli ti porterà ad alcune delle risposte che stai cercando. Capirai allora che ci sono diversi modi per costruirlo. Le risposte a ciascuna domanda dovrebbero essere indirizzate per soddisfare la tua visione del business. Se non soddisfano le tue aspettative, passa alla risposta successiva. E così via.

Ad esempio, al momento di leggere la tua domanda ho immaginato un'applicazione in tempo reale e mi ha fatto pensare negli eventi e nelle web socket.

1: In alternativa a HTTP

Sarebbe molto più semplice programmare l'Android per chiamare periodicamente il server PHP.

Quella chiamata potrebbe essere "Sono in (lat, lon) e posso accettare un ordine".

Il server controlla la posizione e restituisce un ordine da elaborare o un messaggio che indica "niente disponibile ora".

L'Android effettuerà la chiamata solo se il corriere è inattivo / pronto per il lavoro.

Devi bilanciare la frequenza con cui il telefono chiama il server; attendere troppo a lungo e ti mancheranno le finestre di consegna. Chiama troppo spesso e esaurirai la batteria del telefono.

Per le tue domande specifiche:

1. Sì, avere il server che esegue il polling del client è problematico per molte ragioni. Non è scalabile, è lento, e ti imbatterai in molte restrizioni di sicurezza che non valgono davvero la pena di risolvere. Sarebbe molto meglio che il tuo client esegua il polling del server.

2. Vedi sopra. Chiedere al personale di consegna inattivo il sondaggio per lavoro e chiedere al server di inviare l'ordine come risposta a tale sondaggio / richiesta.

3. Quando il corriere accetta un ordine, fai effettuare una seconda chiamata al server con "I am at (lat, lon) e inizierai a lavorare su questo ordine".

4. Con lo schema sopra descritto, il tuo server può memorizzare tutte le posizioni ogni volta che il telefono effettua una richiesta di polling. È anche possibile che il telefono effettui un'altra chiamata al server ogni pochi minuti durante l'elaborazione di un ordine. Tuttavia, esiste una cosa come "troppi dettagli". Non hai davvero bisogno di sapere dove si trova il tuo corriere più di una volta al minuto, e hai solo bisogno della loro posizione entro un paio di centinaia di piedi.