After more than a month of working on this app, it still never ceases to amaze me when I find yet another super useful MSDN documentation page. This morning I was considering adding a hyperlink to my UI and so I used Ms. Google to search for "windows store xaml controls" and found this useful list of controls with thumbnails of what they look like with code used to create them. Then they have a list of all of the controls by function. Those pages are just so useful to someone starting out. Wait, that was me a month ago. I guess I am a little slow. It kinds of reminds me of the Adobe Flex Showcase. Some days I think there is definitely nothing new under the sun as the employees at Microsoft just learned from other tools what works well and then borrow the ideas and improved on them. I don't know which came first Adobe Flex MXML or Windows XAML but Apple Storyboards are the exact same idea and I know they came later than MXML or XAML.
When I was looking thru the controls list, I see they support tooltips. I still find this really odd on a touch device. I know from using Windows 8 that touch and hold results in a difference action from touching but that is not obvious since that gesture does not exist on Apple devices. Maybe it should be it does not.
Before going to too crazy, I wanted to go back to my existing Kanbanery stories and add references to the MSDN documentation on how I would solve the problems, just in case someone else picks up those tasks in the future. Even if it is me, then many weeks from now I am not going to remember what in the world I was doing.
The list of available components is pretty large and it was easy getting distracting looking at all of the examples to see what I could have used but did not for the UI I created, but I found what I need as it is called a HyperlinkButton. I think I am finally getting the hang of this. I then wanted to style the hyperlink as the default color just does not work with my themed colors. I could not find the styles off the main HyperlinkButton class documentation, but I found it right away in Ms. Google as I searched for "hyperlinkbutton styles xaml c#". I define the two brushes and then I run the app expecting easy success. I get the strangest error message I have not seen before:
WinRT information: Failed to create a "Windows.UI.Xaml.Media.Brush" from the text ''. [Line: 185 Position: 46]I looked in my resources XAML file and then at Git to see what I changed as that just did not make sense. I see the problem immediately as I started adding Foreground color to my Hyperlink button and had Foreground="". Sure enough I look at my MainPage.xaml file and on line 185 I found that half baked code. I compile the code and re-run it and it looks exactly as I intended it to. A little bit more code and I am done with that task.
It is time to do all kinds of manual testing to make sure the latest app is super stable. That is more important to me than adding any new features at this late in the game. I need a really stable app to deliver on Monday morning at my 9am meeting and I cannot work during the weekend, so bug free is very important.
At the same time I have to find out where the time is being spent processing data from the server as the time spent processing is pretty amazing when load the same data from local files. I must say that over the many years I have been doing this I have not found great benefit in using a performance analyzer as they are not to understand and take time to figure out what is being presented in the output report. I used to run analyzers all of the time in OpenGL development as they helped me. So, I decided to give it a try in VSE. They certainly make it so easy to run as I just select "Performance and Diagnostics" from the DEBUG menu. Download 6 hours worth of data and then stop the app and up comes the report. I really like the presentation as I can click on the column chart or select a region and the details below update to show the "Hot Elements" where most of the time was spent. The first time I selected "XAML UI Responsiveness" but the second time I selected "CPU Sampling". The later one was easy to explain as most of the CPU is spent in the mapping engine. Although those reports looked really good and had great interactivity, they did not help me with my problem at hand at all. And since I like to torture myself, I ran the amusing "Energy Consumption" report as well. The nice donut chart said it all "The session consumed approximately 139.09 mW-h of battery charge in 1.03 min. This rate of usage will drain a fully charged standard battery in approximately 5.23 hrs." - nice. The nice thing about this report is that I see "Wi-Fi Network" in the table with his blue bars of data that represent each of my downloads. I double click on them and I see another set of "Data Transfer" blocks and tool tips that tell me about each one as far as how much data transferred in each request and uploaded data which must be the request and acknowledgement responses. If I use my touch screen then I just tap on one of the blue blocks and the tool tip displays. Very nice - it does help me see one thing - the network is not the problem and the size of data is not a problem either. At least that helps me some. I look back at the donut chart and see that 59% of time was spent in CPU, 40% of the time was spent rendering data to the display and 2% was spent on network traffic. I went back into the "CPU Sampling" report and start poking around to see if any glaring problems came out. Although interesting and good looking, I need to add console log statements in my code and figure out what the delay is between getting the server data and starting the next download as that is my real problem.
In order to find the problem in my code I searched for way to get elapsed time and found the StopWatch class and added a Start/Increment/End calls and reran the app. Loading the data form the server took a total of around 44 seconds but reading the same data from files took a little over 1 second. To read 24 hours worth of data (around 65,000 data points with 18 values per point) took 20 seconds. Then I got brave and went back to loading 24 hours of data from the server and that took 4 minutes. I sent an email to the customer with this information. Now blinding fast but not horrible and the times are predictable and do not really vary much at all.
It took way longer than I expected to get the last issues resolved, but finally I am done and the only thing left to do is to have one final meeting and do the official hand off to the customer, but that is for another day.
No comments:
Post a Comment