Nokia E61,E71 etc has different variations of keyboard layouts like QWERTY, QWERTZ , AZERTY etc. Is there a way I could detect the current keyboard layout through J2ME?
And there is also some funny thing happening, some E61 we tested has QWERTY keypad but is running QWERTZ layout pre-installed. Is anyone aware of such issues?
I don't think you are going to be able to find out what the physical keypad layout is unless Nokia encoded a pattern into the "microedition.platform" System property. I couldn't find any.
If the physical key is sending the wrong key code to java, I would expect it to also behave badly in native applications and the one reason I can see for this would be that the handset contains the wrong version of the firmware (The physical handset is localized for one region and the firmware is localized for a different region).
Related
Question
I would like to catch/preview all keyboard inputs that our application receives.
It would be enough if only the inputs from the external keyboard is caught.
I've come around solutions examples such as register a notification observer for UITextViewTextDidChangeNotification and UITextFieldTextDidChangeNotification but since this requires a TextView or TextField to be the current first responder it does not capture all our needs.
An example for this is that we are using the scanning to filter a list where the entire view is the list and navigation buttons.
Are there any way to register an observer that can preview all key inputs the application recieves?
Background:
I have an iPhone application that scans barcodes to identify objects at several different views.
Currently we scan the barcodes either by the camera (using zbar library) or with an MFI-certified barcode scanner.
In order to support more devices (for example an iPad) we are investigating other means to capture bar codes.
One of the device classes we are looking at are bluetooth scanners that identifies as a HID keyboard. This would be a great addition since it be usable with different products and manufactures.
In order to
Another option for iOS 7 and above is to use declare a keyCommands method on the current view controller. It can trap special key combinations. The downside is that you'll need to explicitly declare what you're looking for.
I answered my own question over here about getting special characters out of 2D barcodes from scanners connected in HID mode.
Seems like usage of IOHID** functions may not be rejected by AppStore reviewers because IOKit is "white-list-framework" (Will Apple reject Mac OS App which uses IOKit framework?)
So you can really try to use callback function from this topic IOHIDEventSystemClientScheduleWithRunLoop with EXC_BAD_ACCESS, hope that helps!
I used this code and it works even if your app is in background (just set special background mode), captures all system touch and keyboard events.
UILocalizedIndexedCollation seems to returning a different result on a Japanese iOS device than that seen in the built in Contacts / Music apps.
Note that this isn't the usual question about Japanese not displaying at all in the index. I'm getting the Japanese kana section, but the order of the index is incorrect when compared to Contacts etc.
Here's screens - on the left, the desired result shown in the music app with the kana names first - on the right, the result I'm getting:
UILocalizedIndexedCollation doesn't appear to have any obvious way to configure it, so I'm not sure what the expected way to adjust the ordering is, and a lot of Googling isn't revealing any answers (though I'm also not the only person having this problem). Any pointers in the right direction would be greatly appreciated.
Well, if you look at the Table in the Music App it shows the latin "A" character up the top anyway. I suppose Apple modified the Array of the Sidebar to show the current language on top of the other one, even though they still are down the bottom.
Regardless, it's probably easier to just leave it the way it is. You'd have to edit section selection code and all.
Is it possible to change the uikeyboard button size for my application.
I mean i want to make the ui keyboard button size bigger..
Is it possible? can i change that?
If so please guide me out
No. You cannot customize the button size on a UIKeyboard. (Although note that the keys become larger in landscape orientation.)
You could, in theory, write your own keyboard; however, you will almost certainly be unable to provide localizations for every language (including non-latin languages such as Japanese). As a result, your app will almost certainly be rejected from the App Store.
I have a view (a couple of them actually) with a standard search bar at the bottom. When the user touches the search bar, I need to move the search bar up so it's not hidden by the keyboard, then down again when the keyboard is dismissed.
I do this the same way as everybody else, by observing UIKeyboardWillShowNotification and UIKeyboardWillHideNotification. From these notifications, I get the height of the keyboard, and that tells me where to put the bottom edge of the search bar. It works perfectly, except for rare cases when the search bar doesn't animate, or doesn't animate far enough, and vanishes behind the keyboard. I have seen this a handful of times out of hundreds of tries with myself and my QA people testing on iPhones and iPods. Just once, I saw the search bar fly off the top of the screen as the keyboard came up. We've never seen any of this on the simulator, and we see it more often on the iPod than the iPhone. We are running iOS 4.x, mostly 4.3.3.
So I can think of two possibilities. One is that very occasionally UIKeyboardWillShowNotification is not sent and the other is that the data in the notification is wrong. The second one would explain the one case where the search bar flew off the top of the screen.
And then of course it is possible that my code is wrong in some very devious way; but the scenario is so simple -- enter the view and tap the search bar -- that I can't see how a bug in my code could cause these rare and intermittent failures.
If anyone can offer insight, I would be very grateful.
I finally discovered the answer to my question, and it's interesting. To cut to the chase, my search bar is animating into the wrong position; in some cases it's still behind the keyboard, and in others it's off the top of the screen. This is not caused by wrong data in the notification, but by a bug in accessing the height member of a CGSize or the y member of a CGPoint.
Specifically: in certain scenarios, when you write mySize.height, the generated code accesses mySize.width. If you are reading, you get the value of mySize.width; if you are writing, you clobber mySize.width. Similarly, myPoint.y actually accesses myPoint.x.
You may never see this problem. I only saw it on older iPod touch devices running iOS 4.2.1, and only in Release builds, and only when compiling with Apple LLVM Compiler 3.0, and then maybe only sometimes. But I reported it to Apple and they say it's a duplicate of a known bug (#10043857) that they are addressing. Connecting a few dots, I am guessing that it's somewhere in the compiler chain in Xcode 4.2.
The workaround is to take the address of the CGSize or CGPoint struct, then use pointer arithmetic to access the desired member. I wrote a set of little helper functions to do this, and I call them all over my app's code.
I have an app with a UITextField, amongst other things. When the user first taps on the text field, there is a noticeable delay before the virtual keyboard appears. On a 3GS it isn't too obvious, but on an older iPhone the delay can be around 1 second. After that the keyboard always pops up instantly. The delay is only the first time the keyboard pops up after app startup.
It looks like the initial UIKeyboard instantiation takes some time (quite a bit...) but is kept around after that.
I found very little information about this, which surprised me. However I did find this write up of the issue along with a hack-around solution.
http://blog.weareuproar.com/preloading-the-uikeyboard
My question is: is this hack around the only available solution? Is there a way to signal the framework (e.g. via info plist?) to instantiate the keyboard on startup?
No, there is no other (documented) way to do that. And even Apple's built-in apps (such as Maps) suffer from the same problem. You can either go with the hack you linked to or follow Apple's advice to not load stuff in advance before you really need it. By the way, this isn't much of an issue anymore with the iPhone 3Gs and the new iPod touch. The newer and faster devices load the keyboard almost instantly.