Sunday , 21 December 2014

How to profile a silverlight application

Try profiling with the Visual Studio profiler in order to get a good measure of your managed code and the native code executing within Silverlight. The profiler will help point you to where you’re spending the most of your time (what the hot path’s are) and whether or not your spending it in framework (SL) code or your own code.

The basics of profiling are:

  1. Open a Visual Studio Command Prompt (as admin), ‘cd’ to the directory where your DLL and PDB files are (typically your "Debug" folder)
  2. VSPerfClrEnv /sampleon
  3. VSPerfCmd -start:sample -output:somefile.vsp VSPerfCmd -globalon VSPerfCmd -launch:"c:\Program Files (x86)\Internet Explorer\iexplore.exe" -args:""
  4. VSPerfCmd -shutdown
  5. VSPerfClrEnv /off

You can find detailed instructions on using the profiler on my blog:http://www.nachmore.com/2010/profiling-silverlight-4-with-visual-studio-2010/

If you find that you are spending time within Silverlight, track down the code path to see where your code is triggering the expensive calls, so that you can then investigate specific solutions based on the cause of the slow down.

Update :

Performance Wizard for Silverlight – taken from VS2010 SP1 KB.

Visual Studio 2010 SP1 enables you to tune the Silverlight application performance by profiling the code. A traditional code profiler cannot tune the rendering performance for Silverlight applications. Many higher-level profilers are added to Visual Studio 2010 SP1 so that you can better determine which parts of the application consume time.

For more details refer to article Profiling Silverlight Applications After Installing Visual Studio 2010 Service Pack ?

Optimize Silverlight applications for smaller size

When putting content on the web, it’s important to get that content to the user as quickly as possible. In general, reducing the amount of data users need to download is a big step in the right direction. As Silverlight applications are usually linked with rich user interface these includes lot of images and other resources.

Performance can become a real issue when the user has to download a total of 5MB or more just to run your application.

In this article I will talk about a few tricks to reduce the size of your silverlight application and thereby reduce the time it takes the application to start on the client.

Remove Extra assembly

By default Visual Studio will add quite a lot assemblies to your Silverlight applications. You application might not require all these assemblies.

The first step in optimizing your silverlight application for size is to remove excess assemblies from the application. A good way to achieve the desirect effect is to remove all assembly references, except for the System reference.

After that you will need to recompile and check for any compile errors that are caused by missing references.A quick way to get rid of these unused usings is to right click on them in Visual Studio 2008/2010 and choose Organize usings / Remove unused usings.

Make sure that you’re including references to assemblies that you actually need and nothing more. Sometimes you’ll need a reference to an assembly but you don’t want it set to "Copy Local", as that adds to the XAP. Visual Studio 2010 is usually good about automatically setting "Copy Local" when appropriate. For example, System.Windows.Controls is not part of the runtime (it’s a part of the SDK). Visual Studio knows this and when you add System.Windows.Controls to the project it automatically sets "Copy Local" to true. But when in doubt about an assembly reference, try setting "Copy Local" to false and see what happens. If your application builds and runs fine, then you’re good.

Reducing Size of final XAP package

The silverlight XAP package format is actually a ZIP container with a special manifest inside that is recognized by the silverlight runtime. The package that Visual Studio will create however is not compressed as efficient as it could be. However Visual Studio 201o has improved quite a bit in this area.

Another tip to get more bang for the megabyte is to unpack the XAP package and repack it using Winzip, Winrar or any other zip application.

Reduce XAP size by using application library caching

(not available for out-of-browser applications). Check this option in Visual Studio 2010 and when your project is built there will be extra files automatically generated. So you’ll have to upload your XAP file and any auto-generated ZIP files to the same directory. The generated ZIP files contain any external assemblies that your XAP require. Behind the scenes this relationship is automatically maintained with the AppManifest. This feature is pretty cool and very easy to use. You should note, however, that the whole idea behind it is caching. And so it speeds up requests from repeat visitors, but in practice it doesn’t do a thing to speed up the experience for a new visitor. Read more about this featurefrom Microsoft.

Other Tools to Automate everything related to optimization of Silverlight application for You

  1. XAPs Minifier Visual Studio 2010 plug-in

sometimes when working with a Silverlight app you might have an assembly reference that has been set to "Copy Local" when it doesn’t need to be. This is easy to overlook when working with a large Silverlight app composed of multiple projects. The XAPs Minifier is intended to remove any redundant or unnecessary assemblies.

