marzika / Snapprefs

A project which offer enhanced features for Snapchat throught the Xposed Framework.
GNU General Public License v3.0
271 stars 83 forks source link

Save button causes crash when story not loaded #262

Closed psylenced closed 7 years ago

psylenced commented 7 years ago

If the data connection is slow, a video or image may not download instantly when attempting to view it. During this, there will be a circular loader displayed in the middle of the screen while the download is loading until the download is complete.

If the save button is pressed whilst in this state, snap chat crashes and loses all current viewed story states.

On the save button, there needs to be a check for the loaded state before processing and only allow it to proceed once an item has loaded.

To reproduce, you simply need to click save instantly before a story has completed download on a slow connection. Another way to reproduce is to have all stories downloading at the same time (to saturate connection), click multiple skips through a user who has multiple stories to reach the point where a story item hasn't loaded, then click save.

M1kep commented 7 years ago

We may be able to check for this but that's not a general use case, its pretty simple to not tap the save button.....

@marzika

psylenced commented 7 years ago

The main issue is related to the loss of viewed state which is a side effect of the crash.

To give an example, if you watch 10 users stories, each with 10-20 items each. Then accidentally click the button before it's loaded - all those items become un-viewed again. This means you need to need to go through and re-view all those stories.

Even if you can't detect the state change, perhaps a solution is just to put a try/catch around the click. This should be enough to prevent a crash and it will just not action the save. This means all the views will not be lost and a user can just re-click once the story is loaded and starts playing.

M1kep commented 7 years ago

@chris-gh Ah I see how that could definitely be an issue, do you have a log by anychance, also what version of SP and SC are you on

psylenced commented 7 years ago

Using 2.0.0 beta / 9.31.1.0.

I don't have a log but will try and capture one tonight after work.

M1kep commented 7 years ago

Awesome, that'd be great, though it may get chalked up to probably being fixed in the next version, depending on the ease of fix, due to a complete overhaul re-write of the story saving system due to changes by SC

M1kep commented 7 years ago

@chris-gh if you can get me a log in the next two hours I should be able to throw together a quick fix for ya, if not I'll try to reproduce myself tonight once I finish this visual filter crash on dev branch

psylenced commented 7 years ago

Unfortunately earliest will be about 9ish hours from now.

My work is 400/400 so it loads too quick for me to reproduce it here. My home is 20/1 and I can slow it down further by downloading in the background to saturate the connection.

M1kep commented 7 years ago

Ah ok, I'll look into reproducing tonight then

M1kep commented 7 years ago

Ya ofc I can't reproduce it now that I want to -_- so once you can get us a stacktrace aka log of the crash i should be able to fix it

M1kep commented 7 years ago

@chris-gh On latest stable build it doesn't crash, just says something about snap being recently saved

psylenced commented 7 years ago

Ok this should have it: Log_2016-10-10_20-01-23.txt

M1kep commented 7 years ago

Awesome, @chris-gh I noticed the line numbers do not appear to be lining up with the current stable build. Are you running the release build or the stable: http://138.68.21.49:8080/job/SNAPPREFS/lastSuccessfulBuild/artifact/app/build/outputs/apk/

psylenced commented 7 years ago

It was the build downloaded via xposed application, so that would be the release build I assume.

Edit - this looks like it, it's the version of the v2.0.0 tag: https://github.com/marzika/Snapprefs/blob/v2.0.0/app/src/main/java/com/marz/snapprefs/Saving.java

Edit2: Looking at the latest version it seems to check for a FlagState of Completed and also checks for null snapData, so probably is already fixed in that version, although didn't look in to how FlagState is set.