Category: Windows Phone

At MWC today Nokia announced the Lumia 610 which is a lower spec device designed for emerging markets. This is running an updated Windows Phone OS which supports devices with just 256MB of RAM. To enable developers to create apps which support the new lower memory devices Microsoft are releasing an update to the Windows Phone SDK – 7.1.1.

At the moment a CTP has been released so that you can test your applications on a 256MB emulator but you should not install this to your main development machine as it doesn’t have a Go-Live license. To try out the new SDK you can download the CTP here:-

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=28962

There is just one API addition to support this change which is an additional property available from Microsoft.Phone.Info.DeviceExtendedProperties.GetValue – “ApplicationWorkingSetLimit” which will let you know whether you are running on a device with 256MB RAM. If your app/game is sufficiently resource heavy that you don’t feel it will run on such a device you can opt out so that your app/game will not be available on these lower powered devices. This is done by adding the Requirements element to your WMAppManifest.xml:-

<Requirements>
      <Requirement Name=”ID_REQ_MEMORY_90″ />
</Requirements>

The other main difference for these devices is there is no support for Background tasks – either Periodic or ResourceIntensive and attempting to add a background task on one of these devices will throw an InvalidOperationException – so it’s important to to check the capabilities first. Because of this limitation you need to design your app such that it doesn’t rely on a background task and that whatever sync/processing the task normally performs can be done when the app is running in the foreground.

Microsoft have prepared some information on optimising apps for 256MB and it is available here:-

http://msdn.microsoft.com/en-us/library/hh855081(v=vs.92).aspx

Some of the suggestions including using the built in launchers and choosers rather than running functionality such as the WebBrowser control or Bing Maps control within your app. They also suggest avoiding using the page transitions provided by the Silverlight Toolkit but don’t suggest an alternative – not sure if this means these devices don’t have the smooth page transitions at all or if they are suggesting that doing them from managed code is too resource intensive. You may decide to implement multiple approaches and use different methods depending on the device capabilities. Obviously the trick here is the balance between providing the best possible experience on each platform and avoiding adding too much more code to maintain.

Microsoft have published details of a new update (7.10.8107.79) which adds a number of fixes to the Mango release. It fixes the issue where the on screen keyboard will randomly hide itself which I’ve been finding frustrating recently and also a fix for the SMS bug which could disable messaging. It also hopefully finally resolves the issue when forwarding Exchange messages where the original message body would disappear. It hasn’t shown up yet but expect it over the next couple of weeks. Full details on all the updates and fixes are published here:-

http://www.microsoft.com/windowsphone/en-us/howto/wp7/basics/update-history.aspx

I’ve been working on an update to the Tasks application which adds in background synchronisation using the new background task support in Windows Phone 7.5. As with any app when you submit your XAP static analysis is performed on it to check, for example, that you have declared the correct capabilities based on the functionality in your app. Within a background agent you are only allow to call a subset of APIs – as you would expect you can’t play sound effects or draw to the UI (with the exception of toast notifications and tile updates). Because the main app has to include a reference to the dll which provides the background task, and the functionality within the dll is used in both the background task and the main app it made sense to move all of the logic into the background dll. This meant including a number of third-party references. I was very careful to ensure that nowhere in the background task was any restricted API called and it worked perfectly in testing.

The first problem is that upon submitting the static anaylsis looks at all of the referenced dlls and sees that they contain APIs not permitted in a background task and blocks the XAP. One of the culprits was InTheHand.Phone.dll (Part of Mobile In The Hand) because it provides a mixture of helper classes for logic and for UI. As I’ve been working on the 7.1 version in tandem I’ve now split this into two assemblies for Windows Phone 7.1 SDK projects. This means we can continue to use InTheHand.Phone in background tasks and add a reference to the second assembly in the main application only.

The second problem is that code within the sync logic calls ScheduledActionService.Add which is disallowed within a background task. This API is used within Tasks to add system-wide reminders (Another new feature for this version) for new task items. The code also has the ability to update and delete reminders based on modified or deleted tasks but these do not seem to have been flagged up as errors. This is a pain because it means that if the device syncs a new task with a reminder set to show before you next open the foreground app we won’t have had a chance to register it.

The other issue with the NeutralResourceLanguage is an issue with projects originally created with an older version of the development tools. You can add this setting from the projects properties, Application tab and click “Assembly Information…”.

