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.
Self-Hosting
A good way to gauge feature importance is dogfooding or self-hosting. Dogfooding refers to developers using pre-release versions of the software they develop. Self-hosting has a similar but more specific meaning. It generally applies only to software that is directly used in its own development — for example, a compiler that compiles its own source code, an operating system that runs the tools used to develop it, or a source control system used to manage its own source.
Time tracking software can be self-hosted simply by using it to track the time spent writing it.
Packaging and Installing
One of the goals of the Universal Windows Platform design is to protect users from malicious or poorly-designed apps. To do this, UWP requires that each app have a certificate that is used to sign its installation package. Despite this requirement, UWP supports the following installation scenarios:
- Running an app in debug mode from Visual Studio
- Side-loading an app that isn’t intended for widespread public use
- Installing an app from the app store
For scenario #1, Visual Studio UWP templates include a certificate file called ProjectName_TemporaryKey.pfx that is used when Visual Studio launches the app.
For scenario #2, there are manual steps that can be used to side-load the app without going through the store. To self-host Time Tortoise, I’ll need to have a stable version running for time tracking purposes, while also running a version inside Visual Studio for development purposes. Since I’ll want to update the stable version fairly often (as I add features and fix bugs), I won’t want to go through the store publishing process for every update. Side-loading is a way to accomplish that goal.
Scenario #3 is a lengthier process that can be used for appropriate apps. I plan to use that process for Time Tortoise later this year.
Maximum Image File Size
One of the steps required for scenarios #2 and #3 is to use Visual Studio to create an app package. As part of this process, Visual Studio runs some checks on the project source files before creating the package. That led to two error messages similar to the following:
App manifest references the wide 310×150 logo image ‘Assets\Wide\Wide310x150Logo.scale-400.png’ which is larger than the maximum image file size. It must be no larger than 204800 bytes.
I actually knew this was coming, since a similar message appeared on the Visual Assets tab of the Package.appxmanifest editor. But I ignored it until now, since it didn’t block anything. Well, it blocks the creation of the app package, so I needed to fix it.
As I mentioned in Initial Commit: Time Tortoise, the source of my tortoise logo is a vector image. So ideally there wouldn’t be any problems with image size. However, there may be some problems with SVG support in UWP. So for now, I just reduced the size of the images (while keeping the canvas size unchanged) for the affected assets.
AppData
One more thought on running a side-loaded and a debug version of Time Tortoise simultaneously: the databases need to be separate. The side-loaded version will have real, useful data, while the debug version will have test data, or may even be deleted.
Local data for UWP apps is stored in %UserProfile%\AppData\Local\Packages\<packageName_id>. For example, my local Time Tortoise database is currently in TimeTortoise_c8f44813jqyya\LocalState\TimeTortoise.db under the Packages directory. To allow two copies of Time Tortoise to coexist, I’ll need to ensure that they don’t both write to the same database, either by changing the local storage location or by changing the database name.