subscriberVideoDisabled Always returns OTSubscriberVideoEventPublisherPropertyChanged - ios

I added a
(void)subscriberVideoDisabled:(OTSubscriberKit *)subscriber reason:(OTSubscriberVideoEventReason)reason
to check when the video is disabled by a subscriber/ publisher. I disable the video by putting wifi off or by going to the background while the broadcast is going on.
Above delegate method is triggered in both the scenarios. However, the reason enum does not return as
OTSubscriberVideoEventSubscriberPropertyChanged
when the video is disabled by the subscriber using any of the above methods. It returns as
OTSubscriberVideoEventPublisherPropertyChanged
which I think is not correct. Is there anything I am doing wrong?
This question is asked at OpenTok Developer forum as well

I believe the reason enum is qualityChanged because it's actually your client that pull off wifi which results in no internet condition. OTSubscriberVideoEventSubscriberPropertyChanged enum describes that situation when the video remote stream(publisher) is disabled explicitly.
There are a couple things you want to look into:
optional public func subscriberVideoDisableWarning(_ subscriber: OTSubscriberKit!)
optional public func subscriberVideoDisableWarningLifted(_ subscriber: OTSubscriberKit!)
optional public func subscriberDidReconnect(toStream subscriber: OTSubscriberKit!)

Related

Create custom "read" Intent like GetCurrentLocation

I'm creating shortcuts for a communication app. In this app there is a presence state (available, dnd, ...). I implemented an intent to set said presence state which worked fine. I created a "read" intent which just returns the currently set state, which works, but i can't pass the result to the next action.
For simplification and testing i created another intent just return a string, trying to process it, but i'm still unable to do that. My intent has no input parameters.
What am i missing? My Goal would be an interaction like Get Current Location offers.
class Return5IntentHandler: NSObject, Return5IntentHandling {
func handle(intent: Return5Intent, completion: #escaping (Return5IntentResponse) -> Void) {
completion(.success(result: "5"))
}
}
Classic case of searching for hours, writing a question only to find the answer 30min later yourself...
One has to explicitly set the output, which is the passed on value for following actions.

iOS SMS and Call Spam Reporting extension is reporting the wrong number

I am new to iOS and I'm facing an issue with the SMS and Call spam reporting extension for iOS 14.6. I've implemented the extension and when I select one or more messages and click the button to report the sender, the sender's phone number is getting reported, but with a string appended to its number. For example:
example screenshot
The numbers that should be displayed are "orange" and "+40 753878811", but instead "filtered" is appended to every number. In this case, the numbers are not actually blocked and I am still able to receive messages and calls from them.
Any meaningful piece of code that I use is in the classificationResponse method:
override func classificationResponse(for request:ILClassificationRequest) -> ILClassificationResponse {
return ILClassificationResponse(action: .reportJunkAndBlockSender)
}
Basically, what I'm trying to do is to block any user that I click on, either from the messages app or from the contacts.
Does anybody know why is this happening?
Thank you in advance for your help!

Why does NWPathMonitor status is always satisfied?

When there is no connection I get an error from the URL Session saying that the request timed out.
I’m using the Network protocol to check for connectivity before hand but apparently this is not working as when I am calling this inside viewDidLoad:
static func startUpdateProcess() {
let monitor = NWPathMonitor()
monitor.pathUpdateHandler = { path in
if path.status == .satisfied {
print("Good! We are connected!")
Helper.createDownloadTask()
} else {
print("No connection. Local file not updated!")
}
}
let queue = DispatchQueue(label: "Monitor")
monitor.start(queue: queue)
}
...I get “Good! We are connected!”.
Shouldn’t the path not be satisfied if there is no connection and therefore trigger the else statement?
FYI the createDownloadTask() questions the API and downloads the required data.
Can you tell me what is wrong here and what could I do to get to the else statement if the path is not satisfied?
Thank you!
Credit to user May Rest in Peace for pointing me to the right direction.
Despite the Documentation being silent on the Network Protocol, it seems that the status property of the NWPath class, an enumeration of type NWPath.Status, returns .satisfied as long as the device is connected to a network, regardless of whether that network is working, transmitting data, or not.
The only way the else statement above could be triggered would have been by deactivating Wi-Fi and/or Cellular data or disconnecting from any network before launching the app.
All those properties are listed in the Documentation but none of them has a description or a discussion attached.
This article by user #twostraws allowed me to create the first part of that code.
Reference to the instance of NWPathMonitor (aka monitor in your scenario) needs to be retained.
You could make it a strong property by making monitor a class level property so that its lifecycle is the same as the place you are referring it from. It looks like the monitor object is being released effectively stopping the callbacks for network status monitoring.

Bidirectional gRPC stream sometimes stops processing responses after stopping and starting

