...if the call was more than five minutes ago. This should help in two
scenarios:
- you've been offline for a while, and you see "missed call" but don't
know when they tried to call
- you hit that NSE bug where a ring gets processed hours or even days
later, possibly when a second call arrives
Not only should we not build avatars, but even loading the image data
costs us our limited memory space, especially when it's a system
contact avatar whose size we have no control over. Instead, record the
cache key for that avatar in the database.
(Unfortunately, we can't jump to the cache like this in the main app,
because then we'd have no way to check if an avatar has *changed*,
particularly for system contacts.)
The expression for the relative cutoff timestamp was
`-self.maximumNumberOfLogFiles * kDayInterval`, but
'maximumNumberOfLogFiles' is an unsigned integer, so this turned into
"some day very far in the future" and immediately deleted all
extension logs. The new expression, `self.maximumNumberOfLogFiles *
-kDayInterval` works because 'kDayInterval' is an NSTimeInterval, a
floating-point value.
* added details for Signalyzer; improved ContactsManagerCache
* some minor runtime improvements
* systems contacts are written and read in big chunks to improve overall performance
* use of __file__, __function__ and __line__ when monitoring objective C methods
* minor changes
* minor changed based on review comments
Call messages delivered to the NSE have to be handled in the main app,
so they're put in a synced key-value store and the app is notified.
Rings are processed oldest-to-newest in case you get two calls in
succession before the main app awakes. However, if this processing is
interrupted, the store won't get cleared, and the app may try to
process the *old* ring when it's woken up by a *new* ring. This would
*still* be correct (e.g. for showing missed call notifications) except
that the "age" of a ring message is calculated purely on when it makes
it to the user's device, since it was assumed that it would be
processed promptly. Since this is not necessarily the case in these
error scenarios, this commit adds a second timestamp to track the skew
between when the NSE enqueues the call message and when the main app
processes it.
Matthew previously stripped this down in our fork of AFNetworking; at
this point there's no benefit to it living in a separate repo and
separate target. With this we can remove the AFNetworking target
completely.
Our AvatarBuilder caches were cleared in their entirety any time a
profile changes. If a profile update raced with a avatar fetch in
ConversationAvatarView, they'd blink briefly while the cached items were
removed.
This change ensures that we're only clearing out avatars that are
associated with an updated profile.
- Clear out avatar cache on local profile changes too
- ConversationAvatarView properly handles local profile updates
- Fix some tiny UI bugs in group calls
Adoption of ConversationAvatarView2 in many key locations. This isn't
exhaustive, but it's mostly there.
Some work left to be done around ConversationAvatarView2 data source
tweaks.
