How to get J2ME RecordStore functionality in J2SE Applet?

Thread view:

Roar Lauritzsen - 17 Jun 2005 13:14 GMT

The javax.microedition.rms.RecordStore provides a way for a MIDlet to
store data persistently and later retrieve it while still operating
without any privileges inside its "sandbox".

I have created an Applet that emulates a MIDlet, but I am unable to
implement RecordStore functionality for an Applet. I simply want to save
a small amount of data when the applet dies, and then when you restart
the Applet, it has access to the data and can update it.

Any ideas on how to achieve this? It is not especially important that
the data survives for all eternity, only that it is available if you
return to the applet within a reasonable time. I would rather not have
to sign the applet, and I would like to avoid putting a file in a
specific location, such as "C:\TEMP\myapplet.dat" or "/home/user/.myapplet".

I am aware of java.io.File.createTempFile(), and I like the the
semantics, if only the created temporary file could be reopened later.
But I suspect that an applet is not even allowed to do createTempFile()
with default privileges.

Regards,
Roar Lauritzsen

Reply to this Message

Raymond DeCampo - 17 Jun 2005 14:51 GMT

> The javax.microedition.rms.RecordStore provides a way for a MIDlet to
> store data persistently and later retrieve it while still operating
[quoted text clipped - 4 lines]
> a small amount of data when the applet dies, and then when you restart
> the Applet, it has access to the data and can update it.

Try the java.util.prefs.Preferences API (available in 1.4 and beyond,
IIRC). I haven't ever examined if it is allowed within an applet, but I
would imagine it is.

HTH,
Ray

Signature

XML is the programmer's duct tape.

Reply to this Message

Andrew Thompson - 17 Jun 2005 15:07 GMT

> Try the java.util.prefs.Preferences API (available in 1.4 and beyond,
> IIRC). I haven't ever examined if it is allowed within an applet, but I
> would imagine it is.

Not an unsigned applet..

<sscce>
import java.util.prefs.Preferences;

public class PreferencesApplet extends java.applet.Applet {
public void init() {
Preferences pref = Preferences.systemRoot();
}
}
</sscce>

AppletViewer ->
java.security.AccessControlException:
access denied (java.lang.RuntimePermission preferences)
at ....

Roar Lauritzsen wrote:

> ..I simply want to save
> a small amount of data when the applet dies, and then when you restart
> the Applet, it has access to the data and can update it.

Unfortunately, there are reports that you cannot rely on
the applet stop()/destroy() methods being invoked by the
browser.

Signature

Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.LensEscapes.com/ Images that escape the mundane

Reply to this Message

Raymond DeCampo - 17 Jun 2005 16:33 GMT

>>Try the java.util.prefs.Preferences API (available in 1.4 and beyond,
>>IIRC). I haven't ever examined if it is allowed within an applet, but I
[quoted text clipped - 16 lines]
> access denied (java.lang.RuntimePermission preferences)
> at ....

I would point out that you attempted to access system level preferences
instead of user level preferences. However, the user level access
methods have the same security issue. Pity, it made so much sense.

Ray

Signature

XML is the programmer's duct tape.

Reply to this Message

Andrew Thompson - 17 Jun 2005 16:43 GMT

>>>Try the java.util.prefs.Preferences API

>> Not an unsigned applet..

>> Preferences pref = Preferences.systemRoot();

>> java.security.AccessControlException:

> I would point out that you attempted to access system level preferences
> instead of user level preferences.

Ehhh.. (shrugs) ..it was the first 'prefs' method I struck
that was static and got me a Preferences object (barring security).
Short and sweet.

>..However, the user level access
> methods have the same security issue. Pity, it made so much sense.

All is not lost, this applet could be signed.

Also, if my vague recollections serve me well, there
is also a webstart API that can store and recall prefs..

Signature

Reply to this Message

Darryl Pierce - 26 Jun 2005 15:25 GMT

> Try the java.util.prefs.Preferences API (available in 1.4 and beyond,
> IIRC). I haven't ever examined if it is allowed within an applet, but I
> would imagine it is.

Not without permission from the user.

Signature

Darryl L. Pierce <mcpierce@gmail.com>
Visit my homepage: http://mcpierce.multiply.com
"By doubting we come to inquiry, through inquiry truth." - Peter Abelard

Reply to this Message

JScoobyCed - 20 Jun 2005 02:20 GMT

> I have created an Applet that emulates a MIDlet, but I am unable to
> implement RecordStore functionality for an Applet. I simply want to save
> a small amount of data when the applet dies, and then when you restart
> the Applet, it has access to the data and can update it.

What about storing a Cookie?

--
JSC

Reply to this Message

Andrew Thompson - 20 Jun 2005 11:07 GMT

