by dback » Fri Sep 03, 2010 2:47 pm
The Android system only has one database/data file into which SMS messages are stored. The retrieval mechanism (I believe) is the built-in Messaging app. So from that perspective, yes, both Handcent and Messaging run simultaneously. I believe however, that the native app is split between a send/receive service (I forget the proper term in Android-speak) and a client interface.
Android takes an interesting approach to minimizing memory footprints, kind of reminiscent of Windows 3.x. When you write an app, (if you chose to) you write sections of code as independent components which can be loaded independently of the main app (similar to DLL's in Windows land). In this way, if an app needs functionality that your app provides, it can request to utilize only that segment of code. In essence, Android looks at an app as a collection of services. Intriguing approach.
So while you'll see the Messaging app in your task list, I believe in Task List you're seeing the core componentry (since Android can run elements of an app as needed, instead of the entire app). Given this nature of Android, I'd venture what's happening is Handcent is utilizing the message-retrieval/message-handler of the native app (and I don't believe this can be avoided, least of all without root/rom), but not the interface code.
Since it's only a single data store, both apps when launched are privy to the same messages. Think of opening a single text file with Word or Notepad - both present the same info, but use a different interface design. The question is who's code is kicking off the send/retrieve process. Once you disable retrieve/send by the native messaging app, the only piece of it's code that's used is the actual retrieve/store engine (segment of code).