Some test scenarios I run load elements such as tables and lists, according to the development team the loading behavior should be identical to that implemented in Android, making requests to populate the screen as the user scrolled down. But on screens only 5 elements should appear and the appium inspector detects all the elements.
Is there any capability we can pass so that it doesn't load that much data?
Ao carregar estes elementos todos o appium não consegue interagir com nenhum elemento na pagina, impedindo os fluxos de automação.
No, there is not.
This is how the mobile "DOM" (It's not precise to say DOM for mobile I believe, but works for the example) works in iOS, it loads the entire thing on the DOM, even the elements that are not visible, in other hand, Android only load on the DOM what you can see.
So you need to manage this difference on your testing framework.
Related
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 am working with flex for the last two years on some desktop apps. Until now I never had any performance related issues but today as we completed a mobile application for the iPad, I'm facing a challenge, the application is incredibly slow on the iPad.
http://i.stack.imgur.com/qkbWn.png
Slow, means that when I press a button in the menu to change the splitview I must wait something like 5s. Then scrolling is really slow two, with less than one fps and my TextInput starts to bug (the text is not in his box anymore).
I started to read a lot of blog post and presentation about optimisation for the mobile platform and then I rewrite some of the components I use. I removed the SkinnableContainer for instance and replaced it by a VGroup including some actionScript based drawing.
Now what you see is a VGroup (the dark grey one) containing some others VGroup (the group with title here) and then each widget is an HGroup with a label and a Widget. I only use Label and TextInput for the text.
Creation time is slow even (several seconds to create the view) for another page where there is only 4 text widget on it, or another one with only a list with a custom item renderer where each row is a set of 4 labels.
The whole things is cabled with RobotLegs, with nothing fancy, one models is injected in the view and at the beginning I set a member variable on the view with this object to bind my variables.
Frankly my thinking right now is : it smells fishy because if I've done everything right it is impossible to have such low performance and thinks that flex is competitive on the mobile platform. So right now I'm trying to disable the application piece by piece to try to locate what could slow it like that. I've got a couple suspects to check, for instance I've got some binding warning to check, and then see if robotlegs has got its share of the problem.
So my main question here is what do you think, and could you have some ideas about "is there a problem" and "how do we solve it".
Thanks
Run profiler for startup and separatelly for each operation that takes longed that it needs. Then prioritize the problems and try to solve them with basic optimization techniques.
Some problems you will not be able to solve fast - e.g. time for creating big components. The only option there is to rewrite those components with AS3 without MXML, styles and anything. I'm sure that flash.text.TextField is created many times faster than mx.controls.Label. The same for other components.
When component is created, it can be reused at a very low price. In your app there must be a lot of places where you recreate while you can reuse old components. It will save you memory and time.
Layouts tend to redraw even when it's not needed. If you have a lot of nested layouts, find the most critical places and replace a series of layouts with one custom layout or even component.
This all is very developer time consuming. At the end you will not get a smooth app anyway, but I believe that it can become usable.
On the IPhone, the map control allows you to switch between a list mode and map mode easily. I've been trying to find examples of this for WP7 but am at a loss.
Is there a best practice for implementing a list of objects on a map?
If not, do we just do it manually, I.E. Save the dataset and display it as a listbox or something?
If you do it manually, where is the best place to put a button to switch you between the 2 screen styles? I feel like that app bar isn't right.
I don't want to copy the IPhone UI standard and have a button in the title bar, although I'm running out of options.
For one "best practice" I'd take a look at how the default Bing Maps app works - it provides a "results list" text menu item accessible from the ApplicationBar - and this is displayed via a full screen dialog (at least I think that's what it is).
However, that is only one "best practice" - I don't think their UI is perfect for all apps.
Application bar is fine, just make sure the buttons are in the same positions for each bar and that toggling views 10 times does not require pressing Back 10 times to go to the previous page, maybe use a different page transition so it doesn't feel like every other transition on the app.
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.
I'm developing a Silverlight application that displays items in a listbox control and I've run into a bit of a performance issue.
Each item in the listbox is a custom stackpanel with some formatted text and such.
When I've got a list of 500 or less items the listbox works fine, but loading more than this causes problems. At 1000 items, Silverlight will consume 10% cpu, even if I'm not doing anything, at 3000 items the cpu constantly uses 32-36%.
This is on a dual core machine, on an older machine I tested out on the cpu usage goes way up.
This also effects the framerate, I'm getting 6fps with a 3000 item listbox, which makes the application sluggish.
Does anyone know what might be causing this? My first thought was that silverlight is trying to render all the items, even though the items are off screen... this seems to be consistant as if I insert items with their Visability.Collapsed, the extra cpu overhead is not present.
PS: I'm running in windowless="true" as I need to display some html ontop of my silverlight form.
You should use the DataGrid in Silverlight 2 because it supports UI Virtualization. It has been tested with millions of items and will only create enough visuals needed to display.
Your guess is basically correct. Although Silverlight does not attempt to render all 3000 elements in the ListBox, it still needs to create 3000 ListBoxItem objects, which in turn get Measured and Arranged during layout time, etc, only for them to get clipped at render time. Layout happens much faster when the elements are Collapsed (since there is basically nothing for layout to do in this scenario).
WPF has VirtualizingStackPanel which would solve this problem, unfortunately Silverlight doesn't have this element.
+1 for using the Silverlight DataGrid in this scenario, make sure you have the latest version installed as the default Silverlight SDK version has a few bugs.
Another option is to use the free Silverlight DataGrid Control available here. One of it's features is also a Virtual StackPanel Row Container which means the grid can handle an unlimited number of rows.
Compare the performance of each and see which works best in your situation.
Just an observation - it looks like this is not an issue anymore with Silverlight 4. Adding 100K elements to a data-templated list box is instantaneous and it renders just fine as well.
This helped me: Silverlight DeferredLoadListBox .
It is written by David Anson, a Microsoft employee.
The DeferredLoadListBox derives from ListBox but has much better performance.