>> I have created an Applet that emulates a MIDlet, but I am unable to
>> implement RecordStore functionality for an Applet. I simply want to save
>> a small amount of data when the applet dies, and then when you restart
>> the Applet, it has access to the data and can update it.
>
> What about storing a Cookie?

There are a couple of distinct parts to this problem.
1) Detecting when the applet dies.
2) Doing something about it (save the options).

If the developer can make a signed applet and expect a 1.4+
installation, Preferences would probably be the way to go.

Of course, there are still browsers out there without 1.4,
so in a JS enabled browser, the 'cookie alternative' may
well be the way to go. Though note that
a) some browsers that support Java might not support JS,
or might have JS disabled. I imagine the number of users
that allow Java but not JS to be *vanishingly* small, though
I have never been able to confirm it with any hard data.
I do not know of a browser that will recognize/act on an
<applet> element while not recognising the <script> element.
b) The cookie handling needs to be done in robust JS
(which excludes 90%+ of the badly hacked out script
available on the internet)

What was my point.. I'm sure, I had one.. Oh yeah!

But coming back to point 1) 'Detecting when the applet dies.'
*That* is the really tricky and unreliable aspect to this.
Unfortunately some browsers just do not invoke the relevant
applet methods that would allow either method to work
reliably.

<musing>
We have an advantage here.

The user *wants* their prefs to be stored, so we can
actively enlist their help. The developer might take
a different strategy to ensure 'prefs save' is invoked.
Here's one idea..

Pop-up a dialog at start-up.
"Be sure to click 'Save Prefs' before leaving to save your work!"

Also invoke the savePrefs() on applet.destroy() or whatever,
but this way it is possible to leave the ultimate responsibility
with the end user..

Just a thought.
</musing>

Signature

Reply to this Message

Andrew Thompson - 20 Jun 2005 11:15 GMT

> ..in a JS enabled browser, the 'cookie alternative' may
> well be the way to go. Though note that
> a) some browsers ... might not support JS,

...

> b) The cookie handling needs to be done in robust JS ..

c) Many cookies die short, cruel deaths in this day and age.
- User settings have long allowed the end user to refuse cookies,
which is (seems to be) a much more common thing than disabling
Java/JS.
- Most pop-up blockers either interfere with, or prevent them.
(Google toolbar, IE SP 2..).
- (At least some) SpyWare software can target and destroy them as well.

Signature

Reply to this Message

Roar Lauritzsen - 27 Jun 2005 15:31 GMT

>>..in a JS enabled browser, the 'cookie alternative' may
>>well be the way to go.

This works just swell! It is exactly what I need.

>>Though note that
>>a) some browsers ... might not support JS,

I don't care about such browsers, it's just a demo of an actual MIDLet
after all. It doesn't have to be bullet-proof

>>b) The cookie handling needs to be done in robust JS ..

Why? What is wrong with this code?:

public int addRecord(byte[] data, int offset, int numBytes) {
try {
JSObject.getWindow(ral.CalcApplet.getCurrentApplet()).
eval("document.cookie='MIDPCalcState="+
encodeByteArray(data,offset,numBytes)+
"; expires=01-Jan-2020 GMT';");
} catch (Throwable e) {
}
return 0;
}

> c) Many cookies die short, cruel deaths in this day and age.

If people don't want to set the cookie or exit the demo Applet in the
recommended fashion, they don't get to save the state of the demo. It's
up to them.

Anyway, thanks for the tips everybody,

-Roar Lauritzsen

Reply to this Message

Andrew Thompson - 27 Jun 2005 15:55 GMT

>>>Though note that
>>>a) some browsers ... might not support JS,
[quoted text clipped - 16 lines]
> return 0;
> }

Their are some quirks in the ways that browsers interact
with LiveConnect. I was dealiing with one recently that
resulted in a Sun bug report - ..but was solved with a bit
of robust JS.

OTOH - if it works well enough for ..your users (make sure
you test it on a variety of JS enabled browsers) then I don't
see it matters that much, I would stick with what you have.

Glad you got it sorted!

Signature

Reply to this Message

Darryl Pierce - 26 Jun 2005 15:25 GMT

> I am aware of java.io.File.createTempFile(), and I like the the
> semantics, if only the created temporary file could be reopened later.
> But I suspect that an applet is not even allowed to do createTempFile()
> with default privileges.

Unless your applet is signed and has permission from the user, it cannot
create any file on the user's system. Do you have a digital signature
you can use to sign your applet?

Signature

Darryl L. Pierce <mcpierce@gmail.com>
Visit my homepage: http://mcpierce.multiply.com
"By doubting we come to inquiry, through inquiry truth." - Peter Abelard

Reply to this Message

How to get J2ME RecordStore functionality in J2SE Applet?

Free Magazines