This section looks at creating a
to-do list app that uses periodic tasks in conjunction with a scheduled
task agent. The app allows the user to enter a to-do item, which is
stored in a local database, and which can be pinned as a live tile on
the start experience. We look at using a periodic task to update the
status of the to-do item live tiles.
TodoItem
To-do items are represented by the TodoItem class, which contains three properties: Id, Description, and DueDate. DueDate is of type DateTime and indicates when the to-do item should be considered overdue. TodoItem objects are persisted using LINQ to SQL. The TodoItem class is decorated with a Table attribute, and its properties with Column attributes (see Listing 1).
LISTING 1. TodoItem Class
[Table]
public class TodoItem : NotifyPropertyChangeBase
{
int id;
[Column(
IsPrimaryKey = true,
DbType = "INT IDENTITY NOT NULL",
IsDbGenerated = true,
UpdateCheck = UpdateCheck.Never)]
public int Id
{
get
{
return id;
}
set
{
Assign(ref id, value);
}
}
string description;
[Column]
public string Description
{
...
}
DateTime dueDate;
[Column]
public DateTime DueDate
{
...
}
}
We now look briefly at the app’s data layer, before moving on to its viewmodels. Persistence of TodoItem objects is performed using a LINQ to SQL DataContext instance, and an intermediary service that decouples the data context from the app’s viewmodels.
TodoDataContext
To retrieve and store TodoItem objects in a database, we use a custom DataContext class called TodoDataContext. This class allows TodoItem objects to be retrieved via its TodoItems property (see Listing 2).
LISTING 2. TodoDataContext Class
public class TodoDataContext : DataContext
{
public TodoDataContext(string connection)
: base(connection)
{
}
public Table<TodoItem> TodoItems
{
get
{
return GetTable<TodoItem>();
}
}
}
In the sample app, viewmodels do not directly interact with the TodoDataContext,
but perform all CRUD operations via a to-do service. This decouples the
data context from the viewmodels, allowing you to replace the to-do
service with an implementation that could, for example, use a cloud
service rather than a local database. Decoupling the data context also
means that you have the flexibility to unit test the code outside an
emulator, perhaps on a build server.
