Facebook update hits Windows Phone 7

On Wednesday, Microsoft made available an update to the Windows Phone 7 Facebook application, which is available for free on the marketplace. Before today, Windows Phone 7 users have had a frustrating time using Facebook on their phones. The application was slow, non-responsive and lacked many features. 

The update comes with some noteable new features, including Facebook Places (with your GPS, too), in-app photo tagging, as well as allowing the application to continue running under screen lock (A feature we couldn't live without), as well as a massive performance increase.

The update also features a slightly different interface, with larger fonts, and the application is responsive to the touch while still loading. Even so, we aren't quite sure why the keyboard still doesn't match the application though -- when the dark theme is selected, the keyboard shows up black even though the entire application is white and blue.

With the Windows Phone 7 marketplace surpassing 4000 applications and Microsoft announcing that they had shipped 1.5 Million devices, it's been a big week for Windows Phone 7. To get the application, go to the applications page on Zune; or visit the marketplace on your phone to grab the update.

Report a problem with article
Previous Story

Daily Gaming: December 21, 2010

Next Story

Woman sues Google over underwear images posted on Street View

27 Comments

Commenting is disabled on this article.

I didn't have much of an issue with performance in the old one and tagging was already there - you just had to hold the person's face and tap their name. However, a welcome update with places and better performance. Just hope they update IE's input field handling in the January update as ~Johnny says, the performance can be awful and some drop downs refuse to work.

jimmyfal said,
I'd rather see it integrated more into the people hub. I use the people hub constantly.

Yeah, just give an option to view a friend's pictures directly from his contact card in the People hub, and give an option to go to his profile. Then it'd be perfect.

andrewbares said,

Yeah, just give an option to view a friend's pictures directly from his contact card in the People hub, and give an option to go to his profile. Then it'd be perfect.


And an option to send them a private Facebook message, via the 'People' hub. Currently, we can write on their wall, but not send them a private Facebook message, through the 'People' hub.

jimmyfal said,
I'd rather see it integrated more into the people hub. I use the people hub constantly.

Yeah, I agree. I hope that the update coming to WP7 adds more Facebook integration to the People Hub as well as other social mediums. Not that I use them all myself, but it would be nice to have the option to have all of your social interactions in the same place. LinkedIn would be awesome, and for those that use Twitter, that would be useful I suppose. LOL

The Keyboard (and message boxes) follows the phones theme - it can't follow and is not allowed to follow a theme an application developer specifies. It's still really bad performance wise as a whole, though the places and friends selector have decent performance. Though as much as it's the developers fault, there's also some blame to lay with the Silverlight framework being relatively heavy, for a phone anyway.

~Johnny said,
The Keyboard (and message boxes) follows the phones theme - it can't follow and is not allowed to follow a theme an application developer specifies. It's still really bad performance wise as a whole, though the places and friends selector have decent performance. Though as much as it's the developers fault, there's also some blame to lay with the Silverlight framework being relatively heavy, for a phone anyway.

It's pretty nice now, it's MUCH more snappier than before.

Owen W said,

It's pretty nice now, it's MUCH more snappier than before.

I agree. I've found it to be much faster and more efficient than before.

Callum said,

I agree. I've found it to be much faster and more efficient than before.

I mean yeah, sure, compared to what it used to be, its a much better performer but compared to its equivalent Facebook apps on other smartphones its still basically crap. Its still probably one of the worst exampl of app performance on the platform.

(On an unrelated note, trying to post a reply using my wp7 phone through neowins mobile site is painful, text entry gets extremly slow at some points and makes the auto correct kill every word you type.)

~Johnny said,

I mean yeah, sure, compared to what it used to be, its a much better performer but compared to its equivalent Facebook apps on other smartphones its still basically crap. Its still probably one of the worst exampl of app performance on the platform.

+1

(On an unrelated note, trying to post a reply using my wp7 phone through neowins mobile site is painful, text entry gets extremly slow at some points and makes the auto correct kill every word you type.)[/quote]

Disable the damn thing, you'll be better off without it (autocorrect).

~Johnny said,
The Keyboard (and message boxes) follows the phones theme - it can't follow and is not allowed to follow a theme an application developer specifies.

Ever used email on a dark theme?

Fred 69 said,

Ever used email on a dark theme?


it can only do that for formative OS apps - it can't do that for any app made by us third party developers in Silverlight or xna

~Johnny said,
...Though as much as it's the developers fault, there's also some blame to lay with the Silverlight framework being relatively heavy, for a phone anyway.

Silverlight is heavy? What do you consider light a DOS batch file?

Silverlight is not native code, but when coupled with the GPU acceleration and considering the .NET/Silverlight base is already in memory and running as the phone OS platform, it means that applications on WP7 are hardly ever doing any heavy lifting of any type.

There are a couple of optimization mistakes I have seen people make like nesting a certain type of control or not using the BitmapCache when building games in Silverlight for the WP7.

There are also a couple of known network calls and WinCE 6.x code specific issues that can affect performance, that are knowning removed in the early 2011 update; however, to actually hear someone say Silverlight is heavy or imply it is slow about made me spit my coffee.

If you want to see HEAVY, go look at any Android Application, that is not only riding on top of a custom and poorly optimized JAVA library set, but are also having to implement basic functionaly that that OS should be providing, which is why you get simple applications that are several MB in size on Android. And this is not even touching on when you try to do something graphically in a JAVA Android Application, that has the performance somewhere between syrup and ice.

If I were going to take a guess at Facebook application performance, I would look at two things specifically, and neither of them would be Silverlight related Facebook performance on any device depends on network speeds, so the place to start would be in how the network calls are handled, and then move on to how the applicaiton is caching and refreshing content.

However to follow up with my point, think of it more like this. All smartphone OSes currently use a runtime framework for their applications.

Android - Java framework
iOS - Cocoa framework
WP7 - .NET/Silverlight framework

And .NET/Silverlight is not the slow one in this group, and could be argued to be the lightest and fastest of the three.

thenetavenger said,
snipped

If anything, Cocoa is the lightest framework by far, and is generally considered a slightly lower level than the other two.

It'd be like not calling WPF heavy - it is, mainly due the XAML parts of the applications, the media and rendering framework, and whaddya know, Silverlight borrows most of it's XAML philosophies from WPF, including the increased memory usage. Yes, it's probably the most powerful of the 3, but it takes more power and more processing time, the slowness of the XAML parsing and drawing on screen (one of the biggest slow down points for complex Windows Phone 7 apps are the draw speeds). The amount of processing and behind the scenes work to draw visuals in Silverlight is far more than that of Cococa, and probably more than that of Java - both of which also draw and load much faster on their respective platforms. Even the RAM usage on Silverlight apps will show you that it's heavy - you can easily hit 40-50mb without doing too much.

Most of the facebook app's problems have nothing to do with network call speeds - even if they did the app should still be functioning rather smoothly, just slow to do anything, but it's not, it's a mess of laggy, choppy scrolling and browsing - it's down to badly optimised data virtualisation and relatively poor drawing speed of elements in the visual tree that are anything more than slightly basic. Heck, I added 4 simple toggle buttons to my app. Caused a 300ms extra drawing time delay. That's a lot

Also, Silverlight doesn't run as the phone OS platform, the platform is all run in (much better performing) native code. The framework itself might be small, but when apps get running on the phone, you'll notice the issues. It's a performance heavy framework, by all means.

~Johnny said,

If anything, Cocoa is the lightest framework by far, and is generally considered a slightly lower level than the other two.

It'd be like not calling WPF heavy - it is, mainly due the XAML parts of the applications, the media and rendering framework, and whaddya know, Silverlight borrows most of it's XAML philosophies from WPF, including the increased memory usage. Yes, it's probably the most powerful of the 3, but it takes more power and more processing time, the slowness of the XAML parsing and drawing on screen (one of the biggest slow down points for complex Windows Phone 7 apps are the draw speeds). The amount of processing and behind the scenes work to draw visuals in Silverlight is far more than that of Cococa, and probably more than that of Java - both of which also draw and load much faster on their respective platforms. Even the RAM usage on Silverlight apps will show you that it's heavy - you can easily hit 40-50mb without doing too much.

Most of the facebook app's problems have nothing to do with network call speeds - even if they did the app should still be functioning rather smoothly, just slow to do anything, but it's not, it's a mess of laggy, choppy scrolling and browsing - it's down to badly optimised data virtualisation and relatively poor drawing speed of elements in the visual tree that are anything more than slightly basic. Heck, I added 4 simple toggle buttons to my app. Caused a 300ms extra drawing time delay. That's a lot

Also, Silverlight doesn't run as the phone OS platform, the platform is all run in (much better performing) native code. The framework itself might be small, but when apps get running on the phone, you'll notice the issues. It's a performance heavy framework, by all means.

1) Cocoa is not more native, is a dynamic runtime framework that is also using interpreted code, just like JAVA and .NET - Even Apple defines Cocoa like a scripting language interpreted framework. (Seriously, more native? http://www.apple.com Explains this quite well.)

2) XAML parsing, really? The XAML and C# are compiled at development time to .NET - Go look up XAML markup compiling. Sure the runtime can process and parse XAML, but this is not the normal nature of an application. Additionally, even when dynamic XAML is used and processed at runtime, .NET uses a JIT concept for the XAML, so it is only parsed once.

