Rosher Consulting

Software Consulting and Development Services

Ride Journal v1.1.7

The next update to Ride Journal has just been be submitted to the Windows store. This update was originally going to contain a couple of changes requested by users; the ability to customise the main stats and improve the calorie calculation but has ended up containing quite a few changes, read on to find out more.

Customise Main Stats

This one has been on my list for a while and has been requested by a number of users. In fact, it’s currently second on the list on the support site.

The work on this feature took a little longer than I was expecting due to having to re-write parts of the code to support it and it was further complicated by having to support BLE sensors. For instance, if you’re using a Speed/Cadence sensor, then the speed and distance stats are based on the sensor, however if the sensor was to disconnect during your ride, the stats switch over to the GPS data and likewise if the sensor reconnects, it will switch back to the sensor data.

To customise your stats you just need to go to Settings->Display and then choose what stat you would like in each position. The stats are ordered top to bottom in Settings, which corresponds to left to right when in use.

SettingsCustom stats

This is just the first step on adding more customisation to the app, I’m planning to gradually introduce more control in the next few versions.

Improve Calorie Calculation

A user contacted me recently to say that the calories burnt during a ride was much lower than those reported by services such as Strava, Training Peaks etc. My response to this was that Ride Journal calculates calories based on your heart beat every second, whereas many other services base this either on 1 minute average heart rate or the average heart rate for the entire ride, so in some respects Ride Journal was trying to be as accurate as possible.

What I did agree with however, is that consistency is important, so while various apps and services will all use their own algorithms to calculate calories, generally the results are quite similar, allowing you to be confident with what you’re seeing, so with this in mind I have re-worked the calorie calculation in Ride Journal.

I’ve tried various different algorithms and compared the results to the values Strava gives me, mainly because Strava is one of the most popular sites with cyclists and the site where I upload my rides to. Ultimately I have found that computing calories based on the overall average heart rate yields the most consistent values with Strava and so this is the algorithm I have implemented in this version.

Ride Journal CaloriesStrava Calories

It goes without saying that you need to configure your gender, weight and date of birth in Settings, otherwise you’ll get wildly different results.

Import Strava Routes

Back in December 2015 Strava finally added the ability to query and download routes via their API, so you now no longer need to jump through a few hoops to get these routes in to Ride Journal.

As with other import add-ins, Strava now appears in the Import list, once selected it will pull down the list of routes you’ve created in Strava, allowing you to then download them directly to the app.

Note: this feature has been added to the existing Strava add-in, so if you’ve purchased this, All Online Services or All Add-ins then you will be able to use this new feature.

Import from Strava

Export to

A new export add-in has been created allowing you to export your rides and workouts to

Here’s a few reasons why you might want to use directly from their website:

  • Power & Simplicity  - SportTracks is known for its intuitive and easy‑to‑use interface, yet it provides every powerful tool required by serious athletes.
  • Exclusive Features - There are many innovative features in SportTracks that simply aren't available in competing platforms, such as customizable layouts and the Personal Records Timeline.
  • Fast Customer Support - The majority of SportTracks users never need help, but you can be assured that we will be available quickly if you need us.
  • Proven & Reliable - SportTracks has remained a leader in fitness tracking and analysis for over 10 years. You can count on us to keep your data secure and to run seamlessly for the long haul.
  • Full Compatibility - SportTracks works perfectly with most GPS watches, bike computers, and mobile fitness apps. Plus, you can easily sync it with your personal calendars and email accounts.

This is a paid for add-in, however if you’ve purchased All Online Services or All Add-ins, then this add-in is included in those and is a free upgrade.

SportTracks Add-inUploadSportTracks Workout

Add-in License Caching

Every time the app starts up, it loads the add-in license information from the Windows store to determine which add-ins you’ve purchased and can use. If however you don’t have a network connection, then the app would previously assume you haven’t purchased any add-ins and you wouldn’t be able to use them, which for something like the sensors add-in, isn’t very useful if you’re in the middle of nowhere when you start your ride.

The app will now save the license information locally and will use this local store if no network connection is available, so now you can use the sensors add-in whether you have a network connection or not.

GPS Signal Timeout

When you start a ride, the app looks for a GPS signal, unfortunately there was previously no time-out on this, so the app would get stuck in the “Locating…” state until the GPS was locked.

The app will now timeout after 20 seconds, allowing you to start your ride (and record any BLE sensor data), it will continue to search for a GPS signal in the background, starting to record your location when a signal is found.

What’s New

When you first run Ride Journal after an update, it will now display the changes that have been made in this version.

