Whoops!  Sorry, yeah it was incorrectly aimed at you, I thought you
were disagreeing with me. :)

On Oct 7, 2:07 pm, "Tom Gibara" <[EMAIL PROTECTED]> wrote:
> Was that reply aimed at me? I was in agreement!
> I've seen several server apps collapse through abuse of createTempFile().
> The semantics are weak: almost to the point of being dangerous :)
>
> Tom.
>
> 2008/10/7 hackbod <[EMAIL PROTECTED]>
>
>
>
> > You can just as well do those things yourself without
> > createTempFile().  I am strongly against createTempFile() because it
> > has no idea what you are doing with your file, how long to keep it
> > around, who you might share it with, etc.  Note that the API doesn't
> > even meet the requirements you are giving, where you store the file
> > either on the SD card or internal storage based on what you are doing
> > with it.
>
> > On Oct 7, 2:14 am, "Tom Gibara" <[EMAIL PROTECTED]> wrote:
> > > I have to disagree with your disagreeing :)
> > > There are two fairly common and well defined situations:
>
> > > Situation: You need a temp file to do some processing that won't
> > necessarily
> > > fit into memory.
>
> > > Solution: Create the file, use it, delete it when you're done*
>
> > > Caveat: The file may be exceptionally large: demand an SDCard. The file
> > > contains sensitive information: use app storage.
>
> > > Situation: You are operating a cache.
>
> > > Solution: maintain the files in the supplied cache directory
> > > (Context.getCacheDir()), the system knows these can be deleted**
>
> > > Caveat: Big ticket items (like songs and videos) go to the sdcard (the
> > user
> > > can treat these types as useful files anyway)
>
> > > How does the availability of createTempFile() effect any solution in
> > these
> > > two cases?
>
> > > * Concerned about termination? Persist the name of your temporary file
> > > before starting work, clear it when you're done, check for it on start-up
> > > and delete it if present.
>
> > > ** I'm only assuming this is what the system will do.
>
> > > Tom
>
> > > 2008/10/7 Jason Proctor <[EMAIL PROTECTED]>
>
> > > > oh yes it should :-)
>
> > > > ok so maybe the unconventional Android application lifecycle changes
> > > > the game a bit wrt temporary files, in the sense that "system
> > > > startup" (etc), with accompanying cleanup, doesn't happen that often.
>
> > > > but still, trusting those applications to keep track of their
> > > > temporary files is a bit naive, especially since application, er,
> > > > termination may happen unexpectedly. but then if Android has some way
> > > > of associating files with applications, via that unique
> > > > application/user ID thing (if i'm reading it right), then anything
> > > > created by File.createTempFile() could be deleted when the associated
> > > > process "exits".
>
> > > > and none of this changes the fact that File.createTempFile() should
> > > > create a writable temporary file whether or not an sdcard is inserted
> > > > or not. createTempFile() has some handy benefits including ensuring
> > > > uniqueness, be a shame to lose that. that's the deal with
> > > > createTempFile(), and bugging out breaks the contract.
>
> > > > if in doubt, have a convention. that way there will be at least a
> > > > little organisation in the chaos that will be Android.
>
> > > > tx
>
> > > > >No it shouldn't. :)
>
> > > > >Temp directories suck.  When do you remove those files?  If it's on
> > > > >the SD card, who owns them?  Especially with a limited out of storage
> > > > >space, it's just a big nasty mess that is best to avoid.
>
> > > > >So you can make your own temp files, and if you want them in internal
> > > > >flash then you have to put them in your own directory, where the
> > > > >system can appropriately bill them against your use of storage.  And
> > > > >you can decide when to delete them, when you are done with them.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to