2. ComponentOne XAPOptimizer

The XAPOptimizer is not free, but it does take optimization to another level. It goes beyond assembly removal. It’ll dig into every assembly through reflection and actually detect unnecessary classes, resources and entire sections of XAML. It’s also configurable in case it makes a mistake you can actually specify what to remove and save your settings. On top of this, it’ll optionally obfuscate your application, making it hard to reverse-engineer.

Conclusion

Often the most significant optimizations involve removing unnecessary or unused components or assemblies.

Silverlight MVVM light toolkit best practices

Basic Usage of MVVM-Light

  1. Intialize the DispatcherHelper in the App.cs file’s Application_Startup function
  2. Create ViewModels from the BaseClass
  3. Always Create a ViewModelLocator class, which contains all your view models and is Linked in your application Resources
  4. Use RelayCommands to expose Functions to your view
  5. Learn when to use the DispatchHelper.

Clean-Up Ideas:

    1. When appropriate, add to your ViewModel to clear your DomainContext’s EntitySet on Cleanup()?
    2. Call your ViewModelLocator’s CleanupSomeVM() function to clear viewmodels when they are no longer actively needed in the application.

I would love to hear from others about when/how you use CleanUp functions. As my application grows, I do feel the need to add some cleanup functions to better manage client memory usage.

For Blendability:

  1. Abstract the Service / Query Implementations to an Interface.
  2. Create 2 classes for each Service Implementation classes (1 for Design, 1 for Production)
  3. Within your each ViewModel, implement its own Service Class (use IsInDesignMode) to create Blendable Service implementations as necessary.
  4. Use a Static variable to hold your DomainContext within the Service Implmentation Class.
  5. Add DispatcherHelper.Initialize() in constructor of ViewModels, but only when in Design Mode. Blend does not load App when loading a page, and this works around that.

For Added Business Logic:

  1. Add Business Logic in the Model first, then in the ViewModel.
  2. Use the Model’s partial methods to add logic for appropriate change / update events.
  3. Add Read-Only properties (only getter) to provide summary and calculated values on your model.

For Views:

  1. Always Bind the root to the Locator Object.
  2. Try to keep code-behind logic to layout or custom UI logic only. Avoid referencing your ViewModel.

For Collections:

  1. Use CollectionViewSource for collections in your ViewModels, with a source of the DomainContext’s EntitySet
  2. Apply all Filtering, Sorting, and Grouping Logic to the CollectionViewSource in your ViewModel.
  3. After ServiceCalls, Call .View.Refresh() on your CollectionViewSource objects as necessary to update the UI.

For ViewModel coordination (Controller Logic)

  1. Use Messages sparingly, too much complexity can be difficult to manage.
  2. Use the NotificationMessage and PropertyChangedMessage classes to Send/Receive with.

For RIA DomainServices:

  1. Implement any logging in the persist changes function, not the update/insert/delete logic.
  2. During Insert,Update,Delete functions, if you need to reference another Entity via Navigation Property, either check the EntityStatus first, or load the entity from another Context, to prevent EntityStatus conflicts.

For Debugging / Testing:

  1. Check the Output Window for Binding Errors and Fix them. Binding Errors fail silently to the user, but degrade application performance and expected behavior.
  2. Create Unit Tests in Silverlight to verify any added Model / Business Logic
  3. Create Unit Test project to test server-side logic and functions

For Entity Framework:

  1. Keep 1-to-1 Match of EntitiesContext to Domain Service. Trying to split this another way causes issues.
  2. Do NOT use the [Composition] attribute unless you fully intend to spend a lot of time carefully building your Insert, Update, and Delete logic.
  3. Use a separate service to serve custom types back to your RIA Client. Do not add them to your DomainService for your EntityFramework Object
  4. Perform Server-side update/integration logic (such as updating other systems) in the PersistChangeSet function, not in the Insert, Update, Delete functions. This will prevent you from accidentally pulling in an entity via Navigation Properties, which will leave your detached version non-updated.
  5. Create an additional Context to find current values during update/integration logic.

What is Dependency Property

