Re: [android-developers] Re: Content Provider for Private Database?
Based on this discussion, I've decided to use a content provider for access to an internal private database for my app. It simply makes the data access simpler for me, and there's a really nice go-by in the NotePad sample. However, I'm worried about your comment about the leaked database connection. I'm still new to this arena. What are the consequences of leaking the database connection? -- 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
Re: [android-developers] Re: Content Provider for Private Database?
There is no leaked database connection with Content Providers. What happens is, the database is kept open as long as the application process is alive, and is open just once, too. When/if the process is killed, the OS kernel closes the file. As far as that extra file being kept open - many (most?) OSs keep executable files open while their code is executing. One more shouldn't ruin anything. On the other hand, not having to reopen the database makes for better performance. -- Kostya 29.03.2011 17:55, Scott McCormack пишет: Based on this discussion, I've decided to use a content provider for access to an internal private database for my app. It simply makes the data access simpler for me, and there's a really nice go-by in the NotePad sample. However, I'm worried about your comment about the leaked database connection. I'm still new to this arena. What are the consequences of leaking the database connection? -- Kostya Vasilyev -- http://kmansoft.wordpress.com -- 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
Re: [android-developers] Re: Content Provider for Private Database?
On Tue, Mar 29, 2011 at 10:19 AM, Kostya Vasilyev kmans...@gmail.com wrote: There is no leaked database connection with Content Providers. Yes, there is, at least by my definition (close() not being called). What happens is, the database is kept open as long as the application process is alive, and is open just once, too. When/if the process is killed, the OS kernel closes the file. That presumes that there is no SQLite logic in a database close() that is important. One hopes that is the case, given the way content providers are implemented. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training...At Your Office: http://commonsware.com/training -- 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
Re: [android-developers] Re: Content Provider for Private Database?
Mark, 29.03.2011 18:27, Mark Murphy пишет: On Tue, Mar 29, 2011 at 10:19 AM, Kostya Vasilyevkmans...@gmail.com wrote: There is no leaked database connection with Content Providers. Yes, there is, at least by my definition (close() not being called). By this definition, every program running in a non-GC environment has a memory leak, which would be a very interesting point of view. To me, a leak is where the use of some resource grows over time and has no chance of decreasing. The resource in question may be memory, open files, DMA buffers, etc. In this particular case, there is only one file which is kept open, and that number does not grow over time. Opening a new database connection for every db operation would be a leak, but that is not happening here. Besides, not closing a database is not specific to content providers. An application that shares a database object among different components might keep it open as well. What happens is, the database is kept open as long as the application process is alive, and is open just once, too. When/if the process is killed, the OS kernel closes the file. That presumes that there is no SQLite logic in a database close() that is important. One hopes that is the case, given the way content providers are implemented. It seems safe to not close a SQLite database, based on empirical evidence supported by some ten million Android devices worldwide, all having some databases and content providers, including those built into the platform. Besides empirical evidence, see this comment made by the author of SQLite, D. Richard Hipp: http://www.mail-archive.com/sqlite-users@sqlite.org/msg01280.html Program crashes, OS crashes, and power failures should not corrupt an SQLite database. -- Kostya Vasilyev -- http://kmansoft.wordpress.com -- 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
Re: [android-developers] Re: Content Provider for Private Database?
On Tue, Mar 29, 2011 at 1:43 PM, Kostya Vasilyev kmans...@gmail.com wrote: There is no leaked database connection with Content Providers. Yes, there is, at least by my definition (close() not being called). By this definition, every program running in a non-GC environment has a memory leak, which would be a very interesting point of view. I never said a memory leak. I said a leaked database connection. To me, a leak is where the use of some resource grows over time and has no chance of decreasing. The resource in question may be memory, open files, DMA buffers, etc. To me, a leak is something that is allocated and not released. The release could be manually (e.g., calling close()) or automatically (e.g., finalizers in a GC environment). http://en.wikipedia.org/wiki/Resource_leak Besides, not closing a database is not specific to content providers. An application that shares a database object among different components might keep it open as well. Which, if never closed, would represent a leak of a database connection. That presumes that there is no SQLite logic in a database close() that is important. One hopes that is the case, given the way content providers are implemented. It seems safe to not close a SQLite database, based on empirical evidence supported by some ten million Android devices worldwide, all having some databases and content providers, including those built into the platform. Those same ten million Android devices worldwide are also using AsyncTask, which Romain Guy indicated has flaws severe enough to cause them to drop it back to a single-thread pool in an upcoming Android release, which may have fairly substantial backwards-compatibility issues. IOW, while I agree that empirical evidence beats no evidence, it is not a guarantee that everything is all coming up roses, either. Besides empirical evidence, see this comment made by the author of SQLite, D. Richard Hipp: http://www.mail-archive.com/sqlite-users@sqlite.org/msg01280.html Program crashes, OS crashes, and power failures should not corrupt an SQLite database. This too is a positive sign. It is entirely possible that I am merely a curmudgeon. Three decades of dealing with resource corruption due to poor coding practices -- like opening databases and not closing them -- will do that to a guy. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _The Busy Coder's Guide to *Advanced* Android Development_ Version 1.9.2 Available! -- 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
Re: [android-developers] Re: Content Provider for Private Database?
29.03.2011 21:57, Mark Murphy пишет: On Tue, Mar 29, 2011 at 1:43 PM, Kostya Vasilyevkmans...@gmail.com wrote: There is no leaked database connection with Content Providers. Yes, there is, at least by my definition (close() not being called). By this definition, every program running in a non-GC environment has a memory leak, which would be a very interesting point of view. I never said a memory leak. I said a leaked database connection. I know you didn't. It was an example of a resource (memory) not being released by application code, relying on the OS or the runtime to clean it up upon process termination -- which is was happens to an open database file. To me, a leak is where the use of some resource grows over time and has no chance of decreasing. The resource in question may be memory, open files, DMA buffers, etc. To me, a leak is something that is allocated and not released. The release could be manually (e.g., calling close()) or automatically (e.g., finalizers in a GC environment). http://en.wikipedia.org/wiki/Resource_leak That definition is overly academic for my taste - it would too, consider almost any C/C++ program to have a memory leak. Besides, not closing a database is not specific to content providers. An application that shares a database object among different components might keep it open as well. Which, if never closed, would represent a leak of a database connection. Which would have nothing to do with content providers. That presumes that there is no SQLite logic in a database close() that is important. One hopes that is the case, given the way content providers are implemented. It seems safe to not close a SQLite database, based on empirical evidence supported by some ten million Android devices worldwide, all having some databases and content providers, including those built into the platform. Those same ten million Android devices worldwide are also using AsyncTask, which Romain Guy indicated has flaws severe enough to cause them to drop it back to a single-thread pool in an upcoming Android release, which may have fairly substantial backwards-compatibility issues. So? Bugs happen and code changes happen. Creating and maintaining a framework is really hard, you can't anticipate everything up front. IOW, while I agree that empirical evidence beats no evidence, it is not a guarantee that everything is all coming up roses, either. Besides empirical evidence, see this comment made by the author of SQLite, D. Richard Hipp: http://www.mail-archive.com/sqlite-users@sqlite.org/msg01280.html Program crashes, OS crashes, and power failures should not corrupt an SQLite database. This too is a positive sign. I just don't know... It's like, he and one other guy wrote the thing :) It is entirely possible that I am merely a curmudgeon. Three decades of dealing with resource corruption due to poor coding practices -- like opening databases and not closing them -- will do that to a guy. Sorry. Get a drink? -- Kostya Vasilyev -- http://kmansoft.wordpress.com -- 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
Re: [android-developers] Re: Content Provider for Private Database?
Mark, the point where database changes are made is in commit(). If you did a commit(), your changes are persisted, if not, they are not. This is a critical part of the behavior of a database. Closing the database (or database connection) has no bearing on this. There is nothing it is *allowed* to do that is important to your application. Thus, if one database connection is opened, but never closed, and the number of database connections does not grow over time with any reasonable usage pattern, we should *not* term this a leak. On Tuesday, March 29, 2011 7:27:12 AM UTC-7, Mark Murphy (a Commons Guy) wrote: On Tue, Mar 29, 2011 at 10:19 AM, Kostya Vasilyev kman...@gmail.com wrote: There is no leaked database connection with Content Providers. Yes, there is, at least by my definition (close() not being called). What happens is, the database is kept open as long as the application process is alive, and is open just once, too. When/if the process is killed, the OS kernel closes the file. That presumes that there is no SQLite logic in a database close() that is important. One hopes that is the case, given the way content providers are implemented. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training...At Your Office: http://commonsware.com/training -- 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
Re: [android-developers] Re: Content Provider for Private Database?
On Tue, Mar 29, 2011 at 10:57 AM, Mark Murphy mmur...@commonsware.comwrote: On Tue, Mar 29, 2011 at 1:43 PM, Kostya Vasilyev kmans...@gmail.com wrote: There is no leaked database connection with Content Providers. Yes, there is, at least by my definition (close() not being called). By this definition, every program running in a non-GC environment has a memory leak, which would be a very interesting point of view. I never said a memory leak. I said a leaked database connection. To me, a leak is where the use of some resource grows over time and has no chance of decreasing. The resource in question may be memory, open files, DMA buffers, etc. To me, a leak is something that is allocated and not released. The release could be manually (e.g., calling close()) or automatically (e.g., finalizers in a GC environment). leak is the wrong word for this, as it implies a bug or undesirable behavior. This is not the case. Android made a deliberate design decision that is can seem surprising, to just give up on the whole idea of applications cleanly exiting and instead let the kernel clean up their resources. After all, the kernel needs to be able to do this anyway. Given that design, keeping *anything* open for the entire duration of a process's life and never closing it is simply not a leak. It will be cleaned up when the process is cleaned up. It is only a leak if you are opening something and not closing it (or freeing it) after you are done with it... in really this means that you can create/allocate it an arbitrary number of times for the life of the process, but are not releasing those instances, causing your resource usage to grow without bound. -- 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
[android-developers] Re: Content Provider for Private Database?
Kostya, Unless I misread it, ACRA is good for catching thrown exceptions and automatically sending them to the developer. I am looking for something will allow me to create a trace file. Essentially, I'm looking for a good way to trap the kind of output that I might otherwise send to syslog (via Log.d) but do it such that I can collect the trace and have the app email it upon request. Can ACRA do this? I also looked at microlog4android but the documentation is not easy to follow and it looks like alot of work. A helpful soul in this group provide me some starter classes that will log a trace into a database. I can then access the database when I want and extract what I am looking for. Can you suggest some other alternative? Getting back to the original topic, so a Content Provider is a good paradigm to use across the board even if the database is only meant to be used internally? ...Jake KV == Kostya Vasilyev kmans...@gmail.com writes: KV Jake, KV ContentProvider isn't just for exporting data. KV One useful thing it provides is data change notifications (based KV on data URIs). In practice, it means that ListViews with content KV provider-supplied data refresh automatically, and it's really KV easy to make other UI elements also update automatically by KV registering data change observers. KV Another useful thing is that it forces you to map your data into KV a hierarchical URI-based scheme. This, IMO, results in a cleaner KV conceptual model for your data. KV Yet another is that you can easily pass data references between KV activities by using a data URI. KV On the other hand, with content providers you can't just run a KV raw sql statement whenever you feel like it - all data access is KV structured, so you've got to do some planning first. KV Howerver, for debug info, I probably wouldn't bother with a KV content provider or a database at all. Just a text log file, with KV timestamps, so it can be cross-referenced with the logcat (if you KV can collect that too). KV And speaking of debug reports - have you looked at ready-made KV solutions for this? For example, this one is often recommended on KV this list: KV http://code.google.com/p/acra/ KV -- Kostya KV 28.02.2011 0:18, Jake Colman пишет: What are best practices? My app will use a private database to store debug information. Should I create it as a content provider and do my own data access that way or, since I do not intend to publish this database for anyone else to use, there is no point? Is best practice to alway wrap database access through a content provider? KV -- KV Kostya Vasilyev -- http://kmansoft.wordpress.com KV -- KV You received this message because you are subscribed to the Google KV Groups Android Developers group. KV To post to this group, send email to android-developers@googlegroups.com KV To unsubscribe from this group, send email to KV android-developers+unsubscr...@googlegroups.com KV For more options, visit this group at KV http://groups.google.com/group/android-developers?hl=en -- Jake Colman -- Android Tinkerer -- 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
Re: [android-developers] Re: Content Provider for Private Database?
28.02.2011 0:51, Jake Colman пишет: Kostya, Unless I misread it, ACRA is good for catching thrown exceptions and automatically sending them to the developer. I am looking for something will allow me to create a trace file. Essentially, I'm looking for a good way to trap the kind of output that I might otherwise send to syslog (via Log.d) but do it such that I can collect the trace and have the app email it upon request. Can ACRA do this? They talk about it here: http://code.google.com/p/acra/wiki/ACRA3HowTo#Can_I_send_reports_for_caught_exceptions_?_or_for_unexpected_app but I think it still requires an exception, and each one is sent as a separate reported event. I also looked at microlog4android but the documentation is not easy to follow and it looks like alot of work. A helpful soul in this group provide me some starter classes that will log a trace into a database. I can then access the database when I want and extract what I am looking for. Can you suggest some other alternative? Well, to share some experience - I use my own logger that can output to logcat or a text file, and has settings for individual facilities (i.e. output only network-related events, or worker-thread-related events, etc.), as well as crash logging. Writing it wasn't terribly difficult, and if I had to do it over again, I would. Perhaps this is another option for you to consider: log data to a text file on the memory card. Ask your user (since he's cooperating) to email it to you. Fix the bug - done - move on - probably in less time than it takes to understand a ready-made logging facility. Getting back to the original topic, so a Content Provider is a good paradigm to use across the board even if the database is only meant to be used internally? I like content providers for the reasons outlined in my previous email. YMMV. -- Kostya -- Kostya Vasilyev -- http://kmansoft.wordpress.com -- 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
Re: [android-developers] Re: Content Provider for Private Database?
On Sun, Feb 27, 2011 at 4:51 PM, Jake Colman col...@ppllc.com wrote: Getting back to the original topic, so a Content Provider is a good paradigm to use across the board even if the database is only meant to be used internally? Kostya is pro-ContentProvider. I'm far less of a fan. Notably: -- Data-change notification is helpful, and becomes increasingly helpful with more complex applications. Simple apps, though, can just requery their Cursors when they do a database change, and result is a savings in code complexity, since ContentProviders don't write themselves. -- Data URls are no more useful than other forms of primary key, except in relatively unusual circumstances (e.g., the recipient of the Uri really isn't using the Uri but is merely passing it along to activities that are keyed to the ContentProvider's MIME type). The costs of a ContentProvider are: -- You leak database connections (i.e., there is no place to close your SQLiteDatabase). -- The limited API that Kostya mentions, so much of makes a relational database worthwhile is tossed out. -- They are *world readable and writable by default*, so developers that fail to put android:exported=false on their provider elements in the manifest make their data available for all other apps on the device, purely by accident. If you like the benefits and don't mind the costs, feel free to use a ContentProvider. It's one of the more contentious architectural areas in Android, with its proponents and detractors, so on the whole I don't think there is a consensus right or wrong answer. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android 3.0 Programming Books: http://commonsware.com/books -- 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
Re: [android-developers] Re: Content Provider for Private Database?
Fwiw, a database is way overkill for a debug log or other such thing. Databases aren't free -- all of their features come with significant costs. If you actually are using those features (queries etc) then they are useful. But for a debug log? You are bringing in a ton of overhead for no real gain. As far as databases vs. content providers, I definitely lean towards the camp of avoiding content provider if the data you are managing is never going to be made available to other apps. That said, content providers are such a common pattern in Android's standard apps (since they tend to publish their data to others) that most of the helpers for dealing with structured data are oriented around them. Also keep in mind that publish to others can actually be pretty broad -- for example if you are writing a messaging app, you probably have no reason to want to expose that data as a content provider to others. Except... well, if you are going to do a share option you will need to have a content provider for a URI to share with others. And in Android 3.0 the drag and drop and rich clipboard APIs are built around data stored in a content provider. Even there, though, there's no reason you couldn't take a hybrid approach -- have your application directly access the database, and put a content provider on top of the same database just for publishing specific URIs you want to make available to other apps. On Sun, Feb 27, 2011 at 1:51 PM, Jake Colman col...@ppllc.com wrote: Kostya, Unless I misread it, ACRA is good for catching thrown exceptions and automatically sending them to the developer. I am looking for something will allow me to create a trace file. Essentially, I'm looking for a good way to trap the kind of output that I might otherwise send to syslog (via Log.d) but do it such that I can collect the trace and have the app email it upon request. Can ACRA do this? I also looked at microlog4android but the documentation is not easy to follow and it looks like alot of work. A helpful soul in this group provide me some starter classes that will log a trace into a database. I can then access the database when I want and extract what I am looking for. Can you suggest some other alternative? Getting back to the original topic, so a Content Provider is a good paradigm to use across the board even if the database is only meant to be used internally? ...Jake KV == Kostya Vasilyev kmans...@gmail.com writes: KV Jake, KV ContentProvider isn't just for exporting data. KV One useful thing it provides is data change notifications (based KV on data URIs). In practice, it means that ListViews with content KV provider-supplied data refresh automatically, and it's really KV easy to make other UI elements also update automatically by KV registering data change observers. KV Another useful thing is that it forces you to map your data into KV a hierarchical URI-based scheme. This, IMO, results in a cleaner KV conceptual model for your data. KV Yet another is that you can easily pass data references between KV activities by using a data URI. KV On the other hand, with content providers you can't just run a KV raw sql statement whenever you feel like it - all data access is KV structured, so you've got to do some planning first. KV Howerver, for debug info, I probably wouldn't bother with a KV content provider or a database at all. Just a text log file, with KV timestamps, so it can be cross-referenced with the logcat (if you KV can collect that too). KV And speaking of debug reports - have you looked at ready-made KV solutions for this? For example, this one is often recommended on KV this list: KV http://code.google.com/p/acra/ KV -- Kostya KV 28.02.2011 0:18, Jake Colman пишет: What are best practices? My app will use a private database to store debug information. Should I create it as a content provider and do my own data access that way or, since I do not intend to publish this database for anyone else to use, there is no point? Is best practice to alway wrap database access through a content provider? KV -- KV Kostya Vasilyev -- http://kmansoft.wordpress.com KV -- KV You received this message because you are subscribed to the Google KV Groups Android Developers group. KV To post to this group, send email to android-developers@googlegroups.com KV To unsubscribe from this group, send email to KV android-developers+unsubscr...@googlegroups.com KV For more options, visit this group at KV http://groups.google.com/group/android-developers?hl=en -- Jake Colman -- Android Tinkerer -- 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
