Time Tortoise: Using SignalR with UWP

SignalR

This is one in a series of articles about Time Tortoise, a Universal Windows Platform app for planning and tracking your work schedule. For more on the development of this app and the ideas behind it, see my Time Tortoise category page.

To communicate with its companion app, Time Tortoise needs to use sockets. In recent weeks, I have been experimenting with socket communication between a UWP client app and a server running in a console app. This architecture works when everything is set up and running as intended. But it can be tricky to make sockets robust. So this week I’m looking into adding a layer that makes sockets easier to use and more resistant to unexpected failures.

« Continue »

Time Tortoise: Notification Icon

Notification area

This is one in a series of articles about Time Tortoise, a Universal Windows Platform app for planning and tracking your work schedule. For more on the development of this app and the ideas behind it, see my Time Tortoise category page.

To build a companion app that implements functionality that a UWP app can’t, it’s necessary to pick a non-UWP technology to use. Here are a few options:

  • A Windows service: Since the Time Tortoise Companion App only needs to send messages to and receive messages from Time Tortoise, it may not require a user interface. A Windows service allows code to run in the background on Windows, without a UI. I have a couple of concerns with this approach: 1) It’s a bit unfriendly, especially for users unfamiliar with Windows services, to have a mysterious service running in the background; and 2) I may find a need for a companion app UI in the future. This is not in itself a good enough reason to avoid the Windows service approach, but it’s a strike against it.
  • A Windows Forms app: This solves both of the concerns with the Windows service. But there’s no reason to use this ancient UI framework for a brand new app, when there are other options available.
  • A Windows Presentation Foundation app: WPF isn’t as cutting-edge as UWP, but it uses the same UI markup language (XAML). And since it is widely used, it’s likely to support any functionality that I need. So that’s what I’m going with for the companion app.

« Continue »

Time Tortoise: A Companion App

Pipes

This is one in a series of articles about Time Tortoise, a Universal Windows Platform app for planning and tracking your work schedule. For more on the development of this app and the ideas behind it, see my Time Tortoise category page.

Last week, I brought up some limitations of UWP apps, including one that will affect Time Tortoise. I also suggested the idea of a companion app that could address these limitations. This week, I’ll start exploring the companion app in more detail.

« Continue »

Time Tortoise: Working Around UWP Limitations

UWP 669

This is one in a series of articles about Time Tortoise, a Universal Windows Platform app for planning and tracking your work schedule. For more on the development of this app and the ideas behind it, see my Time Tortoise category page.

I decided to use the Univeral Windows Platform for Time Tortoise because I’m targeting Windows, and because UWP is the direction that the Windows user interface is moving (as of 2017). However, I knew from the beginning that UWP would not have all of the functionality of more established options like Windows Presentation Foundation. So as I make design decisions, I also look for ways to avoid getting stuck due to UWP limitations.

« Continue »

Time Tortoise: Creating an App Package

Package

This is one in a series of articles about Time Tortoise, a Universal Windows Platform app for planning and tracking your work schedule. For more on the development of this app and the ideas behind it, see my Time Tortoise category page.

Last week I covered some of the requirements for self-hosting Time Tortoise. The next step is to package and deploy a self-hosted version of the app, without disrupting the ability to run it in debug mode in Visual Studio.

« Continue »

Time Tortoise: Self-Hosting

Assets

This is one in a series of articles about Time Tortoise, a Universal Windows Platform app for planning and tracking your work schedule. For more on the development of this app and the ideas behind it, see my Time Tortoise category page.

As I mentioned last week, Time Tortoise is almost at the point where it could be used as a rudimentary time tracker. However, it still needs a number of improvements before I would want to use it instead of my regular time tracker.

As I’m adding features to Time Tortoise, it’s important to add them in priority order. In other words, add the most useful features first. This ensures the best use of time, and avoids throwing in features without a good reason.

« Continue »

Time Tortoise: An Early Fit and Finish Pass

Fit and Finish

This is one in a series of articles about Time Tortoise, a Universal Windows Platform app for planning and tracking your work schedule. For more on the development of this app and the ideas behind it, see my Time Tortoise category page.

Although far from done, Time Tortoise now has some basic functionality for tracking work time:

  • Add, remove, and edit activities (the things you work on).
  • Start and stop an activity timer, which creates a time segment (a start and end date/time).
  • Manually add, remove, and edit time segments.
  • Show the time segments associated with the selected activity.
  • Filter the list of time segments by start date.

You could in theory use these features for tracking real work, but there’s a lot missing. However, before moving on to add more features, I spent some time this week on fit and finish.

« Continue »

Time Tortoise: Unit Testing Update

Test Explorer

This is one in a series of articles about Time Tortoise, a Universal Windows Platform app for planning and tracking your work schedule. For more on the development of this app and the ideas behind it, see my Time Tortoise category page.

Last week, I added some functionality to filter time segments by start date. Since time trackers generate many time segments over time, it’s not practical to show all of them. The list view would slow down over time.

As always, adding new functionality provides an opportunity to learn more about how the Time Tortoise technology stack works, and I covered some of that last week. However, there’s an inherent conflict between investigating new aspects of the stack, and writing unit tests first. While writing unit tests can help clarify a design, getting a new feature to work sometimes requires some initial experimentation. Integrating this with a test-first approach can lead to a lot of re-writing.

For example, consider the Entity Framework code changes from last week. Because they modified the way time segments are loaded, they required numerous changes to unit tests. But the necessary changes were only apparent after some experimentation with the EF code.

As a result, this week has been focused on fixing unit tests, and adding new ones. Here are some unit test topics from this week’s work.

« Continue »

Time Tortoise: Loading Related Entities with Entity Framework

Time Segment Filtering

This is one in a series of articles about Time Tortoise, a Universal Windows Platform app for planning and tracking your work schedule. For more on the development of this app and the ideas behind it, see my Time Tortoise category page.

When you click on an activity in Time Tortoise, the app displays the list of time segments associated with that activity. But you don’t normally want to see every time segment ever recorded for that activity. Instead, it makes more sense to show only the most recent ones, like the segments recorded for the current day. That’s the change I’m making this week.

« Continue »

Time Tortoise: Timers

Time Segment Timers

This is one in a series of articles about Time Tortoise, a Universal Windows Platform app for planning and tracking your work schedule. For more on the development of this app and the ideas behind it, see my Time Tortoise category page.

Consider the basic Time Tortoise workflow:

  • Select an activity
  • Start the timer
  • Do some work
  • Stop the timer

This will result in a single time segment that has the appropriate start and end times and is associated with the selected activity. The duration will be calculated and displayed in the Time Segment list view, so you’ll know how much time you spent working. Everything looks good.

But there’s one problem: in order to see your elapsed time, you have to stop the timer. That’s inconvenient. When I’m timing an activity, I like to periodically glance at the timer to see how I’m doing, especially if I’m working towards a time goal.

So it would be nice if the active time segment would update dynamically while the timer was running. That’s the goal for this week.

« Continue »