A dependency property is a property on one object whose value depends on some other object. So, for instance.

  • The value of the FontFamily property of a TextBox can (and usually does) depend on the FontFamily property of its container. If you change the property on the container, the value on the TextBox changes.
  • The value of the Text property of a TextBox can depend on a bound data source. When the value of the bound property changes, the value of the Text property changes.
  • The value of the Opacity property of a Label can depend on an animation storyboard, in the common scenario where you’ve set up a UI element to fade in or fade out in response to some event.
  • The value of all kinds of properties on any UI element can depend on the style that you’ve applied to them.

The central concept behind dependency is that the thing that’s depending should get the property value from the thing it’s depending on. This is why a dependency property is implemented as a CLR property whose getter calls a method.

When the TextBox, or the thing that’s rendering it, needs to know what its FontFamily is, the FontFamily getter calls the GetValue method. That method finds the value from the container, or animation, or binding, or whatever.

There’s a lot of complexity in that method. If the value’s inherited, for instance, it works in a way that’s pretty analogous to how WPF finds styles in a resource dictionary: it looks in a local dictionary to find the value, and if there’s no entry it looks in its parent’s dictionary, and so on all the way up until it finds a value or reaches the top of the hierarchy, in which case it uses a default value.

If you look at the implementation of dependency properties, that’s what you’ll find. A dependency object has a dictionary that may or may not contain an entry for a given property. The GetValue method gets values from that dictionary (which is how objects with dependency properties can have local values that override what they’re inheriting from), and if it doesn’t find the value, it uses the metainformation about the property to figure out where it should look.

Since that metainformation is the same for every object in the class (i.e., TextBox.Text works the same for every TextBox), the dictionary it’s stored in is a static property of the class.

So when you see code like this:

static Button()

{

   // Register the property

   Button.IsDefaultProperty = 

     DependencyProperty.Register("IsDefault",

     typeof(bool), typeof(Button),

     new FrameworkPropertyMetadata(false,

        new PropertyChangedCallback(OnIsDefaultChanged)));

}

 

what’s happening is that the metainformation that defines the IsDefault property on all Button objects is being added to that dictionary. And when you see this:

public bool IsDefault

{

  get { return (bool)GetValue(Button.IsDefaultProperty); }

  set { SetValue(Button.IsDefaultProperty, value); }

}

what you’re seeing is the getter method that looks up the property’s value (from the local dictionary, the parent object, or whatever) based on that metainformation.

Remember how I said that the first place the getter looks to find a property’s value is in the object’s local dictionary? The SetValue method in the setter is how that entry gets added to the dictionary (if it’s ever called, which it will only be if you’re overriding the dependency by explicitly setting the property, i.e. saying "I want this TextBox to display text in Consolas irrespective of what the other controls in the window are using.").

A hugely significant benefit that we get from this kind of apparently-complex system is that dependency properties on objects only consume memory if they’re set. If I create 10,000 TextBox controls and add them to a Window, not one of them actually contains a reference to a FontFamily object. That’s 10,000 object references that I’m not allocating memory for, and that the garbage collector isn’t checking. In fact, if a TextBox has 100 dependency properties (and it does, just about), whenever you create a TextBox, that’s 100 backing fields you aren’t allocating memory for. Dependency properties only consume memory if you explicitly set them. Since the vast majority of properties on UI objects never get explictly set, these are fantastic savings.

Silverlight Auto logout user after 10 minutes of inactivity

 

Many projects have requirement to logout a user after some time of Inactivity user has not performed any activity for past 10 minutes we need to auto logout the user.

Solution

Use

DispatcherTimer SMNetworkTimer = new DispatcherTimer();

Sample implementation

App.xaml.cs

 

Declare a timer in app file as as follows
public static System.Windows.Threading.DispatcherTimer _Logouttimer = new System.Windows.Threading.DispatcherTimer();
private static DateTime App.timer=DateTime.Now; // this variable helps in finding the user interaction time in master page

public Timer
(
set{};
get{};
)

 

public App()
        {
            this.Startup += this.Application_Startup;
            this.Exit += this.Application_Exit;
            this.UnhandledException += this.Application_UnhandledException;
            _Logouttimer.Tick += new EventHandler(_Logouttimer_Tick);
            __Logouttimer.Interval = TimeSpan.FromSeconds(60);
            InitializeComponent();
        }


this timer will check for every 60 seconds for timeout logout

