Use the PushRegistry. Simply register your MIDlet to launch for this specific tag type in the JAD-file (or do it programmatically in the MIDlet)
See:...
Type: Posts; User: alixwarnke; Keyword(s):
Use the PushRegistry. Simply register your MIDlet to launch for this specific tag type in the JAD-file (or do it programmatically in the MIDlet)
See:...
I'm not sure, but I believe you have to format the MIFARE card to use MF Value blocks instead of the standard ones to be able to do increment/decrement. Maybe you have to set that up in the general...
Unless it's MAD-enabled :)
Yes, it's possible. I've done it in a project using a signed MIDlet
Sounds like you need GPRS settings for your phone
Typecast to char isn't good?
Suggestions:
- Try extending data to 16 bytes
- do (assumes you use Key B again):
System.out.println("Allowed to write? " +...
It looks good... Just to eliminate a possibility, can you change
KeyB to KeyA? Maybe the access conditions in the emulated internal element doesn't allow using key B to read/write data blocks.
Terenas: Ah, I misinterpreted.
cisa: No, you don't need a certificate for the emulator. The emulator uses default keys (0xff...) for its secure element.
According to MIDP 2.0 specs a MIDlet must always be signed to access the secure element (which the internal MIFARE is part of). Something I've missed?
/A
Since your phone is locked, try the other transport keys, 0xa0a1a2... and 0xb0b1b2... (google for them). Not sure that it will do any help, one of the things that happen when you unlock your phone is...
getBlock(1) should be fine, it should point to the second block of the standard sector, which also uses the default keys. But to be sure, try:
conn.getSector(1).getBlock(0); instead
Also: Have...
It appears that your key was invalid then.
You are not trying to write the first block in the first sector?
Check the access bits if both writing and reading data can be done using key B
/A
Why don't you look in the javadoc? It is provided with the Nokia 6131 NFC SDK
The blank squares are 0s, I'm quite surprised you didn't get a nullpointexception from this code. Any way it seems that you may need to initiate MY_KEY with KEY_BYTES
/A
The emulator doesn't care if it's signed or not (well, to make sure you can adjust the protection domain settings)so yes, only for the phone.
As far as I know, the "mifare portion" is part of the secure element. The SE is split logically in a JavaCard-part and a MIFARE storage area.
Yes, you need to have a signed (with a code signing...
This is correct, but not for sector 0. For all other sectors you may use this byte however you want, but for the manufacturer sector it indicates the presence of MAD (and perhaps also for sector 16...
disp.setCurrent(screen) must be done after adding the Form, but maybe you've done so. In that case I don't know what's wrong
/A
Hi, get a: Display instance, Display yourDisplay = Display.getDisplay(this), and do:
yourDisplay.setCurrent(screen);
this will refresh your screen
/A
I have it integrated with IDEA IntelliJ, try just installing the SDK and see if it is available in your IDE as a choosable JDK for your project
/A
Yeah, choose Nokia SDK as your project JDK
/A
Are you using the Nokia 6131 NFC SDK for compiling?
Hard to say as it depends on the context (I don't have your source code), but make sure you do not try to use java.util.List since it is not available. Often this data structure can be substituted...
The general purpose byte in the sector trailer at sector 0 must indicate the presence of MAD for you to get anything to work with, I suggest you make a "connection.createApplicationDirectory()" if...