2016-04-07 7 views
0

一部の部分では、Pahoクライアント・ライブラリーを介してMQTTと対話する必要があるREST APIインターフェースを開発しています。デザインによって、PAHOクライアントは、メッセージごとに一つだけのコールバックを受信することができます:Paho JavaライブラリーでMQTTメッセージを処理するためのベスト・プラクティス

mqttClient = new MqttClient(MQTT_ADDRESS, MQTT_CLIENT_ID); 
mqttClient.setCallback(new MqttCallbackImpl()); 
... 
private static class MqttCallbackImpl implements MqttCallback { 

    @Override 
    public void connectionLost(Throwable cause) { } 

    @Override 
    public void messageArrived(String topic, MqttMessage message) throws Exception { 
     switch(topic) { 
      // Endless list of cases... 
     } 
    } 

    @Override 
    public void deliveryComplete(IMqttDeliveryToken token) { } 
} 

は私が受信したメッセージを処理するために「正しい」方法を考え出すに苦労し、それに応じて反応しています - 私は回避することにより、私のコールバックを書くだろうかペイロードの一部またはトピックの巨大なスイッチ()?

+0

if/switchステートメントが問題となる十分なトピックを購読しているユースケースは何ですか?あなたはどこかでフィルタリングをしなければなりません – hardillb

+0

トピックについて気にしないでください:ペイロードのいくつかの情報をチェックするときにも疑問が残っています –

答えて

2

短い答え:大きなif/switch文が解決策です。

ペイロードに基づいて決定する必要がある場合は、ペイロードを何かに関わらず解析する必要があります。トピックに基づいてペイロードタイプをフィルタリングすることができれば、ペイロード解析を手渡して、メソッドを分離することで、単純化することができます。

+0

オクラホマ、私の質問はあまりにも愚かではなかったようです...いくぶん安心: –

2

ディスパッチMapを使用して、if/switchステートメントを回避できます。

要件に基づいてさまざまな具象クラスを実装し、適切なインスタンスに各トピックをマップすると

interface MqttMessageProcessor { 
    void processMessage(String topic, MqttMessage message) throws Exception; 
} 

あなたのペイロードを処理するために(これもfunctional or Single Abstract Method interfaceです)シンプルなインターフェイスを定義します。メッセージが到着すると、正しいハンドラにディスパッチされます。あなたがJava8を使用している場合

Map<String,MqttMessageProcessor> dispatchMap = new HashMap<>(); 
dispatchMap.put("topic1", new Payload1MessageProcessor()); 
dispatchMap.put("topic2", new Payload2MessageProcessor()); 


@Override 
public void messageArrived(String topic, MqttMessage message) throws Exception { 
    dispatchMap.get(topic).processMessage(topic, message); 
} 

、あなたは一般的なハンドラをしたい時に簡単にケースを処理するためにMap.getOrDefaultメソッドを使用することができます。

@Override 
public void messageArrived(String topic, MqttMessage message) throws Exception { 
    dispatchMap.getOrDefault(topic, generalMessageProcessor).processMessage(topic, message); 
} 

これは新しいトピックやペイロードフォーマットが追加されたときにのみ、巨大な場合/他の滝へのコードの代わりに、掘りの行を追加する必要があるとして、維持することが容易です。

ペイロードプロパティに基づいてメッセージをディスパッチする必要がある場合も同様です。 messageArrivedコールバックでペイロードを解析し、ディスパッチマップを使用します。 if文これは醜いせずにメッセージハンドラを分離するためのお手伝いをする必要があり

client.subscribe(topic, new IMqttMessageListener() { 

     @Override 
     public void messageArrived(String topic, MqttMessage message) throws Exception { 
      // do something 
     } 

}); 

:私はあなたがが実際にサブスクリプションごとに別々のリスナー、例えばを持つことができることを発見するまで、

0

ディスパッチマップは、私には良いアイデアのように思えました。

関連する問題