(0) exportieren Drucken
Alle erweitern
EN
Dieser Inhalt ist in Ihrer Sprache leider nicht verfügbar. Im Folgenden finden Sie die englische Version.

Implementation Differences Between Silverlight and Silverlight for Windows Phone

This topic describes feature implementation differences between Silverlight on Windows Phone and Silverlight 4 on other platforms. This topic also describes some differences between Silverlight on Windows Phone OS 7.0 and Windows Phone OS 7.1.

The following topics also provide additional information about Silverlight for Windows Phone.

The following sections in this topic provide detailed information about Silverlight for Windows Phone.

For information about supported and unsupported controls, see Controls in Silverlight for Windows Phone.

Silverlight for Windows Phone always uses hardware acceleration on a MultiScaleImage image, if possible. As a result, any change you make to the CacheMode property of MultiScaleImage is ignored.

Asynchronous delegate calls, specifically the BeginInvoke and EndInvoke methods, are not supported in Silverlight for Windows Phone. Consequently, the following code is not supported:

AsyncCallback callback = new AsyncCallback(result);
callback.BeginInvoke();

Some exceptions are different in Silverlight for Windows Phone when using delegates:

Constrained execution regions (CERs) are not supported in Silverlight for Windows Phone.

For information on supported fonts in Silverlight for Windows Phone, see Fonts in Silverlight for Windows Phone.

When you specify a generic type you can specify a maximum of 64 generic type parameters. If you are using generics types with LINQ to SQL, you can use nested queries to work around this limitation.

The graphics threading architecture in Silverlight for Windows Phone is optimized for devices. For information on the threading architecture and how to improve graphics performance, see Graphics in Silverlight for Windows Phone.

In Silverlight for Windows Phone, effects such as BlurEffect and DropShadowEffect are not supported.

Custom pixel shaders are not supported, so the PixelShader type is not supported.

For additional information about graphics and animation in Silverlight, see the following topics.

Silverlight applications on Windows Phone are hosted on the client device and do not run inside of a browser. Silverlight features that are based on a browser host are not supported. These features include the HTML DOM bridge, JavaScript programmability, and the Silverlight plug-in object reference.

Controls that are supported on Windows Phone are gesture-aware, and support gestures such as tap, double-tap, hold, pan, and flick.

For additional information on input differences between Silverlight on Windows and Windows Phone, see Input in Silverlight for Windows Phone.

For information on using manipulation events to respond to touch input, see How to: Handle Manipulation Events.

For information on platform differences associated with I/O streams, see Streams in this topic.

Isolated storage allows applications to store data in a virtual file system. The data is completely isolated from other system components. This prevents unauthorized access and data corruption by components other than the application that is storing the data.

As in Silverlight on Windows, the data is automatically deleted when you uninstall the associated application on the Windows Phone. The data is retained in other scenarios, including a device or application update, or a device restart.

Isolated storage on Windows Phone does not enforce quotas to restrict the size of isolated storage for Silverlight-based applications. The default quota size of 1 MB does not apply.

Implementation differences between Silverlight on Windows Phone and Silverlight on Windows include the following:

  • Isolated storage on Windows Phone does not include the concept of a site; therefore, GetUserStoreForSite is not supported.

  • IncreaseQuotaTo throws an exception.

  • When you call BeginRead or BeginWrite in a Windows Phone application, the operation is executed synchronously. If you need to write a large amount of data and do not want to interrupt the UI thread, you can create a new thread and perform the operation on that thread.

  • In the IsolatedStorageFileStream class constructor, FileShare.Delete and FileShare.Inheritable are not supported because of a platform limitation. Passing a value of Delete will cause a IsolatedStorageException.

  • The default quota size returned to an application is MAXLONG.

  • IsolatedStorageSettings is not thread safe and throws an IsolatedStorageException when Save() is called.

  • When using isolated storage, strings that contain wild card characters or regular expression are not supported when passed as input if the string also contains a filename or a directory name.

For information about isolated storage in Silverlight, see the following topics:

LINQ query providers for custom data sources are not supported in Silverlight for Windows Phone.

LINQ to XML

The following limitations apply to LINQ to XML support:

The constructor for the XmlSerializer object throws an InvalidOperationException if the XmlSerializer object is initialized with a type parameter that contains two XElement members and both are marked with the XmlAnyElementAttribute.

Expression Trees

LambdaExpression.Compile is not supported in Windows Phone SDK.

Silverlight for Windows Phone throws an exception while trying to create a new object using a lambda expression that targets expression trees. For example,

Expression <D1> d = () => new N(); will compile, but fails at runtime.

