Skip to main content

Disable H/W Keyboards while App is running ?

4 replies [Last post]
albert_kam
Offline
Joined: 2007-11-26

Hello,

I wonder if anyone has knowledge about requirements that i am facing right now :

I want to disable all .. yes, i mean all hardware keyboards from functioning while my custom application is running, and i'll enable all the keyboard functions again after i've exited my custom application. My custom application itself will be able to use the virtual keyboard with the stylus.

I'm currently using HP iPAQ 6965 messenger edition.

I really wonder about things that could render this possible :
1. a command tool from windows mobile ?
2. a utility from HP ?
3. a 3rd party program ?
4. windows mobile registry ?
5. from the app itself ?

Any helps would be greatly appreciated !

Cheers,
Albert Kam

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
terrencebarr
Offline
Joined: 2004-03-04

Thanks for the excellent answers, Shawn. I agree that by using a CDC-based VM you should be able to call native device-specific methods that enable most of what Albert needs, although of course this will require some system knowledge and be non-portable.

Albert, just to follow up: You mention AGUI. You might want to take a look at LWUIT (http://lwuit.dev.java.net/) which has the advantage of being a library you simply add to your app and that it will be open source in a few weeks. It should do all of what you need from AGUI and probably more and it is portable across a wide range of devices.

-- Terrence

sfitzjava
Offline
Joined: 2003-06-15

What VM are you using? If you have a JavaME MIDP vm I dont think you will be able to reach out to activate a native applications. And yes a native application is the only way you are going to disable all of the device keys other than your virtual onscreen keyboard.

However let me point out the dangers of this. If something goes horrible wrong in your code or with some other code, or even the system level code popping up a warning message you could lock the users device. I have found in the past if a user feels they have lost control of their device they will pull the battery, reboot, and remove what they think is the offending software.

Why do you feel it is needed for your application to be such a control freak? I noticed some of your last posts revolve around this idea of removing the users ability to use their application. Actually I've been concerned with answering your questions because it sounds like you are writing a virus, and Java is designed not to be supportive of that kind of behavior. I'm not saying you are, I'm only saying that the features you are trying to attain are much like those sought after by virus writers. It is also much the same needs as I had for when working with a company information security monitoring application for the BlackBerry device. Trust me it's better to write those in native than try and get JavaME to do your bidding. ;)

Maybe it would be easier to reexamine your design and see if there is another less restrictive implementation direction you could go in and get similar functionality without locking the user out of their own device.

Regards,
-Shawn

albert_kam
Offline
Joined: 2007-11-26

Hello, thank you for replying .. :-)

I dont intend any harm by saying this, but your reply about virus gave me and my boss (i showed him the post) a good laugh. Actually i'm quite confused with finding ways to fulfull our requirements, and the picture of me as a virus maker just gives me a good laugh. So thanks :-D

I understand your point. It must be a hellish user experience if i do all that stuff i mentioned. But the necessity is like this for now. Our client wants it to be like that.

I'm using Creme JVM for the CDC app that'll be used by salesman in field to do, store and print transaction. Some of the requirements are :
0. Rich user interface (AGUI)
1. Starts automatically, full screen when the ppc is activated
2. The app always stay on top
3. Must be able to sync via WiFi
4. Must be able to sync via GPRS with HTTPS with custom generated certificate
5. Got embedded database (derby runs fine)
6. The app cant be closed by the salesman, only by those admins with the correct passwords. So the menu File -> Exit will prompt for a password. Wrong password takes you back to the app screen.
7. H/W keyboards wont be usable, like the camera button, the windows button that could trigger the start menu activation, etc. Only virtual keyboard will be usable.

Point 1, 6 and 7 suggests an important point which means that our app cant be closed by the salesman who use the ppc. This is important to refrain the salesman from doing unwanted things like browsing internet, listening to mp3, watching movie, chatting, and all other stuffs that are irrelevant with the job on hand. And of course, those things could decrease battery power.

When i asked in javaranch, http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=4...
, i got an insightful advice about disciplining the salesmen rather than limiting their access. But then our partner from germany came and introduced us their mobile software using C++, and they too control their app exactly the same way. Full screen, keylocks .. :)

Perhaps this approach works only in several cases when the app will run exclusively on the ppc device.

Actually i asked the HP too about this matter, and today i just got a followup. I'll try them and post here if there's any advancements.

http://track.ipaqdevelopers.com/default.asp?38895_GAUJWCXS

Thanks for sharing :-),
Albert Kam

sfitzjava
Offline
Joined: 2003-06-15

Glad to have brightened your day with a laugh. :)

So using the CDC version of a JVM you should have access to JNI or at the least the execute() method to call outside native applications to disable everything. However there is no "standard way" to disable the features you need to address the requirements.

This is the problem with using OTS devices for custom development. This is where JavaME tends to break down a bit. However you could also use the Advanced PhoneME, which supports WinMo, and then code your own native commands as system methods, such as System.lockButtons(boolean);

If you have this option you might look at other devices that do not have a keyboard, and run linux and can have the OS custom built. The Nokia n800 would be such a device, where you could lock down at the OS level by removing the other applications, and only having you app on the device.

But now that I know this is to lock out salesmen from running any willy-nilly app they want I am totally on board with the lockdown. ;D

Best wishes,
-Shawn