The Spinning Wheel of Death & Solution:
03-28-2012: Web View / URL Spinner BT_screen_customHTML.java and BT_screen_webView.java would not hide the progress / loading indicator in some cases when the HTML document was done loading. Fixed
If your Source Code was downloaded prior to this date (or your self-hosted server hadn’t been updated) you will still need to implement the solution.
(NOTE: Users are reporting that the Wheel of Death is still a problem with newly created apps. If so, you’ll need to use solution.)
First the Solution, then the testimonial, then the credit.
Solution for BTv1.5:
Comment out line 137 in BT_screen_webView.java
(in the / src folder) so the showProgress() method doesn’t trigger.
Solution for BTv2.0:
Comment out line XXX (see below) in Source Code > src > com.(your package name) >
- BT_screen_customHTML.java (line 132)
- BT_screen_customURL.java (line 133)
Next Step for BTv1.5. & BTv2.0:
- Recompile and export a new .apk.
The END (That’s all it takes to fix the problem.)
How to comment out: simply add // in the front of the line.
- original line: showProgress(null, null);
- commented out line: //showProgress(null, null);
Testimonial: Does this work, well here’s the response from the first person I sent the solution to that tried it, “Yup! It was the most fabulous thing to not see that spinner appear! I think I can really get the hang of this!”
Explanation & Credit: My post in response to an inquiry about the Spinning Wheel of Death, “Ahhh! The Spinning Wheel Of Death, precisely the reason I’m all over BTv2.1.6. Lots of screens (Ok, just a few) in BTv1.5 have this problem that I’ve not encountered in BTv2.1.6. I try various ways of linking to urls in BTv1.5, I’ve not figured out the best method. Try Custom HTML, Custom URL, . . .” Here’s David @buzztouch solution:
“Spinning Wheel of Death. Major bummer that Android isn’t calling the page finished loading method all the time. Sigh. The loading indicator shows when the activity begins then hides when the page is done loading. If Android doesn’t report this, the loading graphic never goes aways. If you can’t get to stop, it’s probably best to just not show the loading graphic at all. To turn it off, search your BT_screens_webView.java file for all occurrences of ‘showProgress()’ and comment them out like / /showProgress();”
Looking for another solution? additional discussion
Another Post by David: “OK, I got this to work on a simulator and a device. A few things… a) You are not pointing to an HTML page, you are pointing to a redirect script that eventually lands you at the .html page. This is generally OK but the built-in Android browser does do some funky thing sometimes when it’s redirected. Seems fine in this case. b) The ‘loading’ indicator on the screen never went away when I first tested it. I created a Custom URLscreen and compiled / ran in the device and the video showed in the background but the loading indicator never disappeared. If this doesn’t disappear nothing will work. The UI is locked up when this is showing so it needs to understand when to go away. c) I commented out line 137 in BT_screen_webView.java (in the / src folder) so the showProgress() method didn’t trigger.
Line 137 looks like this in my project: //showProgress(null, null);
If you do the same it should work. The idea is that the WebView fires a ‘did finishloading’ message when it’s done and that’s when the loading graphic goes away. For whatever reason, this ‘did finish loading’ message isn’t happening so the graphic never goes away, causing the issue. I’ll bet it’s related to the way the iFrame is loading the content. Lots of stuff loading for sure. Uncomment that line, see if it works -does here 😉
After you’ve commented out a line in the java code, you need to recompile and submit a new binary to the market. The only changes that are automatically pushed out to users are those made in the control panel, which get reflected in BT_Config.txt. Everything else is code related, and needs to be recompiled, tested, and resubmitted.”
Original Posts:
January 17th, 2012. Many thanks to David @ Buzztouch for the Solution.
MaximusXXII, Posted: Sun, Mar. 04 2012,:
Yes, the exact same issue was happening with BT2.0 which I have running on my server. Editing the BT_screen_customURL fixed it though.
On 03/11/12 Bigfishtools posted:
Under customhtml try line 131
Javooooo replied: Thanks so much for your help BigFish, worked a treat.
Just a word about this problem and solution. You’ll noticed I (Fred) didn’t solve anything. All I’ve done is made to solution available and have documented the contributions of all involved. I did give it its name, ‘The Spinning Wheel of Death’. Your contributions on the Forum make this possible. Thanks to one and all. / Fred
***** Update:
The updated plugin resolved the Wheel of Death problem but you may wish to show the progress spinnen.
You can easily modify this.
Open your BT_screen_customURL.java file. This is in the plugin folder. Scroll down to line 108 or so and add this:
showProgress(null, null);
This is just after the
baseView.addView(thisScreensView)
All this does is show the progress wheel in the onCreate method, as soon as the screen loads it will show. It SHOULD go away after the URL finishes loading.
We removed this line from the downloadable plugin because it was causing issues for lots of folks (commonly referred to as the Wheel of Death problem). The trouble is related to the content loading, the content loading depends on the URL. Add that line, if it works well with the URL you’re loading, great. If not (the wheel may never go away!) remove the line 🙂
Dec 3rd, 2012 Forum post regarding the issue:
“Spinning wheel of death – too funny. It would be super-duper easy to remove the showProgress from the plugin, permanently, on our end. BUT, I’ve made tons and tons of Android apps without ever running into this problem. Ever. I’m convinced that it has to do with the combination of the device + the URL that’s loading. In almost all cases, the apps I create load URL’s that I also create. In other words, I don’t load content from other sites in to Android apps.
It’s important to understand what’s happening here. The showProgress graphic shows when the WebView first starts to load. Then, when it’s “done” it hides. It’s the “done” thing that doesn’t necessarily happen when you may think. And, it’s different on different devices. The “done loading” event on the built in Android WebView is widely regarded as a giant pain in the butt. LOL
So, why does it matter where the content comes from? I can only speculate about this, but, it’s my opinion that most folks don’t realize entirely what a browser does when you load a URL. I say this because people (app owners) don’t necessisarily understand that a heavy web-page with tons of resources will make lots and lots of HTTP requests to grab all kinds of resources. Every image, script, .css style sheet, etc, etc, while it gathers all the assets for the HTML content. Each and every time it begins one of these requests, it triggers the showProgress() method (the loading wheel). Then, when it completes, it turns it off. But, and this is where the Android debate begins, depending on the type of content being downloaded and where the content is (same server as root URL, https, etc, etc) Android will not always fire the “done loading” event.
All this means is that when I make the HTML and load it, it works 100% of the time on every device I’ve ever tested on. But, if you load HTML content that you didn’t author, you never really know what’s “trying to load” and how Android will report it’s progress.
Maybe we should re-invent the showProgress method. LOL.”
ok, try this..
Using customURL as an example, find this at around line 153:
//do not try to load the URL.. return true;
}
}
Under the last closing curly brace, add:
@Override public void onLoadResource (WebView view, String url) { if (url.contains(“facebook”)||(url.contains(“twitter”)||(url.contains(“something else”)|| (url.contains(“some other site”) ) ) ) ) ) ) { if(view.getHitTestResult().getType() > 0){ view.getContext().startActivity(new Intent(Intent.ACTION_VIEW, Uri.parse(url))); view.stopLoading(); } } }
I’ve added facebook and twitter as examples. To add or remove sites just follow the pattern and make sure there are the right amount of closing brackets! It might not be quite what you want but it should stop the wheel of death and load the destination url.
* * * end of Post * * *
MySkylla's Blog 
Thanks for the greate instruction.
But a problem remains: by commenting out the “showprogress” line, the progress indicator won’t even show before the page is fully load in the custom URL screen, which would be a problem if the connection speed is slow (users will see a blank screen for quite a while, wondering if the app stops working). So is there anyway to only eliminate the progress indicator(SWoD) after the page is fully load where it shouldn’t be there?
Hi,
The problem is that no one has figured out what causes the problem to occur. Certain websites cause the problem but not others.
This solution merely removes a indicator that should do as you indicate.
Perhaps by adding code that will remove the indicator after a given amount of time regardless of whether the website has “fully loaded”.
Unfortunately I don’t know what’s the cause, so I can’t propose a solution.
I would think this solution only works because the page has already fully loaded. Or, has it?
Fred