I'm currently working on a keyboard extension for iOS, and am now wondering how to integrate multiple layouts support into the system settings.
In the system settings, the default en_US keyboard has an additional menu (indicated by a arrow to the right), where you can choose from multiple keyboard layouts, as you can see in the screenshot from the iOS simulator below (iOS 9.1 13B137)
Can this be achieved with a custom keyboard extension, too? I can't find any documentation on it. (Which may mean that it either isn't possible using public APIs or I am too stupid to use Google.) I've searched quite a lot online, but most of what I find is about setting the keyboard locale in the Info.plist file or instructions on how to enable the system keyboard in different languages (which are registered as different keyboards), which I would like to avoid.
I can see an alternative, if this doesn't work, which would be to basically create multiple keyboard extensions in one wrapping app, which include the same code base, but define other layouts. However, this would look rather ugly, clutter up the code, and people will have to enable each layout individually, which, from my point of view, isn't the most user-friendly approach. As stated above, iOS ships with different keyboards for different languages, but I'm trying to provide multiple keyboard layouts for the same language, so this is not what I want.
This doesn't appear to be directly supported. Like you said, other third-party keyboards are stepping around this issue by providing alternate keyboard layouts as a function within the keyboard itself.
For example, Swype allows QWERTY/AZERTY/QWERTZ layout changes by long-pressing on the spacebar.
Related
I am making an app where I use the "People" emojis as avatar faces and the "Food and drink" emojis for, well, food and drink icons. I would like to use the regular keyboard for presenting the emojis for user input, but I would like to present only these two categories of emojis (and even so, each category would be presented in a different context).
I am working with iOS 8, Xcode 6.3 and Swift.
Can I configure the regular keyboard so that it only shows a subset of emojis which I define?
If not, can I create a new custom keyboard preserving everything from the original Apple keyboard but limiting the subset of characters? Any pointers on how to do this?
Thanks.
You can not configure the regular keyboard so that it only shows a subset of emojis. But yes can make your own custom keyboard.
You can find some really good posts about how to make the custom keyboards:
http://verisage.us/en/blog/2014/07/17/ios-8-custom-keyboard-swift-tutorial/
http://code.tutsplus.com/tutorials/ios-8-creating-a-custom-keyboard-in-swift--cms-22344
Also I found this FaceBoardPlus sample: http://code4app.net/ios/FaceBoardPlus/52a9ba56cb7e841e178b69d0 which is exactly what you are looking for but written in objective c.
EDIT: From iOS developer library:
After a user chooses a custom keyboard, it becomes the keyboard for
every app the user opens. For this reason, a keyboard you create must,
at minimum, provide certain base features. Most important, your
keyboard must allow the user to switch to another keyboard.
To provide a fully custom keyboard for just your app or to supplement
the system keyboard with custom keys in just your app, the iOS SDK
provides other, better options. Read about custom input views and
input accessory views in Custom Views for Data Input in Text
Programming Guide for iOS.
I want to design my own custom input view keyboard using a custom keyboard extension in swift. The existing Xcode 6.1 default set of keyboards do not fit my app needs. What I want is an enhanced number pad which I would modify, like in the Soulver app in the iOS app store. http://www.acqualia.com/soulver/iphone/
Ultimately I do not need a custom keyboard extension to offer to other apps but I do not mind if my app offers one. It looks to me like custom keyboards are the right place to start for for a custom input view keyboard.
I finally just about have digested constraints in the editor and would like to make use of a storyboard or xib.
I do need to be able to programmatically select the keyboard extension within the app.
The keyboard/custom view needs to be available to the app that contains it without activation in iOS settings.
Can this be done as an extension given the requirements, or can the custom keyboard extension be easily converted to a custom input view? Can you illustrate either one or point out sample Swift code I missed when searching? Thank you.
I am writing a keyboard extension in Swift right now and highly recommend not doing the same. Both Swift and the Keyboard Extension API are brand new, not well documented, creating significant learning curves, and both have significant bugs or weird implementation details to work around.
From the way you phrased your question it doesn't sound like you are very experienced in iOS development, and attempting to learn too many things at once is a recipe for disaster. If I could do my current project over, I would have done it in Objective C just to vastly simplify what I was learning.
But the good news is that you don't need the keyboard to run in other apps. This is good news because writing a custom input keyboard class within your own app is very simple and easy, and a great place to start. There is a good deal of existing documentation on how to do so, including this excellent post on stack overflow.
How do I retrieve keystrokes from a custom keyboard on an iOS app?
More detail:
The standard custom input view API in cocoa is very powerful, the one in the keyboard extension is almost entirely neutered, so you can do far more with a custom input view than you can with a keyboard Extension. To activate a keyboard extension requires getting the user to turn it on in their iPhone settings, there is no way around that and no way to pick which keyboard they choose within your app (other than to not allow custom keyboard extensions at all).
If you need to access the internet or data within your app for any reason (tracking usage information, activating an in-app purchase, accessing preferences) you must also convince your user to turn on "Full Access", which presents an incredibly scary alert that reads to users as if turning it on means you will be able to spy on them and steal their passwords
Getting back to why you don't want to use Swift in an extension. First, Objective C doesn't cause Xcode's code parser to crash many times a day, while developing in Swift does, sometimes crashing Xcode itself. In Objective C the debugger is almost always correct, in the current version of Swift often you can't see array or dictionary contents, sometimes what it shows is inaccurate, and when stepping through code often takes nonsensical routes. Developing in Objective Code means you won't have to update your code because of changes to Objective C itself, with Swift it's pretty much guaranteed they'll make significant syntax changes every major release (the last one in September did).
Developing a keyboard extension means sometimes your extension won't load for mysterious reasons, and you'll need to waste hours debugging why. My Swift keyboard extension is sometimes debugged solely with println() statements because I can't get the debugger to load. Since Apple's tools don't yet work well with Keyboard extensions, and also don't yet work well with Swift, using them together are multiplying your pain exponentially.
The end result is if you don't need to use this keyboard outside of your own application it's foolish to build it using the Keyboard extension API. If you do need to use the Keyboard extension API it's foolish to do it in Swift. This is written by a fool working full time trying to ship a Swift based keyboard extension.
If you want to use the standard cocoa custom input view API, then using Swift is probably fine. You will still have to deal with additional problems because it's such a young language, but you won't have lose so many days to mysterious, seemingly insoluble problems trying to figure out if they were caused by Swift, the Keyboard Extension API, failures in Xcode and it's debugger, or your own blunder.
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)
I'd like to build a custom iOS control which can take keyboard events from a physically keyboard connected to an iPad. I'd rather not subclass or otherwise make use of any of the existing high level UIKit classes but would rather receive and process the low level keyboard events themselves.
Is this even possible with an iOS app?
Unless you are going to implement your own keyboard (not recommended - it's wrong on so many levels including internationalisation/foreign language support), you'll need to either use an instance of UITextField or UITextView or subclass one of these classes. AFAIK (and I've looked into it in some depth) there is no other way to trigger the on-screen keyboard in iOS.
You might try looking in the ExternalAccessory framework - maybe you could find an open source implementation of the USB keyboard interface and put that to work.
I've read a lot of topics about developing a custom keyboard for iOS and it's clear that it is impossible to build a system-wide alternative keyboard.
But I still try to understand how Emoji keyboard(the emoticons additional layer) could make it possible and it is an official app on AppStore (that means it passes Apple approval!).
Note that their keyboard, once installed, can be added in Keyboard section in Settings!
Thanks for help
Emoji apps enable a by-default-disabled keyboard built into iOS. If I recall correctly, it's enabled by default in certain regions (Japan) but disabled in most places. So they aren't adding a new keyboard, just revealing one that's already there.
edit: ... and here's how they do it
The Emoji Icons are a stored in the private use area of unicode. They won't look any good on a different device than an iPhone/iPad, this is Apple specific.
The app is just to enable the keyboard. You can do it yourself: Making An Emoji Enabeling App.
Have a look at The truth about iPhone Emoji, which sheds some light on the whole topic.