GWT / Комета: опыт?
Вам нужно использовать actions вместо title
actions: <Widget>[
Image.asset('images/logoapp.png',fit: BoxFit.contain,height: 32,),
Container(padding: const EdgeInsets.all(8.0), child: Text('Solid Shop')),
Image.asset('images/logoapp.png',fit: BoxFit.contain,height: 32,), // here add notification icon
Container(padding: const EdgeInsets.all(8.0), child: Text('Solid Shop')) // here add other icon
],
6 ответов
Для StreamHub существует модуль GWT Comet:
http://code.google.com/p/gwt-comet-streamhub/
StreamHub - это Comet сервер с бесплатной версией сообщества. Вот пример этого в действии здесь .
Вам нужно будет загрузить сервер StreamHub Comet и создать новый SubscriptionListener, использовать пример StockDemo в качестве отправной точки, а затем создать новый JsonPayload для поток данных:
Payload payload = new JsonPayload("AAPL");
payload.addField("bid", "88.84");
payload.addField("ask", "88.86");
server.publish("AAPL", payload);
...
Загрузите JAR с сайта кода Google, добавьте его в путь к классам проектов GWT и добавьте включение в свой модуль GWT:
<inherits name="com.google.gwt.json.JSON" />
<inherits name="com.streamhub.StreamHubGWTAdapter" />
Подключитесь и подпишитесь с помощью своего кода GWT:
StreamHubGWTAdapter streamhub = new StreamHubGWTAdapter();
streamhub.connect("http://localhost:7979/");
StreamHubGWTUpdateListener listener = new StockListener();
streamhub.subscribe("AAPL", listener);
streamhub.subscribe("IBM", listener);
streamhub.subscribe("GOOG", listener);
...
Затем обработайте обновления как вам нравится в слушателе обновлений (также в коде GWT):
public class StockListener implements StreamHubGWTUpdateListener {
public void onUpdate(String topic, JSONObject update) {
String bid = ((JSONString)update.get("bid")).stringValue();
String ask = ((JSONString)update.get("ask")).stringValue();
String symbol = topic;
...
}
}
Не забудьте включить streamhub-min.js в главную HTML-страницу ваших проектов GWT.
Некоторые предварительные идеи для реализации Кометы для GWT могут быть найдены здесь..., хотя интересно, существует ли что-то более сформировавшееся.
существует действительно подобная cometd библиотека для gwt - http://code.google.com/p/gwteventservice/
Но я лично не использовал его, таким образом, наклон действительно ручается за то, кажется ли его польза или нет, но doco довольно хорошей. стоящий попытки.
Существует несколько других, которые я видел, как cometd библиотека gwt-ракеты.
Кроме того, некоторое понимание на интеграции GWT/Comet доступно там, с помощью еще большего количества cutting-bleeding технологии: "Гагатовые Продолжения". Стоящий взгляда.
Я использовал эту технику в нескольких проектах, хотя она действительно имеет, это - проблемы. Я должен отметить, что только сделал это конкретно через GWT-RPC, но принцип является тем же для любого механизма, который Вы используете для обработки данных. В зависимости от того, что точно Вы делаете, не могло бы быть большого количества потребности к законченному, усложняют вещи.
Прежде всего, на стороне клиента, я не полагаю, что GWT может правильно поддерживать любой вид потоковой передачи данных. Соединение должно закрыться, прежде чем клиент может на самом деле обработать данные. То, что это означает с точки зрения нажатия сервера, - то, что Ваш клиент соединится с сервером и блоком, пока данные не будут доступны, в которой точке это возвратится. Независимо от того, что код выполняется на завершенном соединении, должен сразу вновь открыть новое соединение с сервером для ожидания большего количества данных.
От стороны сервера вещей Вы просто заскакиваете в цикл ожидания (Java, параллельный пакет особенно удобен для этого с блоками и тайм-аутами), пока новые данные не доступны. В то время сервер может возвратить пакет данных вниз клиенту, который обновит соответственно. Существует набор соображений в зависимости от того, на что Ваш поток данных похож, но здесь является некоторыми для размышления о:
- Клиент получает каждое важное обновление? Если так, затем сервер должен кэшировать любые потенциальные события между временем, клиент получает некоторые данные и затем снова соединяется.
- Там будут ртами обновлений? Если это верно, это могло бы быть более мудрым к пакету много обновлений и снижать блоки за один раз каждые несколько секунд вместо того, чтобы иметь клиент, получают одно обновление за один раз.
- Серверу, вероятно, будет нужен способ обнаружить, если клиент ушел, чтобы не накапливать огромные количества кэшируемых пакетов для того клиента.
Я нашел, что было две проблемы с подходом нажатия сервера. С большим количеством клиентов это означает много открытых соединений на веб-сервере. В зависимости от рассматриваемого веб-сервера это могло означать много потоков, создаваемых и сохраненных открытыми. Второе имеет отношение к пределу типичного браузера 2 запросов на домен. Если Вы можете вручить свои изображения, CSS и другое статическое содержание fro вторые домены уровня, эта проблема может быть смягчена.
Здесь Вы можете найти описание (с некоторыми исходными образцами) того, как сделать это для IBM WebSphere Application Server. Не должно быть слишком отличным с помощью пристани или любого другого сервера J2EE с включенным кометом. Вкратце, идея: кодировать ваш объект Java к строке JSON через RPC GWT, затем, используя Cometd, отправьте его на клиента, где он получен Dojo, который запускает ваш код JSNI, который вызывает ваши методы виджета, где вы определяете методы виджета снова, используя GWT RPC. Вуаля! :)
Мой опыт с этой установкой положительный, с ним не было проблем, кроме вопросов безопасности. Не совсем ясно, как реализовать безопасность для Comet в этом случае ... кажется, что сервлеты Comet Update должны иметь разные URL-адреса, а затем можно применять безопасность J2EE.