If Jason's suggestion of pushing it to a server is inadequate, you can buffer events, and only write them out once a minute or 10 minutes or something. This will put an upper bound on the number of writes performed.
You can combine the approaches, and push to the server, and only write to the filesystem if you don't succeed in pushing to the server within a decent interval. Then when communications is reestablished, push the saved data up first. You could also send it to the SD -- and when the SD is not available, buffer it on the local filesystem until it becomes available again. Essentially, we're looking at a 3-level buffering hierarchy -- RAM, local flash, and either SD or server. The more the buffering in RAM, the more data you risk losing in the event of a crash, but the fewer writes and less battery required. On Apr 4, 12:53 pm, Nadav <nad...@gmail.com> wrote: > Thanks Bob and Dianne, > > The issue is that I have no choice but do a lot of writing since this > is a research app that constantly logs phone and user activity over > many months... We are dealing ok with battery and processing power > (we only write every several minutes), and the main concern remains > the Flash lifetime. > > We are working with cyclic log files (that roll over every several > hours), and have already found a way to move our older files to the SD > card. However our current dilemma is whether to do all writing on the > SD-card, or keep the "current" open file on the main memory, and copy > it to SD when moving to the next log file. > > The problem of doing everything on the SD card is that when a user > mounts the card to a PC, we can't access it for logging and other > tasks, and that leads to various crashes and issues, so I thought it > might be simpler if we work with the "current" file on the main > memory, but I fear the Flash degradation... I'm willing to buy new SD > cards every few months, but I really don't want to mess up the phone > itself! > > On Apr 4, 2:27 am, Dianne Hackborn <hack...@android.com> wrote: > > > > > If you are talking about internal storage (not RAM memory), then yes this is > > generally flash memory, and you want to be careful about how much you write > > to it for numerous reasons: also extremely important are the battery impact > > (writing to flash is expensive) and performance (causing other things that > > are accessing flash storage to be blocked by what you are doing). > > > That said, properly designed flash storage won't let you write to the same > > block over and over. Writes are spread across the flash storage just to > > avoid that kind of issue. > > > On Sat, Apr 3, 2010 at 9:49 AM, Nadav <nad...@gmail.com> wrote: > > > Hi All, > > > > I'm wondering how worried should I be about writing an app that does a > > > lot of writing (logs + db files) to the phone's main memory. > > > > In the past I was involved in a project that had to do a lot of > > > writing to SD card, and the SD cards started malfunctioning after 2-3 > > > months due to this, and had to be replaced every now and then. The > > > developer realized he was reaching the flash memory's read/write > > > guarantees (don't remember the exact specs). > > > > If the phone's main memory is also flash based, should this be a > > > concern? I wouldn't want to damage the phone's memory in a permanent > > > way.... > > > > I'm also not sure if the issue is related to reading writing to the > > > same physical block (the guy was using a single log file and kept > > > appending it, so he was constantly accessing the file's header block), > > > and whether writing cyclic log files might remedy a problem like > > > this.. > > > > Would appreciate any thoughts on this issue. > > > > Thanks! > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Android Developers" group. > > > To post to this group, send email to android-developers@googlegroups.com > > > To unsubscribe from this group, send email to > > > android-developers+unsubscr...@googlegroups.com<android-developers%2Bunsubs > > > cr...@googlegroups.com> > > > For more options, visit this group at > > >http://groups.google.com/group/android-developers?hl=en > > > > To unsubscribe, reply using "remove me" as the subject. > > > -- > > Dianne Hackborn > > Android framework engineer > > hack...@android.com > > > Note: please don't send private questions to me, as I don't have time to > > provide private support, and so won't reply to such e-mails. All such > > questions should be posted on public forums, where I and others can see and > > answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
