I am developing an iPhone app, and have come across an issue that leaves me completely perplexed.
In the app, there is a normal UIView, which consists of a UISegmentedControl. This UISegmentedControl is not once called or looked at in the code, in fact, there is no IBOutlet whatsoever, it lives only on the Storyboard.
Every time I load the app on my phone, my segmented control looks like this:
However, to my dismay, after a certain yet to be found out mixture of using the app, putting it in the background, and then using it again, the segmented control turns into this:
I know I don't have much more information to provide as of yet, but it seems hard to give any sort of code when there isn't any to do with the UI of the segment.
What I can say is that my "Use AutoLayout" is switched off.
I hope one of you can provide me more insight on how to fix this, thanks.
Related
Setting showsTouchWhenHighlighted, e.g. via the IB option "Shows Touch On Highlight," on a button without a title will alter the VoiceOver description. After reading the accessibility label, VoiceOver beeps and announces a description of the image. Is there a way to disable this behavior?
Setting the accessibilityContainerType value to UIAccessibilityContainerTypeSemanticGroup works and that's great 👏 but I'm not sure that
this is the goal of this element.
Even if a button my be seen as a container, I understood this instance property dealt with
data-based containers rather. 🤔
I looked into your problem that arouse my curiosity and couldn't find out an appropriate solution with the Apple API unfortunately.
First, I thought that this solution may help but it didn't work as you mentioned in your comment... thanks. 😉
Apparently, when the showsTouchWhenHighlighted property is used, there's an added view inside the button that renders the glow touch ⟹ this is a UIButtonBarPressedIndicator image you can detect thanks to the Debug Hierarchy in Xcode for instance. 👍
This new image seems to put the default value of the accessibility trait property of your button image even if you have already changed it programmatically. 🤯
So, in order to avoid VoiceOver from using the screen recognition and reading out some useless information, I made something very ugly but efficient to reach your goal in the viewDidAppear for instance (see the 'basic operations' sheet of this link):
myButton.subviews.forEach{$0.accessibilityTraits = .none}
Bad hack due to a native problem of implementation or a simple line of code that anyone can understand, this solution removes every possible VoiceOver screen recognition from the button 🥳... and I'm still interested if you can explain a little bit the reason why your solution works, please. 😉
Set accessibilityContainerType = UIAccessibilityContainerTypeSemanticGroup.
I am fairly new to developing for iOS. I have a fully functioning program written in Swift and the UI was created in the scene builder on Xcode. I created an app for my work to simplify closing out the registers and other financial aspects. The app is complete and works perfectly, but was designed on the iPhoneX. The problem is that only a few of the employees have an iPhoneX, but they all have some kind of iPhone. I have tried setting up constraints but it never works. Ive tried scaling restraints and position restraints but I can't get the layout to look right on any other phone, and when I add the constraints it affects the view on the iPhoneX as well and doesn't look good on any iPhone. I need help getting this to work on all iPhones. I would like it to look and act the exact same regardless of the size of the phone, basically just scaled down. There are a lot of things on the screen and I can't figure out how to do this. Please help!!!
I have been working on this for a long time and I really need help. Please let me know if I need to clarify anything. I have posted links to some pictures of my UI so you have an idea of whats going on.
Constraints I tried adding, although I have played around with some other options.
Here's what it looks like on the iPhoneX, this is how I want it to look.
What it looks like on iPhoneSE (with constraints).
One thing I noticed in your Xcode project that none of your features are in UIView. Without it, it will be quite challenging and somewhat always different results. In theory, if you use AutoLayout features correctly it should work without UIView, but they make life so much easier. This is something I learned the hard way at the beginning of my iOS development. First set up your UIViews without any content inside it, give them some background colour to differentiate, once they are working on all devices. You can pin your features to superviews with no difficulty.
Since you have a repetitive features, you could also consider using Stack Views. You don't have complicated features, so as long as AutoLayout is set up correctly you should have no problems seeing it ok on all devices
I'm having a small annoying issue, I'm using storyboards on this app since it's creation, I want to make an update to it and something that used to work before doesn't anymore
See I was using an image as a UINavigationBar Title, Dragged it to the storyboard and it worked almost automatically,
Now well the image doesn't display anymore... Here's a screen :
As you Can see, the UIImageView is there, but nothing shows up. and when I run the app, still nothing...
I'd like to solve it trought Storyboards, but my knowledge is limited
thanks
I have lots of views - sub classes (UILabel, UIVIew, UIButton etc) using core graphics (within drawrect).
These show fine within normal interface builder.
However they do not show in the preview assistant editor for the storyboard (where you can see how views should look on actual devices).
I've been doing some research and found posts suggesting prepareForInterfaceBuilder should be used. However this doesn't show in preview for me.
I asked this question some years ago, IB_DESIGNABLE, having views show in preview? however I can't reproduce this, I'm not convinced it did work back then either.
I'm still following the same approach, with a framework and that link shows my implementation.
I know that prepareForInterfaceBuilder should be used to do something different, to show something basic. Therefore I believe that core graphics won't work.
However, I can't even get a simple change in background color to work in the preview, although it does work in normal interface builder.
I would like to know if this is a bug (that core graphics can not be used in preview) or still a limitation in xcode?
At the very least I'd like to do something simple (like a change in background color). I have a lot of views and an impossible task to make auto layout changes.
Previously I was producing lots of screen shots, different devices, languages etc (via automation) just so I could see my auto layout changes, which is really slow way to work.
I can verify this is a long standing bug. Apple doesn't care. Custom view be damned. All those dollars spent for more broken Xcode functionality.
Android?
Daniel
I am looking to implement a custom toolbar that sits above my keyboard for a text field with some custom values. I've found a ton of tutorials online but this question is for asking what's the best way to do this.
This tutorial here http://blog.carbonfive.com/2012/03/12/customizing-the-ios-keyboard/ provides the most common way I can see across many tutorials, with creating a new subclass of UIView and using delegates to get that information across.
That's the commonality. However, I came across this tutorial which in the view controller itself just creates the toolbar, assigns it to the textField inputAccessory and it's good to go. In fact, I tried out the code and without any effort, I have now a custom keyboard.
http://easyplace.wordpress.com/2013/03/29/adding-custom-buttons-to-ios-keyboard/
This just seems a bit too easy to me though and I'd think the proper, Apple recommended way would be to create that UIView subclass and use delegates so that the view controller with the text fields acts as that delegate.
I'm specifically targeting iOS 7 in my app.
What are people's thoughts on this? If the second easier link is supported and is likely to pass Apple's guidelines, it's a good starting point but if delegates are the way to go, I'd rather look into that from the start.
Your thoughts will be appreciated.
There is no 'Apple Approved' way to do this, and its hard to believe anything you do here would get your app rejected. The custom keyboard you reference in your post has the iOS6 look and will appear outdated in an iOS6 app. I'll mention some iOS7 suggestions shortly, but the constant danger of mimicking what the System looks like today is guaranteed to look outdated later. In Mac/Cocoa development, Apple use to say at the WWDC that if you did something custom, make it look custom, don't take a standard Apple widget and try to duplicate it. But that advice is mostly ignored.
For iOS 7, you can create buttons that appear just like the system ones do (not pressed), but of course when someone presses them, they won't act like system buttons (i.e. animate up and "balloon" out.
I'm currently using a fantastic add-on keyboard, my fork of KOKeyboard (which uses the buttons above). This is such a cool addition. While the buttons look like iPad buttons, each one has 5 keys in it. By dragging to a corner you select one of the four, and tapping in the middle gives you that key. This might be overkill for your app, but it really helped me with mine. It looks like this:
(the Key / Value is in the under laying view.) The center control lets you move the cursor - its like a joy stick - and can be used to both move and select text. Amazing class, I wish I'd invented it!
Also, for any solution, you want to use a UIToolbar as the view holding the keys, for the reason that it supports blur of the view it overlays, just like the keyboard does. You can use the UIToolbar with no bar button items in it (if you want), and just add subviews. This is a "trick" I learned here, as there is no other way to get blur!
David's KOKeyboard (er…, the one he used - see David's comment below) looks nice. I suspect that he is using the official Apple mechanism:
inputAccessoryView
Typically, you'd set that value on a UITextView, but it can be any class that allows itself to become the first responder.
The provided view will be placed above the default apple keyboard.
It is correct that there is no official mechanism (and it is suggested against) to modify any system provided keyboard. You can add to it, as above. You can also entirely replace it for with your own mechanism. Apply will forgo the keyboard setting on your view and use a custom input mechanism if you set
inputView
set it to any view - Apple will still manage its appearance and dismissal as it does the custom keyboards.
Edit: Of course, iOS 8.x added significant access to keyboards. (not mentioned here)