void __Logouttimer_Tick(object sender, EventArgs e)
        {
            try
            {
                if ((DateTime.Now - App.Timer) > new TimeSpan.Minutes(20))
                {
                    
App app = (App)Application.Current;


            
            
                // Remove the displayed page
                app.root.Children.Clear();

                // Show the next page
                app.root.Children.Add(new LoginPage); //load the loginpage or the specific page you want to naviagte the user after timeout
            }
                
            }
            catch (Exception ex)
            {

            }
        }
           



Keep this event in master page to get the users last interaction time with the application

void LayoutRoot_MouseMove(object sender, MouseEventArgs e)
        {
            try
            {
                App.Timer = DateTime.Now;
            }
            catch (Exception ex)
            {
            }
        }

Debugging tips for SharePoint

Debugging on SharePoint is much the same as debugging any other ASP.Net application…you can use the same techniques. Here are some of my tips for diagnosing & solving your problems…

Debugging starts with your first line of code

As you start writing some code you need to bear in mind that at some point you will need to debug it. This may mean attaching a debugger (easy) or looking at a crash dump (hard). This means debugging should always be at the back of your mind when writing any code…ask yourself “when this is live how am I going to find out what has gone wrong?”

In practice this means making full use of the features of .Net … System.Diagnosticstry…catchexception logging, etc. One thing in particular to remember is that if you do ever have to look at a crash dump your variable & method names will be in there too. The more descriptive they are the easier it is going to be to analyse the dump. Also bear in mind that the less code in each method the easier it will be to pin-point the location of the error. Les Smith has some good points to make about refactoring…I would add that refactoring making debugging easier!

Use Trace.WriteDebug.Write

This is the first thing I would recommend. Adding these method calls at suitable places in your code can really help to solve problems. Used in conjunction with DebugView these methods can give you great insight to what is happening within your code. Personally I use Trace whenever something unexpected or ‘out of the ordinary’ occurs, normally exceptions, but it could be anything that may help solve a problem. Calls to the Trace methods remain in release code and so will add an overhead to the code execution. I generally use Debug to enable me to see code execution paths during development and as these do nothing in a release build can be used much more liberally.

Using the Trace statements can really help when you cannot attach a debugger (on a live server) to give you more information of what has gone wrong. If you ensure you use try…catch…finally blocks throughout your code, using Trace to log the exception makes it easy to see where the error has occurred (including the call stack) simply by running DebugView on the server.

Use try…catch…finally

When developing ASP.Net controls and WebParts I like to add try…catch blocks when overriding methods likeOnInitOnLoadCreateChildControls and Render. I do this because I don’t what the whole page to fail to render simply because one control has a problem…If the search box control throws an exception, why shouldn’t the rest of the page display? Therefore my Render method would look like this…

protected override void Render(HtmlTextWriter writer)
{
try
{
// Do something to render the control, which may cause an exception

}
catch (Exception ex)
{
Trace.Write(ex);
Trace.WriteLine(HttpContext.Current.Request.Url.ToString());
// Maybe render an error message

}
}

This way if an exception is thrown the page will still render…the user may not get the full functionality of the page, but at least they get something. Essentially wrapping your code in a try…catch block has a negligible hit in terms of performance and so you should look to using them wherever something may throw, even if you just Trace and re-throw the exception. Also you should bear in mind that throwing an exception is a big overhead and should only be used when a real exception has occurred…something you really did not expect and cannot recover from.

Check the SharePoint log files

These will be located in the /12/LOGS folder. The log files contain errors & messages generated by SharePoint. I have to say that generally they don’t give you as much information as you would like (sometimes nothing), but occasionally they point you straight to the problem. Either way you should always check them just in case.

You should also know that you can increase or decrease the amount of logging SharePoint does in Central Administration. Here you can change the verbosity of the logging within different parts of the application. Its not the easiest interface to use, but you can increase the number of messages logged…doing this has solved problems for me in the past.

You change the settings under ‘Logging and Reporting’ in the operations tab…

ASP.NET: Controlling Caching in ASP.NET Web Forms

ASP.NET allows you to cache pages. The means that when the code behind the page runs, it produces HTML, the HTML is sent down to the client, however a copy is stored in the memory of the web server. If the same page is requested again, then the page is retrieved from the cache and the code is not rerun. You have virtually infinite flexibility on controlling when the cache gets flushed.

The most basic caching is implemented by placing this line at the top of your ASPX page:

<%@ OutputCache Duration="3600" VaryByParam="none"%>

What this tells the ASP.NET caching code is to cache the page for one hour.

The full spec for the @OutputCache lines is:

