I want to search for an element in an android application page which has a count down animation, so the searching for the element does not finish until the count down ends.
Is there any way Appium does not wait and return immediate results?
Use threading while the one counts down other can help with the search and when the countdown ends the other thread can kill the searching thread.
Related
It seems that the api replaceCurrentItemWithPlayerItem: will stuck the main thread for some seconds, I understand that replacing the item need the information of the new item which might take some time to preload. But questions come up that why replaceCurrentItemWithPlayerItem: with a nil item object would also stuck the main thread?? It happens to me that sometimes it take more than 5 seconds to replace a nil playerItem.
I wonder what can I do to avoid the issue. Thanks for any advices!
I came across a similar blocking UI thread issue when I used UICollectionView to display and preview video in local photo library via ALAssetLibrary.
The scroll on switching videos is not smoothly,so I guess some method block UI thread.Then I use Core Animation of Instruments to analyze what exactly occupy the UI thread.In Time Profiler I found out that replaceCurrentItemWithPlayerItem need about 30ms to execute in main thread,which is more than 16ms (1000/60(fps)) result in choppy scrolling.
To solve the problem,first I tried that put replaceCurrentItemWithPlayerItem in to background thread using GCD,but It not work.I'm not sure if it is because the Cocoa itself need update UI when call replaceCurrentItemWithPlayerItem,which means the UI thread is still block.Finally I made it work by putting replaceCurrentItemWithPlayerItem at the scrolling end (the delegate func scrollViewDidEndDecelerating(scrollView: UIScrollView)).Now the scrolling is smoothly,yep!
Therefore,my advice is obvious : Using Instruments to analyse what exactly occupy the UI thread
We have here a page which contains quite a few UITableView.
When we transfer from this page to another, the application will have a one-second delay.
And there is another one-second delay when we transfer from the other page to the first page mentioned above.
Instruments reveals that the LayoutSublayers Method takes most part of the very one second, as showed in the picture below:
Can anyone tell me how to optimize the performance and kill the delay? I will appreciate any good suggestions.
In my application, I have actions/buttons that are linked to queries that load new forms and populate tables with data. I would like to have an animated spinner animate while the queries load.
My current code has by default the TaniIndicator.visible/enabled properties set to false and then when the button is pressed to load the new form, the procedure begins by enabling both of those TaniIndicator properties, however, in my application, the spinner never shows and only is faint to see once the queries are finished and the new form is ready to appear. help ?
Using Delphi xe4, developing an iOS application.
It is because you perform your query on the main thread, and UI updates is blocked while the query is executing. You should start indicator, detach a new background thread or queue, launch task on that thread. Once it is done, switch back to main thread and hide or stop the indicator.
I just coded:
application.processMessages
as the article suggested by #LU RD guides to...
Was no need to create another Thread.
I found interesting things.. Following code doesn't show #"One" and it show #"Two" after 3 seconds delay..
I think that #"One" need to be shown and then 3 seconds delay and then #"Two" need to pop up..
Am I wrong?
self.statusLabel.text = #"One";
sleep(3);
self.statusLabel.text = #"Two";
Thanks..
If you're doing this on the main thread, that sleep(3) will block it, freezing the app for 3 seconds. Event processing, including things like repainting the UI, won't happen til that's over.
To get what you're expecting, try something like this:
[self.statusLabel setText:#"One"];
[self.statusLabel performSelector:#selector(setText:)
withObject:#"Two"
afterDelay:3.0];
Does the first change, then queues up an invocation performing the second change to happen in the future. Then returns control to the OS to do any necessary redrawing.
Your notion of how things should work is incorrect.
self.statusLabel.text = #"One";
This sets the value of the statusLabel field to "One". This does not immediately draw to the screen. Instead, the label will mark itself as needing display. At the end of the current run loop cycle, all the views marked as needed display will be drawn, and then their contents flushed to the screen.
Next you do:
sleep(3);
self.statusLabel.text = #"Two";
This blocks the main thread for 3 seconds (never returning to the run loop to do the work mentioned above), then changes the value to "Two" which marks the view again as needing display.
When it is eventually drawn, and flushed to the screen, the current value is "Two".
It is hard to give more specific advice about what you should be doing, because it isn't clear if there is a real problem you are trying to solve, or just experimenting in order to learn more about the frameworks.
But you should almost never use sleep, and you certainly shouldn't be blocking the main thread with sleep for several seconds.
You're wrong...
Think of it this way: when you execute code in a block you're telling iOS what you want to do. It only actually implements your instructions after you pass control back to the OS.
Your code blocks the main thread (which is a very bad thing to do).
What you need to do is set the label to "One" then set a timer that will fire in three seconds time. The code in the timer would set the text of the label to "Two."
I'm working on a game, and I'm using a CAEAGLLayer backed UIView subclass to present the game engine. Touch handling is done using -touchesBegan:withEvent: et. al.
Everything works fine, except that very rarely, if one of the on-screen controls is tapped rapidly, -touchesBegan:withEvent: doesn't get called for somewhere between 0.1 and 1-2 seconds. This happens maybe one in 20 times, and only if you tap the screen rapidly (4-5 times) first. It seems to be more likely to happen if I am also holding down another finger on a different control on the screen.
Thinking that it was something to do with my own code, I subclassed UIApplication so I could add a logging statement to -sendEvent:. When the laggy touch happens, -sendEvent: doesn't get called until some period of time after the touch has started, so it the touch handling code inside my UIView subclass doesn't appear to be at fault.
Does anyone have any idea what's going on here (other than iOS having some obscure bug)? Is there some sort of internal "events queue" that makes event delivery become laggy when it fills up? Has anyone else experienced this?
Touch events are only dispatched in the main UI run loop, and sometimes only when the main run loop goes idle for a bit. So if your app is busy handling several previous touch events in a row without taking a break, the main UI run loop might be saturated, and thus not get any further touch events until done with the current stuff.
Touch events also have time stamps. So you can check if they're coming too fast (faster than your event handlers and resulting UI updates can run), and skip or combine some of the event handlers, as appropriate for your app, if you want the app to stay maximally responsive.