Monday, 2 December 2013

ADTECH and Windows Phone

Recently I had a requirement to integrate ADTECH banner and interstitial ads in a Windows Phone 8 app.  Like it or not, mobile advertising is here to stay; and I suppose ADTECH is as good as the next.

To their credit, ADTECH have published a Windows Phone SDK which makes integration relatively painless.  If you've done much third-party integration you have to appreciate when a vendor releases a SDK for your platform.

Unfortunately, with the WP SDK ADTECH has decided to give us a wrapper around the WebBrowser control, which smacks of "quick n dirty".  So, for my current requirements, it meant that I would have to accommodate the overhead of a WebBrowser control on nearly every page.

Personally, I avoid using the WebBrowser control and instead use a custom set of RichText controls and the HTML Agility Pack.  This gives me complete control over the rendering of my HTML, by converting HTML objects into native WPF controls, allowing me to render HTML without the overhead (and memory leaks) of the WebBrowser control.

If we take a look at what ADTECH is doing behind the scene, you can have a look at your app's IsolatedStorage using a tool like Windows Phone Power Tools.  Here we can see ADTECH getting busy by downloading individual banner ads, which effectively amounts to an HTML page and accompanying JavaScript files.


Let's face it, displaying a banner ad is not rocket science, nor should it require the use of a WebBrowser control.  All we really want to do is display an image (with or without animation) and respond to a user Tap event.  Use of the WebBrowser control to accomplish this seems a bit overkill in my opinion.

None of this would be worth writing about if it were not for the unexpected impact this had on the app and the UX.  Empirically, I have found a significant degradation in app performance once the ADTECH controls have been included in the app.  What's worse is that the inherit problems with the memory leaks associated with the WebBrowser control as detailed here, raise their ugly head in the ADTECH controls.  The net effect is eventually your app will reach its memory limit threshold and crash.

 

Wednesday, 6 November 2013

Windows Phone Development Tips

For the past several months I have been knee-deep in developing a commercial Windows Phone 8 app for a well-known sports company (NDA prevents me from disclosing any specifics).  While this is my seventh Windows Phone app, there are always new things to discover.  Here are a few tips I would like to impart, which you may or may not find useful.

async/await

WP8 developers can take advantage of the new async and await keywords in C#.  If you're unfamiliar with asynchronous programing here's a good place to start.  For both Windows Phone and WinRT applications, responsiveness is no longer a "nice to have", users expect your application to instantly respond to user input.  The Modern UI is fast, fluid and very responsive.  async/await is your best friend in making that happen. 

Monitor Memory Consumption

When embarking on my latest WP project I was fortunate to have a team of UI/UX designers.  They had spent a lot of time creating wireframes and screen mockups.  They had created some very rich screens, loaded with great content and functionality.  As a developer I immediately go into design mode, figuring out how to build the screens, behaviours and functionality.  Quite quickly my app came together, as well as the complexities.  It's easy to get caught up in the moment and forget about things like memory management.  So, I had a fully functioning app that worked great in the emulator and on my Lumia 920, but sucked on low/mid-range devices. 

Add these lines of code to your pages:

public MyPage()
{
     InitializeComponent();
     Debug.WriteLine(string.Format("MyPage constructor {0}", DeviceStatus.ApplicationCurrentMemoryUsage));
}


~MyPage()
{
     Debug.WriteLine(string.Format("MyPage destructor {0}", DeviceStatus.ApplicationCurrentMemoryUsage));
}

 This will allow you to monitor your apps memory consumption and identify pages that are not being destroyed.  You can do the same with your ViewModels, if you are using MVVM.

Additionally, you can periodically run the Windows Phone Application Analysis Tool (Debug | Start Windows Phone Application Analysis) to locate troublesome areas of your app.

Use WVGA 512MB Emulator...and buy a Lumia 520

When working in the development environment, use the WVGA 512MB Emulator.  While it is not exactly the same as a 512MB device, it will give you a feel for lower end devices.

