Databases
StackOverflow2013
Postsdbo
POFrom WebView Errors to ImageView Cover-ups to Screen Orientation
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POFrom WebView Errors to ImageView Cover-ups to Screen Orientation
    primarykey
    data
    text
    <p>It all started with a simple <strong>WebView</strong> within an Android app.</p> <p>This view loads info from a public URL. Nothing unusual there.</p> <p>However ... if there should be a network interruption, you can easily end up with an error displayed prominently in the <strong>WebView</strong>.</p> <p>Well, that's no good, right? So I searched the docs and elsewhere for a way to suppress this, or trap it ... and found no leads. With that, I inquired on <code>#android-dev</code> on IRC: I know about <strong>WebView.onReceivedError</strong>, but can the visual portion be suppressed? (Instead, I wanted to display a <strong>Dialog</strong> warning of said network problem, with an option to retry.)</p> <p>Answer: <a href="http://code.google.com/p/android/issues/detail?id=2340&amp;can=5&amp;colspec=ID%20Type%20Status%20Owner%20Summary%20Stars" rel="nofollow noreferrer">You can't</a>. :(</p> <p>Very well. Time for plan B. Perhaps an <strong>ImageView</strong> might fill the bill?</p> <p>Should there be any kind of <strong>WebView</strong> error, the <strong>ImageView</strong> can be used as a makeshift curtain. It overlays the <strong>WebView</strong> at the start (before the URL is loaded), then it fades to reveal the <strong>WebView</strong> behind it. If the <strong>WebView</strong> works, wonderful! But if <strong>onReceivedError</strong> kicks in, we put the curtain back up immediately and show the aforementioned dialog. Once WebView gets an <strong>onPageFinished</strong>, the curtain fades once more.</p> <p>... and THIS ... works WONDERFULLY!</p> <p>Until I was asked to support screen orientation changes. (Foreshadowing: "Things went downhill from here.")</p> <p>Up until now the app was using <code>android:screenOrientation="portrait"</code> in the Manifest's main activity. So I removed that part, and of course we ran into the infamous "activity is being restarted" issue, which blows away and then brings back the <strong>WebView</strong>.</p> <p>Of course it's not an issue per se. This is Android OS working as designed.</p> <p>Also, we want the <strong>ImageView</strong> to display properly depending on orientation. Thankfully, we have <a href="http://developer.android.com/guide/topics/resources/resources-i18n.html#AlternateResources" rel="nofollow noreferrer">alternate resources</a> we can leverage! Meanwhile, we still have this <strong>WebView</strong> we don't want to reload. We want it to be left alone and let the view do its own thing, be it in portrait or landscape at the time.</p> <p>I found <a href="http://www.androidguys.com/?s=rotational+forces" rel="nofollow noreferrer">a few well-explained ways to handle screen orientation</a>, plus I have already read through author <a href="http://commonsware.com/Android/" rel="nofollow noreferrer">Mark</a> <a href="http://commonsware.com/AdvAndroid/" rel="nofollow noreferrer">Murphy's</a> <a href="http://commonsware.com/AndTutorials/" rel="nofollow noreferrer">eBooks</a> (highly recommended reading). Yet I was still stuck! With the <strong>ImageView</strong> now in the mix, none of the techniques seem to fill the bill:</p> <ol> <li><p>Forcing portrait mode is, of course, out of the question (or is it?).</p></li> <li><p><code>android:configChanges="keyboardHidden|orientation"</code> and <code>onConfigurationChanged</code> seem to take care of the WebView, which blissfully handles the screen resizing gracefully on its own. Of course, the <strong>ImageView</strong> doesn't get the memo either, and it keeps using its original (portrait/landscape) resource!</p> <p>An ill-conceived call to <code>activity.setRequestedOrientation(newConfig.orientation)</code> within the config change handler didn't help matters.</p></li> <li><p>Since the <strong>WebView</strong> doesn't need to be persisted between app executions, <code>onRetainNonConfigurationInstance</code> looked like another possibility. Alas, that didn't seem to work either. Resetting <code>webview</code> with the last nonconfig instance (since that's all I really passed in) resulted in a blank <strong>WebView</strong>. Not quite what I was after.</p> <p>On the other hand, the <strong>ImageView</strong> seemed to responding nicely to orientation changes. Go figure.</p></li> <li><p>How about <code>onSaveInstanceState</code>? Same gotchas. <strong>WebView</strong> has a <code>saveState</code> method, but it doesn't seem to be saving it at a level deep enough to keep the transition seamless. If so, then it's probably not supposed to either, so this might be the wrong way to go too.</p></li> </ol> <p>As to the wisdom of using <code>configChanges</code>, <a href="http://developer.android.com/reference/android/webkit/WebView.html" rel="nofollow noreferrer">the documentation recommends this very technique</a>, in fact:</p> <blockquote> <p>Standard behavior for an <strong>Activity</strong> is to be destroyed and recreated when the devices orientation is changed. This will cause the <strong>WebView</strong> to reload the current page. If you don't want that, you can set your <strong>Activity</strong> to handle the <code>orientation</code> and <code>keyboardHidden</code> changes, and then just leave the <strong>WebView</strong> alone. It'll automatically re-orient itself as appropriate.</p> </blockquote> <p>Of course <a href="https://stackoverflow.com/questions/1002085/android-webview-handling-orientation-changes/2067409#2067409">I could also be committing some sort of pilot error</a> here, but I have yet to figure out what that might be.</p> <p>I have read and re-read the documentation and tried every which way to hack through this on my own. Perhaps I'm missing something (obvious?) in the docs, or the solution is non-obvious (but someone can shed light) ... or this simply isn't possible. Hoping it's not the latter.</p> <p>Clues welcome/appreciated!</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USCommunity
    1. USJoe D'Andrea
    plurals
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POFrom WebView Errors to ImageView Cover-ups to Screen Orientation
      1. USAndhravaala
      1. VTFavorite
    2. VO
      singulars
      1. POFrom WebView Errors to ImageView Cover-ups to Screen Orientation
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload