2015-04-23 1 views
2

кода, я использую:Есть ли какие-либо улучшения надежности Wearable.MessageApi.sendMessage? Это примерно так же последовательно, как кошка

client.blockingConnect(); 
    try { 
     Wearable.MessageApi.sendMessage(client, 
        nodeId, path, message.getBytes("UTF-16")); 
    } catch (UnsupportedEncodingException e) { 
     e.printStackTrace(); 
    } 
    client.disconnect(); 

переменного путь, и сообщения являются строки, которые содержат только то, что они названы в честь, и клиент, и NodeId устанавливается с этим кодом (который с последней версией Android Wear необходимо изменить слишком вмещать несколько устройств, но не актуальный вопрос я работаю):

  client = new GoogleApiClient.Builder(context) 
        .addApi(Wearable.API) 
        .build(); 

      while (nodeId.length() < 1) { 
       client.blockingConnect(); 
       Wearable.NodeApi.getConnectedNodes(client).setResultCallback(new ResultCallback<NodeApi.GetConnectedNodesResult>() { 
        @Override 
        public void onResult(NodeApi.GetConnectedNodesResult nodes) { 
         for (Node node : nodes.getNodes()) { 
          nodeId = node.getId(); 
          //nodeName = node.getDisplayName(); 
          haveId = true; 
          status = ConnectionStatus.connected; 
         } 
        } 
       }); 
       client.disconnect(); 

проблема у меня иногда это работает, иногда быстро , и в других случаях после долгой задержки, а иногда и вовсе. Приливы, фаза луны, влажность, бабочки хлопают по другую сторону света, не знаю, какие изменения. Android wear сообщает, что устройство всегда подключено. Иногда сообщения имеют одинаковые значения, но их все равно нужно обрабатывать отдельно, потому что, когда они происходят, важно, чтобы часы или мобильный ответ отвечали.

Есть ли способ улучшить надежность?

Я пробовал:

 sendMessage(String.valueOf(System.currentTimeMillis()), "wake up!"); 

Но не проходят иногда либо.

+0

Просто добавьте: я просто прочитал, что sendMessage не может быть запущен в потоке ui, однако я вызываю его из отдельного потока, поэтому я думаю, что это можно исключить, поэтому никто не тратит время на Это. – netsplit

ответ

1

Нет, MessageApi по своей сути ненадежно. Думайте об этом как UDP. Вы можете использовать его, если хотите быстро отправить сообщение, и вы не возражаете, что он потерпит неудачу, потому что вы можете повторить его (например, пользовательские переключатели отслеживают в вашем музыкальном приложении - либо он работает, либо ему придется нажать).

Если вам нужна надежность, используйте DataApi. Это медленнее, но гарантирует постоянную согласованность.

Если вы хотите как скорость, так и гарантированную доставку, используйте оба подхода - отправьте сообщение и установите элемент данных с тем же токеном. Если сообщение получено, сохраните токен и проигнорируйте элемент данных позже. Если нет, элемент данных, наконец, вызовет действие.

РЕДАКТИРОВАТЬ Документ утверждает, что сообщения будут доставлены к узлу, только если узел подключен:

сообщения доставляются к подключенным узлам сети. Сообщение считается успешным, если оно поставлено в очередь для доставки на указанный узел . Сообщение будет помещено в очередь только в том случае, если указанный узел связан с . DataApi следует использовать для сообщений для узлов, которые в настоящее время не подключены (для доставки по соединению).

+0

Спасибо! Это значительно улучшает их роли. – netsplit

+0

@gruszczy: Говорит ли где-нибудь в документации разработчика, что MesageApi ненадежен (по дизайну)? Или это просто наблюдение? – Gant