Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Since network access works with the AVD's browser, I'd focus on other potential sources of the problem.</p> <p>If I were you, I'd simply try to compile against API 8. When you do that, you will be pointed towards any methods and other constructs you use in your code which are not available for API 8. (You haven't provided all code, e.g. there could be something hidden in MyAdapter. Also, you haven't mentioned whether or not your <code>catch</code> log message appears in the LogCat.)</p> <p>The other aspect which may be worth looking at is that you're not using AsyncTask correctly, and it's going to behave differently on different API versions.</p> <p>Depending on the API version, when you do not choose the Executor explicitly, your AsyncTasks will either run sequentially or in parallel, resulting in many or few http connections and also resulting in concurrent manipulation of your data structure.</p> <p>You may manipulate your Adapter only on the main/UI thread. Otherwise, e.g. when the user scrolls through your list, the UI will call your adapter's getView() which may be interrupted by your AsyncTask modifying the very entry which is currently being processed by getView(), resulting in inconsistencies and/or crash.</p> <p>You have tried to achieve this by manipulating <code>lt</code> asynchronously and calling <code>myAdap.l = lt</code> on the UI thread.</p> <p>This is a nice idea, but it has two problems. First, on API 8, many AsyncTasks can run in parallel, while on API 17 it will only be one. <a href="http://developer.android.com/reference/android/os/AsyncTask.html" rel="nofollow noreferrer">Qoute</a>:</p> <blockquote> <p>Starting with DONUT, this was changed to a pool of threads allowing multiple tasks to operate in parallel. Starting with HONEYCOMB, tasks are executed on a single thread to avoid common application errors caused by parallel execution.</p> </blockquote> <p>So on some versions of Android, you would encounter a race condition by which copies of <code>lt</code> would be manipulated in parallel, resulting in data loss upon the assignment. <em>If</em> those were actual <em>copies</em>, that is -- they aren't. By manipulating <code>lt</code> asynchronously while it is already assigned as the underlying data structure of your Adapter, you're breaking the rule of not manipulating UI objects asynchronously.</p> <p>So you'll need to pass the fetched data from <code>doInBackground</code> to <code>onPostExecute</code> and update your Adapter's data structure there.</p> <p>The two points I mentioned may not be the final cause of the problem but they could very well contribute to the observed behaviour, need to be addressed anyway and will make it easier to identify any other potentail root cause.</p> <p>Hope this helps.</p> <p><strong>Update</strong> You may also be using the HttpClient in a wrong way. See for example <a href="https://stackoverflow.com/questions/5377941/unknownhostexception-with-apache-httpclient">here</a>. Maybe not all combinations are (correctly) supported for all API levels (there were several bugs in the past). You may also want to read <a href="http://android-developers.blogspot.de/2011/09/androids-http-clients.html" rel="nofollow noreferrer">Android’s HTTP Clients</a>.</p>
 

Querying!

 
Guidance

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