Unsubscribe from ble characteristic instantly after cancel call.#81
Unsubscribe from ble characteristic instantly after cancel call.#81Nikolas-LFDesigns wants to merge 3 commits intoMonnoroch:masterfrom
Conversation
8b7b5f3 to
d3ea09f
Compare
|
А, ну конечно.. пока без тестов |
2ecdbb1 to
731d074
Compare
| () -> { | ||
| subscriptionToCancel.clearCanceled(); | ||
| if (!subscriptionToCancel.hasAnySubscriber() | ||
| && subscriptionToCancel.status == SubscriptionStatus.SUBSCRIBED) { |
There was a problem hiding this comment.
А что будет, если SUBSCRIBING?
There was a problem hiding this comment.
Посмотри тест testSubscribeIgnoreCanceledCall, похоже он проходит, а значит всё норм будет.
С unsubscribing еще проще: не даст выполниться, пока не пройдет call отписки.
There was a problem hiding this comment.
Я так и не понял, что будет с SUBSCRIBING. Можешь разобраться? Тесты -- это хорошо, но они тестируют только то, что мы предусмотрели и запрограммировали в тестах.
There was a problem hiding this comment.
Ну смотри, в случае Rx ситуация чисто гипотетическая, ибо мы не сможем отписаться пока не подпишемся, а так произойдет подписка несмотря на cancel, с чем мы тоже ничего не сделаем, ибо процесс writeDescriptor уже запущен и ты его не отменишь в процессе.
There was a problem hiding this comment.
А вот и не гипотетическая. Мы можем подписать несколько обзерверов и отписывать их пока подписываем новые. И статус соединения тут будет мигать.
There was a problem hiding this comment.
Вот последний и определит исход, ну
так уж если мы хотим отписываться сразу же, это просто норма, не понимаю, зачем с этим что-то делать.
There was a problem hiding this comment.
Ох, ну опять ты со своим "да все будет ок, расслабься". Это сложный код, который будет нам гейзенбаги выдавать если мы в обработке ошибок напортачим, тут нельзя отмахиваться. Я позже подумаю сам и верифицирую.
4cd12da to
71f1ff9
Compare
|
Ребейзнул на все фиксы, теперь-то всё? )) |
71f1ff9 to
f8e3129
Compare
11dbc90 to
e314ea5
Compare
Related to #14.