Push 要求の要件は、Mobile Link サーバーがデバイスとの通信に使用している方法によって異なります。すべての Push 要求に、subject カラムと content カラムが必要となります。
ライトウェイトポーラーを使用して Push 通知をポーリングする場合は、poll key カラムを作成して Push 通知を識別できるようにします。
ゲートウェイを使用して Push 通知を送信する場合は、gateway カラムと address カラムを作成する必要があります。
システムに Push 要求カラムがある場合は、カラムを作成する必要はありません。Push 要求の要件が満たされると、Push 要求を使用できます。 Push 要求の使用を参照してください。
ライトウェイトポーラーを使用して Push 通知をポーリングする場合は、次のカラムを作成します。
カラム | 型 | 説明 |
---|---|---|
Poll key |
VARCHAR |
ライトウェイトポーラーを識別するために使用するキー。各ライトウェイトポーラーはユニークなキーを送信して、Mobile Link サーバー上で自身を識別します。 |
Subject |
VARCHAR |
メッセージの件名の行です。 |
Content |
VARCHAR |
メッセージの内容。 |
特に指定がないかぎり、ゲートウェイを使用して Push 通知を送信する場合は、次のカラムを作成してください。
カラム | 型 | 説明 |
---|---|---|
Request ID |
INTEGER |
オプション。Push 要求のユニークな ID。 一部の Notifier イベントでは、このカラム名が必須です。 Notifier イベントを参照してください。 |
Gateway |
VARCHAR |
メッセージの送信先ゲートウェイの名前。 |
Subject |
VARCHAR |
メッセージの件名の行です。 |
Content |
VARCHAR |
メッセージの内容。 |
Address |
VARCHAR |
デバイスの送信先アドレス。 |
Resend interval |
VARCHAR |
オプション。メッセージが再送される時間間隔。 resend interval は、信頼性の低いネットワークで UDP ゲートウェイを使用する場合に便利です。Notifier は、Push 要求に関連付けられたすべての属性が変更されないことを前提としています。要求を最初にポーリングした後、後続の更新は無視されます。次のポーリング時刻の前に Push 通知を送信する必要がある場合、Notifier は次のポーリング間隔を自動的に調整します。Push 要求の送信を停止するには、request_cursor イベントで同期論理を使用します。対象 Mobile Link Listener から受信確認が届くと、次の再送は停止されます。 request_cursor イベントを参照してください。 |
Time to live |
VARCHAR |
オプション。再送の有効期限が切れるまでの時間です。 |
次の例では、SQL Anywhere 統合データベースのテーブルで必要なカラムを作成して、ライトウェイトポーリングを使用する場合の Push 要求の要件を満たします。
CREATE TABLE PushRequest ( req_id INTEGER DEFAULT AUTOINCREMENT PRIMARY KEY, poll_key VARCHAR(128), subject VARCHAR(128), content VARCHAR(128) ) |
このようなテーブルの作成が必要になるのは、Push 要求のカラムが他の場所で使用できない場合のみです。Push 要求のカラムは、複数のテーブル間、既存の複数のテーブル、または 1 つのビューに作成できます。
![]() |
DocCommentXchange で意見交換できます
|
Copyright © 2012, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.1 |