What's new

As always, if you have any suggestions for new features or you’ve encountered any bugs then you can submit them to the support site.

Ride Journal v1.1.4

The next update to Ride Journal is almost ready to be submitted to the Windows store. Unlike the last few updates that mainly concentrated on bug fixes, this version contains two new features as requested by users.

Merging Journal Entries

The first new feature is the ability to merge multiple journal entries together to create one new entry that you could then upload as one single ride to Strava for instance. This is useful for those days where you go for a nice long ride, stop off for coffee or lunch somewhere, stop the app recording and then start a completely new recording when you head home.

The following screen shots show the feature in action:


There are a couple of caveats with this feature:

  • The recordings have to be the same type i.e. either GPS or Turbo Trainer
  • The recordings have to have been made on the same day

Once the recordings have been merged, a new entry will appear in the list with the same date and time as the first recording, albeit with “merged” displayed so you can distinguish the new entry from the original. The original recordings will not be deleted automatically, these are kept in case anything goes wrong with the merge. Of course, once you’re happy that the merge has been successful, you can delete the original recordings yourself.

Customise Display Stat Size

This one has been on my todo list for a long time and after a user requested it again a couple of weeks ago I thought that I should finally get around to doing it!

There are now three new sizes to choose from; small, medium and large, with small being the same size as in the previous version, which you can change from the “Display” section within “Settings” as below:


The following screenshots show the effect of each setting on the map stats:


And the following screenshots show the effect of each setting on the training stats:


Another small change that you may have noticed here with the Heart Rate stat is that the background colour now shows your current heart rate zone (as configured within settings). Previously the text colour changed to reflect your zone, however I didn’t feel this was clear enough, hence the change.

As always, if you have any suggestions for new features or you’ve encountered any bugs then you can submit them to the support site.

Using multiple Solr URLs with SolrNetFacility and Castle Windsor

The current project I’m working on involves moving the generation of various product feeds from a console application into a new administration website that uses HangFire to schedule when these feeds should generate, so we’ve gone from setting up our IoC container individually for each feed in a console app, to setting it up once for all feeds in a website and this is where we’ve hit the problem of configuring the SolrNetFacility as some feeds talk to our live Solr index and some talk to our staging Solr index.

The Solr docs contain some information on this with their Multi-core / multi-instance documentation page, however they don’t quite give a full example, for instance this is how they resolve a specific Solr instance:

ISolrOperations<Product> solrProduct1 = container.Resolve<ISolrOperations<Product>>("core0-id"); // use proper Windsor service overrides instead of resolving like this

Their own comment says that you should use service overrides instead of resolving as in the example, but it would be nice if they could give an example service override.

If you Google for answers you’ll come across various posts asking the same question, which while in this example, the maintainer of Solr.NET is the one actually answering (and he does in fairness provide the correct answer), he still doesn’t elaborate over and above the documentation, which may seem pedantic but if you’re going to give an example at least give one that is complete.

Additionally, in our case we’re using ISolrReadOnlyOperations<> rather than ISolrOperations<> as in their example, so it wasn’t immediately obvious if we could do a service override or whether we would have to switch to ISolrOperations<> instead. However a quick look at the source code for the SolrNetFacility over on GitHub helped clarify how the multi-core / multi-instance setup works.

How to implement multiple Solr URLs

Firstly, as per the Solr.NET example, you need to set up your SolrNetFacility and then register your cores/instances (note: the URLs for each core do not need to be on the same server or same port):

var solrNetFacility = new SolrNetFacility("http://localhost:8983/LiveSolr");
solrNetFacility.AddCore("live", typeof(Product), "http://localhost:8983/LiveSolr");
solrNetFacility.AddCore("staging", typeof(Product), "http://localhost:8983/StagingSolr");
container.AddFacility("solr", solrNetFacility);

The documentation implies that the URL passed in to the constructor becomes the default, however in my testing the first core added becomes the default and this is what Castle Windsor will resolve and pass in to your classes, which means that the URL you pass in to the constructor also needs to be added as the first core, so that this becomes the default.

Once you’ve setup the separate cores/instances, you need to setup your service overrides.

As I’ve previously said, we use ISolrReadOnlyOperations<> as opposed to ISolrOperations<>, the underlying class that implements these two interfaces is the same, so Castle Windsor will resolve the correct Solr instance when we specify the dependency as ISolrReadOnlyOperations<>, like so:

        Dependency.OnComponent(typeof(ISolrReadOnlyOperations<Product>), "staging"),

If you then run your app and debug into the creation of “MyFeed” you’ll see that the Solr connection passed in to your class is the one you’re expecting.

