Justin James discusses the trials and tribulations of week three of his Windows 8 Metro/WinRT application development project.
In last week's column, I described replacing the sample data sources in my Windows 8 Metro/WinRT application with connections to the Microsoft Research OData source. This week's work on the "MSR Browser" project was eventful, but I hit a big wall.
First, I started working on the search system; it turns out to be pretty painless. I have code written, but I have not been able to test it because of some issues that I will discuss in a bit.
Next, I made the necessary changes to the UI. This was a cinch, because there is a common styles file in the project's "Common" folder, and all of the templates used by the various pages for item and group display are in there. I was able to remove the useless images, but it didn't help the performance at all.
Performance has been the big problem. I keep getting an error about "exceeding my quota" when my data source populates itself. It's the kind of error I expect from a file system, but I'm not using the file system. Research showed this was a covered up out of memory error, and suggested the issue was that the page file was too big. Quick peeks at Task Manager showed the app was consistently crashing at about 300 MB of memory usage, but the machine was running at only 46% memory use. More fine-grained profiling showed a really strange thing: The downloaded data on one "group" of data was roughly 5 MB of memory, and the object to store it sucked up another 5 MB of memory — that made sense. But, when I added the in-memory "group" to the internal list of groups, it consumed an additional 40 MB of memory. Clearly, something was wrong.
I need to do additional work to find out what's going wrong, but my deep suspicion is that the Metro UI bound to the list object is the issue. I reached out to Microsoft for help, and I hope to have a solution to report next week. I do not want to leap to conclusions until I discover what's happening. I could be to blame, though I am worried that something in the binding process may be multiplying the memory usage of a data object by a factor of eight.
Unfortunately, because of this issue, I have been unable to test my code for the search functionality. So far, it has been a snap to implement searching. To do it, I added an optional parameter to my "GetGroups" method (I renamed it "GetData" while I was there) to accept a query. When the text is loading if the query string exists and isn't null or empty, I alter the URLs that fetch the items for individual groups to have "/?search=" and the query added to it, as per the FAQ for the service. I added another group to the list called "All" and whenever I add an item to a group, I also add it to "All." The item's data still shows that it belongs to a specific group, but now it also can be shown on the "All" page, which is nice.
I look forward to working with Microsoft to figure out the performance issues, and I will hopefully be passing on what I learn next week.
Keep your engineering skills up to date by signing up for TechRepublic's free Software Engineer newsletter, delivered each Tuesday.