If you're serious about Windows Phone development do yourself a favour and pickup a Lumia 520 as a test device.  The 520 is one of the most popular Windows Phone on the market, and for about £100 (SIM-free) its a steal.  Sideload your app onto your 520 and give it whirl.  If your app behaves well on the 520 you can pretty guarantee it will perform on other devices.  I only recently picked up a 520 in an emergency after my 920 died and was returned to Nokia.  Running your app on something like a 920 doesn't tell you much - of course its going to kick-ass, its a kick-ass phone.

Clean-up after yourself

Because your are working with limited memory (150MB for low end device, 300MB for high end), for larger apps you eventually become aware of this ceiling.  It is a good practice to tidy-up after yourself once the user is completed with a page.  I generally do this on the BackKeyPress event, but it could also be done in the OnNavigatedFrom override, depending on your circumstances.

If you're using MvvmLight you can call the CleanUp method on your ViewModel to decouple EventHandlers, dispose of unused objects and resources, etc.

Additionally, the issue regarding images on Windows Phone is well-known.  So, this is a good place to purge any unused images.

Give your app to a kid

By chance I let my 14 year old use my app.  Hmm...it was revealing.  Granted, he's a pretty switched-on kid, but observing him do things with the app (or try and do things) was a real eye-opener.  As well, I had him talk about the app as he was using it, telling me what he liked or didn't like, what was intuitive, what was confusing.  This resulted in some major changes in the user journeys we had originally designed.

Okay, a 14 year old is not a focus group.  But, on a budget, it was free and provided invaluable feedback.

Use IsolatedStorage, not Windows.Storage

I started out using IsolatedStorage, then mid-development switched to Windows.Storage - big mistake.  Stefan Wexel writes about this on StackOverflow, check it out:

StorageFile 50 times slower than IsolatedStorageFile

I'm sure Windows.Storage will improve in time, but for now stick with IsolatedStorage for Windows Phone 8.

Well, that's it for now;  I hope these tips were of some use.  Will post more as they hit me in the 'ead.




Friday, 21 June 2013

Style Explorer is in the Store

Style Explorer has passed certification and is now available in the Windows Phone Store.  Here's the link:

http://www.windowsphone.com/en-us/store/app/style-explorer/2e3ab244-d803-4b54-81cb-efeccc79e10d

As always, any comments, feedback or suggestions are welcome.

Even better - rate and review :)


Tuesday, 18 June 2013

Coming Soon: Style Explorer for Windows Phone 8

I've just submitted my fourth WP8 app to the Store.  It is called Style Explorer and is primarily for Windows Phone developers.  If you are a developer you are probably aware of the numerous built-in resources that comes bundled with Windows Phone.  Microsoft encourages use of these resources to produce a consistent look and feel and user experience on the Windows Phone platform.

Style Explorer is a reference tool which organises and displays these resources so you get a feel for what they look like on the target device.  This includes:


  • Supported Font Families
  • Font Sizes
  • Font Weights
  • Text Styles
  • Accent Colors
  • System Brushes
  • Control Brushes
  • Default standard control properties
  • Segoe UI Symbol Named Glyphs
  • A Visual Designer which allows you to modify the look and feel of standard controls and export the settings as C# or Xaml


Here are some screenshots:

Thursday, 6 June 2013

In defense of WPF

Recently there was an interesting thread on a LinkedIn WPF Group about the future of WPF.  The originator sparked the discussion by raising the question if WPF was going to be replaced by HTML5.  Many WPF developers shared the opinion that the introduction of HTML5 did not herald the end of WPF.  I agree.

From this I did a quick Google search on recent WPF news and ran across a blog posting by a former WPF disciple.  The thrust of his article was that WPF has not evolved in the six years since its introduction.  He then proceeded to highlight what he felt was wrong with WPF.  This included poor designer support, ugly syntax, complex binding expressions, etc.

The author espouses the virtues of ASP/MVC as a platform that is really going places.  Having done 10 years web development, including classic ASP and ASP.Net, I thought this was amusing.  Even more interesting that I left web development shortly after Microsoft released WPF; 10 years was more than I could stomach.  I've always felt that web applications were always attempting to do things that the platform was never designed to do, in short it was a kludge.  Is it getting better?  Sure it is, but a leopard cannot change its spots.

