I already made a SortCursor to do the necessary mergin/sorting. The only problem with merging/sorting cursors is all moves need to be made one by one unless you want to keep a mapping around. The problem with keeping a mapping around is the entire mapping would need to be refreshed upon every change to the underlying data of the cursor. If the cursor changes a lot, this effects performance significantly.
So, since it would be too big of a change to restructure Contact History, would you think a SortCursor would be a significant enough class to add to the framework, or is it something I should just put up on the web somewhere for someone to download? It's really a matter of whether you think a lot of people will be treating two tables as equal objects/wanting to list them together. On Jan 22, 3:08 pm, Dianne Hackborn <[email protected]> wrote: > I don't think this is something we would probably be taking in to the > platform. First because we already have the existing content providers, so > restructuring them all to be under a new provider while still retaining > compatibility with existing apps would be a tremendous endeavor. Second > because I would guess that trying to make a content provider structure > general enough to hold phone call entries, SMS messages, and whatever else > counts as "communication" would result in something incredibly general and > thus difficult to use and with a lot of overhead. > > I don't think it would be hard to write your own code to merge multiple > cursors together into a single list, provided that the original cursors are > all sorted in the same way. That seems like the way I would go. > > On Thu, Jan 22, 2009 at 12:13 PM, Jonathan Herriott <[email protected]>wrote: > > > > > > > > > I was originally going to submit this post on the need for a > > SortCursor, which would take in an array of Cursors and a Comparator > > and treat the list of cursors as a single sorted list. Then I thought > > about the real issue I'm having is the fact that there is not a common > > CommunicationHistory provider. Essentially, the problem is that there > > are two history tables, one for phone calls, and one for sms, and > > there could potentially be many more depending on number of > > applications retaining communication history. I think that the there > > should be a ContentProvider for CommunicationsHistory in order to > > consolidate the history to make it easier to sort/display as a single > > list. I just wanted to see what other people's thoughts are before I > > start on this endeavor or whether something like this would be > > accepted into the framework were I to submit it as a patch. > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support. 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-framework" 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-framework?hl=en -~----------~----~----~----~------~----~------~--~---
