search

alaurenz / metrobike

0 stars 1 forks source link

Backend should handle extreme inputs (from section Thu 5/16) #96

Closed dutchscout closed 11 years ago

dutchscout commented 11 years ago

This was one of the items mentioned here: https://github.com/alaurenz/metrobike/issues/91

I'm not sure what this means. In what ways is the backend not handling these inputs now?

CoolCapri commented 11 years ago

This means that when user inputs an origin and a destination that lead to a long route in between (such as from New York to University of Washington), backend can successfully return a very long result. This long result will exhaust memory when resultsActivities try to draw it on the map, which is the reason for the app to crash and the device to freeze. So how shall we deal with this problem?

CoolCapri commented 11 years ago

Now I tried from Schmitz Hall to New York, instead of returning a long result, SimpleAlgorithm now throws a NullPointerException and cause app to crash. Is this because someone is in the middle of fixing the long distance problem?

dutchscout commented 11 years ago

I can think of a couple things we can do about this:

1) Limit distance of searches - if your route is over 500 mi (or something), we just say "Your route is too long!" and display no results. Our app is meant primarily for in-city travel, so this might make sense. However, this could cause an issue if someone searches for a nearby place (like Northgate mall) and gets their query rejected because the Northgate mall found is in a different state.

2) Optimize the polyine. What Google does for longer routes is that it gives a less accurate overview polyline that can be drawn quickly. There are a couple of ways we could do this. The easiest would be: if a route has more than 20 steps, don't draw the real polyline. Instead, draw lines like we did before, from the start location to the end location of each step. There are optimizations to this, but the idea is that we should draw less on the map if the search results are very large.

As far as the crash, I don't know if anyone is working on the app now, but we need to track down the NullPointerException. Please copy/paste the stack trace here if you see it again!

CoolCapri commented 11 years ago

@csmengwan @alaurenz @coreyh3 What do you think about this?

dutchscout commented 11 years ago

I just checked the Schmitz to NewYork route. It looks like the SimpleComboAlgorithm is doing what it is supposed to do. Since we also recently fixed the messaging system, the error message is now "Found no results. Please check to be sure your addresses and travel options are correct!" instead of 'null' for the error.

We should revisit this issue once we get multiple algorithms working at the same time.

dutchscout commented 11 years ago

Let's use option 1 - anything over 500 miles gets an error message saying it's too long. I'll try to add this tonight.

dutchscout commented 11 years ago

This issue is probably related to https://github.com/alaurenz/metrobike/issues/160

dutchscout commented 11 years ago

We now reject results over 500km. However, this doesn't stop the backend from being slow to process them. If we had extra time, we could make the JSON parser aware of the distance limitation and refuse to process routes over 500km, but this would require significant modifications.

For now, I am closing this issue because long routes don't make it to the UI. Note that the message will be NO_ROUTES_FOUND. If you want to know why (like if the route was too long), it will be displayed in getVerboseErrorMessages().