Handle no internet connection better about the-blue-alliance-android HOT 17 CLOSED

How's this for a start? Should I go ahead and make the rest of the fragments work this way?

from the-blue-alliance-android.

Yeah, that looks like a solid start. I don't know if I should break this into a new issue or not, but here's something I've been considering: do we want to make a subclass of Activity that we use as the base for most (or all) of our activities? It seems like a lot of functionality, mainly showing these warning and the navigation drawer, will have to be duplicated in a lot of places.

If we had this "super" Activity, we could avoid a lot of redundant boilerplate code. That hinted at my next point, which is that I think these warnings should be displayed at the activity level. a) we avoid a lot of boilerplate, and b) they would remain still when scrolling between tabs. When launching the activity, we could check the internet connection and display this if there is none. If we want to get really fancy, we could register to receive updates on network status and hide the warning and trigger a refresh of all fragments (once all of them incorporate the refresh framework).

I think I answered my own question: we need a new issue :P

from the-blue-alliance-android.

I do like having a "super activity" - it will make a lot of things simpler.

Just to keep in mind, the way I have this written now, the Populate task will return an API Response object. That means that displaying these warnings should happen at an individual task level (and they should - because the states could change between loading of different fragments and such), not the activity level. Just something to keep in mind...

from the-blue-alliance-android.

I don't see why we couldn't put it at the activity level. If we properly
orchestrate refreshing, we're guaranteed to get up-to-date data when we
regain internet connectivity. We could provide a fallback that would notify
the activity to show the warning if data wasn't loaded successfully,
however.

It would also be a poor UX to potentially have some fragments saying you're
offline and some saying you're not. If we do this at the activity level, we
won't have that problem.

On Sun, May 11, 2014 at 8:37 PM, Phil Lopreiato [email protected]:

I do like having a "super activity" - it will make a lot of things simpler.

Just to keep in mind, the way I have this written now, the Populate task
will return an API Responsehttps://github.com/plnyyanks/the-blue-alliance-android/blob/handle-no-connection/android/src/main/java/com/thebluealliance/androidclient/datatypes/APIResponse.javaobject. That means that displaying these warnings should happen at an
individual task level (and they should - because the states could change
between loading of different fragments and such), not the activity level.
Just something to keep in mind...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/51#issuecomment-42790078
.

from the-blue-alliance-android.

Could we add "12_alerts_and_states_error" or "12_alerts_and_states_warning" to that fragment that you posted above @plnyyanks?

from the-blue-alliance-android.

But what if the user is offline and one fragment has data loaded and the
other doesn't. Then, only one of the two fragments would have to show a
warning

On Sun, May 11, 2014 at 9:42 PM, Nathan Walters [email protected]:

I don't see why we couldn't put it at the activity level. If we properly
orchestrate refreshing, we're guaranteed to get up-to-date data when we
regain internet connectivity. We could provide a fallback that would
notify
the activity to show the warning if data wasn't loaded successfully,
however.

It would also be a poor UX to potentially have some fragments saying
you're
offline and some saying you're not. If we do this at the activity level,
we
won't have that problem.

On Sun, May 11, 2014 at 8:37 PM, Phil Lopreiato [email protected]:

I do like having a "super activity" - it will make a lot of things
simpler.

Just to keep in mind, the way I have this written now, the Populate task
will return an API Response<
https://github.com/plnyyanks/the-blue-alliance-android/blob/handle-no-connection/android/src/main/java/com/thebluealliance/androidclient/datatypes/APIResponse.java>object.
That means that displaying these warnings should happen at an
individual task level (and they should - because the states could change
between loading of different fragments and such), not the activity
level.
Just something to keep in mind...

—
Reply to this email directly or view it on GitHub<
https://github.com/the-blue-alliance/the-blue-alliance-android/issues/51#issuecomment-42790078>

.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/51#issuecomment-42790266
.

from the-blue-alliance-android.

Could we put one these instead of the text "Warning"?

from the-blue-alliance-android.

Yeah, ic_action_warning would be a better bet here

from the-blue-alliance-android.

Do you want me to make blue versions?

from the-blue-alliance-android.

Sure

from the-blue-alliance-android.

Here is the link. Has all the assets, Dark, Blue, and Light for ic_action_warning. https://drive.google.com/file/d/0B560TT78WfD-OU0xeFhJUnRRT3c/edit?usp=sharing

from the-blue-alliance-android.

Thanks

from the-blue-alliance-android.

Take a screenshot of how it looks with the icon.

from the-blue-alliance-android.

I like the images, visual things are better. @plnyyanks, regarding that case, we can still show the global offline notification, but then display a special "no data" view in the fragment, or something like that.

And really, we should be doing that anyway. Keeping "no cached data" and "offline" indicators separate and in distinct parts of the screen would require the least amount of effort from the user's perspective to differentiate between the two potential statuses.

If you really want to handle it on a per-fragment basis, be my guest. I'm just trying to reuse as much code as possible.

from the-blue-alliance-android.

Code reuse is definitely better - I think I know how to do it per-Activity, and it does seem better. It'll involve having a base activity like above that can set a message bar, and in onPostExecute, the populating AsynTasks will set it to whatever it needs to be. I'll spend some time tomorrow writing that up.

@Adam8234

from the-blue-alliance-android.

That looks good.

from the-blue-alliance-android.

Sounds good, and looks good.

On Sun, May 11, 2014 at 9:31 PM, Adam Corpstein [email protected]:

That looks good.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/51#issuecomment-42791874
.

from the-blue-alliance-android.