This has been an interesting learning experience and shows that the validation picks up not just APIs used in the background agent code-path but also in referenced assemblies.

Anyone who has built an application for Windows Phone 7 in multiple languages will know there are three parts to the process. Within your application you can use managed RESX resource files to provide localised strings. For your application title or the initial text for your Live Tile you must use native resource dlls. Then when you are ready to submit your application to Marketplace you’ll need to provide descriptions, keywords and screenshots tailored for each supported language. At the moment there are six possible languages on the device side:-

• English (United States)
• English (United Kingdom)
• French
• German
• Italian
• Spanish

On Marketplace there are five languages – English (International) is used to cover both variants above. Even if your icon is standard across all languages you still have to submit it with each language as you upload to Marketplace.

There are several ways you can get your text translated, however one thing we noticed from experience is that certain features have established names in these different markets which may not equate to a direct translation from the English. Because the emulator and all retail Windows Phone 7 devices support all six languages you can easily change your device language and see how your application looks.

Feature names

For my future reference (and for yours) I’ve included a table below of some of these which may be useful. As I compile a list of more common words and commands I’ll add them to the table:-

Common Controls

See also my previous post with localised resources for the Silverlight Toolkit which localises the Date/Time pickers and ToggleButton controls. This also works with the latest February release of the toolkit, simply use this destination folder:-

C:Program Files (x86)Microsoft SDKsWindows Phonev7.0ToolkitFeb11Bin

The exception which proves the rule

Finally another observation which is specific to German. While the UI normally displays pivot headers and toolbar/menu text in lower-case this is not true for German where items should be capitalised.

The Silverlight Toolkit for Windows Phone (Latest version is February 2011) contains a Tilt Effect implementation. To add it to your controls requires the addition of an XML namespace definition and one dependency propery set in your page XAML.

<phone:PhoneApplicationPage

…etc…
xmlns:toolkit=”clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone.Controls.Toolkit”
toolkit:TiltEffect.IsTiltEnabled=”True”>

However the implementation doesn’t apply the effect to all the same places as you will find it in the native application. So far I’ve identified the ListPicker and MenuItems within the ContextMenu control. You can add additional types to receive the Tilt effect and I’ve raised an issue in the CodePlex project so hopefully this will be addressed in the next update. In the meantime you can add the following to your App constructor:-

TiltEffect.TiltableItems.Add(typeof(ListPicker));
TiltEffect.TiltableItems.Add(typeof(MenuItem));

By itself I found that this didn’t actually fix the ContextMenu and the items do not tilt as they do in built in applications. However all is not lost! If you apply the property to each entry in your ContextMenu it does use the feature:-

<toolkit:ContextMenuService.ContextMenu>
<toolkit:ContextMenu>
<toolkit:MenuItem toolkit:TiltEffect.IsTiltEnabled=”true” Name=”firstMenuItem” Header=”edit” Click=”FirstMenuItem_Click”/>
<toolkit:MenuItem toolkit:TiltEffect.IsTiltEnabled=”true” Name=”secondMenuItem” Header=”delete” Click=”SecondMenuItem_Click” />
</toolkit:ContextMenu>
</toolkit:ContextMenuService.ContextMenu>

Once you’ve done this you’ll have a context menu which behaves closer to the built in control. The Silverlight Toolkit is a great resource for additional controls and features which are not present in the Windows Phone 7 SDK. As always I’m eagerly awaiting the next update!

The latest update for Windows Phone 7 adds automatic support for Copy and Paste to TextBox controls in your application. By default this means you can’t copy text from static TexBlock controls. There is however a solution which requires minimal changes to implement. You have to replace the TextBlock control with a TextBox and set the IsReadOnly property to true. At first glance this will totally ruin the look of your application – even if you set custom background/foreground colours the control will display in grey on grey when IsReadOnly is true. It is possible to change this behaviour by applying a custom template to the control. Originally I did this in Blend but I found it had generated much more XAML than absolutely necessary so I set about removing redundant parts to result in this:-

<ControlTemplate x:Key=”PhoneDisabledTextBoxTemplate” TargetType=”TextBox”>
            <ContentControl x:Name=”ContentElement” BorderThickness=”0″ HorizontalContentAlignment=”Stretch” Margin=”{StaticResource PhoneTextBoxInnerMargin}” Padding=”{TemplateBinding Padding}” VerticalContentAlignment=”Stretch”/>
