I have a function that continuously takes screenshots of an UI element to then draw it itself. The UI element can change, so I take a screenshot in very short intervals to not have the second drawing lag behind (please don't question this and just assume that redrawing it is the right way. The use case is a bit more complicated).
However, taking the screenshot and invalidating the previous drawing to redraw it is quite an expensive operation, and most often not needed as the UI element doesn't update that often. Is there a way to detect when a UI element changes in such a way that it needs redrawing, including when it happens to one of its subviews? One solution would be to copy the state and the states of all its descendents and then check that, but that doesn't seem like a good solution either. iOS must know internally when it needs to redraw/update the views, is there any way to hook into this? Note that I tagged this UIKit and Core-Animation, I suppose the way to go for this is Core-Animation, but I'm open for a solution that uses either of these.
Related
I’m trying to ascertain what exactly happens differently when posting a UIAccessibilityLayoutChangedNotification, and a UIAccessibilityScreenChangedNotification. From what I can see, I can use them interchangeably everywhere and nothing different happens.
The Apple documentation simply says to use LayoutChanged when (for example) an element has been hidden or shown, and to use ScreenChanged if the entire screen changes, but I’m interested in what THEY do when I provide this information, and what I should see differently when using one or the other.
Can anyone give a clear explanation of implementation differences between the two?
These two notifications are for dynamic content on views, and communicating these changes to VoiceOver for screenreader users. There is little difference between these two notifications, except for their default behavior, and the silly little "boop beep" for ScreenChange notifications.
In both instances, the argument
UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, arg);
Represents a string to be read out, or an on screen element, which VoiceOver will shift its focus to. In the event of dramatic context changes, it is important to send focus to a place that makes sense, or announce that such changes have taken place. Either approach is acceptable from an accessibility point of view, though I prefer approaches that involve the least amount of change possible. In the event of simple layout changes, it is almost always best just to announce the context change, and leave focus where it was. Though sometimes, the element that caused the context change is hidden, and then it is clearly necessary to direct voiceover to highlight new content, because the default behavior in this case is undefined, or perhaps deterministic, but determined by a framework that knows absolutely nothing about your app!
The difference between the two events, given that they both do exactly the same thing, is in their default behavior. If you supply nil to the UIAccessibilityLayoutChangedNotification it is as if you have done nothing. If you supply a nil argument to the UIAccessibilityScreenChangedNotification it will send focus to the first UIObject in your view hierarchy that is marked as an accessibilityElement, once all view hierarchy changes and drawings are complete.
UIAccessibilityLayoutChangedNotification
A good use case example for UIAccessibilityLayoutChangedNotification is for dynamic forms. You want to let users know that, based on decisions they've made in the form, new options are available. For example, if in a form you select that you are a Veteran, additional areas of the form may pop up to provide more input, but these areas may have been hidden to other users who did not care about them. So you could shift focus to these elements after user interaction:
UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, firstNewFormElement);
Which would shift focus to the provided element, and announce it's accessibilityLabel.
Or just tell them that the new form elements are there:
UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, #"Veterans form elements available");
Which would leave focus where it is, but VoiceOver would announce "Veterans form elements available".
Note: This particular behavior is bugged on my iPad (8.1.2).
Or finally you could do this:
UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, nil);
Which does absolutely nothing :). Seriously, I don't even think the a11y framework backend cares. This particular line of code is a complete waste!
UIAccessibilityScreenChangedNotification
A good use case example for the UIAccessibilityScreenChangedNotification is customized tabbed browsing situations. When the entire screen, with the exception of your navigation area, changes. You want to let voiceover know that essentially the entire screen changed, but NOT to focus the first element (your first tab) but to focus the first content element.
UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, firstNonGlobalNavElement);
Which would play the "boop beep" sound and then shift focus to just beneath your global navigation bar. Or you could do this:
UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, #"You're on a new tab");
Which would wait for the new tab to load, play the "beep boop" sound, announce "You're on a new tab" in voiceover, then shift focus to the first element on the screen, then announce the accessibilityLabel for that element. (PHEW! That's a lot! This is jarring for screen reader users. Avoid this scenario, unless absolutely necessary).
And finally you can of course do this:
UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, nil);
Which is equivalent to:
UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, firstA11yElement);
Both of which will play the "beep boop" sound, shift VoiceOver focus to the first element on the screen, and then announce it.
Finally
In a comment somebody mentioned caching, and I occasionally comment in my answer about things the A11y Backend may or may not care about. While it is certainly possible that there is some backend magic happening, I don't believe in either of these circumstances, the back end cares at all. The reason I say this is because:
If you've ever used the UIAccessibilityContainer protocol, you can watch as your container of views gets queried. There is no caching going on. Even the accessibilityElementCount property gets pinged each time VoiceOver changes focus to a new AccessibilityElement within your container. Then it goes through the process of checking which element it is on, asking for the next element, and so on. It is designed at its core to handle dynamic situations. If you were to insert a new element into your container after interaction, it would still go through all of these queries and be just fine about it! Furthermore, if you override the properties of the UIAccessibility protocol, in order to provide dynamic hints and labels, you can also see that these functions get called every time! As such, I believe that the A11y Framework backend gleans ABSOLUTELY ZERO information from these notifications. The only information VoiceOver needs to do its job is it's currently focused Accessibility Element, and this elements Accessibility Container. The notifications are simply there for you to make your app more usable for VoiceOver users.
Imagine if this weren't the case how many times Safari would post these notifications!!!! :)
These particular statements can only be confirmed by someone with backend knowledge of the framework, who works with the code, and should be viewed as conjecture. It could be the case that this is highly version/implementation dependent. Definitely open to discussion on these points! The rest of this post is pretty concrete.
For Your Reference
Most of this comes from experience working with the frameworks, but here is a useful reference if you wish to dig further.
https://developer.apple.com/documentation/uikit/accessibility/uiaccessibility
https://developer.apple.com/documentation/uikit/uiaccessibilitylayoutchangednotification
https://developer.apple.com/documentation/uikit/uiaccessibilityscreenchangednotification
And finally, an open source repo of the silly little app I put together to test all this stuff.
https://github.com/chriscm2006/IOS-A11y-Api-Test
UIAccessibilityScreenChangedNotification is to indicate that the whole screen has changed and VoiceOver should reset.
UIAccessibilityLayoutChangedNotification is to indicate that one or more, but not all, elements on the screen have changed.
when your UI changes dramatically. Usually when a user moves into a different part of your app (navigates to a different screen). VoiceOver notifies the user with a tone, and it clears its caches and does other preparations to deal with a new set of accessibility data. It alerts VoiceOver that the screen has changed and there may be new elements on the screen so VoiceOver will rebuild it's index of accessibility elements.
UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, nil);
If some part of your UI changes, but the user hasn’t necessarily jumped to an entirely different part of your app. (Example: in the iTunes Store app, tapping on the price label ($0.99, etc.) next to a song changes it to a “Buy” button.) This notification tells VoiceOver to re-read the current state of all accessible items that are on-screen, and by doing this it figures out what has changed and informs the user of those changes. It alerts VoiceOver that the layout has changed and that it's current index is out of date because the items on the screen have reordered themselves.
UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, nil);
I'm building a cross platform UI library's iOS implementation using UIKit, one of the library's primary function is allow user to change the child control's size freely, and the parent control's size will automatically adapt.
Since refresh the parent's size everytime when a child's size changed is inefficient and unnecessery, so I designed the UI system to refresh all "dirty" control's position, size, and a lot of things before actual device draw/render happen. On iOS, I use CADisplayLink to call the refresh method, then I discovered the event was called AFTER everything has presented onto screen, that caused the following problem:
User will see a "crashed" layout first. (The render happens first)
After a short period (CADisplayLink's event triggered), everything will return to normal.
At first I thought my way of using CADisplayLink is wrong, but the solution cannot be found anywhere, so I'm quite despaired right now (I'm going to hang my self!!)
Or maybe I shouldn't use CADisplayLink at all?
Please Help me!
PS. Since I'm building a cross platform thing I'm actually using MonoTouch, but I believe the basic concept is same.
PS2. And since I'm using MonoTouch, which is C#, so the description above may not fit in the Objective-C world (like the word "event", I think the Obj-C relevant is selector, or something ^_^)
PS3. Also please pardon my poor English, feel free to ask me any questions if my description isn't clear enough.
Codes here:
CADisplayLink _displayLink = CADisplayLink.Create(Update); //Update is my refresh method
_displayLink.AddToRunLoop(NSRunLoop.Current, NSRunLoop.NSDefaultRunLoopMode);
Should be easy enough to understand ^_^
From all the information of what I can gather, is that basiclly there is no way of doing that. So I have modified my layout code, which now apply the properties immediatly after a value is set. Some optimization still required, but no need to rely on CADisplayLink anymore.
Thanks anyway!
I want to restore my view state, and my view has aUIPickerView.
UIPickerView looks to me like it has graphics components, namely the background wheel image. I know thatUIImage cannot be archived. Anything with an image, likeUIImageView, you have to first set the image tonilbefore you can encode it.
However,UIPickerViewisNSCodingcompliant. That means thatencodeObjectanddecodeObjectshould work.
They don't though. I mean, they don't cause any errors. But after decoding, you get theUIPickerViewwithout any images. It doesn't look good!
Here's a before and after shot just to prove I'm not going mad:
Before
After
Now, I know that I could simply store the current user selection, and recreate the view by invoking the picker'sselectRowmethod. But really, I'm curious. Why isUIPickerView NSCoding compliant if it isn't really and you can't do anything further to get the background wheel image back?
You seemed to have answered your own question. UIImageView conforms to NSCoding yet does not save the UIImage (obviously since the image is saved elsewhere) so why would you expect UIPickerView to behave any differently?
From what I've read (although never done) NSCoding on UIViews is used to save state (frame, visibility, etc) not the actual view. Although a little inconsistent on Apple's part, it seems logical to me, since the entire UIView library is already in iOS, why waste time & space reserializing all that data?
The only thing that would be gained from your proposed solution would be a little less boilerplate code (for resetting the view) and has the potential to slowing the reading/writing of the objects down (because it has to account for the images)
When using the Ti.UI.iPad.SplitWindow what is the best(cleanest looking) way to update the detailView?
The options I can think of are changing the positions of elements in the detailView event or to show()/hide() vs open()/close() on an orientationchange event. I know that using the native UI components on the iPad should dynamically update to the layout width/height of the iPad but in my case the content on each detailView will have it's child objects positions updated on orientationchange. I'm just trying to get the smoothest from your all experiences. Even if I have to build custom animations I just want to start this correct from the beginning so no current code exists yet. Thus none included.
I'm hoping this isn't a duplicate as I searched before I ask but there are no Titanium based questions on this topic I can find. Possible but still different to what I'm asking.
The smoothest experience will be delivered by changing the least. I don't know what animations you are envisioning, but I would nudge you towards keeping it simple.
Here's a quick example of an orientation change in an iPad app I built recently. I had a bunch of images in a view with layout: 'horizontal'. Due to a nice bug, the images wrapped automatically. When the user reoriented the device, I animated the width of the view, and the images automatically and animatedly resorted themselves.
I've also had some clients at a large corporation get their hearts set on really complicated changes to the layout whenever the user reoriented the device. This resulted in a really unsatisfactory app that took 10-20 seconds to reorient. We made a lot of optimizations, and a lot of improvements in both their code and the underlying framework, but the heart of the problem was the complex design.
Take the time to consider if you really need complicated changes every time the user reorients, and how much benefit you are offering to your users. Also consider the cost to the user (not just to the device) of presenting them with a new UI.
Past that, you're probably not going to get too many answers until you put some experimentation in to this. If you come back with some code and some questions to go along with it, I can reformulate my answer to better pinpoint your situation.
Hope this helps! -Dawson
So I have a printing component that serves a Silverlight application. Other modules in this program have the ability to signal the printing component and pass it a UIElement, which the printing component will then draw to the screen. All well and good. The problem arises when I try to manipulate the UI Element in order to better format it to fit the user's selected paper size or anything to that effect; it seems that the UI element that is passed in is frequently the exact same instance of the one on the screen, and the screen element changes itself to match the 'print-only' changes I have made. For now, I can manually save the previous values, make my changes, and restore the previous values, but it would be easier/more robust/more efficient/more flexible if I had a way to, given the UI element, make a copy of the element, and manipulate that freely, without worrying about alterations or state on the original UI element. How can I programatically copy an instance of a UI element such that I have another instance with the same visual appearance?
I know 2 ways you can try:
Save the object to a xaml string and recreate it from it.
(XamlWriter.Save and XamlReader.Parse)
Save the object with the serializer to a memorystream and recreate it from that - it is possible that not all objects are marked serializable so the other option might be the one to use.
It might seem a bit much - but there are not so many ways to create a deep copy - and not any standard c# method that I know of.