In short
We have a mobile app that streams fairly high volumes of data to and from a server through various bidirectional streams. The streams need to be closed on occasion (for example when the app is backgrounded). They are then reopened as needed. Sometimes when this happens, something goes wrong:
From what I can tell, the stream is up and running on the device's side (the status of both the GRPCProtocall and the GRXWriter involved is either started or paused)
The device sends data on the stream fine (the server receives the data)
The server seems to send data back to the device fine (the server's Stream.Send calls return as successful)
On the device, the result handler for data received on the stream is never called
More detail
Our code is heavily simplified below, but this should hopefully provide enough detail to indicate what we're doing. A bidirection stream is managed by a Switch class:
class Switch {
/** The protocall over which we send and receive data */
var protocall: GRPCProtoCall?
/** The writer object that writes data to the protocall. */
var writer: GRXBufferedPipe?
/** A static GRPCProtoService as per the .proto */
static let service = APPDataService(host: Settings.grpcHost)
/** A response handler. APPData is the datatype defined by the .proto. */
func rpcResponse(done: Bool, response: APPData?, error: Error?) {
NSLog("Response received")
// Handle response...
}
func start() {
// Create a (new) instance of the writer
// (A writer cannot be used on multiple protocalls)
self.writer = GRXBufferedPipe()
// Setup the protocall
self.protocall = Switch.service.rpcToStream(withRequestWriter: self.writer!, eventHandler: self.rpcRespose(done:response:error:))
// Start the stream
self.protocall.start()
}
func stop() {
// Stop the writer if it is started.
if self.writer.state == .started || self.writer.state == .paused {
self.writer.finishWithError(nil)
}
// Stop the proto call if it is started
if self.protocall?.state == .started || self.protocall?.state == .paused {
protocall?.cancel()
}
self.protocall = nil
}
private var needsRestart: Bool {
if let protocall = self.protocall {
if protocall.state == .notStarted || protocall.state == .finished {
// protocall exists, but isn't running.
return true
} else if writer.state == .notStarted || writer.state == .finished {
// writer isn't running
return true
} else {
// protocall and writer are running
return false
}
} else {
// protocall doesn't exist.
return true
}
}
func restartIfNeeded() {
guard self.needsRestart else { return }
self.stop()
self.start()
}
func write(data: APPData) {
self.writer.writeValue(data)
}
}
Like I said, heavily simplified, but it shows how we start, stop, and restart streams, and how we check whether a stream is healthy.
When the app is backgrounded, we call stop(). When it is foregrounded and we need the stream again, we call start(). And we periodically call restartIfNeeded(), eg. when screens that use the stream come into view.
As I mentioned above, what happens occasionally is that our response handler (rpcResponse) stops getting called when server writes data to the stream. The stream appears to be healthy (server receives the data we write to it, and protocall.state is neither .notStarted nor .finished). But not even the log on the first line of the response handler is executed.
First question: Are we managing the streams correctly, or is our way of stopping and restarting streams prone to errors? If so, what is the correct way of doing something like this?
Second question: How do we debug this? Everything we could think of that we can query for a status tells us that the stream is up and running, but it feels like the objc gRPC library keeps a lot of its mechanics hidden from us. Is there a way to see whether responses from server may do reach us, but fail to trigger our response handler?
Third question: As per the code above, we use the GRXBufferedPipe provided by the library. Its documentation advises against using it in production because it doesn't have a push-back mechanism. To our understanding, the writer is only used to feed data to the gRPC core in a synchronised, one-at-a-time fashion, and since server receives data from us fine, we don't think this is an issue. Are we wrong though? Is the writer also involved in feeding data received from server to our response handler? I.e. if the writer broke due to overload, could that manifest as a problem reading data from the stream, rather than writing to it?
UPDATE: Over a year after asking this, we have finally found a deadlock bug in our server-side code that was causing this behaviour on client-side. The streams appeared to hang because no communication sent by the client was handled by server, and vice-versa, but the streams were actually alive and well. The accepted answer provides good advice for how to manage these bi-directional streams, which I believe is still valuable (it helped us a lot!). But the issue was actually due to a programming error.
Also, for anyone running into this type of issue, it might be worth investigating whether you're experiencing this known issue where a channel gets silently dropped when iOS changes its network. This readme provides instructions for using Apple's CFStream API rather than TCP sockets as a possible fix for that issue.
First question: Are we managing the streams correctly, or is our way of stopping and restarting streams prone to errors? If so, what is the correct way of doing something like this?
From what I can tell by looking at your code, the start() function seems to be right. In the stop() function, you do not need to call cancel() of self.protocall; the call will be finished with the previous self.writer.finishWithError(nil).
needsrestart() is where it gets a bit messy. First, you are not supposed to poll/set the state of protocall yourself. That state is altered by itself. Second, setting those state does not close your stream. It only pause a writer, and if app is in background, pausing a writer is like a no-op. If you want to close a stream, you should use finishWithError to terminate this call, and maybe start a new call later when needed.
Second question: How do we debug this?
One way is to turn on gRPC log (GRPC_TRACE and GRPC_VERBOSITY). Another way is to set breakpoint at here where gRPC objc library receives a gRPC message from the server.
Third question: Is the writer also involved in feeding data received from server to our response handler?
No. If you create a buffered pipe and feed that as request of your call, it only feed data to be sent to server. The receiving path is handled by another writer (which is in fact your protocall object).
I don't see where the usage of GRXBufferedPipe in production is discouraged. The known drawback about this utility is that if you pause the writer but keep writing data to it with writeWithValue, you end up buffering a lot of data without being able to flush them, which may cause memory issue.

Swift cast generic without knowing the type

Is it possible to typecast an object like so (let the code speak for itself):
protocol Parent {
...
}
class Child<LiterallyAnyValue, SameAsThePrevious>: Parent {
...
}
And then when using it:
func foobar(parent: Parent) {
if parent is Child { //ONE
print(parent as! Child) //TWO
}
}
At the signed points xcode wants me to supply the two types of "Child" within <> like Child<Int, String>...
The problem is that those types could be anything... LITERALLY
(And I've tried Child<Any, Any> but that doesn't work in this case)
Is there a workaround or a solution to this?
-------- Clarification --------
I am working on an iOS 7 project so I can't really use any modern library :)
That is including PromiseKit and Alamofire and the app has to make tons of http requests. The use promises in requests has grown on me, so I created my own Promise class.
At first I made it so that the Promise class would not be a generic and it would accept Any? as the value of the resolution procedure.
After that I wanted to improve my little Promise class with type clarification so the class Promise became "class Promise<T>"
In my implementation the then method created a PromiseSubscriber which then would be stored in a Promise property called subscribers.
The PromiseSubscriber is the protocol here that has two subset classes, one being PromiseHandler (this is called when the promise is resolved), and the other the PromiseCatcher (this is called when the promise is rejected)
Both PromiseSubscriber subset classes have a property called promise and one called handler.
These classes are also generics so that you know what kind of Promise they store and what is the return type of the handler.
In my resolution process I have to check if the PromiseSubscriber is a (let's say) PromiseHandler and if it is then call the handler that returns something and then resolve the subscribed promise with that value.
And here is the problem. I can't check if the subscriber is a catcher or a handler...
I hope it's clear enough now. Maybe this is not the right approach, I honestly don't know I am just trying to create something that is fun and easy to use (code completion without checking the type).
If it's still not clear and you are willing to help me, I'll send over the classes!
It's a little difficult to understand what you're really trying to do here (please tell me it's something other than JSON parsing; I'm so tired of JSON parsing and it's the only thing people ever ask about), but the short answer is almost certainly no. Some part of that is probably a misuse of types, and some part of that is a current limitation in Swift.
To focus on the limitation in Swift part, Swift lacks higher-kinded types. It is not possible to talk about Array. This is not a type in Swift. You can only work with Array<Int> or Array<String> or even Array<T>, but only in cases where T can be determined at compile time. There are several ways to work through this, but it really depends on what your underlying problem is.
To the misuse of types side, you generally should not have if x is ... in Swift. In the vast majority of cases this should be solved with a protocol. Whatever you were going to do in the if, make it part of the Parent protocol and give it a default empty implementation. Then override that implementation in Child. For example:
protocol Parent {
func doSpecialThing()
}
extension Parent {
func doSpecialThing() {} // nothing by default
}
class Child<LiterallyAnyValue, SameAsThePrevious>: Parent {}
extension Child {
func doSpecialThing() {
print(self)
}
}
func foobar(parent: Parent) {
parent.doSpecialThing()
}
Thanks for the clarification; Promise is a great thing to play with. Your mistake is here:
In my resolution process I have to check if the PromiseSubscriber is a (let's say) PromiseHandler and if it is then call the handler that returns something and then resolve the subscribed promise with that value.
Your resolution process should not need to know if it's a handler or a catcher. If it does, then your PromiseSubscriber protocol is incorrectly defined. The piece it sounds like you're missing is a Result. Most Promise types are built on top of Result, which is an enum bundling either success or failure. In your scheme, handlers would process successful Results and ignore failing results. Catchers would process failing results and ignore successful Results. The promise resolution shouldn't care, though. It should just send the Result to all subscribers and let them do what they do.
You can build this without a Result type by using a protocol as described above.
protocol PromiseSubscriber {
associatedType Wrapped // <=== It's possible you've also missed this piece
func handleSuccess(value: Wrapped)
func handleFailure(failure: Error)
}
extension PromiseSubscriber {
func handleSuccess(value: Wrapped) {} // By default do nothing
func handleFailure(failure: Error) {}
}
class PromiseHandler<Wrapped> {
func handleSuccess(value: Wrapped) { ... do your thing ... }
}
class PromiseCatcher {
func handleFailure(failure: Error) { ... do your thing ... }
}
I recommend studying PinkyPromise. It's a nice, simple Promise library (unlike PromiseKit which adds a lot of stuff that can make it harder to understand). I probably wouldn't use a protocol here; the associatedtype makes things a bit harder and I don't think you get much out of it. I'd use Result.
Use a generic type in your foobar function, the one below requires the parent parameter to conform to the Parent protocol and T will represent the class of the object passed.
func foobar<T: Parent>(parent: T) {
print(parent)
}

Resources