New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reports of no galaxy being presented #12

Closed
chrislintott opened this Issue Dec 23, 2014 · 6 comments

Comments

Projects
None yet
2 participants
@chrislintott
Copy link

chrislintott commented Dec 23, 2014

1 user on Lollipop is reporting that the app loads and flashes, but does not display a galaxy.

@murraycu

This comment has been minimized.

Copy link
Owner

murraycu commented Dec 24, 2014

Thanks. I need a few clues, please:

When it can't download a galaxy it should at least show an error message. Does it?

Does it continue to show the "Loading..." message and circle?

Does it help to close the app and reopen it? For instance, by swiping it away in the list of running apps.

And can I have the app's version number, please? It's in the About box, which can be opened from the menu.

@murraycu

This comment has been minimized.

Copy link
Owner

murraycu commented Dec 24, 2014

This is what happens (or is meant to happen) in these cases at the moment:

  1. There's no network connection at all:
    The user sees a "No network connection" message for a short time.
    Re-opening the app, for instance by going to home and then opening the app again, will make it try again.
  2. There's only a mobile/cellular connection but the app's setting has "wifi-only" selected:
    The user sees a "No Wi-Fi network connection" message for a short time.
    Re-opening the app, for instance by going to home and then opening the app again, will make it try again. Also, changing the setting will make it try again.
  3. There's a suitable network connection but it's not working for some reason, such as a problem with the local network or a problem with the zooniverse server:
    The users sees an alert dialog saying "Cannot download new subjects to classify." with Cancel and Retry buttons. If you press Cancel then re-opening the app will make it try again.
@murraycu

This comment has been minimized.

Copy link
Owner

murraycu commented Jan 15, 2015

Any chance of that user talking to me here?

murraycu added a commit that referenced this issue Feb 6, 2015

Add log output when we abandon an item.
To give us more clues to investigate this bug:
#12
which might be caused by (Picasso) loading of images failing for every
image in the database, for some reason.
@murraycu

This comment has been minimized.

Copy link
Owner

murraycu commented Feb 6, 2015

I've seen this a couple of times after testing the app immediately after updating beta releases from the play store, though that's generally when I test it. It seems to be trying a cached subject, abandoning it, then trying the next, and not trying to download another when it has tried (and failed to load) them all. This abandoning-an-item behaviour is there to deal with cached subjects whose images have not been completely downloaded. Strangely, it seems to even lose its cached subjects that have already been classified and uploaded, suggesting a general problem with the sqlite database.

Restarting the app seems to fix the problem.

I've added some log output to the app and I've installed a log viewing app so I can investigate it more next time I see it.

murraycu added a commit that referenced this issue Feb 22, 2015

SyncAdapter: Abandon items whose images have been cleared from the ca…
…che.

* app/src/main/java/com/murrayc/galaxyzoo/app/syncadapter/SubjectAdder.java:
  Add checkForDeletedCachedImages(), which removes any items whose
  cached images have been downloaded but no longer exist.
* app/src/main/java/com/murrayc/galaxyzoo/app/provider/ItemsContentProvider.java:
  Expose the (Android) standard _data field name so we can check if the URI
  in this field really points to a file that exists.
* app/src/main/java/com/murrayc/galaxyzoo/app/syncadapter/SyncAdapter.java:
  doRegularTasks(): Call checkForDeletedCacheImages() during each sync.

  This should help with this bug:
  #12
  which is maybe being caused by an automatic clearing of the cache, for instance
  to temporarily get enough space for an app install.
  This would only avoid the initial flashing while the UI tries each item only
  to abandon each one in turn when it cannot load the images.
  If the user still has no subjects to classify, for instance if they are not on wifi,
  but have chosen wifi-only, the explanatory message should be simpler to see.

  However, this is very inefficient - most checks will succeed, and we are checking
  each file each time, just for the rare (but it happens) case that the cache has
  been cleared.

murraycu added a commit that referenced this issue Feb 22, 2015

SyncAdapter: Abandon items whose images have been cleared from the ca…
…che.

