Один уважаемый человек проработал учебный пример по обратным вызовам (callbacks) и инициировал его модификацию на тему "чистый callback со стороны сервера".
Любителям сразу получить по-полной рекомендуется загрузить нафаршированный фичами пример с центрального хранилища. Загружать его надо непосредственно из Delphi IDE способом, описанном в упомянутом выше уроке.
Но мне, как бывшему (?) Delphi-тренеру более по душе поэтапное знакомство, когда ты не копипастишь чужие наработки, а именно символ за символом вбиваешь код в среду (и мозг). Поэтому давайте по-тихому (кто еще не сделал) всё-таки выполним пример на обратные вызовы и также медленно научим сервер самостоятельно вещать в полностью асинхронном режиме (для чего как раз и нужны heavy-weight callbacks).
Постановка задача (не моя): таймер на сервере, который оповещает клиентов вызовом клиентского метода (что и есть callback).
В раннем DataSnap что-то как-то было сложно с тем, чтобы нагрузить серверное приложение интерфейсными элементами. Сейчас с этим просто: добавляем на серверную форму компонент TButton и запланированный TTimer. Кнопка - чтобы запустить таймер с вполне тривиальным кодом:
Timer1.Enabled := not Timer1.Enabled; // в design-time таймер Enabled = fasle
На событие таймера напишем тоже что-нибудь простое, но ёмкое:
ServerContainer1.DSServer1.BroadcastMessage(
"DelphiLabsChannel", // название канала, куда будет вещание
TJSONString.Create("This is a message, triggered by timer") // посылаем в формате JSON
)
Тогда при запущенном сервере и клиенте (именно в такой последовательности) нажатие на кнопку пустит таймер, таймер через умолчательную секунду сделает broadcast по клиентам, подключенным к указанному каналу (первый параметр).
Где на клиенте поискать название канала?
Выбираем компонент (уже выбранный на рисунке) и ищем в инспекторе объектов.
А как сообщить серверу, "в какой" канал нужно вещать? Можно, конечно, вызвать специально созданный метод на сервере, заставив сервер запомнить данное имя. Если вы будете запоминать название канала в каком-нибудь поле класса серверных методов, то помните, что LifeCycle объектов бывает разный (материал урока о жизненных циклах).
Но забудем о жизненных циклах и не будем вообще думать о сообщении серверу название канала. Подумаем о том, что, вероятно, целесообразно изначально спроектировать систему обмена сообщениями между клиентами и сервером на базе системы каналов вещания. Что-нибудь лёгкое типа:
- Канал оповещения о блокировках
- Канал оповещения о критической загрузки сервера
- Канал сообщений о принудительных обновлениях
- Канал сообщений о желательных обновлениях
- Чат-канал
- …
… в таком случае названия каналов уже жёстко прошиты и ничего сообщать не надо. Вообще, приятно, что в новой DataSnap XE все хранится в строках: ChannelName, CallbackName, ClientName.
(прошу прощение за излишнюю подробность - инстинкт тренера :))