Tuesday, December 17, 2013
So, the recommended way to share data between the app and the periodic task is by files in the isolated storage - perfect, that was my plan!
BUT, my periodic task project doesn't by default have access to the classes defined in the app - which will make it tricky to read and parse the schedule xml :/ And I can't make it reference that project, because it 'is not supported by a Background Agent'.
Clearly, I need to extract shared functionality to a library of some supported type, and reference it from both projects. I'll need
- event object definition
- schedule parser
Basically this is all the bits contained in my Model definition, which makes me feel like I must have structured it in a reasonable way :) Unfortunately, once I moved them, I found that I had a lot of View-related code in there, calling App.Resources, etc, which wouldn't work in a shared library :/ Well, I guess the cleanup required here will make the code better altogether, so it's worth doing!
I used this post as an example to get me started:
Specifically, I have an SQLite db which is instantiated in the App.xaml.cs class, which I can't refer to from my library - and is probably the wrong place anyway. But, the DB seems to use the Assembly name to access it: and isn't the assembly name going to be different between the main app and the background task? There's not much reference on the web, but a couple of people say that it isn't possible to use sqlite in a background task. I was worried that I would have to update my model to use the db for the full list, and back to the flat file for the individual schedule, which would be a shame - but I decided to go ahead with the refactoring and try it - and everything ran! It didn't work, quite - it always said 0 events found - but it managed to instantiate the db connection and run through all the code without panicking, so must be most of the way there.
Unfortunately, I found that the database had starting renaming all events to "1.0" when they were stored. I figured out that this was because I had added a new field to the Event object, which was messing up the Insert statement. Once that was solved, I started hitting exceptions when the scheduled task tried to read the db - I figured that was because the db file was locked, because it was never being closed by the main process. I cleaned up the DBHelper file a little, turning it into a singleton and making sure that every operation which called Open() also called Close(). At this point, I decided should probably create an Interface for the DBHelper, which would make testing easier and also make migration easier if I switch away from SQLite at some point. I recently started actually trying to use some of Visual Studio's refactoring abilities, so here I did right-click on the class name -> Refactor -> Extract Interface. Then select which of the public methods I wanted in the Interface, and Done! Pretty nice.
Unfortunately, when I ran the app again, the database locking was even worse - even the original app process could never open it, always getting the same error. I decided that I did need a real mutex. I found the outlines in another stack overflow answer and added a check/hold/release mutext everywhere I had the open/close db work. Running with this made it clear that actually, it wasn't a deadlock - even when I turned off the background agent, I was getting 'unable to open database' errors every time. Clearly, the actual problem had been introduced when I updated the DB schema. I could validate with the Isolated Storage Explorer that it was being copied into storage correctly. I stepped through the code and verified that the db was being opened successfully on first contact - but then when it attempted to execute a query, the code tried to open a dbname of "Events.sqlite-journal", which threw a storage exception because it didn't exist.
I followed advice (from Stack Overflow, obvs) to create the journal file back at the start with the actual db file - but still got an error when trying to open it. To narrow down the problem, I tried opening the file straight after creating it - and still got the error. I think I should have been able to figure this out from there, but instead I went and searched to get a list of basic causes for this error - and the very first answer was 'you haven't closed the stream that was returned when you created the file'. Duh, I mean, really. Added a file.Close(), ran the app, everything works! Well, except a Null Reference Exception when I tried to add an event to my schedule, but lots of things worked. Some, at least. More than earlier today.
(this post was written as-it-happened, between december 17 and 26. Very useful for tracking what I had done when I was only doing random half-hours of work!)
Thursday, December 12, 2013
I'm working on adding a live tile to my PAX app, to show the next item in the schedule. Finally got 'a' live tile working, with a couple headaches along the way.
1. Because I still have a 7.0 project, the nice simple API for 'ActiveTiles.FirstOrDefault' doesn't exist, so you have to use an Enumerator on the ActiveTiles set, and apparently I am still hazy on Enumerators so forgot to get next before trying to use the current tile.
2. I'm really making life more difficult for myself by continuing to target 7.0 devices, but I don't want to give up on them yet. But I do really want to offer a wide tile option to those who can use it! Fortunately Telerik offers a LiveTileHelper in their tools (which I already use and pay for) which handles the 'does this device support x' aspect of it, I haven't incorporated that yet but will definitely use it. I should probably read through all their docs to see what else there is, because I only found out about this by someone mentioning it in a stack overflow response about tiles.
3. Because I want the front of the tile to display a bunch of text, I'm going to have to generate a bitmap containing that text. I found a few examples on stack overflow , but somehow when I ran my app the generated image was not applied. I checked the tile docs and they mentioned that setting the BackgroundImage property to a null Uri would just be ignored, but I used the Isolated Storage Explorer to verify that the image was created and in the file system exactly where I expected. After going back to doublecheck anything I'd missed in the sample code, I noticed that their code looked like
whereas I had
BackgroundImage = new Uri("isostore:/Shared/ShellContent/Image.jpg", UriKind.Absolute),
data.BackgroundImage = new Uri("/Images/Tiles/paxTile.png", UriKind.Relative);
curiously enough the background image worked, but not the front image. I changed the front image to be in the format isostore:file, Absolute, and it worked! Still not sure why the requirements are different for the front and back - I left a comment on one of the MSDN pages for setting Live Tiles asking about this (and for a note to be added to the docs somewhere).
data.BackBackgroundImage = new Uri("/Images/Melbourne/melbTile.png", UriKind.Relative);
Now I just have to design the tile layout and actually make it look decent. Here's the plan so far:
// (x) // <- if you have more than one session on your schedule for the
// // next hour, this is how many. The tile just shows details on one.
// my great session... // max 14 chars? check font size
// rest of name?
// time // in users culture
// __PAX Digital Assistant__
// My session name is...
// 12:30: Unicorn
// Come play with my f...
// 12.30: Cat.
// Leave Me Alone Wit...
// 13:00: Main Theater
// layout wide:
// My session name is the funniest thing you eve...
// 12:30: Unicorn
// Come play with my friends while I make fun of y...
// 12.30: Cat.
// Leave Me Alone With My Collection of Pokemon...
// 13:00: Main Theater