3) WPF/Silveright Heavy/XAML - You seem to think the development concept of WPF and Silverlight that use and abstracted rich XML stucture for UI is bigger or bad. Cocoa also uses a dual UI/Code concept, does this make it big and bad too? I think you are trying to apply desktop application rules to the WP7.

On the desktop when running a WPF or Silverlight application, there is extra memory use as parts of the .NET framework for each application is loaded separately. This is done for a couple of reasons: versioning, security. This is what creates the additional sandbox of security around these applications and keeps .NET version conflicts from occuring. So ya, on a desktop application, add an additional xxMB to each .NET/WPF/Silverlight application.

However on WP7, this is NOT the case as they are using the same .NET and Silverlight already in RAM. Each application on WP7 does NOT fire up a new instance of .NET or Silverlight. There are not versioning issues and the sandboxing is handed via the Silverlight platform on WP7.

4) Silverlight DOES run as the phone OS platform. I don't think you understand what this means.

The core OS is WinCE with a WinCE kernel and WinCE upper layers for drivers and API sets. On top of this runs a new mobile version of .NET which is running a Silverlight OS Platform.

Applications run on top of this layer, and access specific Silverlight based API sets designed for WP7 with a full object oriented OS platform model. This Silverlight platform provides the controls and other events and interactions for the applications. So if you specify a 'listbox' control in your application, it is pulling this from the Silverlight OS platform listbox control, and provides a complete object oriented relationship from the listbox to the application and from the application listbox back to the Silverlight OS platform. (This is why WP7 not only uses true object 'oriented' development tools, but also is a true object 'oriented' OS. -WinCE is not an object oriented OS, although portions of WinCE are object based, like NT is. And there is a difference between object 'based' and object 'oriented'.)

