Урок 80. Handler. Немного теории. Наглядный пример использования
Урок 80. Handler. Немного теории. Наглядный пример использования
В этом уроке:
- разбираемся, что такое Handler и зачем он нужен
Click here to read this article!
- разбираемся, что такое Handler и зачем он нужен
Click here to read this article!
Последний раз редактировалось damager82 19 май 2017, 10:21, всего редактировалось 7 раз.
-
- Сообщения: 2
- Зарегистрирован: 21 май 2012, 09:42
Re: Урок 80. Handler. Немного теории. Наглядный пример испо
Спасибо за урок. Я читаю уроки с конца. Не особо вчитываясь в код, но внимательно читая сам текст, что бы понимать. В данном примере для меня все ясно, это мне пригодится.
Re: Урок 80. Handler. Немного теории. Наглядный пример испо
Немного не по теме урока (Handler), но т.к. добрая половина была посвящена "проталкиванию" сообщения к UI из второстепенного потока в основной, вот еще 3 способа это сделать
http://developer.android.com/resources/ ... ading.html
http://developer.android.com/resources/ ... ading.html
Re: Урок 80. Handler. Немного теории. Наглядный пример испо
Есть такое дело, об этом тоже будет урок.andev писал(а):Немного не по теме урока (Handler), но т.к. добрая половина была посвящена "проталкиванию" сообщения к UI из второстепенного потока в основной, вот еще 3 способа это сделать
http://developer.android.com/resources/ ... ading.html
Re: Урок 80. Handler. Немного теории. Наглядный пример испо
Не пойму, чем работа через Handler отличается от AsyncTask и что лучше использовать? Насколько я понял AsyncTask использует методы Hendler, т.е. это как бы обвёртка для handler-a и видимо предпочтительнее использовать её, или я ошибаюсь?
Re: Урок 80. Handler. Немного теории. Наглядный пример испо
Все так. Используем то, что больше подходит для ситуации или, что больше нравится.goodroot писал(а):Не пойму, чем работа через Handler отличается от AsyncTask и что лучше использовать? Насколько я понял AsyncTask использует методы Hendler, т.е. это как бы обвёртка для handler-a и видимо предпочтительнее использовать её, или я ошибаюсь?
Re: Урок 80. Handler. Немного теории. Наглядный пример испо
а возможен такой код который будет запрещать отправку смс на короткие номера, или будет требовать разрешение через дополнительное диалоговое окошко перед каждой отправкой смс, в том числе и несанкционированную абонентом?
Re: Урок 80. Handler. Немного теории. Наглядный пример испо
Хотелось бы уточнить. С потоками в Java я знаком и применял их даже в Андроид, ошибки вроде не вылетало... Но вопрос у меня вот по какому поводу. В Java насколько я знаю поток можно создать 2мя способами : через класс наследник или путем имплементации Runnable... В метод run ложится тело "то что будет делать поток". То тут мне не совсем понятно. Метод handleMessage является аналогом run или же выполняет другую роль?
Вопрос номер два :
Строка if (msg.what == 10) btnStart.setEnabled(true); В эту строку мы кладем int. Метод what возвращает текущее значение переданного параметра?
И третий вопрос, точкой входа в handleMessage является Handler.sendEmptyMessage(msg); ?
Спасибо.
Вопрос номер два :
Строка if (msg.what == 10) btnStart.setEnabled(true); В эту строку мы кладем int. Метод what возвращает текущее значение переданного параметра?
И третий вопрос, точкой входа в handleMessage является Handler.sendEmptyMessage(msg); ?
Спасибо.
Re: Урок 80. Handler. Немного теории. Наглядный пример испо
1) Handler - это обработчик. Обычно он принадлежит какому-либо потоку и работает с его очередью сообщений.MeTeOpA писал(а):Хотелось бы уточнить. С потоками в Java я знаком и применял их даже в Андроид, ошибки вроде не вылетало... Но вопрос у меня вот по какому поводу. В Java насколько я знаю поток можно создать 2мя способами : через класс наследник или путем имплементации Runnable... В метод run ложится тело "то что будет делать поток". То тут мне не совсем понятно. Метод handleMessage является аналогом run или же выполняет другую роль?
Вопрос номер два :
Строка if (msg.what == 10) btnStart.setEnabled(true); В эту строку мы кладем int. Метод what возвращает текущее значение переданного параметра?
И третий вопрос, точкой входа в handleMessage является Handler.sendEmptyMessage(msg); ?
Спасибо.
Можно провести аналогию со станком (поток) и работником (handler). Работник обычно прикреплен к станку и работает только на нем.
Ну и, допустим, у станка сбоку есть некий ящик (очередь сообщений).
Работнику принесли несколько заготовок из которых надо сделать детали (Мы передали в handler несколько сообщений).
Работник складывает полученные заготовки в ящик (Handler помещает все полученные сообщения в очередь процесса).
Работник по очереди достает заготовки из ящика и обрабатывает с помощью своих рук и мастерства, используя ресурс станка (Handler получает из очереди сообщения и обрабатывает их в своем методе handleMessage, используя ресурс процесса).
2) То, что кладем в sendEmptyMessage, читаем потом в what.
3) Точкой входа в handleMessage является механизм в процессе, который мониторит очередь сообщений и отправляет их в handler на обработку. Он будет отправлять их по очереди, пока не закончатся. Либо можно указать ему время, через которое он должен их отправить.
В следующих уроках идет более подробный обзор handler-а.
Re: Урок 80. Handler. Немного теории. Наглядный пример испо
damager82 писал(а):В этом уроке:
- разбираемся, что такое Handler и зачем он нужен
Click here to read this article!
спасибо
в кои веки пример из инета заработал без длительного поиска ошибок в коде)
Re: Урок 80. Handler. Немного теории. Наглядный пример испо
Эклипс намекнул на то, что Handler должен быть статическим, иначе возможны утечки памяти.
Re: Урок 80. Handler. Немного теории. Наглядный пример испо
Я Handlerы так и реализовал, благо в Инете нашлись паттерны на эту тему. Для новичков это сильно усложнит и без того непростую тему связанную с потоками, а тут еще утечки памяти и слабые ссылки Но для тех, кто реально пишет приложения для Андроид и JAVA нужно иметь это ввиду.brucemax писал(а):Эклипс намекнул на то, что Handler должен быть статическим, иначе возможны утечки памяти.
Re: Урок 80. Handler. Немного теории. Наглядный пример испо
А ссылочки не осталось?)AndreyI писал(а):благо в Инете нашлись паттерны на эту тему
Re: Урок 80. Handler. Немного теории. Наглядный пример испо
http://stackoverflow.com/questions/1140 ... inghandler
http://stackoverflow.com/questions/1127 ... in-android
См. первые ответы.
Ну и конечно паттерн от Romain Guy на основе которого, собственно, и были составлены вышеприведенные.
Если я правильно понял, это связано с особенностью работы сборщика мусора, он не уничтожает объекты в памяти пока на них ссылается хотя бы один другой не уничтоженный объект. А handler-ы не уничтожаются пока у них в очереди есть необработанные сообщения, это может случиться, к примеру, если получать сообщение уже не кому, т.е. объект к которому он привязан хотя еще и существует в памяти, но его поток уже отработал, в особенности это актуально для сообщений с задержкой по времени, т.е. пока сообщение ждет отправки получателю, пользователь может попросту закрыть приложение и получать сообщение будет некому. Т.к. при обычной (нестатической) реализации класса объект handler имеет внутреннюю ссылку на объект внешнего класса, то он удерживает от уничтожения весь объект этого класса, т.е. получается они как бы друг друга оберегают от сборщика мусора перекрестными ссылками друг на друга (этакий deadLock от смерти ). А если учесть, что handler создавался в классе Activity к которому привязано еще куча объектов (это фактически весь GUI этого Activity со всей иерархией View) и все это остается висеть мертвым грузом в памяти.
Как-то так, если не прав, поправьте.
http://stackoverflow.com/questions/1127 ... in-android
См. первые ответы.
Ну и конечно паттерн от Romain Guy на основе которого, собственно, и были составлены вышеприведенные.
Если я правильно понял, это связано с особенностью работы сборщика мусора, он не уничтожает объекты в памяти пока на них ссылается хотя бы один другой не уничтоженный объект. А handler-ы не уничтожаются пока у них в очереди есть необработанные сообщения, это может случиться, к примеру, если получать сообщение уже не кому, т.е. объект к которому он привязан хотя еще и существует в памяти, но его поток уже отработал, в особенности это актуально для сообщений с задержкой по времени, т.е. пока сообщение ждет отправки получателю, пользователь может попросту закрыть приложение и получать сообщение будет некому. Т.к. при обычной (нестатической) реализации класса объект handler имеет внутреннюю ссылку на объект внешнего класса, то он удерживает от уничтожения весь объект этого класса, т.е. получается они как бы друг друга оберегают от сборщика мусора перекрестными ссылками друг на друга (этакий deadLock от смерти ). А если учесть, что handler создавался в классе Activity к которому привязано еще куча объектов (это фактически весь GUI этого Activity со всей иерархией View) и все это остается висеть мертвым грузом в памяти.
Как-то так, если не прав, поправьте.
Re: Урок 80. Handler. Немного теории. Наглядный пример испо
Полезно, спасибо!AndreyI писал(а):http://stackoverflow.com/questions/1140 ... inghandler
http://stackoverflow.com/questions/1127 ... in-android
См. первые ответы.
Ну и конечно паттерн от Romain Guy на основе которого, собственно, и были составлены вышеприведенные.
Если я правильно понял, это связано с особенностью работы сборщика мусора, он не уничтожает объекты в памяти пока на них ссылается хотя бы один другой не уничтоженный объект. А handler-ы не уничтожаются пока у них в очереди есть необработанные сообщения, это может случиться, к примеру, если получать сообщение уже не кому, т.е. объект к которому он привязан хотя еще и существует в памяти, но его поток уже отработал, в особенности это актуально для сообщений с задержкой по времени, т.е. пока сообщение ждет отправки получателю, пользователь может попросту закрыть приложение и получать сообщение будет некому. Т.к. при обычной (нестатической) реализации класса объект handler имеет внутреннюю ссылку на объект внешнего класса, то он удерживает от уничтожения весь объект этого класса, т.е. получается они как бы друг друга оберегают от сборщика мусора перекрестными ссылками друг на друга (этакий deadLock от смерти ). А если учесть, что handler создавался в классе Activity к которому привязано еще куча объектов (это фактически весь GUI этого Activity со всей иерархией View) и все это остается висеть мертвым грузом в памяти.
Как-то так, если не прав, поправьте.
Re: Урок 80. Handler. Немного теории. Наглядный пример испо
Написано на этом уроке:
Получить доступ к Handler из какого-либо другого потока мы сможем без проблем, т.к. основной поток монополизирует только доступ к UI. А элементы классов (в нашем случае это Handler в MainActivity.java) доступны в любых потоках. Таким образом Handler выступит в качестве «моста» между потоками.
Подскажите, если объявление другого потока вынесено в отдельный файл. Как тогда получать доступ к Handler, который описан в файле с MainActivity?
Получить доступ к Handler из какого-либо другого потока мы сможем без проблем, т.к. основной поток монополизирует только доступ к UI. А элементы классов (в нашем случае это Handler в MainActivity.java) доступны в любых потоках. Таким образом Handler выступит в качестве «моста» между потоками.
Подскажите, если объявление другого потока вынесено в отдельный файл. Как тогда получать доступ к Handler, который описан в файле с MainActivity?
Re: Урок 80. Handler. Немного теории. Наглядный пример испо
здесь нормально выводится в TextView из другого потока
проблемы появляются при добавлении downloadFile(). В документации андроид по этому поводу пишут, что можно получать доступ к UI элементам из другого потока, но делать это нежелательно. Т.е. доступ все-таки имеется
Код: Выделить всё
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
tvInfo = (TextView) findViewById(R.id.tvInfo);
Thread t = new Thread(new Runnable() {
public void run() {
tvInfo.setText("Закачано файлов: " + 11111);
}
});
t.start();
}
Re: Урок 80. Handler. Немного теории. Наглядный пример испо
Здратсвуйте. Как сделать чтобы когда все (10) файлы загрузились чтобы processbar тоже остановился крутить? и опять когда нажимаем start process bar опять крутился.
Re: Урок 80. Handler. Немного теории. Наглядный пример испо
Ну делай в хэндлере спиннеру dismiss() когда не нужен и show() когда нужен.
R.id.team
NullPointerException - что делать???
viewtopic.php?f=33&t=3899&p=28952#p28952
Где моя ошибка?
viewtopic.php?f=60&t=3198
NullPointerException - что делать???
viewtopic.php?f=33&t=3899&p=28952#p28952
Где моя ошибка?
viewtopic.php?f=60&t=3198
Re: Урок 80. Handler. Немного теории. Наглядный пример испо
Все сделал. на 81 уроке есть пример как скрыть ProgressBar. pbar.setVisibility(View.INVISIBLE); .
я не понял зачем нам нужен spinner?
через dismiss() не получилось,то есть я не знал как и куда писать этот dismiss().
я не понял зачем нам нужен spinner?
через dismiss() не получилось,то есть я не знал как и куда писать этот dismiss().