The comments section of this blog post quickly filled up with like-minded developers for a good old-fashioned WPF bashing.  Comments ranged from "WPF hurts my brain" to "MVC is sooo cool, and WPF ain't".  A small minority cautiously defended WPF and what it could do.

What struck me about these comments was how self-centered the viewpoints were.  The choice of technologies and preferences were largely based on them - what made their life easier.  Almost no one focused on the end product or the end user, or how they were affected by these technologies, it was all about themselves.

I challenge any of these WPF-bashers to sit down with an end user and present to them two applications:  One, a properly designed WPF desktop application; and Two, an equivalent ASP.Net/MVC application.  Then, after using both ask the user which they prefer.  I would put money on the WPF application.  Why?  Because WPF is a superior user interface framework over HTML.

My heart goes out to office workers who have been forced to use web applications day in, day out.  The truth is - web apps SUCK.  And everybody knows it.

I have been in countless design/planning meetings for new internal applications and there rarely is a discussion about whether to go down the web app route or desktop route.  Why?  Because often it is assumed that web apps are more cost effective, easier to maintain, easier to deploy.  No one ever says the reason for the decision is HTML/ASP's vastly superior UI capabilities or how it delivers an excellent user experience.  Why?  Because - web apps SUCK.  And everybody knows it.

Why do I use WPF over HTML/ASP?  Because of the end product I can create; because of the effect that product has on the end user and their work.  I don't pick a technology because it is easy for me.  I pick a technology that is going to assist me in bringing about a superior valuable product for the end user.  My goal is to change the way my users work, to assist them in performing their job, to make the whole experience more efficient and enjoyable.

Thursday, 16 May 2013

Tuesday, 7 May 2013

Coming soon: Huffy for Windows Phone

Within the next five days or so my new Windows Phone 8 app, Huffy, will be in the Windows Store.  Huffy is the unofficial Huffington Post Reader.

For quite some time The Huffington Post has been absent from the Windows Phone landscape.  Back in 2011, HuffPost released a WP7 app, but then it suspiciously disappeared, never to return.  I thought it was long overdue, so decided to take on the task.

Here's what I came up with...

Huffy offers three editions of the Huffington Post: US, UK and Canada; and 75 categories of news articles and blogs.

Once the app has passed through Microsoft's certification process I will post the link to the product page.

Also, I have created a Facebook Product Page for the app:

https://www.facebook.com/pages/Huffy-for-Windows-Phone/450955798325055







Monday, 25 March 2013

New Free App: M1 for WP8

I have published my second Windows Phone 8 app entitled M1 for WP8.  You can find it here:

http://www.windowsphone.com/en-gb/store/app/m1/5c929ae0-7ef7-47d4-81e4-2f5753d00e89

Similar to my previous app M25 for WP8, M1 allows you to monitor the current state of the M1 motorway here in the UK.  Here's a few screenshots.


After publishing the M25 I stepped back and took a look at refactoring my codebase to support any motorway in the UK.  As a result, the new version of M25 and the M1 app share a common core codebase.  As well, the size of the xap file has gone down dramatically from about 500kb to around 275kb.

Anyway, if you are familiar with M25 you will know how to use the M1.

As always, comments/feedback/reviews are appreciated.

Thursday, 31 January 2013

M25 for WP8 Reviews

My M25 app for Windows Phone 8 has been in the store for a couple of weeks now and has gotten some positive reviews, currently with a 5-star rating.  Here's a few (I know...shameless self-promotion):


"Where have you been all my life!! The at a glance section for each junction is a brilliant feature and showing all the planned roadworks is great."
"Awesome app if you use the m25 daily"
"Just downloaded and had a quick play with it - so surprised someone hasnt come up with this app sooner - I live in Romford and regularily use the bridge and tunnel to get to and from Dartford. Will stop me blindly driving into the car park at the toll booths. Good job. Its well presented and the route plan and planned roadworks info are great additions - at a glance section is genius. Left you a short 5 star review as well. Thanks Ron"

From the official Microsoft User Community:
"Great work on M25, Ron! Just showcased the app to the community. Next time we're in London we'll be using it. :)"

And my personal favourite...
"Ooooo. This is good :-)"
I've got a minor update coming out in the next couple of days.  Anyone who has installed it will find it as an update in the store.