Additionally, the Silverlight platform provides the common OS features and the entire interface and UI of the device itself.

XNA Applications run directly on the .NET layer. Non-Silverlight .NET applications could also run on .NET directly, but as of now this is not supported on WP7. Native WinCE applications could also be written where legacy WinCE's upper layer API set has not been removed,, but this is also not supported or allowed. (Anything that bypass the .NET layer is dangerous to the security and mangaed code stability of the device.)

So on WP7, Silverlight is very much an OS platform, and as it provides the APIs and controls to the non-XNA applications, so it is somewhat analagous to Win32 on the desktop Windows 7 (NT) OS. (And yes Win32 is an OS platform too, and on NT even has its own kernel running its own subsystem.)

5) If 4 simple toggle buttons cause a 300ms drawing delay, then you are doing something horribly wrong or are doing something that is turning off portions of the GPU acceleration. I can add three videos playing and animating by rotating and bouncing around the scren and not cause a 300ms delay.

thenetavenger said,
snip

- The OS, it's UI, and common features are NOT built on Silverlight. It's built on it's own, much faster, bespoke UI framework (rumoured to be known as Iris, probably likely an extension of the Zune team's platform then). Controls behave differently between "Native" OS apps and their themed Silverlight counter part, and quite a number of the OS's controls have not yet been replicated, or substandardly replicated as Silverlight controls at the moment. That, and there's a noticeable difference in performance and usability of Native applications and Silverlight OS apps. Things like the application bar and message boxes are also handled natively by the OS, outside of Silverlight.

- I didn't call Cocoa more native - but it does have better performance generally, and it does have a lower memory footprint.

- It might compile the Silverlight XAML, but when it gets to your phone, Silverlight is still going through it, and creating the visual tree exactly as defnied in the XAML, and you can still get upto a 20% boost in performance by not writing your UI in XAML, but all in code.

- 3 Toggle buttons, (which by the way are not actually included in the base Silverlight runtime, but actually written by the WP7 team in Silverlight as silverlight controls, based on the button control... an unideal solution, and also accounts for some of the additional time needed), 3-4 levels down the visual tree, there's nothing you can do about it. You just have to deal witth the delay in loading, which also screws up your animations/transitions (not helped by the fact that there's no event that can be triggered to signify drawing is complete). Infact, all the Windows Phone 7 silverlight toolkit controls add far more drawing delay times than the other controls,

- In the end - SIlverlight apps initially load slower, the UI thread locks up faster, and the memory usage is larger than both Android & iOS's platforms. Ergo, it's valid to call Silverlight heavier. It's an awesome powerful framework, you can do great things with it, but trying to do anything that heads towards slightly complex, and the current WP7 SIlverlight runtime cannot handle it very well. I've spent a lot of time with the platform, and I have one of the better rated and best performing apps on the system by a long run under my belt, so I've spent a lot of time doing hardcore performance tuning and dealing with these issues. From my first hand experience, performance tuning is far more of an issue on Windows Phone 7's Silverlight runtime that it is on iOS and Android.

One can update to the newer version using the Marketplace hub on their phone, as well.

I'm excited to see Facebook Places added, finally! Now they should add Facebook Groups