I have a Today Extension and I have a textfield and button and what I want to do is if textfield.hasText == true do something and if textfield.hasText == false then i want to show an alert within the widget
First of all, Keyboard Entry is not allowed in iOS Extensions, so have a UITextField in Today Widget doesn't make any sense.
Because user interaction with Today widgets is quick and limited, you
should design a simple, streamlined UI that highlights the information
users are interested in. In general, it’s a good idea to limit the
number of interactive items in a widget. In particular, note that iOS
widgets don’t support keyboard entry.
Related
I have custom text view that implement UITextInput. Everything works except the voiceover does not repeat the characters I typed using soft keyboard.
Is there any additional API or services I need to implement in order to make it work?
Unfortunately, now it seems that VoiceOver cannot announce the soft keyboard feedback made by native code.
But it possible to get VoiceOver feedback at text field of WebView().
So, I'm making iOS App by this way.
In an iOS application, is it possible to make own keyboard suggestions if the user taps a specific UITextField? The suggestion should only appear if the UITextField is empty.
By keyboard recommendations I mean the Predictive Keyboard:
Swift code is preferred.
Thanks!
I don't think you can provide suggestions to the actual keyboard so they get presented, but what you can do is write your own inputAccessoryView to be there instead, and handle the tapping/appending of text yourself, and possibly disable the completion from the keyboard. This is essentially what the messaging apps do to present a bar with buttons to add photos and attachments when writing.
Since you don't mention what you're trying to accomplish I don't know if this would make sense. Let me know if you want me to elaborate on how to do this in code.
First of all I'm not looking for code or how to do it, just the process.
I don't fully understand how Custom Keyboards work in iOS8-up and I would like to include a simple custom numeric keyboard in my app. In the past I have created static keyboards with multiple UIButtons which are visible all the time, this time however I want a custom 9 digit keyboard with the same behavior as one of the default keyboards in iOS, in other words, the keyboard will show when a UITextField is tapped and hide when the resignFirstResponder method is called. I want this to be the default and ONLY keyboard used in my app.
What are my alternatives to adopt the behavior described above?
Do I need to create a Custom Keyboard extension?
Can someone describe the process to include a custom keyboard that acts as the default keybaord WITHIN your app?
Again I'm not looking for how to do it just the process.
Thanks
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.