Commit Graph

8824 Commits (60a6128afdc620ab96e93e346fd4c64571e4f318)
 

Author SHA1 Message Date
Matthew Chen 7df8976559 Fix breakage in production builds. 6 years ago
Matthew Chen beea74b761 Merge branch 'charlesmchen/performUpdatesExceptionDetails' 6 years ago
Matthew Chen 1cc0fbcb12 Elaborate logging around 'perform updates' crash. 6 years ago
Matthew Chen 97d4b3bc14 Merge branch 'charlesmchen/objcLogging' 6 years ago
Matthew Chen 9477606732 Apply OWS log functions in Objective-C. 6 years ago
Matthew Chen f473f60111 Apply OWS log functions in Objective-C. 6 years ago
Matthew Chen cc5a480baa Apply OWS log functions in Objective-C. 6 years ago
Matthew Chen 03829779cc Apply OWS log functions in Objective-C. 6 years ago
Matthew Chen c0d486b1f1 Apply OWS log functions in Objective-C. 6 years ago
Matthew Chen 3a50377902 Apply OWS log functions in Objective-C. 6 years ago
Matthew Chen d81dea1d84 Add OWS log macros. 6 years ago
Matthew Chen 2c60f6f224 Merge branch 'charlesmchen/logSdp' 6 years ago
Matthew Chen 0b5b74a901 Respond to CR. 6 years ago
Matthew Chen 490ac5dd76 Redact ice-pwd from SDP. 6 years ago
Matthew Chen 02daca11af Redact ice-pwd from SDP. 6 years ago
Matthew Chen b4539328e1 Log call session description. 6 years ago
Matthew Chen 2d06c05a4f Log call session description. 6 years ago
Matthew Chen 329f8d6f45 Log call session description. 6 years ago
Matthew Chen 77711df274 Merge branch 'charlesmchen/prodFail' 6 years ago
Matthew Chen 713606271c Rename fail macros in Obj-C. 6 years ago
Matthew Chen 5b50e81b4f Rename fail macros in Swift. 6 years ago
Matthew Chen 7be8f30877 Apply -> Never. 6 years ago
Matthew Chen d01023d862 Respond to CR. 6 years ago
Matthew Chen 11eaf1474e Add OWSProdExit(). 6 years ago
Matthew Chen 202a91680f Merge branch 'charlesmchen/reworkingLogging' 6 years ago
Matthew Chen 16a7361e54 Update Cocoapods. 6 years ago
Matthew Chen 4f2f4a44a0 Respond to CR. 6 years ago
Matthew Chen d4f7b5d45b Respond to CR. 6 years ago
Matthew Chen f34bdd34bc Respond to CR. 6 years ago
Matthew Chen dd4f1babba Respond to CR. 6 years ago
Matthew Chen e1049fdfcc Respond to CR. 6 years ago
Matthew Chen bc23e38efc Respond to CR. 6 years ago
Matthew Chen cf6f3841a8 Apply new Swift logging. 6 years ago
Matthew Chen 3697974ca8 Rework Swift logging. 6 years ago
Michael Kirk 1a92f414eb Revert "Disable dark theme in production."
This reverts commit 472a92a1a3.
6 years ago
Michael Kirk 1d2590fa12 Merge tag '2.29.0.17' 6 years ago
Michael Kirk 65c323440b update translation location 6 years ago
Michael Kirk 1503608f5f Merge branch 'mkirk/faster-presentation' 6 years ago
Michael Kirk 7e8b2e3034 Faster conversation presentation.
There are multiple places in the codebase we present a conversation.

We used to have some very conservative machinery around how this was done, for
fear of failing to present the call view controller, which would have left a
hidden call in the background. We've since addressed that concern more
thoroughly via the separate calling UIWindow.

As such, the remaining presentation machinery is overly complex and inflexible
for what we need.

Sometimes we want to animate-push the conversation. (tap on home, tap on "send message" in contact card/group members)
Sometimes we want to dismiss a modal, to reveal the conversation behind it (contact picker, group creation)
Sometimes we want to present the conversation with no animation (becoming active from a notification)

We also want to ensure that we're never pushing more than one conversation view
controller, which was previously a problem since we were "pushing" a newly
constructed VC in response to these myriad actions. It turned out there were
certain code paths that caused multiple actions to be fired in rapid succession
which pushed multiple ConversationVC's.

The built-in method: `setViewControllers:animated` easily ensures we only have
one ConversationVC on the stack, while being composable enough to faciliate the
various more efficient animations we desire.

The only thing lost with the complex methods is that the naive
`presentViewController:` can fail, e.g. if another view is already presented.
E.g. if an alert appears *just* before the user taps compose, the contact
picker will fail to present.

Since we no longer depend on this for presenting the CallViewController, this
isn't catostrophic, and in fact, arguable preferable, since we want the user to
read and dismiss any alert explicitly.

// FREEBIE
6 years ago
Michael Kirk ae44b316aa Merge branch 'mkirk/show-message-actions-on-call' 6 years ago
Michael Kirk bc2ba63c21 DRY refactor 6 years ago
Michael Kirk 37738c24c5 Allow menuActions + callBanner
// FREEBIE
6 years ago
Michael Kirk 495ed56676 Merge branch 'mkirk/cleanup-longview' 6 years ago
Michael Kirk 464b854eb1 CR: follow naming conventions 6 years ago
Michael Kirk 9c9f3875a7 Link styling 6 years ago
Michael Kirk 5148747c12 clean up long text VC 6 years ago
Michael Kirk c8c2b8c640 Merge branch 'mkirk/swift-assert-main-thread' 6 years ago
Michael Kirk 82e559d11b Use swift macros for main thread assert 6 years ago
Michael Kirk aabf9e79e8 Merge branch 'mkirk/async-search' 6 years ago
Michael Kirk 781c535327 weak capture self 6 years ago