Angular Tips: Measuring Rendering Performance

Recently I’ve had to try and improve the performance of a page that had too many watches, specifically I had a table where each row was generated with an ‘ng-repeat’ and then within each row I had a ‘select’ element whose options were also generated with an ‘ng-repeat’. The ‘select’ had around 200 options with a binding for both the value and text, the number of rows varied but probably averaged around 5 and each row had a few bindings itself, so tally that up and you’re looking at over 2000 bindings, which when combined with the rest of the page was quite simply too much.

There are many ways of improving the performance of this page but before attempting any changes I wanted to be able to measure the rendering performance, so that I would then have something to compare my changes to.

I’d previously read the blog post from Scalyr on improving Angular rendering performance and in this post they mentioned that they ‘detected the finish of the $digest cycle’ in order to measure the rendering performance. I was curious how they did this and nothing obvious popped up in my searching, however I then noticed a question in the comments, which Scalyr responded to that pointed me in the right direction, I quote:

‘The approach we used was to use a $provider decorator on the $rootScope service to monkey patch $rootScope.$digest. In the override method, we simply record the start time, invoke the original $digest method, and then capture the end time.’

From this I was able to determine that I needed to override the regular ‘$digest’ method and replace it with my own, so I came up with the following simple override:

   1:  angular.module('myApp').run(['$rootScope', function($rootScope) {
   3:              var $oldDigest = $rootScope.$digest;
   4:              var $newDigest = function() {
   5:                  console.time("$digest");
   6:                  $oldDigest.apply($rootScope);
   7:                  console.timeEnd("$digest");
   8:              };
   9:              $rootScope.$digest = $newDigest;
  10:          }])

This will call 'console.time' when the ‘$digest’ starts and 'console.timeEnd' when it finishes, which allowed me to see how long each render of the DOM takes. Combined with some logging in my controller I was then able to see that after my data had been loaded from the server it took around 3-4 seconds to render this to the page and for the page to be ready for input.

With some useful measurements to hand, I could now begin the process of making some improvements.

Angular Tips: Displaying an Ajax loading spinner using a custom Interceptor

I think one of the reasons Angular has become so popular, so quickly is because it has a series of conventions that make extending it really easy.

A common requirement for any UI is to let the user know when something is happening, such as when making ajax calls to the server and a common way to do this is to display a spinner. Prior to using AngularJS I would have handled this by creating my own module for talking to the server and then all other modules would have had to call this module, nothing wrong with this approach at all, but Angular already has its own module for dealing with ajax requests: ‘$http’, so we don’t really want to re-invent the wheel and create another module to sit on top of this.

This is where Angular’s extensibility comes in as we can handle this by hooking into Angular’s ‘$http’ service by creating our own interceptor, which allows us to intercept the request to the server, display the spinner, handle the response back and hide it again

Here’s a template for a custom interceptor that displays an ajax spinner when a request starts and hides it when the request finishes:

   1:  var App = angular.module('myApp', []).
   2:      config(['$httpProvider', function ($httpProvider) {
   4:          $httpProvider.interceptors.push('myHttpInterceptor');
   6:      }]).factory('myHttpInterceptor', ['$q', function ($q) {
   7:          var numRequests = 0;
   8:          var ajaxSpinner = $("#ajaxSpinner");
   9:          var hide = function (r) {
  10:              if (!--numRequests) {
  11:                  ajaxSpinner.hide();
  12:              }
  13:              return r;
  14:          };
  16:          return {
  17:              'request': function(config) {
  18:                  numRequests++;
  19:        ;
  21:                  return config;
  22:              },
  24:              'response': function(response) {
  25:                  return hide(response);
  26:              },
  28:              'responseError': function(response) {
  29:                  return $q.reject(hide(response));
  30:              }
  31:          };
  32:    }]);

This is pretty straightforward and adds a nice effect to our UI, but we can also take this a step further.

Whenever I want to send messages back from the server indicating success or failure I always send a standard object back, such as:

   1:  {
   2:      Error: true,
   3:      Message: 'An error occured saving XYZ'
   4:  }

Now I could handle this at the point I make the call, but since this is a standard message, this seems like a perfect fit for our custom interceptor.

