Я пробую реализовывать просьбу ресурса json
используя HttpURLConnection
Проба следующий код в onCreate ()
try {
URL url = new URL("http://localhost/testrealm/api/v1/status");
HttpURLConnection urlConnection = null;
urlConnection = (HttpURLConnection) url.openConnection();
InputStream in = new BufferedInputStream(urlConnection.getInputStream());
Log.d(TAG, "get json: " + in.toString());
urlConnection.disconnect();
} catch (IOException e) {
e.printStackTrace();
}
Ошибка в просьбе
java.lang. RuntimeException: Unable to start activity ComponentInfo... android.os. NetworkOnMainThreadException
Log целая Ошибка
06-10 14:32:21.113 E/AndroidRuntime: FATAL EXCEPTION: main
Process: realm.test.app.testrealm, PID: 11702
java.lang.RuntimeException: Unable to start activity ComponentInfo{realm.test.app.testrealm/realm.test.app.testrealm.MainActivity}: android.os.NetworkOnMainThreadException
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2339)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2413)
at android.app.ActivityThread.access$800(ActivityThread.java:155)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1317)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5343)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:905)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:700)
Caused by: android.os.NetworkOnMainThreadException
at android.os.StrictMode$AndroidBlockGuardPolicy.onNetwork(StrictMode.java:1161)
at java.net.InetAddress.lookupHostByName(InetAddress.java:418)
at java.net.InetAddress.getAllByNameImpl(InetAddress.java:252)
at java.net.InetAddress.getAllByName(InetAddress.java:215)
at com.android.okhttp.HostResolver$1.getAllByName(HostResolver.java:29)
at com.android.okhttp.internal.http.RouteSelector.resetNextInetSocketAddress(RouteSelector.java:232)
at com.android.okhttp.internal.http.RouteSelector.next(RouteSelector.java:124)
at com.android.okhttp.internal.http.HttpEngine.connect(HttpEngine.java:272)
at com.android.okhttp.internal.http.HttpEngine.sendRequest(HttpEngine.java:211)
at com.android.okhttp.internal.http.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:382)
at com.android.okhttp.internal.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:332)
at com.android.okhttp.internal.http.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:199)
at realm.test.app.testrealm.MainActivity.onCreate(MainActivity.java:57)
at android.app.Activity.performCreate(Activity.java:6010)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1129)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2292)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2413)
at android.app.ActivityThread.access$800(ActivityThread.java:155)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1317)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5343)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:905)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:700)
Документация HttpURLConnection
NetworkOnMainThreadException: он вызывается, когда ты стараешься реализовывать операции в главном трэде (Main thread), что неправильный.
Если ты используешь StrictMode. ThreadPolicy. Builder, чтобы позволять любую операцию, функционирует, но ты дезактивируешь политику, которая предполагается, не должно позволять некое поведение в приложении, в этом случае операции в главном Трэде, это используется главным образом для разработки, для производства ты не был бы должен использовать это.
StrictMode.ThreadPolicy policy = new StrictMode.ThreadPolicy.Builder().permitAll().build();
StrictMode.setThreadPolicy(policy);
Используй runOnUiThread ()
runOnUiThread(new Runnable() {
@Override
public void run() {
try {
proceso(); //Realizar aquí tu proceso!
} catch (Exception e) {
Log.e("Error", "Exception: " + e.getMessage());
}
}
});
Другие выборы - Asynctask и также Handler.post ().
Я нашел эту превосходную статью для большей информации: "Задания на втором плане в Android (I): Thread и AsyncTask" (blog Сальвадора Гомеса).
Добавлять следующего cГіdigo перед тем, как реализовывать ее peticiГіn Веб с HttpURLConnection
StrictMode.ThreadPolicy policy = new StrictMode.ThreadPolicy.Builder().permitAll().build();
StrictMode.setThreadPolicy(policy);
Как другой выбор в эту проблему, которая также перемещает это меня из-за рук, состоит в том, чтобы осуществлять твой код внутри одного runOnUiThread()
что позволит соглашаться на переменные главного трэда, так как этот справедливый проблема.
В этом вопросе, я объясняю этот метод:
Использовать Activity.runOnUiThread () или Андлер.пост (Runnable), чтобы обновлять главный Thread?
Как только он вновь имел случай я протестирую твое решение и так знать хорошо другие возможные решения.
StrictMode
он это не знал, но это хорошо изучать эти вещи. Что ты можешь, или не делать. Спасибо.:)
– Vicky Vicent
10.06.2016, 19:54
Эта тема всегда дает о котором говорить. Окончательно дезактивировать политику не выбор.
Но глаз, что это имеет много общего, с как ты хочешь сделать вещи, в моем опыте я увидел следующие сцены:
Следовательно, я не знаю, который был твоим случаем, и важно, чтобы ты думал об этом. Для первого случая AsyncTask
он приходит к тебе очень хорошо. Ты выполняешь твой процесс, взвешенный в doInBackground
, ты сообщаешь пользователю о прогрессе того же самого в publishProgress
и в конце концов ты показываешь результат на Вашем экране через onPostExecute
. Это общепринятое, не только чтобы реализовывать просьбы в серверы, также стоит для сложных вычислений, поисков в базе данных, и т.д. Всякий раз когда твоя интенсивность состояла в том, чтобы поддерживать пользователя в ожидании этого процесса (что-то, что может быть причиняющим беспокойство), и что могло бы работать с app, однажды закончилось.
Для второго случая один Thread
или один Runnable
вместе с одним Handler
он приходит к тебе очень хорошо, ты выполняешь процесс в методе run
что независимый от Вашего состояния окончания и пользователь ни из-за сообщенный встречается этого.
Для третьего случая, давайте помещать примера: У тебя есть процесс, который захватывает данные и преобразовывает их в полезную информацию, ты сохраняешь эту информацию в твоей локальной базе данных, но также должен посылать ее в сервер из-за вопросов излишка данных; но также ты должен ждать результат отправления в сервер, чтобы обновлять курсор на реестре, который определяет тебя, если отправление было успешным или нет, это, чтобы вновь не посылать например. Для этого типа ситуаций годится работать с проектировщиками Трэдов, которые позволяли бы тебе выполнять действие для момента, в котором трэд заканчивает Ваше выполнение. Очень простой пример - Google Guava и Ваши классы Futures
и ListenableFuture
.
Это немного добавочной информации которое они ответили тебе, что хороший, которая должна знать ее, так что он определяет хорошо твои сцены для того, чтобы ты смог выбирать лучший способ работать.