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