Thursday, 24 January 2013

New UI Gallery

I've added a link in the header toolbar to a UI Gallery, with some examples of my WPF/Windows Phone work.

Here is the link to the page: http://rgramann.blogspot.co.uk/p/ui-gallery.html


Sunday, 20 January 2013

M25: My First WP8 App - Part V

One of the areas which gave me some grief was the ScheduledTaskAgent.  It was important the the app periodically refresh its data and update the Live Tile.  Setting this up is pretty simple, however, getting it to behave proper was another.

You can think of ScheduledTaskAgents like a mini-Windows Service.  Once a ScheduledTaskAgent is  registered the OS will run it every approximately every 30 minutes allowing it to do its business and you have 10 seconds to do your thing.  This is done through the ScheduledTaskAgent.OnInvoke method.  With my app, my ScheduledTaskAgent needed to re-fetch all of the latest traffic data, process it and update any Routes (if defined).

Within my M25.Data component I have a RefreshTrafficData method which is marked with the new async keyword.  This was done to allow the WP UI to retain control while the DataManager was busy fetching and processing new data.  The DataManager fires appropriate events, such as DataTransferStarted and DataRefreshed, to allow the UI to display a progress bar.

While all this works wonderfully from the WP app, calling this method from the ScheduledTaskAgent is another matter.  When refreshing traffic data we don't want this to run asynchronously, since we need to take the result of the refresh and update our Live Tile with the new data.

To make a long story short, I ended up creating a new method in the DataManager which effectively was a wrapper around RefreshTrafficData, but which returned a Task object.  By returning the Task object I can this call the Task.Wait method from within the ScheduledTaskAgent.OnInvoke.  Execution will pause until completed and proceed to call the NotifyComplete method signalling the end of our operation.

There are a couple of extension methods which I found/created which were beneficial.  The first method addresses the fact that in WP8 WebClient.DownloadString has been removed and replaced with the asynchronous DownloadStringAsync (which fires the DownloadStringComplete event with the result).

The DownloadStringTask extension method allows you to call DownloadStringAsync synchronously, if needed.

public static Task DownloadStringTask(this WebClient webClient, Uri uri)
        {
            var taskCompletionSource = new TaskCompletionSource();
            webClient.DownloadStringCompleted += (s, e) =>
                      {
                         if (e.Error != null)
                         {
                             taskCompletionSource.SetException(e.Error);
                         }
                         else
                         {
                             taskCompletionSource.SetResult(e.Result);
                         }
                      };

            webClient.DownloadStringAsync(uri);
            return taskCompletionSource.Task;
        }

This allows you to do this:

Task data = new WebClient().DownloadStringTask(new Uri(SOME_URL));
await data;

if (data.Exception == null && !string.IsNullOrEmpty(data.Result))
{
     ProcessResults(data.Result);
}

The other extension method relates to setting the BackContent of a Live Tile.  WP8 introduces a new large size to Live Tiles, so now the user can pick between small, medium and large tile sizes.  In most cases you will want to display dynamic information on the back of your tile.  But, there is no way of know which size the user has selected for your Live Tile.  Forget about the small size, since it does not permit back content.  Unfortunately for medium and large sizes the text WP does not provide automatic wrapping of text, so you will have to do it yourself.

Per MS documentation, the WideBackContent takes 27 characters, while the BackContent takes 13.  The
GetTitleLines extension method allows you to parse your Live Tile data into lines of text to accomodate both WideBackContent and BackContent.


  public static List GetTitleLines(this string theString, int wordCount)
        {
            string[] parts = theString.Split(' ');

            var lines = new List();

            string line = string.Empty;
            int index = 0;
            foreach (string part in parts)
            {
                if (!string.IsNullOrEmpty(part))
                {
                    if (line.Length + part.Length + 1 <= wordCount)
                    {
                        line += part;
                        line += " ";
                    }
                    else
                    {
                        lines.Add(line);
                        line = part;
                        line += " ";
                    }
                }

                index++;

                if (index >= parts.Length)
                {
                    lines.Add(line);
                }
            }

            return lines;
        }