Support for globalization is based is based on the cultures and regions supported by the underlying platform. For additional information, see Creating Globally Aware Applications. For information on culture names supported on Windows Phone, see Globalization and Localization Overview for Windows Phone.

Some of the types and members that support localization behave differently on Silverlight for Windows Phone, as follows:

  • A custom culture returns standard formatting when custom formatting is expected. For example, 31/08/2006 12:30:15 Afternoon! returns as 8/31/06 12:30:15 PM.

  • You cannot use a neutral culture in formatting and parsing; therefore you cannot set a neutral culture as the thread's current culture.

  • DateTimeFormatInfo.ShortTimePattern values do not change when the clock is set to 24 hours. The property values should become "h:mm" but remain "h:mm tt" where tt is AM or PM.

  • ToString() does not return the expected value for a null format and Invariant Culture.

  • DateTimeFormatInfo.GetEra returns -1 for the fr-FR culture.

  • new CultureInfo(“fr”).DateTimeFormat.AMDesignator throws a NotSupportedException.

  • DateTimeFormatInfo.GetEraName method returns incorrect values in some cases. For example, the fr-FR localization string DC is returned when A.D is expected.

  • DateTime.ToString does not return the correct string for Russian dates. For example, 15.Июнь.2000 is returned instead of 15.июня.2000.

  • System.DateTime.Now.Millisecond.ToString always returns zero on the Windows Phone Emulator.

  • Double.ToString does not return the correct string containing comma delimiters between group digits when a custom format is used.

  • ResourceManager.GetSatelliteContractVersion returns a random version number instead of the expected value.

  • String comparison operations for strings containing trigraphs may not work as expected for cultures where trigraphs are used, such as "dzh" in the culture hu-HU. For example, IndexOf(String, String, CompareOptions) and IsSuffix(String, String, CompareOptions) may return an incorrect result.

  • The constructor, ResourceManager(String, Assembly, Type), throws NotSupportedException when the usingResourceSet parameter is null.

  • ResourceManager.GetObject does not throw an exception when the object is missing in the resource file.

Some localization exceptions thrown by applications are different in Silverlight for Windows Phone:

For information about media implementation differences between Silverlight on Windows and Silverlight on Windows Phone, see Media in Silverlight for Windows Phone.

To enable multitouch and manipulation events, Silverlight for Windows Phone supports types, members, and events that are not present in Silverlight 4. For additional information, see How to: Handle Manipulation Events.

For information on input differences between Silverlight on Windows and Windows Phone, see Input in Silverlight for Windows Phone.

Silverlight for Windows Phone provides a different page navigation model than Silverlight on Windows. The Frame and Page classes are not supported. The implementation of these classes and some navigation-related events such as the FragmentNavigation event, are provided in the Microsoft.Phone assembly instead of the System.Windows.Controls.Navigation assembly. For additional information, see the Frame and Page Navigation topic in Windows Phone Development.

In Windows Phone OS 7.1, if you use the NavigationEventArgs(Object, Uri) constructor to create a NavigationEventArgs and pass null for the uri parameter, when you later access the Uri property, it will be an empty Uri.

For information about networking implementation differences between Silverlight on Windows and Silverlight on Windows Phone, see Networking in Silverlight for Windows Phone.

On Windows Phone, Environment.CurrentDirectory and Environment.GetFolderPath have a SecurityCriticalAttribute attribute, because Silverlight for Windows Phone is based on Silverlight. This attribute restricts this member to internal use. Application code that uses this member throws a MethodAccessException.

Some path-related exceptions thrown by applications are different in Silverlight for Windows Phone:

  • If you pass an invalid path in GetDirectoryName, the method does not throw an exception. For example, System.IO.Path.GetDirectoryName(@"D:\temp\ .") returns "D:\temp" instead of throwing an exception.

  • GetDirectoryName does not throw any exception when the source path is longer than the system-defined maximum path length.

  • GetPathRoot returns an empty string when the input is prefixed with whitespace.

  • System.IO.Path.GetPathRoot(String.Empty) returns a null string instead of throwing an ArgumentException.

  • System.IO.Path.GetPathRoot(@":hello") returns a null string instead of throwing an ArgumentException.

Silverlight for Windows Phone supports a composition thread for certain graphics animation and access to the graphics processing unit (GPU). For information on optimizing graphics performance using this architecture, see Performance Considerations in Applications for Windows Phone and Graphics in Silverlight for Windows Phone.

Note Note:

The frame rate counter in Silverlight for Windows Phone is different than the frame rate counter on Windows. For additional information, see Graphics in Silverlight for Windows Phone.

