1. 19 Nov, 2019 1 commit
  2. 03 Jul, 2019 1 commit
    • chriadam's avatar
      [libcontacts] Update section bucket index cache after deletions. Contributes to JB#46496 · c7112dae
      chriadam authored
      When a contact is deleted, we need to recalculate the section bucket
      index cache as that contact may have been the only contact in a given
      section bucket (display label group).
      
      However, since updating the section bucket index cache is an expensive
      operation, we should only do this once per bulk deletion, so this
      commit also adds support for bulk deletion operations.
      c7112dae
  3. 28 May, 2019 1 commit
  4. 30 Apr, 2019 1 commit
    • chriadam's avatar
      [libcontacts] Explicitly tell models to update section bucket index caches. Contributes to JB#45504 · 689011e6
      chriadam authored
      When contact data changes in the backend and we have pulled these
      changes into the model, we need to tell the attached models that
      they need to recalculate their cache of section bucket indexes.
      
      Note that we cannot have a single cache of section bucket indexes
      which the models read, as models can have a search filter applied
      which means the indexes of contacts in the seaside cache won't
      necessarily match what the model expects.
      689011e6
  5. 17 Apr, 2019 1 commit
  6. 08 Mar, 2019 1 commit
  7. 10 Oct, 2016 1 commit
  8. 30 Oct, 2015 1 commit
  9. 04 Aug, 2015 1 commit
  10. 05 Mar, 2015 1 commit
    • mvogt's avatar
      [libcontacts] Some scripts imply name token ordering · f4c2e52e
      mvogt authored
      For a specific set of character scripts, if a contact's first and last
      names are entirely composed of that script, then that (most likely)
      implies a cultural ordering for given/family name tokens that should
      override the device setting.
      f4c2e52e
  11. 12 Feb, 2015 1 commit
    • Richard Braakman's avatar
      [performance] Avoid resolving addresses multiple times · 4bfe8804
      Richard Braakman authored
      Parts of commhistory (GroupManager) will send a stream of
      resolve requests with many duplicates. This used to be
      tolerable because requests were handled slowly in the
      event loop, but now that they have higher priority it has
      become a problem.
      
      I went for the simple solution of ignoring requests that
      are identical to still-active requests (same uids, same
      listener, same requireComplete flag). It's not optimal (we
      could combine more requests into the same backend query if we
      tried), but it solves the problem without adding a lot of
      bookkeeping.
      4bfe8804
  12. 21 Oct, 2014 1 commit
  13. 17 Oct, 2014 1 commit
    • Richard Braakman's avatar
      [performance] Schedule resolveAddress immediately · e2ab0615
      Richard Braakman authored
      resolveAddress requests are done with one query at a time, in
      order to correlate the results with the looked-up addresses.
      Doing them sequentially via UpdateRequest events added a lot
      of overhead in the form of coordination between threads.
      
      This commit creates a dedicated QContactFetchRequest for each
      resolveAddress call, so that the events for starting them can
      arrive all together in the backend thread and the events
      announcing the results can arrive all together in the UI thread.
      They will still be processed sequentially, but this change cuts
      out the delay between finishing one request and starting the next.
      
      In tests with 10k contacts and a recent contacts list with limit=20,
      this reduced the resolve time from 1s to 0.3s.
      e2ab0615
  14. 15 Oct, 2014 1 commit
  15. 31 Jul, 2014 1 commit
  16. 27 May, 2014 1 commit
  17. 10 Feb, 2014 1 commit
    • mvogt's avatar
      [libcontacts] Skip validation when normalizing numbers · f73cd4cd
      mvogt authored
      In most cases, there is no benefit to validating numbers as they are
      normalized, since the data has come from the system. Validation of
      data already present in the system is counterproductive since it can
      cause us not to process some details.
      f73cd4cd
  18. 28 Jan, 2014 2 commits
  19. 15 Jan, 2014 1 commit
  20. 09 Jan, 2014 3 commits
  21. 11 Dec, 2013 1 commit
  22. 10 Dec, 2013 3 commits
  23. 09 Dec, 2013 3 commits
  24. 06 Dec, 2013 1 commit
  25. 24 Oct, 2013 3 commits
    • mvogt's avatar
      [libcontacts] Do not resolve minimized numbers from cache · b9d4941f
      mvogt authored
      If we try to resolve a minimized number that we have not previously
      queried matches for, then do not resolve to any contact that happens
      to be in tha cache that matches that number - there may be a better
      match that we should query for.
      
      Once we have queried a specific number, or set the cache to fetch all
      numbers, it is safe to resolve from the content of the cache.
      b9d4941f
    • mvogt's avatar
      [libcontacts] Index initial-'+' numbers in their complete forms · 329e46b7
      mvogt authored
      A number starting with an initial '+' can be tested at full length
      which is preferential to tetsing minimized form.
      329e46b7
    • mvogt's avatar
      [libcontacts] Allow multiple matches for a minimized phone number · 7b112bdd
      mvogt authored
      For resolution, find the contact possessing the number with the longest
      match to the input number.
      
      Also, correct the previous terminological misuse of 'normalization'
      to mean 'minimization'.
      7b112bdd
  26. 21 Oct, 2013 1 commit
  27. 14 Oct, 2013 1 commit
  28. 02 Oct, 2013 2 commits
  29. 01 Oct, 2013 1 commit
  30. 20 Sep, 2013 1 commit