muffin stuff#2 (webstart cookies)

Shared Code
#1

http://kaioa.com/src/tools/MuffinTest.jnlp
http://kaioa.com/src/tools/MuffinTest_src.zip


public class Muffin

Constructors:
public Muffin(String muffinName) throws MuffinException
public Muffin(URL muffinURL) throws MuffinException

Methods:
private static void init() throws MuffinException
public String toString()
public static String[] getNames() throws MuffinException
public static String[] getNames(URL url) throws MuffinException
public boolean exists() throws MuffinException //doesnt work :P
public int getTag() throws MuffinException
public void setTag(int tag) throws MuffinException
public void delete() throws MuffinException
public InputStream getInputStream() throws MuffinException
public OutputStream getOutputStream()

It’s more (re)usable and the demo application is also more interesting now. You can load, save and delete muffins.

Tell me what you think’n’stuff.

Btw the source is comment free - it’s ment to be some kind of draft.

#2

Just to prove I read what you wrote :wink:

What happens if I call delete() then call getOutputStream()?

I take it the tags are the ones that I defined within the JNLP lib?

I’m really starting to like that style of using static methods on a class to get the collection, its really intuitive, at least for me :slight_smile:

Looking smooth,

Kev

#3

What happens if I call delete() then call getOutputStream()?

Nothing special.

The (inner class) MuffinOutputStream deletes the muffin anyways (tries to - actually [since there won’t be a muffin in first place]), then creates the muffin and then writes (in the close() method, because we don’t know the final size before).

I could have choosen another way… like checking the size and if it’s big enough open it with overwrite enabled and delete/recreate otherwise, but y’know there won’t be any benefit doing so. Like there’s a muffin with 100 bytes… and the new one is only 90… the remaining bytes would contain junk then (which could be annoying).

[Eventually that stuff is handled automatically, but I really can’t be arsed to try that just for ending up with a more complex method which does the same]

So… just nuke it all and rebuild. Simple, pain free and relyable :wink:

I take it the tags are the ones that I defined within the JNLP lib?

Yes, PersistenceService.TEMPORARY, PersistenceService.CACHED and PersistenceService.DIRTY. The javadoc comments will of course explain that :slight_smile:

The unofficial jnlp faq said that those tags are only used by webstart to determine, in which order the muffins should be deleted if it runs out of space. First temp, then cache and then dirty. So if you want to keep em as long as possible (eg forever) then “dirty” would be the one you should pick.

I’m really starting to like that style of using static
methods on a class to get the collection, its really
intuitive, at least for me :slight_smile:

Yea, I thought it would be silly if you would have to create a dummy muffin just for getting the already stored muffins.

It would be like ordering random food in a restaurant for getting the bill of fare :wink:

What could be added is a getFileContents and a getRandomAcessFile method. Well, I won’t have time to do any changes on that thing within the next 48 hours… I think I should have a pretty good idea then what’s missing. Suggestions are of course still welcome.

#4

Eventually that stuff is handled automatically

Most likely it is - there are two bytes (motorola byte order) at the beginning with the file length.

Eg a muffin with “lol” looks like this:


0003 6C6F 6C
   3  l o  l

Well, I’ll still keep that nuke and recreate approach since it’s way simpler and I don’t see any reason for doing that the other (more complicated) way.

#5

Known issues (demo app):
-MuffinTest.java:14 String muffinName is never used.
-load/savedelete throw a (non letal) NPE if the muffin directory doesn’t exist (eg they work just fine if the directory is there but there aren’t any muffins)

Just in case anyone stumbled upon that and wondered what went wrong there :wink:

edit: save of course doesn’t throw an NPE ::slight_smile:

edit²

plan to add:
public String getText() readUTF()
public void setText(String text) writeUTF(String text)

I also had a somewhat closer look at overwriting and it isn’t that complicated, but I still don’t see a reason for doing so.

#6

I wonder if it would be ok if I borrowed this code and extended it to happily work in webstart or out?

Kev

#7

We’re going to stick it on JGF eventually anyway, so go ahead :).

#8

[quote]I wonder if it would be ok if I borrowed this code and extended it to happily work in webstart or out?
[/quote]
My intention was to do something like that anyways… so what about teaming up? :slight_smile:

Eg I could “finalize” the Muffin class, by adding these two methods and javadoc comments (and doing something about that demo app) and you could write the abstraction layer thingy and/or the file part and/or some design stuff.

public static String[] getNames() throws MuffinException
public static String[] getNames(URL url) throws MuffinException
//public boolean exists() throws MuffinException//eventually?
public int getTag() throws MuffinException
public void setTag(int tag) throws MuffinException
public void delete() throws MuffinException
public InputStream getInputStream() throws MuffinException
public OutputStream getOutputStream()
public String readUTF()
public void writeUTF(String text)

Since there are two statics an interface won’t do the trick.

#9