<%@ OutputCache Duration="#ofseconds" Location="Any � Client � Downstream �
Server � None" VaryByControl="controlname" VaryByCustom="browser �
customstring" VaryByHeader="headers" VaryByParam="parametername" %>

Duration is a count in seconds to cache.

Location allows the caching to occur on the server, on the client, on a proxy server in between. The default is Any. If you always want server caching (which seems to me to be the most useful choice), change the line to read:

<%@ OutputCache Duration="3600" Location="Server" VaryByParam="none"%>

VaryByControl is only used by user controls, not on standard web pages. See the .NET documentation for more details.

VaryByCustom=”browser” keeps a different copy of the output for each browser name and major version information. So if you have cloaking by browser version going on (which is easy to implement in .NET), then each separate page will get delivered.

VaryByCustom=”customstring” Allows you to specify a string that will be passed to your code. To make this useful, you must then override the GetVaryByCustomString method in the Global.asax file. For example, place this line in your ASPX file:

<%@ OutputCache Duration="3600" Location="Server" VaryByCustom="Referer" VaryByParam="none"%>

Then in your Global.asax file add the following code:

public override String GetVaryByCustomString(System.Web.HttpContext hcContext, String strCustom)
{
    switch (strCustom)
    {
    case "Referer":
        Uri uriReferrer = hcContext.Request.UrlReferrer;
        String strRet;
        if (uriReferrer != null)
            strRet = uriReferrer.Host;
        else
            strRet = null;
        return strRet;
    default:
        return base.GetVaryByCustomString(hcContext, strCustom);
    }
}

VaryByHeader allows you to cache based off of some field in the HTTP header sent by the client. The classic example is based off the Accept-Language header line.

VaryByParam allows you to cache different versions based off of querystring or post field parameters. So http://www.domain.com/foo.aspx?bar=baz would be cached separately from http://www.domain.com/foo.aspx?bar=bletch

There are also ways of controlling the caching through code.

.NET Tip: Using a Nullable Value Type

How often do your programs grab some data from a database and throw the values returned into local variables without giving the data another thought? I used to, until my programs started throwing exceptions because of nulls in the data. So, what did I do? I checked every field coming back from the database that could possibly be null before storing it in a local variable. Depending upon what your database allows, this could lead to an explosion of code. Here is an example of the type of code that was used to check for a null value before storing it in a local variable. In this case, the BranchCode from a DataReader is being checked:

double BranchCode;
if (dr["BranchCode"] == DBNull.Value)
   BranchCode = -1;
else
    BranchCode = dr["BranchCode"];

This worked, but later in the code the “magic value” of -1 would have to be checked to see whether the variable had a valid BranchCode.

if (BranchCode <> -1)
{
   ...
}

Nullable types allow a cleaner solution to this problem. You can store the data returned from the database into a nullable variable without worry about an exception being thrown at that time. You still may have to perform the check for a valid value later, depending upon exactly how you are using the variable. You can declare a value type variable as nullable using the ? type modifier. Nullable types have two read-only properties that you use to get information about the variable. HasValue returns false if the value is null; otherwise, it returns true. If HasValue returns true, you can access the Value property, which contains the currently stored value. If you attempt to use the Value property when HasValue is false, an exception will be thrown. Here is what the example above would look like using a nullable type:

double? BranchCode;
BranchCode = dr["BranchCode"];

if (BranchCode.HasValue)
{
   switch (BranchCode.Value)
   {
      ...
   }
}

In addition to checking HasValue, you can also just compare the value to null, like this

if (BranchCode != null)
{
   ...
}

You do need to use some caution, however, when using nullable types. Nullable numeric types can be used in comparisons and expressions just like normal numeric expressions. If the nullable variable has a non-null value, everything will work as you would expect. If the nullable variable is null, you need to realize that the result of the expression could be null and make sure that case is handled appropriately.

Nokia N97 NAM – review

Nokia N97 NAM – Specs