* app/src/main/java/com/murrayc/galaxyzoo/app/syncadapter/SubjectAdder.java:
  Add checkForDeletedCachedImages(), which removes any items whose
  cached images have been downloaded but no longer exist.
* app/src/main/java/com/murrayc/galaxyzoo/app/provider/ItemsContentProvider.java:
  Expose the (Android) standard _data field name so we can check if the URI
  in this field really points to a file that exists.
* app/src/main/java/com/murrayc/galaxyzoo/app/syncadapter/SyncAdapter.java:
  doRegularTasks(): Call checkForDeletedCacheImages() during each sync.

  This should help with this bug:
  #12
  which is maybe being caused by an automatic clearing of the cache, for instance
  to temporarily get enough space for an app install.
  This would only avoid the initial flashing while the UI tries each item only
  to abandon each one in turn when it cannot load the images.
  If the user still has no subjects to classify, for instance if they are not on wifi,
  but have chosen wifi-only, the explanatory message should be simpler to see.

  However, this is very inefficient - most checks will succeed, and we are checking
  each file each time, just for the rare (but it happens) case that the cache has
  been cleared.

murraycu added a commit that referenced this issue Feb 23, 2015

SubjectAdder.checkForDeletedCachedImages(): Avoid unnecessary file ch…
…ecks.

Only keep checking if the first ("next") item has had its images
deleted. It seems unlikely that only some of the cache would be deleted,
and we'll catch that later if it happens anyway.

See
#12

murraycu added a commit that referenced this issue Feb 23, 2015

SubjectAdder.checkForDeletedCachedImages(): Avoid unnecessary file ch…
…ecks.

Only keep checking if the first ("next") item has had its images
deleted. It seems unlikely that only some of the cache would be deleted,
and we'll catch that later if it happens anyway.

See
#12

murraycu added a commit that referenced this issue Feb 23, 2015

SubjectFragment.onLoadFinished(): Call destroyLoader() to avoid extra…
… calls.

As we do in our other onLoadFinished() methods, to avoid an apparent Android
bug that causes multiple extra calls. This was causing showImage() to be
called with some older out-of-date item IDs, confusing our checks, as
well as being inefficient.

This seems to avoid the problem where the user is left with just a blank
image (and the question) after the UI has had to abandon some items
due to their images being deleted from the cache. Now it doesn't stop until
it has a new image or until it has complained about a lack of a suitable network
connection.

Hopefully this completely solves this bug:
#12

murraycu added a commit that referenced this issue Feb 23, 2015

SubjectFragment.onLoadFinished(): Call destroyLoader() to avoid extra…
… calls.

As we do in our other onLoadFinished() methods, to avoid an apparent Android
bug that causes multiple extra calls. This was causing showImage() to be
called with some older out-of-date item IDs, confusing our checks, as
well as being inefficient.

This seems to avoid the problem where the user is left with just a blank
image (and the question) after the UI has had to abandon some items
due to their images being deleted from the cache. Now it doesn't stop until
it has a new image or until it has complained about a lack of a suitable network
connection.

Hopefully this completely solves this bug:
#12

murraycu added a commit that referenced this issue Feb 23, 2015

SubjectFragment.updateFromCursor(): Abandon the item if it does not e…
…xist.

This can happen sometimes, depending on the timing. Previously,
in this case, we were just silently giving up. Now the ClassifyActivity
will try to get or download a new item, and complain if it can't.

This should be the last part of this bug:
#12
@murraycu

This comment has been minimized.

Copy link
Owner

murraycu commented Feb 23, 2015

I managed to reproduce this reliably by deleting the app's cache and then going back to the app and trying to load another image - for instance, by clicking Invert or by finishing the classification.

So I think this was triggered by the Android system automatically deleting the app's cache to temporarily save space - Maybe that happens sometimes when installing app updates.

I'm confident that it's fixed now, but I will play with it a bit more here before releasing a new version.

@murraycu

This comment has been minimized.

Copy link
Owner

murraycu commented Feb 25, 2015

I've just released version 1.38 with these fixes. Please let me know if the problem still happens.

@murraycu murraycu closed this Feb 25, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment