No route lines when connectivity returns

[sgdoerfler]

Go to airplane mode, then start the app. You get a map, but no RT info of course. Now leave airplane mode. The bus icons appear on the map after a few seconds, but the route lines do not, even waiting several minutes. Rotating the device to change its orientation makes them come back. 2.95B.

I also saw the missing-route-lines issue once after the device had powered down due to inactivity, but haven't been able to reproduce that case.

[RitwikGupta]

Weird. We'll look into that, thanks. Having a lot of problems with losing connectivity at any point in the life cycle.

[epicstar]

This currently what I expect to happen btw.... This has to be done this way otherwise the asynctask gets stuck forever in limbo which will freeze the app otherwise. Any connection timeout has to either be recycled or reloaded and that could possibly break the app (like it already did before I did this)

[epicstar]

I think the only solution is to have a reload button honestly. The reason why the missing route lines issue happened is most likely because the device wasn't receiving internet.

[epicstar]

If there are suggestions we can do within the asynctask, it'd be nice

[epicstar]

Pretty much, it'd be in this line of code where we get the polylines:
https://github.com/rectangle-dbmi/Realtime-Port-Authority/blob/beta/Android/Pittsburgh_Realtime_Tracker/app/src/main/java/rectangledbmi/com/pittsburghrealtimetracker/handlers/RequestLine.java#L103

[sgdoerfler]

It looks like you can detect when the connectivity state changes.
http://developer.android.com/training/monitoring-device-state/connectivity-monitoring.html#MonitorChanges
So maybe whenever you get a CONNECTIVITY_ACTION, check to see if the async task has exited with an IOException instead of returning the data. It so, restart the async task. (Or maybe something vaguely like
if (stillNeedData() && !asyncTaskRunning()) restartAsyncTask().)

Or maybe have the IOException code in that async task request getting a CONNECTIVITY_ACTION, then respond to it by restarting the async task. Or perhaps the caller of the async task notices it got no data back, and handles restarting it when a CONNECTIVITY_ACTION comes in.

[epicstar]

Route calls should be reduced using #149.... Please report issues if there are problems in 3.2 (beta)

[sgdoerfler]

As expected, in 3.2 it's now harder to make this bug show up. New steps are:

1. Switch to Airplane mode (or otherwise lose connectivity).
2. Clear Transit, then select some routes.
3. Restore connectivity.

The bus icons then appear, but the route lines and stops do not. Switching to the home screen and back to the app makes them appear.

[epicstar]

I can only fix this atm by pressing "Clear Transit" and then selecting the route lines when internet activity is restored. I will make a new method to close the whole app when there's no internet but for now, I'll leave it as is...

[sgdoerfler]

I'm not sure forcing the app to exit would be better than the current behavior, where I can always manually exit and restart the app. It's happened that the app gets some info I care about, and then while it's trying to retrieve some other info (say, list of stops for a route that might even be off the map now), I move out of range of the Wifi signal and get the message at the bottom that there's a problem. Right now, I can use the data it managed to retrieve successfully. Forcing the app to quit at that point would lose whatever data it's already retrieved.

I suggest just leaving it alone, unless you can find a way to have the routes update once the network comes back up. (But it might be OK if "network is now back up" caused the app to reload itself.)

[epicstar]

It'd be very possible to do that, but I would have to re-make the whole "retrieve route lines" task to use volley. It'll be an interesting task..........

[epicstar]

Don't think the fix will be a fix in this sense...

[epicstar]

Going to reopen this issue. I got this working with bus updates, so I'm going to do the same mechanism for the route lines.

[epicstar]

This is a direct cousin of #267 and requires #196

@sgdoerfler, this will be fixed in release 8.0.0

[epicstar]

I'm actually going to close this issue now. We can actually improve the app via #301. It won't make it to the 8.0.0 release but the current behavior without fixing this issue is already what we have right now.

[epicstar]

@sgdoerfler, this issue is going to be fixed in #316. Pretty much, all routes are downloaded from the TrueTime API at build time and then saved to the assets folder of the app. I know I had a concern about doing this from the TrueTime license, but it should be ok regardless.

[epicstar]

Released with 8.0.0b3. Thanks @sgdoerfler for bringing up this issue.