Overview
Regions available Canada
Technology GSM 850/900/1800/1900 MHz
UMTS 850/1900/2100 MHz
Packet Data GPRS, EDGE, HSDPA
SIM Card Yes
World Phone Yes
Operating System Symbian v9.4 (S60 5th Edition)
Processor ARM11 434 MHz
Internal Flash Memory 32 GB
RAM No
ROM No
GPS Yes
FlightMode Unknown
Hearing Aid Compatible Unknown
TTY/TDD Unknown
SAR Head: 0.66 W/kg
Body: Unknown
Languages English, French, Spanish
Manufacturer Warranty 1 Year
Accessories Included AC Charger, Data Cable, Headset, Manual, Standard Battery
Power & Battery
Type Lithium-Ion (Li-Ion), 1500 mAh
Removable Battery Yes
Talk Time Up to:
320 minutes (2G)
Unknown (3G)
Standby Time Up to:
700 hours (2G)
Unknown (3G)
Physical Characteristics
Design Type Slider
Multi-Use Smart Phone / PDA Yes
Colors Black, White
Dimensions [H x W x D] 11.7 x 5.5 x 1.6 cm
(4.6 x 2.2 x 0.6 in)
Weight 150 grams
(5.3 ounces)
Rugged Design No
Antenna Type Internal
Changeable Faceplates No
Display / Screen
Type Color
Technology LCD (TFT)
Colors 16.7 million
Resolution 640 x 360 pixels
Size Unknown
Secondary Display No
Sensors No
Graphics Yes
Themes No
Backlit Illumination Yes
Battery Strength Indicator Yes
Signal Strength Indicator Yes
Voice Mail Indicator Yes
Text Message Indicator Yes
High Speed Data Indicator Yes
Bluetooth Indicator Yes
Additional Display Features -
Input / Navigation
Input Type QWERTY
Navigation Type D-pad, Touchscreen
Illuminated Keypad Yes
Predictive Text Entry T9
Voicemail Key Yes
Any Key Answer No
Voice Commands Yes
Keypad Lock No
External Volume Control Yes
External Media Playback Controls Unknown
Call Management
Phone Book Capacity Depends on system memory
Multiple Numbers Per Contact Yes
Auto Answer No
Photo Caller ID Yes
Voice Activated Dialing Yes
Web / Email / Messaging
Web Browsing Type Yes (WAP 2.0, HTML)
Browser -
Javascript Unknown
Flash Unknown
Email Yes
Email Protocols POP3, IMAP, SMTP, Microsoft Exchange, Lotus Domino
Additional Email Features -
Messaging Services SMS, EMS, MMS, IM (AIM, MSN, Yahoo)
Push-to-talk (PTT) Yes
Connectivity
USB Yes
Bluetooth Yes
Bluetooth Profiles -
Infrared No
WiFi Yes (802.11 b/g)
WiFi Encryption Unknown
UMA Support Unknown
Data Tethering Compatibility Yes
Java Applications Yes
Brew Applications No
Expansion Slots Yes
Expansion Slots Info microSD (up to 16 GB)
ECML / Digital Wallet Unknown
PC Synchronization Yes
PictBridge Unknown
TV-out Unknown
Camera
Built-In Yes
Resolution 5+ megapixels
Zoom Yes
Flash Yes (LED)
Additional Camera Info Auto focus, Geotagging, Self-timer, Carl Zeiss Tessar lens
Video Capture / Recording Yes
Video Recording Formats MPEG-4
Video Recording Parameters -
Secondary Camera Yes
Secondary Camera Info -
Audio / Video
Audio Playback Yes
Audio Formats MP3, eAAC+, eAAC, AAC, WAV
Radio Yes
Video Playback Yes
Video Playback Formats H.264 / AVC, MPEG-4, WMV, RealVideo
Mobile TV Unknown
Streaming Video No
External Speakers No
Headset Jack Other / proprietary
Custom Ringtones Truetone / MP3
Downloadable Ringtones Yes
Ringtone Composer No
Ringer ID Yes
Vibration Alert Yes
Speakerphone Yes
Apps
To-Do / Task List Yes
Calendar Yes
World Clock Unknown
Alarm Yes
Stopwatch No
Timer Unknown
Calculator Yes
Currency Converter Yes
Weather Unknown
Stocks Unknown
Maps Unknown
Notepad Yes
Voice Memos / Recorder Yes
Games Downloadable
Included Software -

Nokia 5800 XpressMusic – Review

Nokia 5800 XpressMusic – Specs

Overview
Regions available Canada
Technology GSM 850/900/1800/1900 MHz

UMTS 850/1900 MHz

Packet Data GPRS, EDGE, HSDPA
SIM Card Yes
World Phone Yes
Operating System Symbian 9.4 with S60 5th edition
Processor ARM 11 369 MHz
Internal Flash Memory 81 MB
RAM 128 MB
ROM 256 MB
GPS Yes (A-GPS)
FlightMode Yes
Hearing Aid Compatible No
TTY/TDD No
SAR Head: 1.00 W/kg

