Уведомления о прогрессе от сервиса HTTP/REST
Если высота и ширина TextView's равны wrap content, то текст в TextView всегда будет центрирован. Но если ширина TextView's равна match_parent, а высота - match_parent или wrap_content, то вы должны написать следующий код:
Для RelativeLayout:
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent">
<TextView
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:gravity="center"
android:text="Hello World" />
</RelativeLayout>
Для LinearLayout:
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent">
<TextView
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:gravity="center"
android:text="Hello World" />
</LinearLayout>
6 ответов
Я полагаю, это зависит от нескольких факторов
- Насколько точной может быть обратная связь (1 процент, 5 процентов, 50 процентов)
Точная обратная связь позволяет добиваться какого-то прогресса бар и толчок в стиле кометы. Если вы можете сказать только «Занято ... подождите ... почти готово ... готово», тогда простой опрос на основе ajax «мы там еще?», Безусловно, легче кодировать. - Насколько своевременным должно быть сообщение «Готово» видит клиент
- Сколько времени занимает выполнение каждой задачи (1 секунда, 10 секунд, 10 минут)
1 секунда делает это немного спорным. 10 секунд того стоит. 10 минут означает, что вам лучше предложить пользователю перерыв на кофе: -) - Сколько будет одновременных запросов
Если у вас нет «специального» сервера, системы в стиле live push, как правило, съедают соединения, и вы довольно быстро исчерпаете свой ресурс. Необходимость добавить больше веб-серверов для причудливого индикатора выполнения может нанести ущерб бюджету.
У меня есть пример кода на 871184 , который показывает ручную прокрутку « навсегда кадр », который вроде получается хорошо. Проект, для которого я его разработал, не так уж и сложен, операции занимают несколько секунд, и мы можем дать довольно точный процент. В коде используются asp.net и jquery, но общие методы будут работать с любым сервером и фреймворком javascript.
edit Как указывает Джон , отчеты о состоянии, вероятно, не являются задачей RESTful сервис. Но нет ничего, что говорило бы, что ты можешь t открыть iframe на клиенте, который подключается к странице на сервере, который опрашивает службу. Теория утверждает, что сервер и служба будут как минимум ближе друг к другу: -)
Опрос
Клиент продолжает опрашивать сервер, чтобы получить статус ответа.
Плюсы
- На самом деле RESTful означает кэшируемость и масштабируемость.
] Минусы
- Не самая лучшая отзывчивость, если вы не хотите слишком часто опрашивать свой сервер.
Постоянное соединение
Сервер не закрывает свое HTTP-соединение с клиентом, пока не будет получен ответ. Сервер может отправлять промежуточный статус через это соединение с использованием нескольких частей HTTP.
Comet - самая известная среда для реализации этого поведения.
Плюсы
- Лучшая скорость отклика, уведомления с сервера почти в реальном времени.
Минусы
- Ограничение на количество подключений на веб-сервере ограничено, слишком долгое поддержание соединения может, в лучшем случае, загрузить ваш сервер, в худшем - открыть сервер для атак типа «отказ в обслуживании».
Клиент как сервер
] Сделайте так, чтобы сервер отправлял обновления статуса и отвечал клиенту так, как если бы это было другое приложение RESTful.
Плюсы
- Лучшее из всех, никакие ресурсы не тратятся на ожидание ответа ни на сервере, ни на клиенте. сторона.
Я считаю, что следует придерживаться решения для опроса, но вас может заинтересовать эта статья в Википедии о технологиях HTTP Push .
REST зависит от HTTP, который является протоколом запроса / ответа. Я не думаю, что вы получите чистый HTTP-сервер, который будет возвращать клиенту статус.
Кроме того, создание отчетов о статусе - это не задача службы. Клиент должен решить, когда и нужно ли ему сообщать о статусе.
Посмотрите на Комету . Вы делаете один запрос к серверу, и сервер блокирует и удерживает соединение открытым до тех пор, пока не произойдет обновление статуса. Как только это произойдет, ответ будет отправлен и зафиксирован. Браузер получает этот ответ, обрабатывает его и немедленно повторно запрашивает тот же URL. Эффект заключается в том, что события отправляются в браузер. Есть плюсы и минусы, и он может не подходить для всех случаев использования, но обеспечит наиболее своевременное обновление статуса.
Вы также можете использовать самообновляющийся iframe, но вызов AJAX намного лучше. Я не думаю, что есть другой способ.
PS: Если вы откроете сокет из клиента, это не сильно изменится - браузер PHP покажет страницу как все еще "загружающуюся", что не очень удобно для пользователя - дружелюбный. (при условии, что вы нажмете или очистите буфер, чтобы раньше отображались другие данные)