MrjAppBuilder

> Protects the user from messing stuff up.

Make something idiot-proof, and sure enough, along will come a better idiot.

> Apps and exe are alterable, jars are not(unless you

> go the the hassle of unzipping and rezipping).

JARs are not alterable?

~

yawmarka at 2007-7-13 0:24:05 >

> Unfortunately, no. The Data inside a jar cannot be

> changed unless the jar is "opened up".

Let me clarify; data inside a JAR *is* alterable. What do you mean by "opened up"? What difficulty are you having?

> The program I'm making has the user constantly changing data.

...which is not a problem that requires one to use a native application in lieu of a JAR file.

> User=the cause of problems for programmers

While perhaps fashionable for the "edgy counterculture" set, that's a bad attitude. The user is the reason for a programmer's existence.

~

yawmarka at 2007-7-13 0:24:05 >

> Because I could alter data inside the Apps more

> freely, because they are actually directories(atlest

> on a mac).

Must be my lack of familiarity with Mac. If a Mac application is "actually a directory", I don't see how that prevents a user from "messing things up".

~

yawmarka at 2007-7-13 0:24:05 >

> Because I could alter data inside the Apps more

> freely, because they are actually directories(atlest

> on a mac).

You seem very confused.

If you want to have files then have files. You can do this with jars or not from jars.

The app builder thing is stupid. Just use an self-executing jar. That (launching) is the problem that the app builder solves. Whatever problem you have is another problem altogether and is NOT solved by the app builder thingy.

cotton.ma at 2007-7-21 23:11:34 >

> Why do I get the feeling you have this sly smirk on

> face because you know you know something that I

> don't?

Paranoia, perhaps.

> Toying with the upcoming developers.

Nope. I'm not familiar with the Mac platform, but I don't see how packaging a JAR as a native application because the user is "constantly changing data" and you don't want the user to "mess things up" is going to help. I'm trying to determine what your actual plan for addressing this is.

~

yawmarka at 2007-7-21 23:11:34 >

> A user can't get into the directory unless there good with the unix command

> line, and at that point I say, if you want to mess up

> your data, go right ahead.

Once again, that's not something that makes a native app different from an executable JAR.

> But I'm talking about for the average user who

> doesn't know 1/10th of this stuff.

So just use an executable JAR and store the data in regular files in some protected/hidden/temp/whatever directory. You're doing backflips to prevent a potential problem that you yourself say isn't likely to happen.

~

yawmarka at 2007-7-21 23:11:34 >

> > Why do I get the feeling you have this sly smirk

> on

> > face because you know you know something that I

> > don't?

>

> Paranoia, perhaps.

>

> > Toying with the upcoming developers.

>

> Nope. I'm not familiar with the Mac platform, but I

> don't see how packaging a JAR as a native application

> because the user is "constantly changing data" and

> you don't want the user to "mess things up" is going

> to help. I'm trying to determine what your actual

> plan for addressing this is.

>

> ~

Well I could create files outside the jar for the users to access but then that would mean the jar is bound to the location of where ever the other files. And if they want to move the jar to another location, they have to move all the correspondig files too.

My actual plan was a native app that runs with java because everything would be inside the App, and it would be more custom to the native look and feel of the platform.

blackmagea at 2007-7-21 23:11:34 >

> > > Why do I get the feeling you have this sly

> smirk

> > on

> > > face because you know you know something that I

> > > don't?

> >

> > Paranoia, perhaps.

> >

> > > Toying with the upcoming developers.

> >

> > Nope. I'm not familiar with the Mac platform, but

> I

> > don't see how packaging a JAR as a native

> application

> > because the user is "constantly changing data" and

> > you don't want the user to "mess things up" is

> going

> > to help. I'm trying to determine what your actual

> > plan for addressing this is.

> >

> > ~

>

> Well I could create files outside the jar for the

> users to access but then that would mean the jar is

> bound to the location of where ever the other files.

No.

You can use whatever path you like and that you permission to.

cotton.ma at 2007-7-21 23:11:34 >

> > > > A user can't get into the directory unless

> > there

> > > good with the unix command

> > > > line, and at that point I say, if you want to

> > mess

> > > up

> > > > your data, go right ahead.

> > >

> > > Once again, that's not something that makes a

> > native

> > > app different from an executable JAR.

> > >

> >

> > I think it mildly does. Maybe. This sounds from

> his

> > description like some sort of resource fork

> > shenanigans.

> >

> > But I still think this is not the way to go.

>

> Then how would you go about making an app(jar) that

> is downloaded, doubl-click to start it, and the user

> can alter data which is inside the jar?

I wouldn't store the data in the jar. I would store the data in a directory I made.

I would probably use the Preferences API to store the path after the first time so that in future I could look for the preferences for my app and if they didn't exist I would know that my program has not been run.

cotton.ma at 2007-7-21 23:11:34 >

> > Protects the user from messing stuff up.

>

> Make something idiot-proof, and sure enough, along

> will come a better idiot.

The alternative saying is :

"Build an idiot proof system and only an idiot will be willing to use it " (Or something along those lines).

Aknibbsa at 2007-7-21 23:11:34 >

> > > Protects the user from messing stuff up.

> >

> > Make something idiot-proof, and sure enough, along

> > will come a better idiot.

>

> The alternative saying is :

> "Build an idiot proof system and only an idiot will

> be willing to use it " (Or something along those

> lines).

You forgot the whole quote.

"Build an idiot proof system and only an idiot will be willing to use it, then call it Vista and sell, sell, sell"

cotton.ma at 2007-7-21 23:11:40 >

1) Idiots are idiots and if they can find a way to screw up the works they will there is no force sufficient to prevent that.

2) There is no way to so utterly secure an application running where a user can get to the file system that they cannot find a way to foul up. Deal with it.

3) Effort spent in trying to hide or secure data that lives on the user's file system is effort wasted. If they choose to do something to muck up the works their works are mucked up and they have nobody to blame but themselves.

4) Making a Java Swing application look native is an exceedingly simple matter that requires a single operational line of code. This does however assume that the appropriate classes are available for the JVM when it needs them. If not the app will not fail it will generate an error in the console and the app will come up in the "metal" look and feel which is the Java default.

I would not waste effort trying to protect the user in this fashion. I would put the data (in whatever form I cared to persist it) on the file system and if I was feeling particularly kind I would give the application the ability to recreate the baseline data. Thusly if the user does something screwball and munges up their own data we can put the application back into a useable state and puppy smack the user for putting their paws where they do not belong.

Just my 2 krupplenicks worth. your milage may of course vary.

PS.

puckstopper31a at 2007-7-21 23:11:40 >