I reakon if we’re to make it abstract then the two statics move to what ever manager/factory (MuffinOven? :)) is used to create the muffins without knowing the implementation.

i.e.


String[] names = MuffingManager.getNames();

Muffin muffin = MuffinManager.getMuffin("mygame\mymuffin");

However, if we’re to support a file system based version they’re would have to be a way to hint at a location to store the muffins:


MuffinManager.setLocationHint("savedata");

which would be ignored by webstart version since thats the whole point :slight_smile:

Ideas, ideas, ideas… what do you think?

Kev

#10

It’s updated now.

The example now uses the new writeUTF() and readUTF() methods and that unneeded String is also gone. However, I wasn’t able to do anything against those (non letal) NullPointerExceptions, because they are triggered under the hood of javaws :-/

Ah well… that’s just a cosmetical thingy.

Btw javadoc comments are still missing.

And “hinting” the location… hmm… what are we gonna do if that one was omitted? Using a default directory? That only screams for trouble… or generating one by the change date in order to create a (basically) unique hex string, but that would mean that you loose your muffins once the jar was updated.

So… either enforce having such a directory name in each case and/or having one way for omitting it which won’t work without webstart.

“MuffinOven” would be funny, yea… but we should try to avoid any confusion :wink:

Hm… getting that exists() working could be done by getting the names and checking for the specified one or by trying to open it’s inputstream (but bouncing of exceptions feels pretty hacky).

#11

+1 for MuffinOven - these days, terms like “creator”, “source”, “manager”, etc (and to a lesser extent the less variably used ones like “factory”) are so over-used as to become meaningless. Heck, if Sun’s going to make us call the damn things Muffins (groan) then it’s a bit late to be trying to fight back by using standard names.

/me dons flame-retardant suit and hopes his words don’t come back to haunt him sometime in the future when he’s trying to use the API

#12

Heh. Speaking of which… are the method names ok-ish?

I’m somewhat not that sure with readUTF and writeUTF, because they read/write always the whole thing. That’s to be expected for readUTF, but it might be somewhat odd for the writeUTF(right?).

#13

While MuffinOven is pretty funny sticking to the conventional at least means that most people will understand what it is :slight_smile:

readUTF and writeUTF just match up with DataInputStream/DataOutputStream so its kinda understood at least. Although I was surprised to see these methods added at all since you can get hold of the InputStream and OutputStream quite happily which of course you can wrap. I suppose as convienience goes its nice but its pretty unlikely I’d even be just writing a String into these files, at worst it’d be a properties file or XML. Although I suppose in turn you could create String froms them and dump those in.

The rest of naming is pretty darn good actually, couldn’t ask for much more, apart from maybe Javadoc :slight_smile:

Kev

#14

:slight_smile:

Yea, it’s just… for very simple stuff. Sometimes you just need that, but… to tell the truth it’s actually there for people who want to try it. Ooooh it really saves and loads that stuff… wow! ;D

[quote]The rest of naming is pretty darn good actually, couldn’t ask for much more, apart from maybe Javadoc :slight_smile:
[/quote]
Kept it close to the common names for methods like these… and the javadoc… gonna do it. Should be there pretty soon now (tomorrow ;)).

#15

I’m trying to do a version of this code at the moment and I’m still having a bit of trouble working out whats a valid use case for the standalone version.

  1. Use it to test your code with
  2. Use it to deploy a standalone version of your game

In the case of 1 I don’t care where the muffins are put as long as its predictable. In the case of 2 I want the files to be in the same place everytime and somewhere that fits my install.

I’m still not quite sure how this can be achieved without something like a hint that is ignored in webstart mode?

Kev

#16

I think we can asume case #2 all the time, because it should be fine for #1, too.

And the “hint”… yes in webstart mode we should just ignore it. However, I would like having that thing a requirement (eg constructor-ish) even if it means that you have to enter some random crap or that the muffin alike thingys from non webstart mode just aren’t available if omitted (eg throwing a runtime exception stating that you need to specify that directory).

Btw did you got an idea for detecting if it’s started through webstart or not? I mean sure… there are some ways, but I still hadn’t found something clean.

Btw² I’m writing the javadoc stuff right now :slight_smile:

#17

This is what I’ve done so far, its not pretty:


webstart = true;
            
try {
     Class.forName("javax.jnlp.ServiceManager");
                  
     // this causes to go and see if the service is available
     ServiceManager.lookup("javax.jnlp.PersistenceService");
} catch (Exception e) {
     System.err.println("MuffinProvider: No webstart detected");
     webstart = false;
}

Kev

#18

Well, that will do it for now (forever?) :wink:

#19

Onyx, is there somewhere I can mail you my version of the code so far so you can take a look. I don’t want to just post it publically here and just override the existing stuff until we’re both happy with it.

Kev

#20

Ah… uhm… sure :slight_smile:

kunnichiwa gmx de