Re: Where/how to store lots of user application data
Re: Where/how to store lots of user application data
- Subject: Re: Where/how to store lots of user application data
- From: Will Mason <email@hidden>
- Date: Fri, 13 May 2005 11:29:08 -0700 (PDT)
- Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Since you're using Java, you can just use:
new File(System.getProperty("user.home") + "/Application
Support/All/Your/Folders").mkdirs();
Take care,
Will
--- Graham <email@hidden> wrote:
> Thanks for all the advice on the location, now I am embarrassed to
> admit I cannot determine how to create a directory.
> I am able to write my data easily using the NSFileWrapper class to an
>
> existing directory, but I cannot work out how to make a directory
> using the Cocoa API's?
> I am using Java by the way.
>
> Thanks
>
> Graham
>
> On May 13, 2005, at 1:51 PM, John Stiles wrote:
>
> >
> > On May 13, 2005, at 10:47 AM, Ricky Sharp wrote:
> >
> >>
> >> Definitely. Or, use a folder hierarchy (this is what I do for all
>
> >> my products). For example:
> >>
> >> + Application Support
> >> + My Company
> >> + My Product Family
> >> + My Product
> >> * all support files
> >>
> >> The reason I went the folder route was that it was easier for the
>
> >> user to find it. Furthermore, it made integration with .mac
> >> syncing a snap; I just had to specify the root "My Company"
> folder.
> >>
> >
> > Agreed. I know it's still the offically recommended way, but in my
>
> > years of OS X usage I have yet to warm up to com.company.product
> > style filenames. If nothing else, it makes it next to impossible to
>
> > use type selection in the Finder.
> > I wish they would revisit that decision for OS X 10.5. Folder
> > hierarchies would be fine with me. Then again, I honestly cannot
> > remember one instance where two OS 9 programs tried to take the
> > same preference file name. It just didn't happen in practice.
> >
> > _______________________________________________
> > Do not post admin requests to the list. They will be ignored.
> > Cocoa-dev mailing list (email@hidden)
> > Help/Unsubscribe/Update your Subscription:
> >
> >
> > This email sent to email@hidden
> >
> >
> >
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
>
> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden