Skip to content
  1. Dec 10, 2020
  2. Dec 08, 2020
  3. Dec 07, 2020
  4. Dec 06, 2020
  5. Dec 02, 2020
  6. Dec 01, 2020
  7. Nov 25, 2020
  8. Nov 16, 2020
  9. Nov 15, 2020
  10. Nov 14, 2020
  11. Nov 13, 2020
  12. Nov 12, 2020
  13. Oct 20, 2020
  14. Oct 08, 2020
  15. Oct 06, 2020
    • nico's avatar
      spelling · fdfac102
      nico authored
      * various spelling fixes
      fdfac102
  16. Oct 05, 2020
    • eta's avatar
      Fix various memory leaks reported by LeakCanary · 364502d1
      eta authored
      - In some places, we weren't nulling out references to destroyed objects. This
        fixes that.
      - (These were all discovered via LeakCanary instrumentation, and the fixes are
        hopefully rather straightforward-looking.)
      364502d1
    • eta's avatar
      Remove the ListSelectionManager / message body selection (fixes memory leak!) · b4805ac2
      eta authored
      - When the `viewHolder.messageBody` `TextView` created by a `MessageAdapter` is
        set to selectable, it leaks an `android.widget.Editor` (because that editor
        registers a view observer that never gets unregistered).
        - This memory leak is really quite problematic, as the message adapter is used
          a lot!
      - Having the text be selectable is useless anyway, though; there isn't any way
        to select it (because long pressing just opens the context menu anyway).
        - It looks like the ListSelectionManager was meant to track selections across
          multiple messages. However, I'm not sure this feature ever gets used.
      - Accordingly, this commit removes the entire feature, thus fixing the memory
        leak (since no `Editor` objects are ever created).
        - It should also reduce memory usage in general, since we aren't attaching an
          `Editor` to every single textview we create.
        - A `TextView` only allocates an `Editor` if you ask it to do certain things,
          like make the text selectable or register custom selection callbacks.
      b4805ac2
  17. Sep 11, 2020
  18. Sep 09, 2020
  19. Sep 02, 2020
    • Daniel Gultsch's avatar
      disable 'leave before join' · 7fb617e3
      Daniel Gultsch authored
      leaving a MUC before joining it was a work around for servers that did not treat a
      <x/> join as a full join and didn’t send the full user list if they thought the user was
      still in the room.
      this happens if Conversations restarts after an inproper disconnect. The MUC will think
      the user is still in the room.
      
      however nowadays most modern servers will treat <x/> joins as full joins. on the user hand
      leave before join would trigger flood prevention on ejabberds and race the first message
      with the actual join (making the message arrive before the user is considered in the room)
      7fb617e3
Loading