In the <GCKDeviceManagerDelegate> Protocol I see two very similar methods:
/**
* Called when the connection to the device has been terminated. It is safe to release the
* GCKDeviceManager object from within this callback.
*
* #param deviceManager The device manager.
* #param error The error that caused the disconnection; nil if there was no error (e.g. intentional
* disconnection).
*/
- (void)deviceManager:(GCKDeviceManager *)deviceManager
didDisconnectWithError:(NSError *)error;
and
/**
* Called when disconnected from the current application.
*
* #param deviceManager The device manager.
* #param error The error that caused the disconnect, or <code>nil</code> if this was a normal
* disconnect.
*/
- (void)deviceManager:(GCKDeviceManager *)deviceManager
didDisconnectFromApplicationWithError:(NSError *)error;
Is deviceManager:didDisconnectWithError: called if the Chromecast receiver is disconnected or loses connection to the application, and deviceManager:didDisconnectFromApplicationWithError: called when the application tries to disconnect from the Chromecast receiver?
What are the use-cases when each delegate method would be called?
A sender application can connect to a cast device and upon successful connection can launch a receiver application on the cast device. So "connecting to a device" and "running an application" are two separate actions, so are "stopping the receiver application" and "disconnecting" from the cast device. As such, there are those two separate methods.
Related
I had zero warnings, then I updated to Firebase 4.0 now I have two warnings within GeoFire that won't go away.
Warnings
.../Pods/GeoFire/GeoFire/API/GeoFire.h:108:11: Empty paragraph passed to '#return' command
.../Pods/GeoFire/GeoFire/API/GeoFire.h:108:5: '#return' command used in a comment that is attached to a method returning void
GeoFire Code
- (void)removeKey:(NSString *)key withCompletionBlock:(GFCompletionBlock)block;
/**
* Gets the current location for a key in GeoFire and calls the callback with the location or nil if there is no
* location for the key in GeoFire. If an error occurred, the callback will be called with the error and location
* will be nil.
*
* #param key The key to observe the location for
* #param callback The callback that is called for the current location
* #return <- WARNINGS GIVEN ON THIS LINE
*/
Does anyone have any information about this or at least how to silence safely. On attempt to remove comment it says GeoFire is locked for editing.
I am working with iOS 8's Core Bluetooth API. I have written some simple Swift code that creates a Central Manager and that implements the CBManager & CBPeripheral protocols. When the callbacks are executed they perform logging:
2015-09-04 14:08:33.719 CentralManager - Did update state to Powered on
2015-09-04 14:08:33.745 CentralManager - Did discover peripheral: CBPeripheral: 0x1700f5080, identifier = 3DD113C3-D175-7374-CF88- F471BB470169, name = Apple TV, state = disconnected
2015-09-04 14:08:33.955 CentralManager - Did connect peripheral: CBPeripheral: 0x1700f5080, identifier = 3DD113C3-D175-7374-CF88-F471BB470169, name = Apple TV, state = connected
2015-09-04 14:08:34.462 Peripheral - Did discover service: CBService: 0x174075600, isPrimary = YES, UUID = Continuity
2015-09-04 14:08:34.582 Peripheral: Did discover characteristic for service Continuity : ()
Everything looks good. As you can see, log statements 2 and 3 print the value of the CBPeripheral argument that was passed to the callback function. I am using Swift's string interpolation capability to accomplish this - ex. "The value is \(peripheral)".
Now for the problem: When I set a breakpoint in one of the callback functions and examine the CBPeripheral argument via Xcode's debug pane, I am not able to view any of the values that are revealed by the logging statements. When I expand the CBPeripheral (i.e. click on the triangle next to it) I see that it is a CBPeer. When I expand the CBPeer I see that it is an NSObject. But, no variables or properties are revealed.
Does anyone have an explanation for this?
Cheers, Robert
I have an iPhone app that performs some computations. It works well. Now I'd like to create a WatchKit extension and target in order to control the start of the computations and display the results once the computations are finished as well as update the progress (e.g. percentage completed when Watch app is displayed, and send a notification from the iPhone app to the iWatch when the progress reaches a significant percentage mark).
I have found some tutorials that explain to use NSUserDefaults and initWithSuitName providing an app group and then add the data object to synchronise. I could use KVO to display a percentage label on the Watch.
As I am exploring the possible architectures here, are you aware of some alternative methods to achieve this? Is using app group the method that Apple recommends?
You can use open app to launch your computation. then you can send information with handoff.
You can follow this steps
After setting Watch kit session and creating data dictionary you can use send message with this
[[WCSession defaultSession] sendMessage:<Your Dictionary> replyHandler:^(NSDictionary<NSString *,id> * _Nonnull replyMessage) {
//You task on completion
} errorHandler:^(NSError * _Nonnull error) {
if (error)
{
//Handle the error
}
}];
at watch extension side
You can set delegate method
- (void)session:(WCSession *)session didReceiveMessage:(NSDictionary<NSString *, id> *)message replyHandler:(void(^)(NSDictionary<NSString *, id> *replyMessage))replyHandler
{
//Handle the received data
}
And you are done
App groups no longer work above watchOS 1. You need to use WatchConnectivity framework. Once you get the values in watch you can use Reactive or Rx to update the values instead of KVO.
Helpful Links:
https://developer.apple.com/documentation/watchconnectivity
https://kristina.io/watchos-2-how-to-communicate-between-devices-using-watch-connectivity/
https://www.natashatherobot.com/watchconnectivity-application-context/
When trying to stream audio/video on a chromecast device in 50% of cases I get mediaControlChannel:requestDidFailWithID:error: method called about 100 times for the same BEChromeCastMediaItem before it actually starts streaming just fine.
Error Domain=com.google.GCKError Code=4 "The operation couldn’t be completed. (com.google.GCKError error 4.)
(Actually it looks like the whole time I see a "blue progress line" in TV I keep receiving callbacks with this error in the client)
What should we do in such cases? Normally when you get notified about an error, you should handle it (i.e. let user know that something failed) and it's up to you to decide if you want to retry or not, but it looks like chrome cast decides it for you and retries automatically until it succeeds. So what is expected of the iOS client? Should we just ignore these calls?
Update: Error codes seem to change (I also got 1, 93) but they are a always the same for one media item. Anybody knows where to look up error codes? Class chrome.cast.Error does not have any info on this.
There are some descriptions here:
https://developers.google.com/cast/docs/reference/ios/g_c_k_error_8h#aea7a716be62f301015e255e1ba63a9cc
Error code 4 you mentioned looks like it means that an invalid request was made.
If you happen to be programming for iOS, in the GCKError.h file, I found there are some additional error codes:
typedef NS_ENUM(NSInteger, GCKErrorCode) {
/**
* Error code indicating a network I/O error.
*/
GCKErrorCodeNetworkError = 1,
/**
* Error code indicating that an operation has timed out.
*/
GCKErrorCodeTimeout = 2,
/**
* Error code indicating an authentication error.
*/
GCKErrorCodeDeviceAuthenticationFailure = 3,
/**
* Error code indicating that an invalid request was made.
*/
GCKErrorCodeInvalidRequest = 4,
/**
* Error code indicating that an in-progress request has been cancelled, most likely because
* another action has preempted it.
*/
GCKErrorCodeCancelled = 5,
/**
* Error code indicating that the request was disallowed and could not be completed.
*/
GCKErrorCodeNotAllowed = 6,
/**
* Error code indicating that a requested application could not be found.
*/
GCKErrorCodeApplicationNotFound = 7,
/**
* Error code indicating that a requested application is not currently running.
*/
GCKErrorCodeApplicationNotRunning = 8,
/**
* Error code indicating the app entered the background.
*/
GCKErrorCodeAppDidEnterBackground = 91,
/**
* Error code indicating a disconnection occurred during the request.
*/
GCKErrorCodeDisconnected = 92,
/**
* Error code indicating that a request could not be made because the same type of request is
* still in process.
*/
GCKErrorCodeDuplicateRequest = 93,
/**
* Error code indicating that a media load failed on the receiver side.
*/
GCKErrorCodeMediaLoadFailed = 94,
/**
* Error code indicating that a media media command failed because of the media player state.
*/
GCKErrorCodeInvalidMediaPlayerState = 95,
/**
* Error code indicating that the application session ID was not valid.
*/
GCKErrorCodeInvalidApplicationSessionID = 96,
/**
* Error code indicating that an unknown, unexpected error has occurred.
*/
GCKErrorCodeUnknown = 99,
};
In my application I connect to a server using
- (void)connectToServerUsingCFStream:(NSString *) urlStr portNo: (uint) portNo
This function is called by another method
- (void)connectToServer:(NSString *)serverName onPort:(int)portNo
{
[self connectToServerUsingCFStream:serverName portNo:portNo];
while (!((iStream.streamStatus == 2) || (oStream.streamStatus == 2))) {
continue;
}
NSLog(#"Streams connected");
[self sendLoginRequest];
}
Now I want to know wether there is an easy possibility to check if my connection request is timed out (maybe with a certain time value?). Is there a way to handle this in my while loop or should I use something different?
Thanks in advance,
Bautzi
I have no idea how you exactly implement the connection, but here I have some connection codes from the XMPPFramework , as the code comments:
/**
* XMPPReconnect handles automatically reconnecting to the xmpp server due to accidental disconnections.
* That is, a disconnection that is not the result of calling disconnect on the xmpp stream.
*
* Accidental disconnections may happen for a variety of reasons.
* The most common are general connectivity issues such as disconnection from a WiFi access point.
*
* However, there are several of issues that occasionaly occur.
* There are some routers on the market that disconnect TCP streams after a period of inactivity.
* In addition to this, there have been iPhone revisions where the OS networking stack would pull the same crap.
* These issue have been largely overcome due to the keepalive implementation in XMPPStream.
*
* Regardless of how the disconnect happens, the XMPPReconnect class can help to automatically re-establish
* the xmpp stream so as to have minimum impact on the user (and hopefully they don't even notice).
*
* Once a stream has been opened and authenticated, this class will detect any accidental disconnections.
* If one occurs, an attempt will be made to automatically reconnect after a short delay.
* This delay is configurable via the reconnectDelay property.
* At the same time the class will begin monitoring the network for reachability changes.
* When the reachability of the xmpp host has changed, a reconnect may be tried again.
* In addition to all this, a timer may optionally be used to attempt a reconnect periodically.
* The timer is started if the initial reconnect fails.
* This reconnect timer is fully configurable (may be enabled/disabled, and it's timeout may be changed).
*
* In all cases, prior to attempting a reconnect,
* this class will invoke the shouldAttemptAutoReconnect delegate method.
* The delegate may use this opportunity to optionally decline the auto reconnect attempt.
*
* Auto reconnect may be disabled at any time via the autoReconnect property.
*
* Note that auto reconnect will only occur for a stream that has been opened and authenticated.
* So it will do nothing, for example, if there is no internet connectivity when your application
* first launches, and the xmpp stream is unable to connect to the host.
* In cases such as this it may be desireable to start monitoring the network for reachability changes.
* This way when internet connectivity is restored, one can immediately connect the xmpp stream.
* This is possible via the manualStart method,
* which will trigger the class into action just as if an accidental disconnect occurred.
**/
I don't know if this XMPPReconect class meets your demand.