title: Android Bluetooth periodic calls to inputStream and outputStream: inconsistent timestamps
body: <p>Two bluetooth enabled devices are connected.  One sends a periodic timestamp (writeTime) through outputStream to the other, which retrieves the writeTimes via inputStream and attaches its own timestamps (readTime) for comparison.  My goal is to make the readTime equal to the writeTime for each loop. The code below causes the writeTimes to increment with a predetermined delay (3 seconds), but the readTimes do not increment.  The readTimes are fixed at the moment when the two devices connect to one another. Here are snippets of the outputStream.write and inputStream.read along with sample results.</p>
  
  <p>For the sending device: Loop within a timer having three-second delays between writes to the outputStream: There is a CountDownTimer driving the onTick</p>
  
  <pre><code>    public void onTick(long millisUntilFinished) {
          Calendar calendar = Calendar.getInstance();
          SimpleDateFormat mdformat = new SimpleDateFormat("HH:mm:ss");
          String thisTime = mdformat.format(calendar.getTime());
          tV.setText("Current Time: " + thisTime);  // thisTime  increments on the display in real time.
          try {
              thisTime=thisTime+ "^";  // "^" added as the end of a line
              outputStream.write(thisTime.getBytes(Charset.forName("UTF-8")));
          } catch (IOException e) {}
  </code></pre>
  
  <p>For the receiving device: A read loop (iloop) that iterates the same number of times as the write loop from the sender:</p>
  
  <pre><code>        for (iloop =1;iloop&lt;6;iloop++) {
              inputStream = socket.getInputStream();
              byte[] inbyte = new byte[1];
              int inbuffer;
              BufferedReader br = new BufferedReader(new InputStreamReader(inputStream, "UTF-8"));
              writeTime = "";
              eol = false;   
              do {
                  inbuffer = br.read();
                  if (inbuffer != 94) { // character "^" (byte 94) triggers an end-of-line for each read.
  
                      ByteArrayOutputStream bos = new ByteArrayOutputStream();
                      DataOutputStream dos = new DataOutputStream(bos);
                      dos.writeInt(inbuffer);
                      inbyte = bos.toByteArray();
                      next = new String(inbyte, "UTF-8");
                      writeTime = writeTime + next;
                  } else {eol = true;}
  
              } while (!eol);
              readTime = mdformat.format(calendar.getTime());
              readarray[iloop] = "\r\n" + writeTime + "  " + readTime ;
          }
      }
  </code></pre>
  
  <p>Screenshot of readarray after it is written: (a loop of five rows with 3 second delay between writes):</p>
  
  <pre><code>14:44:12  14:44:02
  14:44:15  14:44:02
  14:44:18  14:44:02
  14:44:21  14:44:02
  14:44:24  14:44:02
  </code></pre>
  
  <p>Conclusion: The inputStream is being read with a timestamp equal to the beginning of the socket connection.
  (In the example output, I waited ten seconds after connecting before intitiating the write to the outputStream). How do I get readTime to reflect the writeTime?  My ultimate goal is to read from an inputStream at a periodic rate rather than batch processing a large number of small reads within a single batch. I want to access each read in real time and know when the read took place.</p>
  
  <p>Update on this post:
  I took the insight from Ole VV and simply moved the following three lines of code from OUTSIDE the read loop (iloop) to INSIDE the iloop just above readTime</p>
  
  <pre><code>  Calendar calendar = Calendar.getInstance();
    SimpleDateFormat mdformat = new SimpleDateFormat("HH:mm:ss");
    String strDate;
  </code></pre>
  
  <p>This solved the problem.  I should have understood that calendar is an instance of Calendar whose characteristic, calendar.getTime(), does not change with the ticking of the clock.
  The outdated SimpeDateFormat was not at fault although Ole VVs suggestion to replace it might be useful in other applications.</p>