1

The context

As a school project, I'm building a PHP and Android app for a fake company. Let's call the company "Express Food", which can talk pretty much by itself.

The "daily meals" are kept by deliverymen who wait in streets for a delivery, we say that these deliverymen are inactive. When a customer orders the meal, the nearest inactive deliveryman is requested to deliver the meal to the customer in less than 20 minutes, which is the guaranteed maximum delivery delay to the customer.

I need to build a Web app from which customers can order and administrators can administrate the site. I'm thinking to build an Android app for the deliverymen to handle deliveries.

The problematic specifications

1) The server should be able to retrieve the current deliveryman's position anytime it needs it (latitude + longitude). For example to populate the currentPosition property of the deliveryman object.

In this context, is it possible to make the PHP server retrieve the deliveryman's current position from his Android mobile? I mean it doesn't even sound natural since the server is requesting something from the client?? But how to do that the good way then?

2) When a customer orders a meal, the order's status is on 'pendingHandling', waiting for the nearest inactive deliveryman to handle it.

Could the server send a delivery handling request to the nearest inactive deliveryman or rather the mobile app should request pendingHandling orders on a defined frequence?

3) Once the deliveryman accepts to handle the delivery, his real time position has to be shown to the customer's delivery tracking web page.

What would you suggest here? How could I display the real time position of the deliveryman on the web page?

4) The workday route of the deliveryman (as active AND inactive) has to be recorded.

Is there another way to do that than to store on a high frequence deliveryman's actual positions to define from them his workday route?

The reason of my questions

Forgive me for the multiple questions. I hope also they are not too broad. I can't post these 4 questions separately since the way we resolve one depends on the way we approach the other. The questions should be approached contextually as a whole problem.

I'd need to know the global strategy to adopt defined by which direction to take, which technologies, protocols, APIs to use in this context. I don't have yet the necessary insight to approach this problem by myself only.

Thanks by advance.

3

1. Retriving deliveryman's location

You are right. Servers pulling clients is a bit unatural. But not impossible. Here some alternatives.

  • Websockets1

    The server checks periodocally the latest locations report and collects those deliveryman that didn't report for a while (let's say 5 min). Then it pushes a event by websocket asking for clients to reprot their current location.

    Clients handle the event and send the location back to the server. The report can be sent by HTTP if you prefer it. At this point, we can combine REST and WS.

    The server acknowledges the receipt, updates the reports and restart the timeout for the next check.

    Usually, this approach would take to implement a message broker too.

    The solution is ,more or less, a watchdog.

    We could force clients to report their location restarting the latest reports or forcing the event.

  • Silent push notifications

    Android supports silent push notifications. These notifications don't pop up on the screen.

    Same as WS. The server sends a push notification and clients reacts according to the notification.

Anyways, I agreed with @Dan, keep it simple. Make clients send their location periodocally. Ultimatelly, this is an exercice for learning.

2. Ready for work

The only who knows the deliveryman status (anytime) is the deliveryman himself. Put buttons in the client application for reporting the status. For example

  • Successful delivery!

    • Ready for more work
    • Delivering next order
  • Could not be delivered!

    • Ready for more work
    • Delivering next order

If he/she press Ready for more work, the server can respond with a list of pending orders, allowing him/her to pick the closer to his/her position.

3. Again the current position

If we implement #2, we can send the location alongside with the status. This will generate a milestone. I was right here when I finished the job and started the next one.

4. Routes

If we implement #1 and #2, the server is already collecting a good bunch of locations.

