Refactor Error Handling to Make Sense

[epicstar]

This is a task to improve Error Handling based on #233...

[epicstar]

Perhaps we will make this into smaller issues into the same milestone...

Consider the fixes:

• Completely lose the toasts....
• Dialog/Fragment to show errors we can consider persistent... (buses not showing as an example)
• Create some sort of Snackbar manager for repeated messages
• perhaps if many persistent errors show up, we say "multiple errors... press button to see the problems"
• Dialog for API died for the day (ffffuuu)
• Dialog to give the user an option to turn on data

[RitwikGupta]

Why not have a Snackbar with LENGTH_INDEFINITE showing the error till the user dismisses it manually?

[epicstar]

Material Design doesn't want people to use that, but I guess they're ok with it since they added that metric after they said not to do that on the design site.... I think it's worth a try to see which errors will take the Length_Indefinite metric, but it may be bad UX for certain messages.

[RitwikGupta]

I want to show the error message for "Bus X is not currently tracked" in LENGTH_INDEFINITE Snackbar

[epicstar]

so rereading again, they still insist not to use that for our use case. We should look at this I think... or some implementation of it: http://stackoverflow.com/a/33682586/4425374

[epicstar]

#272 has a way that times out on non-timed out requests.