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 -~----------~----~----~----~------~----~------~--~---
