Silverlight и уведомления о нажатии
вы должны использовать
double g=1.0/3;
или
double g=1/3.0;
Целочисленное деление возвращает целое число.
8 ответов
Уведомление о нажатии поддерживается в Silverlight 2 с помощью новой поддержки WCF PollingDuplexHttpBinding. Существует два блока, установленные с SDK Silverlight ( один для приложения Silverlight один для сервера WCF ).
я имею немного сообщений в блоге и полный пример приложения , которые демонстрируют, как 'продвинуть' обновления Stock с сервера Консольного приложения, который саморазмещает сервис WCF для связанных клиентов. Это также показывает, как каждый клиент может добавить примечания против Запаса и иметь те синхронизируемые примечания (продвинутый с сервера) всем другим связанным клиентам.
последняя версия образца (Часть 4) показывает, как синхронизировать продвинутые обновления и между Silverlight и между клиентами WPF, использующими две конечных точки сервера следующим образом:
using System;
using System.ServiceModel;
using System.ServiceModel.Description;
namespace StockServer
{
public class StockServiceHost : ServiceHost
{
public StockServiceHost(object singletonInstance, params Uri[] baseAddresses)
: base(singletonInstance, baseAddresses)
{
}
public StockServiceHost(Type serviceType, params Uri[] baseAddresses)
: base(serviceType, baseAddresses)
{
}
protected override void InitializeRuntime()
{
this.AddServiceEndpoint(
typeof(IPolicyProvider),
new WebHttpBinding(),
new Uri("http://localhost:10201/")).Behaviors.Add(new WebHttpBehavior());
this.AddServiceEndpoint(
typeof(IStockService),
new PollingDuplexHttpBinding(),
new Uri("http://localhost:10201/SilverlightStockService"));
this.AddServiceEndpoint(
typeof(IStockService),
new WSDualHttpBinding(WSDualHttpSecurityMode.None),
new Uri("http://localhost:10201/WpfStockService"));
base.InitializeRuntime();
}
}
}
клиенты WPF соединяются с конечной точкой WSDualHttpBinding, и клиенты Silverlight соединяются с конечной точкой PollingDuplexHttpBinding того же сервиса WCF. Приложение также показывает, как обработать клиентские требования политики доступа Silverlight.
Клиенты (Silverlight или WPF) могут добавить примечания против Запаса в их UI, и эти примечания распространяют назад к серверу, который будет продвинут всем другим клиентам. Это демонстрирует коммуникацию в любом направлении и надо надеяться выполняет всю необходимую коммуникацию, требуемую для Вашего приложения.
Вы видите снимок экрана демонстрационное приложение, работающее здесь .
Не то, чтобы продвигаю Flex способом мальчика вентилятора, но вопрос factly, это - вид архитектуры, которую мы обычно встраиваем во все наши основанные на Flex приложения. Вот то, что мы делаем на Flex - несомненно он мог быть соответственно переведен в Silverlight:
Мы берем три компонента и интегрируем их вместе для выполнения этой возможности:
- шаблон Кометы (HTTP совместимый способ сделать уведомления о нажатии сервера - считают Википедию для большего количества информации)
- JMS обменивающиеся сообщениями темы (публикуют/подписчик очереди)
- сервлет Adobe BlazeDS
последний объект реализует шаблон Кометы, поддерживает объект AMF, упорядочивающий (двоичный формат сериализации Adobe для объектов ActionScript3), и образует мост очереди JMS или теме. При образовании моста к теме тогда несколько клиентов Flex, работающих в браузере, могут быть проксированы в как подписчики на тему JMS. Таким образом, если какой-либо клиент опубликует сообщение (или серверный код публикует в тему), то всем клиентским подписчикам продвинут сообщение им через BlazeDS и реализацию Шаблона Кометы.
Эффективно необходимо определить местоположение или записать компонент, который выполняет то, что делает BlazeDS. Вы, возможно, также должны были бы реализовать некоторый клиентский код, который взаимодействует с шаблоном Кометы этого компонента серверной стороны.
WCF поддерживает Шаблон Кометы и двунаправленный обмен сообщениями? Особенно, где соответствует HTTP и порту 80 или порту 443 для SSL. Похож Вы уже изучили это и не нашли что-либо для двунаправленного обмена сообщениями. Таким образом, Вы, возможно, должны засучить рукава и сделать некоторое кодирование.
Некоторые вещи отметить о выполнении сервера продвигают к веб-приложению:
BlazeDS поддерживает два основных режима реализации шаблона Кометы (существует на самом деле 3-я опция опроса, но игнорирует его):
- длинный опрос
- HTTP, передающий потоком
долго опрашивающий, необходимо найти, чтобы быть более универсально приемлемыми к большинству веб-браузеров. Таким образом, Вы могли бы оптимизировать только к поддержке этого первоначально. Или Вы могли провести время, чтобы заставить Ваш клиентский код попробовать HTTP, передающий потоком сначала и переключиться на длинный опрос при необходимости.
относительно брокера сообщений, который может обеспечить publish/suscribe capatibility, Вы могли бы рассмотреть использование ActiveMQ JMS. Это - открытый исходный код и свободный с активной общественной поддержкой (можно купить поддержку также). Плюс Вы может использовать NMS для интеграции как клиент.NET.
Наличие брокера сообщений, находящегося на среднем уровне, на самом деле важно, потому что это будет место для сообщений, которые будут помещены безопасно. Если бы Ваши клиенты делают длинный опрос, Вы не хотели бы, чтобы они пропустили любое новое сообщение во время интервала, когда они на самом деле не соединены.
Другая вещь рассмотреть в сценариях объема интенсивного трафика (сотни или тысячи клиентов, таких как веб-сайт в Интернете), у Вас должен быть подход к Шаблону Кометы, который масштабируем.
В мире Flex/Java, сервлет BlazeDS (который является открытым исходным кодом) был изменен для работы с асинхронной моделью. В Java слушатель сокета может быть создан для использования каналов NIO и пулов потоков Исполнителя Параллелизма Java. Веб-сервер Tomcat имеет слушателя NIO и поддержку асинхронных событий Servlet 3.0. BlazeDS в особенности был изменен, тем не менее, для работы с Гагатовым веб-сервером. Нижняя строка - то, что масштабируемость этого асинхронного подхода означает, что единственный физический веб-сервер может быть улучшен для поддержки приблизительно до 20 000 параллельных соединений клиента стиля Кометы.
Это было некоторое время, так как я сделал серьезное программирование.NET, но привык для io возможностей, были во многом как Java 1.1 кроме с асинхронной возможностью обработчика результатов. Это, тем не менее, не то же самое как создание асинхронных слушателей сокета по каналам NIO Java. Реализация канала NIO может поддерживать сотни к тысячам сокетных соединений с относительно небольшим пулом потоков. Но C# и.NET прошли две или три значительных версии - возможно, были новые io возможности, добавил, что сопоставимы с каналами NIO.
PollingDuplexHttpBinding является, вероятно, самым изящным способом сделать это.
Одна возможно менее включенная альтернатива должна использовать сокет TCP от Вашего клиента Silverlight. Каждый раз, когда одному из клиентов Silverlight нужно было продвинуть обновление, можно отправить ему сообщение TCP, которое содержит название службы WCF, которую оно должно назвать или некоторая другая информация легкого веса.
я использую этот подход для приложения, и он работает хорошо.
Моя организация нашла Silverlight 2.0/WCF реализацией нажатия для немного "не чтения к прайм-тайму", по крайней мере, для того, для чего мы планировали использовать его.
Мы закончили тем, что шли с XMPP/Jabber, потому что это - более хорошо сформированный зверь, и можно реализовать его довольно легко в Silverlight, просто получив некоторые ресурсы от Интернета.
Я действительно полагаю, что Silverlight 3.0 реализует более новую/больше хорошо сформированную реализацию нажатия, от того, что я могу сказать от общедоступной информации.
В качестве альтернативы
, если вам нужен собственный API Silverlight без задействованных прокси, мостов или веб-серверов, вы можете использовать Nirvana from my-Channels в качестве промежуточного программного обеспечения для обмена сообщениями. Проверьте Nirvana на my-Channels и на их сайте-витрине. (извините, я новый пользователь и не могу отправлять ссылки):
Alex
Одно гораздо более простое и мощное решение на сайте http://www.udaparts.com/document/Tutorial/slpush.htm
РЕДАКТИРОВАТЬ: он действительно работает нормально. Меня сильно укусила «скрытая переменная» в закрытии: (
Я использовал PollingDuplex для SL2 и думаю, что он еще не готов к производству.
Моя главная проблема заключается в том, что он не различает на клиентах на одном компьютере. Если я запустил 2 клиента, то один из них больше не сможет опрашивать сервер и умрет из-за тайм-аута. Для двух клиентов существует идентификатор SessionId, но он просто игнорируется на клиентская сторона.
Аналогичным образом, если я убиваю клиента, а затем создаю нового, то новый клиент некоторое время будет получать push-обновления от предыдущего клиента.
Сталкивался ли кто-нибудь с такими же проблемами или они исправлены в SL3?
На самом деле я запустил еще несколько демонстрационных кодов и понял, что по какой-то причине вам нужно указать InstanceContextMode и InstanceMode, чтобы служба была основана на сеансе, а не на синглтон (насколько я могу судить). В простом демонстрационном коде, который я использовал, есть явные проблемы с производительностью.
Очень жаль, что это поведение не было задокументировано.
Я просто хотел уточнить, что PollingDuplexHttpBinding не реализует «истинные» push-уведомления, поскольку раскрывает его имя (опрос). Из документации msdn :
При настройке с этой привязкой клиент Silverlight периодически опрашивает службу на сетевом уровне и проверяет наличие новых сообщений, которые служба хочет отправить по каналу обратного вызова. Служба ставит в очередь все сообщения, отправленные по каналу обратного вызова клиента, и доставляет их клиенту, когда клиент опрашивает службу.
Однако это более эффективно, чем традиционный способ опроса веб-службы, поскольку после каждого опроса сервер будет держите канал открытым в течение определенного времени (скажем, 1 минуту), и если сообщение приходит в это время, оно напрямую «проталкивает» сообщение клиенту. Клиент должен многократно обновлять соединение, так сказать, опрашивает сервис.
Если вы хотите реализовать настоящие push-уведомления с помощью silverlight, я считаю, что вам нужно работать с сокетами, и я рекомендую прочитать некоторые сообщения в блоге Дэна Валина на эту тему.