Has anyone come up with a real solution to the show progress 'wheel of death' issue? //show progress //showProgress(null, null); I've commented it out, which works, inasmuch as the screens load, but on slow internet connections when a url or photo takes a while to load, the app looks like it is locked up. Not a good user experience. Any tips on actually getting the a progress indicator to work would be GREATLY appreciated! Thanks.

I had no problem. Fred

Really? I re-downloaded/installed the plugins and updated my sources code (saw an earlier post from David that said he'd solved the issue), but still get the never ending progress indicator. I'm really stumped.

By no problem I mean no problem if I use the solution.

Oh. Ok. Thanks.

For sure an ongoing, very frustrating idea. The idea is simple and I think we all understand it: "When the built in Android Web View widget "isLoading" then show the progress wheel, else, hide it." The trouble is determining when exactly to show it. A few things to consider: Idea 1: If you show it as soon as the activity is created (during the screen layout routine, like in the onCreate method somewhere), it would show nicely and I can almost guarantee it would "hide" when the webView was done. This idea would be to move the showProgress() call from inside the canLoadDocumentInWebView block to the onCreate block. Side note: This is about the BT_screen_customURL.java self hosted / downloadable plugin (I have hacked around a bit on the "hosted" version of this plugin trying to engineer a new solution so there are tiny differences). This file has overridden the canLoadDocumentInWebView method. So, moving it from the canLoadDocumentInWebView() would probably keep it from "hanging" BUT it would also mean that when a link was tapped, or the browser needed to load lots of content from many different URL's (think images, embeds, .css style sheets, etc) it would NOT continue showing. It would show when the screen was created then "hide" on the first occurrence of onPageFinished(). This is the tricky part...the onPageFinished() method runs multiple times, depending on the content the Web View is loading. This is also the bogus part, the name of that method suggests that it SHOULD only fire once. Sometimes it's once, sometimes it's multiple time. Ugh. The other idea is to fire the showProgress() method when the canLoadDocumentInWebView() method fires, (again, multiple times, depending on the content being loaded) showProgress() is fired to ensure the loading graphic shows until EVERYTHING is loaded. This is the part that has proven unreliable. Blah, blah, blah. Try this. a) Move the showProgress() method call from "inside" the canLoadDocumentInWebView block on line 129. Cut it out of here and paste it below this: baseView.addView(thisScreensView); b) Search for all occurances of showProgress in the file. It should only appear twice. Once in the place you just pasted it, and again in the handleRefreshButton() method on line 331 c) Compile, test. In most cases this will work well. In strange cases, where you're loading tons of different resources (as mentioned above) in the Web View you'll get strange results. Lastly: This same issue is also problematic in the customHTML, htmlDoc plugins. You could implement the same changes in those files (it's nearly the same thing) if you're using them. Still not an Android fan!

Ha ha - 'Still not an Android fan!' Me too!! Thanks, David. I'll give this a whirl. Came up with a pretty crazy hack for the rss plugin to allow me to not have to recreate a separate Android app in my control panel (what I used to do). My new plugin downloads rss for iOS and a customURL setup for Android. Cool and it works.

Hey David. Looks like it is working pretty well. Thanks.

Great! I think more than anything it depends on how "complicated" the HTML Request / Load is that Android's doing. The more complex, the more likely it doesn't behave as expected. Dig the RSS thing too. Look for a Plugin Creator Tool update in the next few days? Super stoked to get this going. Hoping it makes a huge impact over the coming months.

Plugin Creator Tool update in the next few days sweeeeeet

awesome, more tips on the Wheel of Death. will experement with it. Thanks! The commenting out seems to work pretty good in my 2.0 Android apps. I'm using a bunch of HTML DOCS in an 2.0 and don't see the indicator stopping anything both on/line and off-line.. Tough to tell for sure as i'm using Revmob in the App now and that ruins the whole experience anyways...LOL. @MGoBlue - I'd still like to discuss the header Image for the Android 2.0. I stopped hacking at for now in hopes of seeing your tips one day to make it work. I can get it to compile now but as soon as the app launches it crashes. I'm using simple menus with no header and just a backround image now to fudge a header. I kinda like the new design/ideas I came up with - but that header image for Android would be a nice to have in the arsenal for future use. @David - if you happen to still be in an Android state of mind.... Row Heights and Font Sizes for the Simple menu for Android?- I've altered the values int he BT_screen_menu_listSimple.java for both Large and Small devices, I've added and removed values in the CP and nothing seems to change them at all. Is there something else in that file that is overrding this? I'm looking at the //inflate the layout and set size furthur down in the file and wondering if this is where I could hard code some values in? But that is a global change and i'd like to control it per menu if possible...? -becoming a Android fan as I keep working with it!

@ATRAIN53 - Here's a link for the Android version of my Michigan App. You'll see I was able to use the custom headers and some other tricks. The spinner solution above works great. https://dl.dropbox.com/u/76141353/michigan.apk (I'll pull this link down later today) For the header images to work, you need to create a BT_Images folder in the assets folder. All your header images and list icons go here. I tried playing with the code to direct it to the drawable folder, but it didn't work. The list sizes are probably controlled in the .xml files. That's where I've made other size adjustments.

Thanks- I pulled that down do if you want to kill the link. Excellent tip on the BT_Images, I'll give that a test. and looking at some XML files right now..... I just discovrered that 'Graphical Layout' builder last week. It's like the IB version 1.0. Took a few weeks to learn how to use IB with BT - I'm wondering if this will be the same... Thanks again, your time and help is most appreciated. 3 weeks! (and how about Mellencamp JR walking on at Duke? Now I'm salty they stopped playing the BIG 10!)

Row Heights / Android - more bogusness! We've had success on tons of devices, not on others. More of the same in the Android world. The way it should work (and does in many cases): Three files. BT_screen_menuListSimple.java, screen_menulistsimple.xml and menu_list_rowsimple.xml. The first layout file describes the entire screen, like the size of the actual ListView, etc. The second layout file is used by each individual menu item row. These layout files have values hard-coded into them for the height. This means they are pre-built as the screen does it onCreate routine (when the layout is inflated). However, also in thie onCreate method, we look at the JSON data to find the listRowHeight setup in the control panel. This value is assigned to a variable. Have a look at line 153 or so to see where this happens. Look for listRowHeight = ....... So far so good. Layout is inflated, value for listRowHeight is saved to a variable for later. Next, later in the code, we need to set the "height" of all the parts inside the layout xml file. This means the titleView (that holds the text) and the imageView. There is an image view in the layout file for each row but it's generally not used in the "simple menu." Note: Android runs a routine called getView (in the private class ChildItemAdapter) for each row in the list. It runs this getView routine as it iterates through the items. 5 items, getView runs 5 times. 30 items, getView runs 30 times. It's this getView method that is responsible for "sending back" a view for the row. It's in this method that the setup is done for each item. You can see it inflate the menu_list_rowsimple.xml file, then dynamically alter the values (like the text for the label, row height, etc) before sending it back. ChildItemAdapters are tough to understand for lots of folks but browsing through the few dozen lines starting at line 479 is helpful if you can get your head around it. If you can't get it to work, you could try changing the height of the ImageView object named indicatorView in the XML. This is the menu_list_rowsimple.xml file. It has a hard coded height value for the pointer icon as a default, 30dip. Because the icon (the indicator arrow graphic) on the right side of the screen is a fixed size (the image) you may have to tinker with this height value? Try wrap_content or fill_parent as needed.