I'm trying to determine some testing strategies for a Silverlight application of ours.
What I'd like to determine is the total time it takes for a grid to load and show data in the client. I've tried to put a timer round assigning the itemsource, but I need to know how long it takes the browser is finish loading the data into the grid.
Is this at all possible? If so, in what direction do I've to search?
This might help an article on MSDN "Loaded event timing in Silverlight"
http://blogs.msdn.com/b/silverlight_sdk/archive/2008/10/24/loaded-event-timing-in-silverlight.aspx
I think the main idea is to make use of the LayoutUpdated event. Since the event hangs off the FrameworkElement object I guess you could add a handler to all controls and effectively profiler all the framework elements of your Silverlight app. Something similar to the MVC Mini Profiler (SO uses/created this). http://code.google.com/p/mvc-mini-profiler/
I would certainly explore the LayoutUpdated event further.
Related
I would like to know if "scroll" event can be added to the Google analytics universal code? i have the below
setTimeout("ga('send','event','engaged users','page visit 30 seconds or more')",30000);
I wanted to track visits over 30secs that the scrolls
You can use window.scroll which is available in the jQuery API.
$(window).scroll(function() {
ga('send','event', 'engaged users');
});
See https://api.jquery.com/scroll/
There are several plugins/libraries out there that add scroll tracking, but if you want to do it yourself make sure you don't send too many events.
You shouldn't send an event to GA directly on the window.onscroll event - this is fired dozens of times a second. It will chew through your hit allowance and it won't provide any useful data.
Even a sampled scroll event isn't much better (where you set a timeout every few hundred milliseconds to check if the user has scrolled) - it still sends potentially hundreds of events user page view.
You should either set it to fire on certain scroll "thresholds" (e.g. 20%, 50%), or, the better way in my opinion is to store a variable with the maximum scroll depth and then use the document.onbeforeunload event to fire just one event at the end of the user's page view. This gives way more accurate data and doesn't send too many events.
onbeforeunload has some browser inconsistencies though (especially on mobile), so you'll want a fallback for that. There's a full tutorial here on creating a cross-browser scroll tracking plugin with tons of code examples here: building a better scroll tracking plugin
My UI is acting choppy and I am trying to understand what the source for this is.
There are a lot of options using Xcode Instruments and I am not sure which set of them are the best for me.
From playing around with some of them it seems that most time is spent in [CALayer drawInContext] and [CALayer layoutSublayers] but I have no idea in what context those methods are called from (what part of the UI is doing that).
Which options should I be choosing in order to better understand?
Also would like to know if there is a way to see what is running in the background which doesn't belong to the current visible UI (I think something in the background may also be thrashing the CPU)
Toogle Display of Primary Views and select:
Separated by Thread
Invert Call Tree
Hide System Libraries
Show Obj-C Only
Try to see this: http://www.raywenderlich.com/23037/how-to-use-instruments-in-xcode
Use the instruments Time Profiler instrument to record your app running on the device during its choppy moments.
Upload the instruments trace at:
http://timeanalyzer.excelsis.com
It will give you a timeline view of your main thread (the main place where UI stutters occur) methods that's a lot easier to visualize than the regular instruments UI. Here's an example view:
http://timeanalyzer.excelsis.com/view.php?jobid=c7f3efc43ff85302a80515b56c0900f0
I am new the WP7.1. I am developing chat app, in that there is screen like friends, in that screen it like 1000s of friends are there, We are binding to longlistselector the using sqlite.
Main problem is like, we have one API for calling friend's update like (displayname, profile picture etc) and I am processing the API data and binding the data to longlistselector, at the time of binding, I am not able to scroll the longlistselecor and any other buttons in the screen.
I am binding the data using Deployment.Current.Dispatcher.BeginInvoke(() => { Binding to }); and Dispatcher.BeginInvoke(() => { Binding to }) and BackgroundWorker (I tried those many ways).
Please suggest any solutions binding the without disturbing UI.
Thanks in advance.
-- Chandra
Whenever you push data on the screen (be it through XAML {Binding} or through directly accessing the page's UI elements) it needs to be done on the UI thread. While the UI thread is busy with processing your code or with redrawing the UI because of your code, the UI freezes.
This means that you need to make everything inside BeginInvoke() as short and efficient as possible. However you also need to make as few calls to BeginInvoke() as possible. Finding the balance between these will determine the experienced speed of your UI.
In the case of LongListSelector I found that it's efficient to add 50 items at a time, wait half a second and add the next 50 items. Your mileage may vary.
I'm finding a common pattern during my WP7 development.
Something takes a long time to display and I want to break down the display into 2 parts - an initial display so I can show a Loading message and start the progress bar then a secondary display where I can load the data.
At the moment I'm trying to do this in a custom control but it could equally apply to user control or a page.
I can't find a way of doing this. Way back in WinForm days there were events I could call before the form was shown and others for after. I guess I'm looking for something similar.
I have also tried to see if I can display a stack panel first with the Loading message then capture an event on that to fire the data loading but nothing so far.
Any ideas?
I'm using Caliburn Micro BTW.
You can use the page's Loaded event or an OnNavigatedTo override to show the Loading message, and then you can use the BackgroundWorker class to run your long-running process on a background thread so that the UI thread remains responsive, and then in the handler for the RunWorkerCompletedEvent handler, which is marshalled onto the UI thread for you, you can hide the loading message and perform your second stage display.
Usually, when a View requires a lot of bindings, or some UI Elements like a Bing Map, it takes a "while" to load (like between half a second and a second).
I don't want a delay between a "tap" action (like tapping an element on a ListBox) and the navigation action (displaying a new page).
I don't mind displaying the page progressively. For example, for a Bing Map, I don't mind displaying a black page with only a title, and a second later, having the Map appear.
What are the best practices ? It could post a sample if i'm not clear enough
edit: I'll keep the question open for a while, so other can answer. Thanks Matt and Mick for awesome answers. I'm already working on some improvements. The major one being binding my controls after the page loaded.
It's expected on resource constrained devices that non trivial actions will take at least a little time to execute.
The most commonly recommended best practice for dealing with this is to use animations to give the user the impression of perceived performance. This has been a recurring recommendation throughout the CTP and Beta phases by the product team and in presentations at Mix 10 and Tech Ed 2010.
Page transitions are a common approach to this.
Discussed here by Kevin Marshall, prior to inclusion in the November toolkit.
WP7 – Page Transitions Sample
And here, referencing the control in the toolkit.
Transitions for Windows Phone 7
There are also a number of very basic optimisations you can do that will give you some bang for a little effort.
don't name controls that you don't reference in code
use background worker to load any data to avoid impact the UI thread (already busy loading your page) and fire this off after the page is loaded (disable any controls not usable in leui of this) (Phạm Tiểu Giao - Threads in WP7)
use httpwebrequest over webclient for the same reason (WebClient, HttpWebRequest and the UI Thread on Windows Phone 7)
I would also reiterate Matt's suggestion for not loading controls that aren't used initially.
If you decide to go the extra mile, there is more you can do to optimise page loading. These two posts are worth absorbing in that regard.
Creating High Performing Silverlight Applications for Windows Phone
WP7 Development Tips Part 1 - Kevin Marshall's Epic Work Blog for Awesome People
If using Listboxes, also familiarise with Oren Nachman and David Anson's
WP7 Silverlight Perf Demo 1: VirtualizingStackPanel vs. StackPanel as a ListBox ItemsPanel
Keep a low profile LowProfileImageLoader helps the Windows Phone 7 UI thread stay responsive by loading images in the background
Never do today what you can put off till tomorrow DeferredLoadListBox (and StackPanel) help Windows Phone 7 lists scroll smoothly and consistently
and be sure image sizes are optimised for their display size.
My suggestions/recommendations:
Create and navigate to the new page as quickly as possible.
Display the page with placeholder content while it loads (if appropriate).
Give an indication that something is happening while the page loads. An indeterminate progress bar (use this one) is the convention on the platform.
If it's not possible to use the page until all controls are loaded, then prevent access to the page. A semi-transparent object displayed over the entire page is a common technique to not only prevent touching of controls but also to indicate that they can't yet be touched.
If possible/practical set the size of the items in xaml/code to prevent relayout due to resizing once an item is loaded.
Try delay loading of items which aren't on the screen initially to get the perceived total load time down.
and finally:
Optimize everything to get the load time down and the application as responsive as possible.