Body: 0.55 W/kg

Languages English, French, Spanish
Manufacturer Warranty 1 Year
Accessories Included AC Charger, Carrying case, Data Cable, Hand Strap, Headset, Manual, Software CD, Standard Battery, Stylus, 8GB microSDHC Memory Card, Audio Adapter, Desktop Holder, Quick Start Guide, TV Out Cable
Power & Battery
Type Lithium-Ion (Li-Ion), 1320 mAh
Removable Battery Yes
Talk Time Up to:

515 minutes (2G)

300 minutes (3G)

Standby Time Up to:

406 hours (2G)

400 hours (3G)

Physical Characteristics
Design Type Bar
Multi-Use Smart Phone / PDA Yes
Colors Black, Blue, Gray, Red
Dimensions [H x W x D] 11.1 x 5.2 x 1.5 cm

(4.4 x 2 x 0.6 in)

Weight 109 grams

(3.8 ounces)

Rugged Design No
Antenna Type Internal
Changeable Faceplates No
Display / Screen
Type Color
Technology LCD (TFT)
Colors 16.7 million
Resolution 360 x 640 pixels
Size 3.2 inches
Secondary Display No
Sensors Ambient Light, Motion / Accelerometer
Graphics Yes
Themes Yes
Backlit Illumination Yes
Battery Strength Indicator Yes
Signal Strength Indicator Yes
Voice Mail Indicator Yes
Text Message Indicator Yes
High Speed Data Indicator Yes
Bluetooth Indicator Yes
Additional Display Features
Input / Navigation
Input Type Touchscreen
Navigation Type Touchscreen
Illuminated Keypad Yes
Predictive Text Entry T9
Voicemail Key No
Any Key Answer No
Voice Commands Yes
Keypad Lock No
External Volume Control Yes
External Media Playback Controls No
Call Management
Phone Book Capacity Depends on system memory
Multiple Numbers Per Contact Yes
Auto Answer Yes
Photo Caller ID Yes
Voice Activated Dialing Yes
Web / Email / Messaging
Web Browsing Type Yes (WAP 2.0, HTML)
Browser S60 Web Browser
Javascript Yes
Flash Yes
Email Yes
Email Protocols POP3, IMAP, SMTP
Additional Email Features -
Messaging Services SMS, MMS, IM
Push-to-talk (PTT) No
Connectivity
USB Yes
Bluetooth Yes
Bluetooth Profiles A2DP, AVRCP, BPP, DUN, OPP/FTP, HID, HFP, HSP
Infrared No
WiFi Yes (802.11 b/g)
WiFi Encryption Unknown
UMA Support No
Data Tethering Compatibility Yes
Java Applications Yes
Brew Applications No
Expansion Slots Yes
Expansion Slots Info microSD (up to 16 GB)
ECML / Digital Wallet No
PC Synchronization Yes
PictBridge No
TV-out Yes
Camera
Built-In Yes
Resolution 3+ megapixels
Zoom Yes (3x digital)
Flash Yes (LED)
Additional Camera Info Auto focus, White balance, Carl Zeiss optics, centre weighted auto exposure, flash modes
Video Capture / Recording Yes
Video Recording Formats 3GP / 3GPP, MPEG-4
Video Recording Parameters VGA (640 x 480 pixels), 30 fps, up to 216 minutes
Secondary Camera Yes
Secondary Camera Info -
Audio / Video
Audio Playback Yes
Audio Formats MIDI, MP3, eAAC+, AAC+, AAC, WMA
Radio Yes
Video Playback Yes
Video Playback Formats MPEG-4, WMV
Mobile TV No
Streaming Video No
External Speakers No
Headset Jack 3.5mm
Custom Ringtones Truetone / MP3
Downloadable Ringtones Yes
Ringtone Composer No
Ringer ID Yes
Vibration Alert Yes
Speakerphone Yes
Apps
To-Do / Task List Yes
Calendar Yes
World Clock Yes
Alarm Yes
Stopwatch No
Timer No
Calculator Yes
Currency Converter Yes
Weather Yes
Stocks No
Maps Yes
Notepad Yes
Voice Memos / Recorder Yes
Games Downloadable
Included Software -