Here is how you can use it:

  private void SetLongData(string data)
        {
            List lines = data.GetTitleLines(27);

            if (lines.Count > 1)
            {
                foreach (string line in lines)
                {
                    LongData += line + "\n";
                }
            }
            else
            {
                LongData = lines[0];
            }
        }

        private void SetMediumData(string data)
        {
            List lines = data.GetTitleLines(13);

            if (lines.Count > 1)
            {
                foreach (string line in lines)
                {
                    MediumData += line + "\n";
                }
            }
            else
            {
                MediumData = lines[0];
            }
        }


In the next part in this series I will be wrapping things up.



Tuesday, 15 January 2013

M25: My First WP8 App - Part IV

Concurrent with my UI experiments, I began researching sources of data.  This work ended up consuming the most amount of time.  I had a number of potential candidates, including the RAC and Twitter, as well as the Highways Agency and Transport for London.

In recent years, the UK government has invested in opening up transportation data to the public.  This may explain why we see a growing number of public transportation (bus, tube, National Rail,etc) mobile applications.  I spent several days exploring all the data feeds and schema, looking for something suitable.  In addition to wanting to keep my app small and lightweight, I did not want to be forced to pull down unnecessary data and process it on the mobile device.  This was a case of too much information.  Certainly forcing a mobile app to pull down 25MB of unfiltered data was out of the question.

Twitter feeds were also on the table.  However, Twitter has recently announced upcoming changes to its usage policy, such as deprecating RSS feeds.  As well, relying on a Twitter feed puts me at the mercy of a third-party, which could change its privacy settings, effectively putting me out of business.  I also did not want to dive into the whole oAuth area at this time.  So, I backburnered Twitter for version 1 and ended up going with the Highways Agency RSS feeds.

Highways Agency (HA) RSS feeds were ideal for my requirements, offering:

  • Easy to ready XML schema
  • Small, lightweight payloads
  • Offered feeds specific to the M25

I ended up using three HA RSS feeds:

http://hatrafficinfo.dft.gov.uk/feeds/rss/CurrentAndFutureEvents/M25.xml
http://hatrafficinfo.dft.gov.uk/feeds/rss/UnplannedEvents.xml
http://api.hatrafficinfo.dft.gov.uk/RSSFeeds/BreakingNewsRSSFeed.aspx

A combination of these three feeds gives me all of the planned events for the M25, as well as unplanned (e.g. accidents, congestion, emergencies, etc).  So all I had to do is pull this data down, parse and process and update my UI.   In the end, a relatively straightforward operation.

In sticking with my original core functional goals, I had my reliable source of data.  I can still introduce other data sources in future versions, including images, enhancing the app and its usefulness.



Sunday, 13 January 2013

M25: My First WP8 App - Part III

Once I determined what my version 1.0 feature set would be I next started work on the UI.  I know other developers who approach it differently, starting with a data model and working their way to the UI.  I've done both and I prefer starting with the UI and letting that drive the model.  This is more of a needs-based approach.  The best approach is the one that works for you.

During this phase I did quite a bit of prototyping and experimenting.  At one stage I envisioned having a clock-like representation of the circular M25, with each junction positioned in its relative position along the rim.  While it was pretty cool, there were usability issues due to limited screen real estate and the number of junctions on the circle.  Unfortunately I had to abandon what was going to be a centerpiece control for my app.

Instead I went with a more conventional edit screen and list picker.

The governing reason for this decision was usability.  It was simple and intuitive.

Early on I had decided to adopt a colour-coded status (red, amber and green) to indicate traffic status.  I wanted to keep things simple and not complicate the user experience.  I wanted the user to simply glance at the screen and get an immediate feel for the traffic conditions.

After reviewing some sample data from the Highways Agency related to the types of incident reports, I came up with this:


The result is the My Routes page:

I chose to use the Cambria font as a title font instead of the standard Segoe WP, more for aesthetic reasons. The same colour convention was used throughout the app, as in the Junction List page:

Another temptation was to incorporate the built-in WP8 maps functionality.  Again, my objective was not to create a SatNav application or journey planner, but to keep the app focus on the current traffic conditions of the M25.  That said, there was a point where I felt access to maps was relevant and potentially useful.  On the Junction Detail page I display a small map snapshot along with traffic data for the junction.  From here the user can jump to WP8 Maps using this location.