To optimize XAML code when applying multiple transformations, Silverlight for Windows Phone supports CompositeTransform.

For Silverlight performance tips, see Performance Tips.

Reflection implementation differences between Silverlight on Windows and Windows Phone are as follows:

Some exceptions thrown by reflection-based applications are different in Silverlight for Windows Phone:

In Silverlight for Windows Phone, the CacheSize property always returns zero because the Regex class implementation does not support caching.

If you pass an invalid value to MatchCollection.CopyTo(Array, Int32), the method throws ArgumentOutOfRangeException instead of ArgumentException.

Silverlight for Windows Phone runs on the .NET Compact Framework. Applications written for previous versions of Windows Phone or for .NET Compact Framework 3.5 or earlier are not supported on Windows Phone.

Windows Phone applications typically must support different screen resolutions for orientation changes. For application design tips, see Designing a Flexible User Interface.

The following differences apply to X509 certificates:

To enable you to set the software input panel (SIP) on a TextBox control, Silverlight for Windows supports several types and members that are not present in Silverlight. For more information, see How to: Specify On-Screen Keyboard Layout for a TextBox.

For additional features that are specific to Windows Phone development, see the Class Library Reference for Windows Phone. These features are included in the Windows Phone SDK.

The following differences apply to the use of streams:

A StringBuilder object can allocate more memory as needed as characters are added to the object. The amount of memory allocated is implementation-specific, and an OutOfMemoryException is thrown if the amount of memory required is not available. If an alternative to StringBuilder is needed, open a MemoryStream and write strings to the memory stream instead of using the StringBuilder class.

If you call Replace when a null character exists in the string, the new string will be truncated at the first null character.

The String.IndexOf method returns incorrect output when the string contains Unicode characters.

The String.LastIndexOf(String, Int32, StringComparison) method returns incorrect values when the string contains Unicode characters.

The StartsWith(String, StringComparison) method returns incorrect values when the string contains Unicode characters.

Unlike Silverlight, Silverlight for Windows Phone splits animation work on two different threads for better performance on devices. For additional information, see Graphics in Silverlight for Windows Phone.

Array.Sort(Array) is not thread safe.

ThreadStaticAttribute is not used by the Silverlight for Windows Phone.

WaitAll is not supported in Silverlight for Windows Phone.

The 64-bit members of the Interlocked class are present but not supported.

In Silverlight for Windows Phone, the HttpUtility class is in the System.Net namespace. On Windows, this class is in the System.Windows.Browser namespace, which is an unsupported namespace on Windows Phone.

LocalPath does not convert the forward slash (/) to a backslash (\). This is because file-based URIs (URIs of the form file://) are not allowed. Paths returned are relative paths.

The OriginalString property for a Uri instance trims any leading space before the scheme in the URL.

To optimize XAML when you are applying multiple transformations, Silverlight for Windows Phone supports CompositeTransform.

Parse is not supported in Silverlight for Windows Phone because Silverlight for Windows Phone does not support document type definitions (DTDs). The application throws a NotSupportedException when it encounters a DTD string in XML. To parse DTDs, an application must either implement this feature or use XML schemas.

The following differences also apply to Silverlight for Windows Phone:

Some XML exceptions thrown by applications are different in Silverlight for Windows Phone:

XNA Framework for Windows Phone and Silverlight for Windows Phone are dependent on .NET Compact Framework for base class library support. Most of the supported types and members are the same. For additional information, see XNA Framework and Silverlight.

Additional implementation differences in APIs are as follows:

  • When you try to create circular nested generic classes, a TargetInvocationException is thrown. You cannot create a circular nested generic class in Silverlight for Windows Phone.

  • Classes in the System.Collections namespace do not throw ArgumentNullException when a null parameter is passed to the constructor. For example, Dictionary<object, object>.ValueCollection valueCollect = new Dictionary<object, object>.ValueCollection(null) does not throw ArgumentNullException.

  • GetHashCode returns equal values for different methods of the same class.

  • GetHashCode returns zero for some user-defined structs in Silverlight for Windows Phone, but non-zero values in .NET Framework.

  • Decimal.Parse returns an invalid decimal value when exponents are used for values near zero. On Windows, the method returns zero. For example, for the values 0E-50 and 10900E-512, an invalid decimal value is returned instead of zero.

  • The value of Math.Sin(Math.PI/2) is 0.99999999999999989. The value on Windows is 1.

Some methods throw different exceptions in Silverlight applications on Windows versus Windows Phone. The following information describes this behavior on Windows.

Anzeigen:
© 2014 Microsoft