I spent the last weekend working with a small Windows Phone 7 news reader app. First I used the default ListBox control to layout the news items but when I later on decided that I would like to group the items nicely, I replaced the ListBox with the LongListSelector from the Silverlight Toolkit.The control brought me the ability to group the items, and it brought me tons on problems and peculiar behavior.

There’s couple big problems with the control which forced me to write stupid hacks in the app:

Problem: When you navigate back to a page which contains LongListSelector, the list may stay empty until you scroll it.

Solution: Call the ScrollTo-method of the LongListSelector when you navigate back to the page. ScrollTo forces the control to redraw itself. ScrollTo requires an object (not index) so you may need get the first item from your item collection and use that as the parameter. You can also store the current selected item from the list (SelectedItem) to somewhere safe when navigating away. When you navigate back to the page, call the LongListSelector’s ScrollTo-method to move back to the correct point.

Problem: The LongListSelector may throw NullReferenceException when you navigate back to the page.

Solution:If your LongListSelector is bound to a collection and you call NotifyOfPropertyChange for the collection when you navigate back to the page, the control may throw NullReferenceException (in its balance-method). The solution is to avoid the call to NotifyOfPropertyChange. There’s also some more tips available from the CodePlex-forums.

Overall, I recommend anyone to think twice before using the LongListSelector. The grouping-functionality is nice but in my humble opinion it’s not worth the problems the control causes.

Are your toast push notifications getting suppressed, even though previously they were working fine? This may be because of the battery level of the device. According to the MSDN documentation, notification may get suppressed if the channel hasn't been configured to accept a particular type of notification:

The push notification was received and dropped by the Push Notification Service. The Suppressed status can occur if the notification channel was configured to suppress push notifications for a particular push notification class.

This is quite hard description to understand. It gets more complicated after reading the description for suppressed notifications from the Push Notification Recipe: 

Suppressed status can occur if the notification channel was configured to suppress push notifications for a particular push notification class, for example the application tile was not pined to the Start menu.

So even though the channel has been configured to accept live tile notifications (by calling channel.BindToShellTile), we may get suppressed notifications if the app has not been pinned to the menu. 

But there is a third reason which will cause the notifications getting suppressed: The battery level of your device. The different battery levels and their effect to the notifications is available through the MSDN's article Power Management and Push Notifications for Windows Phone. Here's the summary from the article:

From the notification's sender's perspective the low battery level looks identical to the situation where a live tile notification is sent but the app hasn't been pinned to the start menu. This is a good thing to remember before you start debugging or modify your previously-working code.

HttpNotificationChannel is the key class at your Windows Phone 7 app’s side if you want your application to support push notifications. For good introductions on the topic I recommend the following links:

• Push Notifications for Windows Phone
• A Really Long Post About the Windows Phone 7 Push Notification System

But one key piece is missing from these articles: The HttpNotificationChannel between your app and the Microsoft Push Notification Service may die (or corrupt) without you nor Microsoft knowing about it. But your app’s end users will notice.

Background

The “canonical” example of setting up a HttpNotificationChannel from your app looks like this:

            channel = HttpNotificationChannel.Find(ChannelName);

            if (channel == null)
            {
                channel = new HttpNotificationChannel(ChannelName, ServiceName);
                channel.ChannelUriUpdated += ChannelUriUpdated;
                channel.Open();
            }
            else
            {
                RegisterForNotifications();
            }

Basically this means that the first time the app asks for HttpNoticiationChannel (by calling the Find-method), it won’t get anything back so it will create a new one. After this the calls to Find-method will return the available channel.

The problem

The problem is that HttpNotificationChannel.Find may return a channel which doesn’t work anymore. The push notification recipe released by Microsoft bypasses the the subject by stating the following:

We highly recommend that you open (or create) the PN channel and send the push channel URI to your web service each time you initiate the application. Sending the URI every time your application starts, ensures that your web service has the latest URI for your phone.

The recipe points out the example implementation of this (PushContext.cs, Connect-method):

                // First, try to pick up an existing channel.
                NotificationChannel = HttpNotificationChannel.Find(ChannelName);

                if (NotificationChannel == null)
                {
                    // Create new channel and subscribe events.
                    CreateChannel(prepared);
                }
                else
                {
                    // Channel exists, no need to create a new one.
                    SubscribeToNotificationEvents();
                    PrepareChannel(prepared);
                }

But even this example presumes that the call to HttpNotificationChannel.Find(ChannelName) will return a working channel. My instinct on the subject is that the Find-method will always return the channel which has been created by calling the Open-method of HttpNotificationChannel, when the connection has been created in the first place. The Find-method doesn’t check if the channel is actually available or usable.

The solution

The solution to this problem is actually quite easy: The Close-method of HttpNotificationChannel will remove the known association between your app and the Microsoft’s site, making the next call to Find-method return a null, allowing you to create a new channel.

Conclusion

My recommendation is to call the HtppNotificationChannel.Close every time your app is closing. This way your users will get a fresh channel every time they start the application. It’s just up to you as a developer to keep track of the device’s current channel’s uri.

Believe it or not, my LG Optimus 7 is not receiving the push notifications anymore and the only thing I can blame is the first update. I've tried to test this with freely available apps and also with a custom app and they both show the same problem: The phone isn't receiving the notifications.

I created a small app and service to test this out. When run through the WP7-emulator, the emulator properly receives the notifications. But when deployed and run from the device, the notifications get lost. The service is using WindowsPhone.Recipes.Push.Messages to send the toast notifications. When the service is run through the debugger, it seems that everything is working proberly. Here's two screenshots. The first message shows the MessageSendResult when the notification is sent to the emulator and the second picture show the MessageSendResult of sending the notification to the actual device.

As you can see, from the notification's sender perspective everything is working OK. The NotificationStatus and SubscriptionStatus are the same in both cases, but only the emulator is receiving the notifications.

Like I mentioned, the problem seems to affect every app. Any ideas? Previously things have worked OK and I have couple apps which I have developed and tested with the same phone. And now the phone is ignoring the notifications from both of those applications.

It seems that the update is here:

The phone reports the following version information (though I have no idea how the values looked like before):

• OS version: 7.0.7008.0
• Firmware revision number: 1.0.1.12
• Radio software version: 1.0.1.12
• Bootloader version: 1.5.0.0

Update: Here is the previous version information:

• OS version: 7.0.7338.0

The thing is, I’m not sure what this update brought. The copy-paste functionality doesn’t seem to be there or if it is, it works differently than it does in the emulator.

Another update: Well, this explains everything.