Jul 26 2010

Avoiding Tight Hardware Coupling

Category: Mobile | ProgrammingJoel Ivory Johnson @ 11:24

As a Software Engineer I'm interested in how tightly coupled that one piece of code is to another. Coupling is the amound of dependencies that one entity has on another and tightly coupled code tends to be less portable and adaptable. But the concept of coupling doesn't stop at software. Coupling is also applicable to the relationship between hardware and software and I'm interested in avoiding tight coupling between the hardware and software for my code too.

With real implementations of Windows Phone 7 devices floating around it would be easy for some one to attempt to write an application that is tightly couple to that implementation. In some cases these low risk associated with doing this; for example if one tightly couples to screen resolutions (and there will only be two screen resolutions) it could be some time before some one needs to address another screen resolution. I'm writing a piece of code that is going to be sensative to the sampling rate of the accelerometer. And easy but tightly coupled way to handle this would be to measure the sample rate of the accelerometer and then write my code accordingly. But if I do this then I assume quite a few things. I would be assuming that other phones have the same sample rate. I would assume that the same phone will always have the same sample rate. I don't know that either of these assumptions are true.

The time information returned in the from DateTime.Now is precise enough for me to perform the measurements that I needed. So I wrote a quick application that would measure the accelerometer sample frequency and display it in a text box.

Here is my initial code

       private Accelerometer _accelerometer;

        // Constructor
        public MainPage()
        {
            InitializeComponent();
            this.DataContext = this;

            _accelerometer = new Accelerometer();
            _accelerometer.ReadingChanged += new EventHandler(_accelerometer_ReadingChanged);
            _accelerometer.Start();
        }

        void _accelerometer_ReadingChanged(object sender, AccelerometerReadingEventArgs e)
        {
            DateTime previousUpdate = LastUpdate;
            LastUpdate = DateTime.Now;
            double period = LastUpdate.Subtract(previousUpdate).TotalSeconds;
            double frequency = 1.0/period;
            if (frequency > HighestFrequency)
                HighestFrequency = frequency;

        }

        
// LastUpdate - generated from ObservableField snippet - Joel Ivory Johnson
  private DateTime _lastUpdate;
  public DateTime LastUpdate
  {
    get { return _lastUpdate; }
      set
      {
          if (_lastUpdate != value)
          {
              _lastUpdate = value;
              OnPropertyChanged("LastUpdate");
          }
      }
  }
 //-----      
// HighestFrequency - generated from ObservableField snippet - Joel Ivory Johnson
  private double _highestFrequency;
  public double HighestFrequency
  {
    get { return _highestFrequency; }
      set
      {
          if (_highestFrequency != value)
          {
              _highestFrequency = value;
              Dispatcher.BeginInvoke(() => { OnPropertyChanged("HighestFrequency"); });
            
          }
      }
  }
 //-----


        void OnPropertyChanged(string propertyName)
        {
            if(PropertyChanged!=null)
            {
                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
            }
        }

        #region INotifyPropertyChanged Members

        public event PropertyChangedEventHandler PropertyChanged;

        #endregion
    }

Ofcourse there may be those that are curious as to what value a real device will currently returned. Of course publishing that type of information could result in more tightly coupled code being written. I'll post more once the code I am writing is done.

Tags: ,

Comments