</ControlTemplate>

Simply add this to the Resources collection for your page.

Then your TextBox is customised like so:-

<TextBox Grid.Row=”1″ Name=”TextBlockCopyable” IsReadOnly=”True” TextWrapping=”Wrap” Foreground=”{StaticResource PhoneForegroundBrush}” Template=”{StaticResource PhoneDisabledTextBoxTemplate}” Text=”We provide software solutions for a mobile world. We have unrivalled expertise in designing, developing and supporting mobile software for Windows Phone and Windows Embedded.” FontSize=”{StaticResource PhoneFontSizeMedium}” />
           

The result looks and behaves like a TextBlock and still follows your system theme but allows copying on the latest emulator.

I created a sample project with all of the code showing the different behaviours of the TextBlock, read-only TextBox and customised TextBox.

Following my review of the LG E900 handset we have the opportunity for one lucky winner to get a Windows Phone 7 of their own. All you need is a little creativity and this handset could be on its way to you!

Good luck!

Due to the absence of a built-in DatePicker control many are using the Silverlight Toolkit which has a Silverlight implementation to match the control used in the native applications. One limitation in the current release is that the UI is only available in English. The day/month names are retrieved based on the device locale but the page header and text labels for buttons are always in English. I had a look at the code to implement a fix, interestingly I found that the strings were already stored in resource files, it’s just that there were no resources for other languages. I’ve submitted a set of .resx files to cover all the currently supported Windows Phone 7 languages so hopefully my patch will be integrated in a future release. I’ve also discovered that by creating my own localised resource dlls from the latest source I can use them against the current release binary. We are sharing these files for other developers who use these controls and write multi-language software for Windows Phone. To use these simply copy the contents of the ZIP file into the install folder for the November 2010 toolkit on your machine which will be somewhere similar to “C:Program Files (x86)Microsoft SDKsWindows Phonev7.0ToolkitNov10Bin”. As a bonus these resources also localise the On/Off text on the ToggleButton control.

If you’ve not attempted building a localised application before have a look at this article on MSDN – http://msdn.microsoft.com/en-us/library/ff637520(v=VS.92).aspx. Mostly this involves standard RESX editing but for Windows Phone you have to make a minor edit to your project file with a text editor, hopefully this can be fixed in a Visual Studio Patch/Service Pack.

The Windows Phone 7 Emulator takes a fairly bare-bones approach having only Internet Explorer available by default. Because it’s easier when presenting to use the Emulator than to try and capture a device screen with a camera it would be nice to show off features of the platform as part of your demonstration – not just your own apps. We put together a simple XAP package to install a Marketplace client onto the emulator, this allows you to demonstrate the Marketplace experience (with live data) and even show your clients how their apps appear within Marketplace. You cannot download apps to the emulator as it will not allow you to sign in with a Live ID – this is provided purely for demonstration purposes.

The Windows Phone 7 emulator is very limited compared with the real phones so there are no built in applications other than Internet Explorer. This can make it difficult to test some of the APIs which interact with data on the device. Luckily there is a way to load contact data onto the emulator which allows you to use these tasks as if you were working against real contacts from your Exchange server or wherever. The trick to this is that the system supports the vCard standard which allows you to attach contact items to emails or via the web. Internet Explorer understands vCard files and provides the option to save them in the People list on the phone. For example you can browse to https://inthehand.com/share.vcf to see how this process works. From within your application you can also use the WebBrowserTask (AFAIK it does not work when you host the WebBrowser control in your own app).

Tap the contact image to open in a new contact page:-

You can make changes to the contact and then tap the disk icon to save.

When you close the emulator the contents are not persisted so you’ll have to repeat this each time you launch the emulator. Unfortunately this doesn’t appear to support vCard files containing multiple entries. However having just one entry in there allows you to test your app flow where you have a contact picking scenario.

If you want to test the PhotoChooserTask you can also import images to the emulator. Simply visit any website and tap and hold over an image – select “save picture” from the context menu which pops up. These are placed in a “Saved Pictures” folder.

The PhoneCallTask and SmsComposeTask work as expected (like the Windows Mobile emulators there is a fake mobile network). The EmailComposeTask does not work as there is no account on the emulator and no way to add one. When you launch it you’ll get an error popup.