That's pretty much the summary for the UI development.  A lot of experimentation occurred to arrive at this point.  Some developers may view the Modern UI (formerly Metro) as being simple or easy to design, and in some respects it is.  I don't claim to be an expert in Modern UI design or that my app is a standard reference.  I do think that working with the Modern UI shifts the emphasis of design.  Instead of making something look pretty or have a wow-factor, the designer is really focused on information and how best to express that on the screen.  To some degree our GUI design legacy leans toward complex UIs.  Modern UI is forcing us to revisit and rethink user experience, stripping things back to the basics.  This is an interesting process, and ultimately a rewarding one.


M25: My First WP8 App - Part II

For anyone considering developing a mobile app, whether for WP or others, I think having a well-defined purpose is the first step.  After all, the app is supposed to do something, right?  I may be stating the obvious, but there are some subtleties here worth recognising.  Initially I wanted to incorporate real-time traffic speed, CCTV cameras, Twitter feeds, etc.  While these are perfectly valid features, including them in the first cut may not fit in my timeline.  So, I stripped things down to the basics, which included:

  • Pull down current traffic information
  • Pull down known planned events related to the M25
  • Allow the user to define routes
  • Display status information
  • Use a background agent to display current data in a Live Tile

So, this was my list of core functionality or deliverables.  Regardless of any extra bells and whistles, the app had to solidly deliver this set of features.  As well as naming those items "to do", you should also be aware of what "not to do".  I set a personal target to get this done within the month of December.  Given my time constraints I felt this was doable.  A lot of the other ideas I had are still valid, but can be added to my roadmap for future versions.

I created a new solution in Visual Studio 2012.  To my solution I added a Windows Phone application targeting Windows Phone 8.0 called M25.WP8; a Windows Phone class library called M25.Data; and a Windows Phone Scheduled Task Agent called M25.Agent.


I knew from my feature set that this was the minimal architectural requirements.  M25.Data would do all the data management and processing.  While the M25.WP8 phone application tended to the UI/UX requirements and M25.Agent was dedicated to running in the background and updating the Live Tile.  Not shown in the diagram is the reference between M25.Agent and M25.WP8; to get your Task Agent to be recognised by Windows Phone it has to be associated with an application so it gets included in your xap.  Pretty straightforward.




 

M25: My First WP8 App - Part I

I will be publishing my first Windows Phone 8 into the Windows Store in the next day or so.  It is called M25.  For those outside the UK, the M25 is the London Orbital motorway.  Like a huge wagon wheel, the M25 circles London with spokes running to the heart of the city.  It is the UK's busiest motorway, and some say in all of Europe.

So why create an app for a motorway?

For three years I traveled the M25 every day, and every time you plan to get on it you wonder what state it's in.  My carpooling passenger and I would have a routine when leaving the office; checking various web sites to determine whether we should even get on the M25.  Anyone who frequents the M25 has their own horror story of spending hours on the M25 parking lot.

I know what you're going to say - but, surely any decent SatNav app is going to tell you the traffic conditions of the M25 - and you would be correct.  But, the point is, I know how to get home.  And maybe I don't want to tie my phone up running Nokia Drive, when all I really want to know is happening on the M25.

What I really want is a lightweight app that is going to give me current, accurate traffic conditions for my section of the motorway.  I don't want to have to wade through traffic data about other motorways or even other parts of the M25 (the M25 is about 115 miles in length).  I'm just interested in what is happening between junctions 13 and 6.  So, I'm looking for the ability to filter traffic data from the volume of information pushed out by the Highways Agency.

Here's what I came up with:
So, that was the motivation for creating this app.  In subsequent articles I will discuss some of the issues I encountered, both technically and functionality.

I'm fully aware that this app is not going to set the world afire.  Developing it was as much for my benefit as it may be for others.  That said, I do think that it may prove valuable to those who wrestle with the M25 on a daily basis.

Thursday, 3 January 2013

USB Dongles and Serial Ports in .Net

