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)
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've started developing for tvOS recently, and discovered that while TVML isn't ideal for our use case, we'd still like to display a number of screens that display the same types of content as I've seen in existing Apple apps, and which I know can be created with TVML.
As an example, I want to display a page of terms, the same way that the Apple TV displays information as a scrollable page of text.
I could do this custom, where I place my own textView on a UIViewController, and setup the width and positioning myself. But it's scenarios like this, where I'm wondering if there's some already existing standard control for it, such as a UIViewController subclass already setup for displaying Terms? Is there a set of these I could be looking at?
UIAlertController should solve what you're looking for. You configure the text, buttons, and then present it.
More info in the docs:
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIAlertController_class/
I have one doubt that how exactly GIF images loaded into Custom keyboard and user can send it. I am new in iOS so want some link which i can refer and will be helpful for me.
Read Apple docs for this, especially this one https://developer.apple.com/library/ios/documentation/General/Conceptual/ExtensibilityPG/Keyboard.html is a good strating point
You can set any UIView as the view for the keyboard layout, so an UIImageView is suitable for your purpose. The real difficulty in custom keyboarding is the management of events. As you are new to iOS dev, I would like to encourage you to try much simpler things first.
I was wondering if it is possible to get the stock Apple keyboard design as a file to make a own custom keyboard with only slight changes to the original one.
I would like to only change one Key and was hoping that I don't have to build the whole design myself and try to imitate the original design.
Thanks in advance
I built a custom keyboard with the same look as the system keyboard (except it has only one "letter" key!): https://github.com/acoomans/ACKeyboard
I'm sure you can start from there and adapt it to your need. Good luck!
There is another custom keyboard with all the keys here. Looks like the might be a bit hacked together but could be another good place to start. https://github.com/archagon/tasty-imitation-keyboard
Ok,
I'm very confused about something... being new to development on iOS I'm often pushed towards the storyboard/graphical design (specially to make file owner, segue, etc type of connections). HOWEVER; every time there's something besides a basic (dare I say primitive) design, I have to do things via code... problem is that just because you can do something via code doesn't make it right according to Apple. so you have to know all the rules to have you app approved. Even some of the examples from Apple (UISPLITVIEW with multiple view controllers -> MultipleDetailViews) do not have story boards just XIB... is that normal???
So question is: why have graphical design if you have to move towards coded solutions anyway. just to say that you have an easy to program interface?
can anyone help me understand that??
cheers!!
Three things (at least!) are going on here:
Storyboards are relatively new and a lot of examples existed before storyboards were introduced.
People are always dreaming up things that are more complex than a very high-level approach can handle. (Even with .xib files, which are more flexible than storyboards, people write custom code to get around limitations.)
For examples, code is linear and a bit easier to follow than the description of a bunch of clicks and drags.
So, first of all, a storyboard is nothing more than a conglomerate of .xib files. When you use storyboards, Xcode handles unloading all the nibs for you. At its core, your app still uses these nib files.
Additionally, your app won't get rejected if you use code to set a property instead of setting it in Interface Builder, or vice versa. I don't know that I would say Apple's stance is just because you can do something in code doesn't make it right. I would argue that they urge developers to set as many properties via IB because less code that you write means less bugs that you introduce. If I have a view in a nib, and I check its "hidden" property in IB, that's no different than me saying view.hidden = YES in code. Apple doesn't prefer one over the other. But using IB relieves me from having to know that the property to hide a view is "hidden" and that it accepts a BOOL as an argument. If in iOS6 they decide to make it shouldHideSelf, using IB's hidden property will be automatically updated, where as I would have to manually update my programmatic setting of the hidden property.