For more accuracy, the client could track the position frequently, store it in the local storage (let's say a file per route) but send only 1/X to the server, for saving resources like battery and data plan.

At the end of the working day, the deliveryman send the routes pressing a button or the client send them automatically when it's near (or inside) the shop. This last is what we call geofencing.

On the other hand, we know that Google already tracks our location and timings. So we could rely on Google for this feature. Maybe Google won't allow users to extract this information for legal reasons as privacy and security, but worth nothing taking a look at the documentation.

Conclusions

Think first how would be Express Food in the real life. Or how would you like it to be. Think then in the interaction between the shop and the deliverymans. The workflows. These workflows are the protocols of the business. Resolving these protocols will lead you to some of the answers you are looking for. You will realise then that there are several ways to build this. The answers to each question should be addressed to meet your vision of the business. If they don't meet your expectations, skip to the next answer. And so on.

For example, at the time of reading your question I envisioned a real time application and it made me think in events and websockets.


1: As alternative to HTTP

| improve this answer | |
  • Thanks for giving me a wider insight. BTW, I like the websocket approach and relying on Google services for the #4... What do you mean with: "You also have focused first on resolving isolated issues rather than defining the business."? The 4 specifications I have listed here is not the concerned business flow? They give a total "greenfield" project having for only "specification" what I put in "The context" part. But yep, I maybe should have been more accurate on the deliveryman "handling process", which I imagined the way you do in the #2. – user282139 Sep 2 '17 at 0:09
  • @user282139 Yes you did. Excuse me, I didn't express myself well. I wanted to say that the 4 "problems" are not totally isolated from each other. There's a relationship between them. How to tie them is what I named the protocols of the business. Like a workflow. This workflow is different among shops. You know, business strategies, models and this sort of things. – Laiv Sep 2 '17 at 8:56
  • Hi @Laiv. Let's suppose I follow your described websocket approach for the #1. For #3, I'd use websocket communication also to display real time deliveryman's position. For #4, I'd collect the data from a route recorder third part Android app and store the routes in routes table. So do you see any case I'd need to persist deliverymen positions in DB? I'd like to avoid making a positions table if possible... – user282139 Sep 3 '17 at 11:17
  • 1
    I think you got me wrong :-). I have edited the comment. I just wanted you to think that if you delegate part of the business to a 3rd party, how that affects the users experience? Do they have to apply in the 3rd system too? Do they need to install an additional application? On the other hand. Are you introducing unecessary complexity? – Laiv Sep 3 '17 at 11:25
  • 1
    Great :-). Then, looks for how to integrate the Google feature. Probably you will need a sort of OAuth authorization. This is how we usually tell Google: ey! I'm Express Food and I need access to your Google's Data. As you see, It introduces one more degree of complexity to the whole system :-). If storing locations is simpler than integrating google, go the simplest way. Always keep it simple (KISS). – Laiv Sep 3 '17 at 11:46
3

It would be a whole lot easier to program the Android to periodically call the PHP server.

That call could be "I am at (lat, lon) and can accept an order".

The server would look at the location and either return an order to be processed or a message that means 'nothing available now'.

The Android would only make the call if the delivery person is inactive / ready for work.

You'll need to balance how often the phone calls the server; wait too long and you'll miss your delivery windows. Call too often and you'll run out the battery on the phone.

For your specific questions:

  1. Yes, having the server poll the client is problematic for a lot of reasons. It doesn't scale well, it's slow, and you'll run into a lot of security restrictions that really aren't worth the effort to solve. It would be far better to have your client poll the server.

  2. See above. Have the inactive delivery person poll for work, and have your server send the order as a reply to that poll/request.

  3. When the delivery person accepts an order, have the phone make a 2nd call to the server with "I am at (lat, lon) and will start work on this order".

  4. With the scheme described above, your server can store all of the locations every time the phone makes a poll request. You could also have the phone make another call to the server every few minutes while processing an order. However, there is such a thing as "too much detail". You really don't need to know where your delivery person is more than once a minute or so, and you only need their location to within a couple hundred feet.

| improve this answer | |
  • I've updated the answer. The server app does know where the available delivery people are, and the server app makes the decision as to who should fulfill the order. The phone app initiates the connection and calls the server periodically (not the other way around) – Dan Pichelman Sep 1 '17 at 20:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.