I have spent the past three years working on mobile field applications for Centrica, mainly on the Smart Metering team.  One of the challenges we faced was with the use of USB dongles that create serial ports.  In our application we used a Zigbee USB dongle manufactured by Telegesis.  This dongle would be attached to a Panasonic H1 Toughbook and the Smart Energy Expert would proceed to commission/decommission smart devices.  Due to the design of the H1, the USB dongle would inevitably get knocked off abruptly terminating the serial port communications.
If you are reading this article you are probably familiar with the well-documented Serial Port issues in the .Net framework.  Many in the .Net community have declared .Net's Serial Port support to be unreliable at best.
In the above scenario, you will become aware of the removed USB dongle when you attempt to read or write data to the serial port - the serial port that no longer exists.  Unfortunately this is not a case where you simply wrap your code in a try/catch and you're good to go.  What you will likely experience are Windows IO exceptions or Dispose exceptions.  When these occur your application cannot recover from them, nor can you trap these exceptions.
Zach Saw has written an excellent blog on this type of scenario here. While this proposed solution goes a long way to resolving this situation, we were still getting unpredictable (and unrecoverable) exceptions.  I have to admit this was a tough nut.
In my research I stumbled upon an MSDN article written by John Hind entitled Use P/Invoke to Develop a .NET Base Class Library for Serial Device Communications written in October 2002.  For all you .Net historians, you might recall that SerialPort support in .Net did not appear until version 2.0.  So, here was John effectively rolling his own using Win32.  A brave soul.
Could it be that a 10 year old piece of code held the answer to our problem?  At this point I was willing to try anything.  Something about it made sense.  This approach removes Microsoft's dodgy SerialPort implementation and relies on the much more stable Win32.  Implementing John's code into our project took a bit of finesse, but we got there and it worked beautifully!
Since finishing up at Centrica I've had some time to put together a sample solution which implements John's code (with changed naming conventions and formatting) and includes a simple Zigbee Test application.

The sample uses WMI to detect the removal/insertion of the USB dongle (there are other ways to do this).  And utilises the custom Serial Port from John Hind.  You can download the solution here (ZigbeeUSB.zip).

Wednesday, 2 January 2013

Beta Testers needed

I am close to publishing my first Windows Phone 8 application and would like to enlist the help of some beta testers.  Ideally you would be in the UK, but not essential.

If you are interested please contact me: ron(at)gramann(.)co(.)uk

Nokia Lumia 920 and WP8...Good News, Bad News

Well it has been quite a while since I've posted anything on this blog.  My bad.  Then a couple of months ago I upgraded to the new Nokia Lumia 920 and felt I had something worth blogging about.  Just as I sat down to compose a glowing review of Nokia/Microsoft's latest offering my 920 bricked.  Soft reset, hard reset - didn't matter, my 920 turned into a sexy paperweight.

After a quick call to Phones4U tech support and a visit to my local shop I had a brand new 920.  While I may have a certain tolerance for these types of hiccups, the general public does not.  In this situation it was clearly a software/OS issue.  The buttons and screen became non-responsive, but if I removed my SIM card the phone came back to life.  Unfortunately there was nothing I could do to resurrect my 920.

Since then I have not had any issues with my replacement.  In fact, I couldn't be happier.  It is a solid quality product from Nokia.  The battery life is impressive, on average I can go for a day and a half without charging - with WiFi enabled.

Windows Phone 8 is fast and fluid and is a perfect marriage with the 920.  The colours and sharpness of the screen is stunning. And the dual core processor is ample to bring about a thoroughly enjoyable WP experience.

All-in-all, I'm quite happy with the 920 and WP8.  I would not go back to the Lumia 800 and WP7.5, not that there was anything particularly wrong with it, it's just that the 920 is so much better all round.
If you recently purchased a 920 you can receive a free wireless charger from Nokia, just go to http://nokiafreecharger.com and fill out the form.  I've had mine for a couple weeks now and love it.

Update 25 Jan - My 920 is still going strong.  I have had two or three incidents where the OS locked up while running an app, forcing me to do a soft reset.  Battery life is still outstanding.  I've dropped the phone a couple of times, but no harm done.  I recently noticed a small scratch on my screen which is annoying.  I have no idea how that happened.  The wireless charging is fantastic.  Next step is to get some NFC tags...