The following code not only shows and hides our ajax spinner, it also checks the response and if necessary displays an alert to the user, saving us from having to handle this everywhere in our code:

   1:  var App = angular.module('myApp', []).
   2:      config(['$httpProvider', function ($httpProvider) {
   4:          $httpProvider.interceptors.push('myHttpInterceptor');
   6:      }]).factory('myHttpInterceptor', ['$q', function ($q) {
   7:          var numRequests = 0;
   8:          var ajaxSpinner = $("#ajaxSpinner");
   9:          var hide = function (r) {
  10:              if (!--numRequests) {
  11:                  ajaxSpinner.hide();
  12:              }
  13:              return r;
  14:          };
  16:          return {
  17:              'request': function(config) {
  18:                  numRequests++;
  19:        ;
  21:                  return config;
  22:              },
  24:              'response': function(response) {
  25:                  if (response && && && 
  26:                 === true && {
  27:                      alert(;
  29:                      return $q.reject(hide(response));
  30:                  }
  32:                  if (response && && === false && 
  33:                 {
  34:                      alert(;
  35:                  }
  37:                  return hide(response);
  38:              },
  40:              'responseError': function(response) {
  41:                  if (!response)
  42:                      return $q.reject(hide(response));
  44:                  if ( && && 
  45:                 === true && {
  46:                      alert(;
  47:                  } else {
  48:                      alert('Sorry, there was an error.');
  49:                  }
  51:                  return $q.reject(hide(response));
  52:              }
  53:          };
  54:    }]);

This is just a couple of examples of what we can do with a custom interceptor to help remove boilerplate from our code and hopefully it’s given you some ideas for your own code.

Angular Tips: Adding functionality to existing directives

One of the features I really like in Angular, which is not that well known is the ability to create new directives with the same name as existing ones and thereby add some new functionality to them.

When you register two directives with the same name, Angular doesn’t complain, it merely runs those directives in the order they were registered. A common scenario I use this for is to create my own ‘ng-click’ directive to provide some feedback to the user when they click a button, such as disabling it while waiting for an Ajax request to complete.

With the above scenario, if you were to look on Stack Overflow for questions about this, the most common answer would be to create your own directive, say ‘my-own-click’ and use that instead of the standard ‘ng-click’. The downside with this is that you have to re-implement the standard ‘ng-click’ functionality and you have to remember to use your ‘my-own-click’ directive everywhere. If you’re working in a team, this then means all of your co-workers also need to know to use this new directive.

A Better Approach

The following is the basic template I use in my projects to add some feedback to my buttons when an action occurs. The directive requires that you also attach an ‘ng-model’ to your button so that it can use the model variable to know when the action starts and ends:

   1:  angular.module('MyApp').directive('ngClick', function () {
   2:      return {
   3:          restrict: 'A',
   4:          link: function (scope, element, attrs) {
   5:              if (attrs.ngModel) {
   6:                  var el = element.find("span");
   7:                  var cls = el.attr("class");
   9:                  scope.$watch(attrs.ngModel, function (newValue, oldValue) {
  10:                      if (newValue) {
  11:                          if (el.length) {
  12:                              el.attr("class", "glyphicon glyphicon-refresh fa-spin");
  13:                          }
  14:                          element.attr("disabled", true);
  15:                      } else {
  16:                          if (el.length) {
  17:                              el.attr("class", cls);
  18:                          }
  19:                          element.attr("disabled", false);
  20:                      }
  21:                  });
  22:              }
  23:          }
  24:      };
  25:  });

The directive itself does a bit more than just disable the button, it also looks to see if the button contains a child ‘span’ element and if it does, it assumes this is a Glyph Icon as used by Bootstrap and then changes the class of the ‘span’ to the Refresh icon and also uses the ‘fa-spin’ class from Font Awesome to rotate the icon, thereby actively showing the user that their action has caused something to happen.

Here’s the appropriate HTML to use this directive:

   1:  <button class="btn btn-primary" ng-click="save()" ng-model="saving">
   2:      <span class="glyphicon glyphicon-floppy-save"></span>
   3:      Save
   4:  </button>

And the ‘save’ function in your controller (this is calling a save method on a service which returns a promise, so we’re handling both the success and failure of the promise and updating the model variable appropriately):

   1:  $ = function () {
   2:      $scope.saving = true;
   3:$ {
   4:          $scope.saving = false;
   5:      }, function() {
   6:          $scope.saving = false;
   7:      });
   8:  };

As you can see, as long as you update the appropriate model variable in your controller, your button will automatically be updated without you having to remember to use the appropriate directive.

Obviously this isn’t totally free, in that you still need to do some work, but this could certainly be improved further by creating your own http interceptor for instance in combination with the custom ‘ng-click’ directive to identify which button was clicked and update appropriately.

Overall I love how easy Angular makes it to do things like this and your users will appreciate the feedback from your UI.