javacard communication with a midlet?

hi all
Can one of you tell me if and how a javacard applet, residing in a SIM-card could start a J2ME-midlet
thanks for any reply
thomasbauAsked:
Who is Participating?
 
jimmackConnect With a Mentor Commented:
>> can the mobile phone still react to incoming call while waiting for bluetooth connection

I'm not sure.  This is probably handset dependent.  What happens if you do:

    display.setCurrent(null);

?

This should (hopefully) put the MIDlet into background mode.  The phone should then behave as normal for call handling etc.
0
 
jimmackCommented:
There's no way to achieve this that I know of.  Under what circumstances do you want to do this and what versions of JavaCard and MIDP are you working with?
0
 
thomasbauAuthor Commented:
I want to develop a application with two main elements.
1.      A daemon with LDAP functionality waiting for bluetooth connection situated on a PC.
2.      On a mobile device, a Javacard application sending a authentication key as soon as it has found the daemon
Since PC situated in the same room and running the daemon would all detect the mobile client, the mobile device should be able to let the user choose between the PCs. So I thought having a midlet handling this.

I choose javacard because (as fare as I know) midlet can not be run as daemon and have to be activated by the user.

I’m using midp2 and thought upon using  javacard 2.2
0
 
jimmackCommented:
I don't think there's anything you could do with JavaCard to cause the MIDlet to be started.

I haven't done anything with bluetooth, but I suppose it *might* be possible to have a class that implements the DiscoveryListener (if that's the right interface for the way you're designing the system) and then try to have the application run in the background (by setting the current display to null).

This would mean that you would need the user to start the application each time they switch on their phone so that the application could be put into background mode.  When a bluetooth connection is discovered, you can set the current display to something meaningful in order to bring the application to the foreground.

There are quite a few assumptions here:

1) Your MIDP-2.0 device acts on the requests to put MIDlets into foreground/background
2) I've understood the DiscoveryListener interface correctly
3) You're design mean the handset listens for bluetooth connections passively, rather than trying discovery attempts actively.
0
 
thomasbauAuthor Commented:
>>This would mean that you would need the user to start the application each time they switch on their phone so that the application could be put into background mode.  When a bluetooth >>connection is discovered, you can set the current display to something meaningful in order to bring the application to the foreground.

This was my first thought to. But can the mobile phone still react to incoming call while waiting for bluetooth connection (on my nokia wen I switch to gprs incoming call are redirected to my combox which is not the same but still give's a hint upon multitask ability).

>>3)You're design mean the handset listens for bluetooth connections passively, rather than trying discovery attempts actively.
yes the mobile device plays the server role waiting for PC asking for identification
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.