post

Developers can update to Mango RTM without falling back to NoDo!

Microsoft has sent an email to all registered developers that there is no need to fall back to NoDO, as they previously stated, but instead can update their phones using the Zune as if nothing ever happened 🙂

To be honest, this news has made me say: “way to go MS devs” for the first time in my life!

In short, this is what they said (copy/paste):

‘Mango’
OS Beta: Updating from 7712 to RTM

Developers can now update their devices to Windows Phone 7.5 without having to
fall back to the backup taken at the beginning of the provisioning process.
This update is being made available to those running build 7712 on a retail
device that was updated using the provisioning tool we published to Connect a
couple months ago. 

Have a nice upgrade! 😀

Modifying the previously released WP 7.0 version of the app is not possible once the Mango version is released!

Recently the folks from MS answered a very frequently asked question, and their answer is copied below. 

When you publish a Windows Phone ‘Mango’ update to an application you had previously published, the following will occur:
  • The WP 7.0 version of your application will remain available to all users on WP 7.0 devices.
  • The WP ‘Mango’ version of your application will be available to all users on WP ‘Mango’ devices.
  • WP ‘Mango’ users who previously installed your application will receive an update notification. This will occur even if they installed your application prior to updating to WP ‘Mango’
  • WP 7.0 users who have installed your application, but not updated to WP ‘Mango,’ will not receive an update notification.
  • The WP7.0 rankings & reviews that your application received will attach to your new updated WP ‘Mango’ version too.
  • The application metadata and screenshots for Windows Phone Marketplace submitted with the WP ‘Mango’ version of your application will be shared across both the WP 7.0 and WP ‘Mango’ versions of the application; i.e., a single set of metadata and screenshots will appear to both WP 7.0 and WP ‘Mango’ users.
  • Once you have released the WP ‘Mango’ version of your application, you will no longer be able to modify the previously released WP 7.0 version of your app. We realize that some of you may worry about this limitation, and so we’re actively working on ways to mitigate it. To improve the experience for users, it’s our preference not to have “duplicate versions” of your apps in the marketplace. We are also going to work hard to encourage our pre-existing users to enjoy the free upgrade to Mango as quickly as possible.
 
 
As you can see, we have a problem here! There is no way to update a pre-mango release after you have released the mango update! Since the majority of users still haven’t updated to Mango there is a need for frequent update of the pre-mango versions.
There is a workaround though, you can publish the pre-mango app which is using mango components if the app detects that the mango is available on the phone! This is done using the reflection, so if you are interested, knock yourselves out! Read more about it! 

Brush object serialization and Isolated Storage

You probably already know that you cant serialize Brush objects using Isolated storage default serialization engine, so there are a few ways you can overcome this simple problem. There are a few approaches to solving this problem and some of them include serialization of brushes Argb byte values, or brush Color values. I’m gonna show you how to create a simple serializable class in order to overcome this problem by serializing brushes Color.

using System.Windows.Media;
using System.Runtime.Serialization;

namespace TheTime.Model
{
    [DataContract]
    public class BindableBrush
    {
        private string _brushName;
        /// <summary>
        /// Initializes a new instance of the BindableBrush class.
        /// </summary>
        public BindableBrush(Color c, string name)
        {
            Color = c;
            _brushName = name;
           
        }

        [DataMember]
        public Color Color
        { get; set; }


        public SolidColorBrush Brush 
        {
            get
            {
                return new SolidColorBrush(Color);
            }
            set
            {
                Color = value.Color;
            }
        }

        [DataMember]
        public string BrushName
        {
            get
            {
                return _brushName;
            }
            set
            {
                _brushName = value;
            }
        }
    }
}

This simple solution serializes the Color object and creates a SolidColorBrush on request. Using this class you can bind to the Brush property without any problem…

Hope it helps!

Hiding the Windows Phone 7 keyboard (SIP) when enter key is typed

There is only one way to close the SIP (Soft Input Panel) by default in Windows Phone 7, and it is by changing focus from the TextBox that is being edited to something else on the screen. As an android user, I am used to close it by hitting the enter key once the text editing is done so I’m gonna show you how to do it and hope it will become a practice.
What we need to do here is change the focus to something other than the TextBox we are currently editing, and for that purpose the PhoneApplicationPage that contains this TextBox will do just fine. All we have to do first is make this page a TabStop so we can enable it to recieve the focus.

<phone:PhoneApplicationPage 
x:Class="PanoramaPivotControls.SettingsPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
IsTabStop="True">

...

</phone:PhoneApplicationPage>

Next thing to do is add the KeyUp event handler to the TextBox and implement it.

<TextBox KeyUp="TextBox_KeyUp">

 

private void TextBox_KeyUp(object sender, KeyEventArgs e)
{
     if (e.Key == Key.Enter)
     {
         this.Focus();
     }
}

 

And that’s it! The SIP is now closed when Enter key is typed in!

Hope you find it useful..

Disabling Windows Phone 7 lockscreen aka Idle detection

Ready for another really useful code snippet? 😀

This time its few lines about the prevention of the lockscreen appearance. Everyone knows about it, but not everyone is really sure how to use it and what are the consequences of its use.

First things first, lets learn how to use it.


Everything we need here is only one property, the UserIdleDetectionMode of the current phone application service. It can be set to either enabled or disabled, and is always recommended to store its current state before you change it, so that you can set it back to whatever value it had before you started messing with it. This is best done  by using a private variable in your App.xaml.cs. Launching and activating events should be used to store the original setting prior changing it to the mode you want, and deactivating and closing events for setting the original setting back.

 

private void Application_Launching(object sender, LaunchingEventArgs e)
{
    _originalMode =PhoneApplicationService.Current.UserIdleDetectionMode;
    PhoneApplicationService.Current.UserIdleDetectionMode= IdleDetectionMode.Disabled;
}

private void Application_Activated(object sender, ActivatedEventArgs e)
{
    _originalMode = PhoneApplicationService.Current.UserIdleDetectionMode;
   PhoneApplicationService.Current.UserIdleDetectionMode= IdleDetectionMode.Disabled; 
}

private void Application_Deactivated(object sender, DeactivatedEventArgs e)
{
   PhoneApplicationService.Current.UserIdleDetectionMode = _originalMode ;
}

 private void Application_Closing(object sender, ClosingEventArgs e)
{
    Microsoft.Phone.Shell.PhoneApplicationService.Current.UserIdleDetectionMode = _originalMode ;
}

And that’s it.. I’ve set the mode to disabled in the code snippet but you could set it to enabled it it suits your needs..

In the end, it is important to be very careful with switching this property of, as it could drain your battery in matter of hours as your app will never be deactivated by a lockscreen.. please take some time to examine the important notes on this page before you start playing with it.

Setting image source programmatically depending on the current phone theme

Every Windows Phone 7 application needs to support both dark and light themes, so it is sometimes needed to change the image displayed depending on the current phone theme. At the moment, there is only one way to find out the theme that is currently being used and it is achieved by examining the PhoneLightThemeVisibility resource. Its not the most clever way to go, but its all we have for now.

Visibility v = (Visibility)Resources[“PhoneLightThemeVisibility”];
String url = v==Visibility.Visible?
“/MYAPP;component/Icons/Light/checkWithCircle.png” : “/MYAPP;component/Icons/Dark/checkWithCircle.png”;

Uri imgURI = new Uri(url, UriKind.Relative);
UniversalImage.Source = new BitmapImage(imgURI);

Hope it helps!

P.S. if you are trying to access Resources from something other that UIElement (e.g. from the ViewModel class), you could use Application.Current.Resources to get the PhoneLightThemeVisibility resource.