I am using SCNetworkReachabilityCreateWithName & SCNetworkReachabilityGetFlags to test for network availability in my iOS device. When I run the app in the Simulator, or run it on the device, but attached to the debugger, everything's completely cool. However, when I run the app on the test device but detached from the debugger, I get a crash. [EDIT: just realized I didn't indicate where: in the call to SCNetworkReachabilityGetFlags] The odd thing is, it doesn't happen the first time I run the check. It happens on the second check. And using a try/catch does absolutely nothing.
The crash is immediate. There is no delay while the async polling occurs and the app just times out. It's immediate.
This is completely effed. I don't understand at all why this would be occurring. I am getting ready to go to a conference to exhibit the app and its accompanying web app. I was planning on walking the floor to show it off. But now I'm basically restricted to keeping my iPhone/iPod tethered to my computer in the booth.
Any ideas? Any work-arounds that don't keep me attached to the computer? And any long-term solutions that solve this? I use this method to check for network availability every time I perform any network activity. I am syncing my data to the Cloud, and run this check each time a sync occurs. I feel this is necessary to keep the user informed if there's a sudden break in the network connection.
Help????
Here's the code snippet.
+ (BOOL) networkConnected {
SCNetworkReachabilityFlags flags = 0;
SCNetworkReachabilityRef netReachability;
BOOL retrievedFlags = NO;
BOOL reachable = NO;
netReachability = SCNetworkReachabilityCreateWithName(CFAllocatorGetDefault(), [EXTERNAL_HOST UTF8String]);
#try {
if(netReachability) {
retrievedFlags = SCNetworkReachabilityGetFlags(netReachability, &flags);
CFRelease(netReachability);
}
if(!retrievedFlags || !flags)
reachable = NO;
else
reachable = YES;
} #catch (NSException *ex) {
reachable = NO;
} #finally {
return reachable;
}
}
Related
One of my app's feature is detect keyDown event and do someting for some specific keys.
So, I use CGEventTapCreate to solve my problem and my code is like this:
if let tap = CGEventTapCreate(.CGHIDEventTap, .HeadInsertEventTap, .Default, CGEventMask(1 << CGEventType.KeyDown.rawValue), callBack, nil) {
let runLoopSource = CFMachPortCreateRunLoopSource(kCFAllocatorDefault, tap, 0)
CFRunLoopAddSource(CFRunLoopGetCurrent(), runLoopSource, kCFRunLoopDefaultMode)
CGEventTapEnable(tap, true)
CFRunLoopRun()
}
Also, I deal with the process trust like:
let options = [kAXTrustedCheckOptionPrompt.takeUnretainedValue() as NSString: false]
let processTrusted = AXIsProcessTrustedWithOptions(options)
if processTrusted {
// do CGEventTapCreate()
} else {
// check again 1s later
performSelector("checkMethod", withObject: nil, afterDelay: 1)
}
It will be called per second until processTrusted is true.
Then strange thing happened:
When I run the app in Xcode and add trust Xcode in Privacy_Accessibility it all work fine. But When I run it with archive the app and Export as a Mac Application to my desktop, CGEventTapCreate() just not work.
After that I found this post Enable access for assistive devices programmatically on 10.9, it notice me that I need to relaunch the app after AXIsTrustedProcess().
You know, it's not a good idea to tell users to relaunch the app themselves. So I try to relaunch it programmatically and add these code into if processTrusted {}:
NSWorkspace.sharedWorkspace().launchApplication(NSProcessInfo.processInfo().processName)
NSApplication.sharedApplication().terminate(nil)
In other words, when I tick the app in Privacy_Accessibility, it will relaunch automatically.
Here comes another strange thing:
The app truly terminate and launch automatically. But when it finish relaunch, the app's Privacy_Accessibility is not tick.
It's really confuse me a lot, I hope someone will tell me the right way to deal with process trust and execute CGEventTapCreate() correctly.
Thanks!
Polling AXIsProcessTrusted and automatically relaunching is a nice touch. Users are often confused by this process, so anything that helps make it easier for them is good.
I'm pretty sure that an application that you launch inherits your current permissions, but don't have references handy to back that up. I have found that when debugging an application with CGEventTaps, I also have to give Xcode the Accessibility permissions that my app requests/requires.
But you can work around this by getting the system to launch your app for you. Try:
[NSTask launchedTaskWithLaunchPath:#"/bin/sh" arguments:[NSArray arrayWithObjects:#"-c", [NSString stringWithFormat:#"sleep 3 ; /usr/bin/open '%#'", [[NSBundle mainBundle] bundlePath]], nil]];
I'm having trouble with staying connected using the Multipeer Connectivity Framework in iOs7. Currently my app is programmatically handling the browsing and advertising using MCNearbyServiceAdvertiser and MCNearbyServiceBrowser. I have an alert view that asks the user if he is a browser or an advertiser. On the return from that view I instantiate either an MCNearbyServiceAdvertiser or Browser accordingly.
#pragma - Alert Delegate
-(void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex
{
if (buttonIndex == 0)
{
_browser = [[MCNearbyServiceBrowser alloc]initWithPeer:_peerID serviceType:#"Context-xl"];
[_browser setDelegate:self];
[self.detailViewController setRemote:YES];
[_browser startBrowsingForPeers];
} else
{
_advertiser = [[MCNearbyServiceAdvertiser alloc]initWithPeer:_peerID discoveryInfo:nil serviceType:#"Context-xl"];
[_advertiser setDelegate:self];
[self.detailViewController setRemote:NO];
[_advertiser startAdvertisingPeer];
}
[self.detailViewController configureView];
}
My session delegate method peer:...DidChangeState... is getting called twice, once for the connect and again for the disconnect. I'm not stopping the advertiser or browser at all after the session is started. Should I stop browsing/advertising?
EDIT Used a support ticket with Apple and they confirmed that calling sendData with too much data or too often can cause disconnects.
EDIT My hypothesis is that Apple has a thread or queue that is polling to check if peers are connected. If this thread / queue stalls (i.e. a breakpoint is hit or the app pegs the CPU or does something that takes a while on the main thread) it appears that this causes a disconnect.
Creating my session without encryption seems to have helped performance and with the disconnects, although they still happen.
MCPeerID* peerId = [[MCPeerID alloc] initWithDisplayName:self.displayName];
self.peer = [[MultiPeerPeer alloc] initWithDisplayName:peerId.displayName andPeer:peerId];
self.session = [[MCSession alloc] initWithPeer:peerId securityIdentity:nil encryptionPreference:MCEncryptionNone];
In addition, I have found calling sendData too often (more than 30-60 times a second) can cause the framework to get in a bad state and cause freezes and disconnects.
Im using MCNearbyServiceBrowser and MCNearbyServiceAdvertiser to join two peers to a MCSession. I am able to send data between them using MCSession's sendData method. All seems to be working as expected until I randomly (and not due to any event I control) receive a MCSessionStateNotConnected via the session's MCSessionDelegate didChangeState handler. Additionally, the MCSession's connectedPeers array no longer has my peers.
Two questions: Why? and How do i keep the MCSession from disconnecting?
This is a bug, which I just reported to Apple. The docs claim the didReceiveCertificate callback is optional, but it's not. Add this method to your MCSessionDelegate:
- (void) session:(MCSession *)session didReceiveCertificate:(NSArray *)certificate fromPeer:(MCPeerID *)peerID certificateHandler:(void (^)(BOOL accept))certificateHandler
{
certificateHandler(YES);
}
The random disconnects should cease.
UPDATE After using a support ticket to Apple, they confirmed that calling sendData too often and with too much data can cause disconnects.
I have had disconnects when hitting break points and when backgrounding. Since the break points won't happen on the app store, you need to handle the backgrounding case by beginning a background task when your app is about to enter the background. Then end this task when your app comes back to the foreground. On iOS 7 this gives you about 3 background minutes which is better than nothing.
An additional strategy would be to schedule a local notification for maybe 15 seconds before your background time expires by using [[UIApplication sharedApplication] backgroundTimeRemaining], that way you can bring the user back into the app before it suspends and the multi peer framework has to be shutdown. Perhaps the local notification would warn them that their session will expire in 10 seconds or something...
If the background task expires and the app is still in the background, you have to tear down everything related to multi-peer connectivity, otherwise you will get crashes.
- (void) createExpireNotification
{
[self killExpireNotification];
if (self.connectedPeerCount != 0) // if peers connected, setup kill switch
{
NSTimeInterval gracePeriod = 20.0f;
// create notification that will get the user back into the app when the background process time is about to expire
NSTimeInterval msgTime = UIApplication.sharedApplication.backgroundTimeRemaining - gracePeriod;
UILocalNotification* n = [[UILocalNotification alloc] init];
self.expireNotification = n;
self.expireNotification.fireDate = [NSDate dateWithTimeIntervalSinceNow:msgTime];
self.expireNotification.alertBody = TR(#"Text_MultiPeerIsAboutToExpire");
self.expireNotification.soundName = UILocalNotificationDefaultSoundName;
self.expireNotification.applicationIconBadgeNumber = 1;
[UIApplication.sharedApplication scheduleLocalNotification:self.expireNotification];
}
}
- (void) killExpireNotification
{
if (self.expireNotification != nil)
{
[UIApplication.sharedApplication cancelLocalNotification:self.expireNotification];
self.expireNotification = nil;
}
}
- (void) applicationWillEnterBackground
{
self.taskId = [[UIApplication sharedApplication] beginBackgroundTaskWithExpirationHandler:^
{
[self shutdownMultiPeerStuff];
[[UIApplication sharedApplication] endBackgroundTask:self.taskId];
self.taskId = UIBackgroundTaskInvalid;
}];
[self createExpireNotification];
}
- (void) applicationWillEnterForeground
{
[self killExpireNotification];
if (self.taskId != UIBackgroundTaskInvalid)
{
[[UIApplication sharedApplication] endBackgroundTask:self.taskId];
self.taskId = UIBackgroundTaskInvalid;
}
}
- (void) applicationWillTerminate
{
[self killExpireNotification];
[self stop]; // shutdown multi-peer
}
You'll also want this handler in your MCSession delegate due to Apple bug:
- (void) session:(MCSession*)session didReceiveCertificate:(NSArray*)certificate fromPeer:(MCPeerID*)peerID certificateHandler:(void (^)(BOOL accept))certificateHandler
{
if (certificateHandler != nil) { certificateHandler(YES); }
}
There are many causes of this, and the two answers thus far are both correct in my experience. Another which you'll find in other similar questions is this: Only one peer can accept another's invitation.
So, to clarify, if you set up an app where all devices are both advertisers and browsers, any devices can freely invite any others found to join a session. However, between any two given devices, only one device can actually accept the invitation and connect to the other device. If both devices accept each others' invitations they will disconnect within a minute or less.
Note that this limitation does not prevent the desired behavior because - unlike what my intuition stated before I built my multipeer implementation - when one device accepts an invitation and connects to another device they both become connected and receive connection delegate methods and can send each other messages.
Therefore, if you are connecting devices which both browse and advertise, send invitations freely but only accept one of a pair.
The problem of only accepting one of two invitations can be solved a myriad of ways. To begin, understand that you can pass any arbitrary object or dictionary (archived as data) as the context argument in an invitation. Therefore, both devices have access to any arbitrary information about the other (and of course itself). So, you could use at least these strategies:
simply compare: the display name of the peerID. But there's no guarantee these won't be equal.
store the date your multipeer controller was initialized and use that for comparison
give each peer a UUID and send this for comparison (my technique, in which each device - indeed each user of the app on a device - has a persistent UUID it employs).
etc - any object which supports both NSCoding and compare: will do fine.
I've been having similar problems. It seems though that if I have run my app on one iOS device, and connected to another, then quit and relaunch (say when I rerun from Xcode), then I am in a situation where I get a Connected message and then a Not Connected message a little later. This was throwing me off. But looking more carefully, I can see that the Not Connected message is actually meant for a different peerId than the one that has connected.
I think the problem here is that most samples I've seen just care about the displayName of the peerID, and neglect the fact that you can get multiple peerIDs for the same device/displayName.
I am now checking the displayName first and then verifying that the peerID is the same, by doing a compare of the pointers.
- (void)session:(MCSession *)session peer:(MCPeerID *)peerID didChangeState:(MCSessionState)state {
MyPlayer *player = _players[peerID.displayName];
if ((state == MCSessionStateNotConnected) &&
(peerID != player.peerID)) {
NSLog(#"remnant connection drop");
return; // note that I don't care if player is nil, since I don't want to
// add a dictionary object for a Not Connecting peer.
}
if (player == nil) {
player = [MyPlayer init];
player.peerID = peerID;
_players[peerID.displayName] = player;
}
player.state = state;
...
I was disconnecting immediately after I accepted the connection request. Observing the state, I saw it change from MCSessionStateConnected to MCSessionStateNotConnected.
I am creating my sessions with:
[[MCSession alloc] initWithPeer:peerID]
NOT the instantiation method dealing with security certificates:
- (instancetype)initWithPeer:(MCPeerID *)myPeerID securityIdentity:(NSArray *)identity encryptionPreference:(MCEncryptionPreference)encryptionPreference
Based on Andrew's tip above, I added the delegate method
- (void) session:(MCSession *)session didReceiveCertificate:(NSArray *)certificate fromPeer:(MCPeerID *)peerID certificateHandler:(void (^)(BOOL accept))certificateHandler {
certificateHandler(YES);
}
and the disconnects stopped.
I use the SocketRocket library for Objective-C to connect to a websocket:
-(void)open {
if( self.webSocket ) {
[self.webSocket close];
self.webSocket.delegate = nil;
}
self.webSocket = [[SRWebSocket alloc] initWithURLRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:#"ws://192.168.0.254:5864"] cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:20]];
self.webSocket.delegate = self;
[self.webSocket open];
}
Opening the connection works totally fine. The delegate is called after the connection was established.
-(void)webSocketDidOpen:(SRWebSocket *)webSocket {
NSLog(#"WebSocket is open");
}
But when I want to close the connection, nothing happens.
-(void)close {
if( !self.webSocket )
return;
[self.webSocket close];
self.webSocket.delegate = nil;
}
The delegate for successfully closing the connection is not called. Can anyone tell me why this happens?
Thank you for reading my question.
I figured out that the delegate is never called, because the websocket is never really closed. The closing of the websocket in the SRWebSocket happens in the method pumpWriting like this:
if (_closeWhenFinishedWriting &&
_outputBuffer.length - _outputBufferOffset == 0 &&
(_inputStream.streamStatus != NSStreamStatusNotOpen &&
_inputStream.streamStatus != NSStreamStatusClosed) &&
!_sentClose) {
_sentClose = YES;
[_outputStream close];
[_inputStream close];
if (!_failed) {
dispatch_async(_callbackQueue, ^{
if ([self.delegate respondsToSelector:#selector(webSocket:didCloseWithCode:reason:wasClean:)]) {
[self.delegate webSocket:self didCloseWithCode:_closeCode reason:_closeReason wasClean:YES];
}
});
}
_selfRetain = nil;
NSLog(#" Is really closed and released ");
}
else {
NSLog(#" Is NOT closed and released ");
}
All streams and an object to retain the websocket are closed or deleted there. As long as they are still open, the socket won´t be closed appropriately. But the closing never happened in my program, because when I tried to close the websocket, _closeWhenFinishedWriting was always NO.
This boolean is only set once in the disconnect method.
- (void)_disconnect;
{
assert(dispatch_get_current_queue() == _workQueue);
SRFastLog(#"Trying to disconnect");
_closeWhenFinishedWriting = YES;
[self _pumpWriting];
}
But when calling the closeWithCode method in SRWebSocket, disconnect is only called in one case and that is, if the websocket is in the connecting state.
BOOL wasConnecting = self.readyState == SR_CONNECTING;
SRFastLog(#"Closing with code %d reason %#", code, reason);
dispatch_async(_workQueue, ^{
if (wasConnecting) {
[self _disconnect];
return;
}
This means, if the socket is in another state, the websocket will never really close. One workaround is to always call the disconnect method. At least it worked for me and everything seems to be alright.
If anyone has an idea, why SRWebSocket is implemented like that, please leave a comment for this answer and help me out.
I think this is a bug.
When calling close, the server echo's back the 'close' message.
It is received by SRWebSocket, however the _selfRetain is never set to nil, and the socket remains open (the streams are not closed) and we have a memory leak.
I have checked and observed this in the test chat app as well.
I made the following change:
-(BOOL)_innerPumpScanner {
BOOL didWork = NO;
if (self.readyState >= SR_CLOSING) {
[self _disconnect]; // <--- Added call to disconnect which releases _selfRetain
return didWork;
}
Now the socket closes, the instance is released, and the memory leak is gone.
The only thing that I am not sure of is if the delegate should be called when closing in this way. Will look into this.
Once an endpoint has both sent and received a Close control frame, that endpoint SHOULD Close the WebSocket Connection as defined in Section 7.1.1. (RFC 6455 7.1.2)
The SRWebSocket instance doesn't _disconnect here because that would close the TCP connection to the server before the client has received a Close control frame in response. In fact, _disconnecting here will tear down the TCP socket before the client can even send its own Close frame to the server, because _disconnect ultimately calls _pumpWriting before closeWithCode: can. The server will probably respond gracefully enough, but it's nonconforming, and you won't be able to send situation-unique close codes while things are set up this way.
This is properly dealt with in handleCloseWithData:
if (self.readyState == SR_OPEN) {
[self closeWithCode:1000 reason:nil];
}
dispatch_async(_workQueue, ^{
[self _disconnect];
});
This block handles Close requests initiated by both the client and the server. If the server sends the first Close frame, the method runs as per the sequence you laid out, ultimately ending up in _pumpWriting via closeWithCode:, where the client will respond with its own Close frame. It then goes on to tear down the connection with that _disconnect.
When the client sends the frame first, closeWithCode: runs once without closing the TCP connection because _closeWhenFinishedWriting is still false. This allows the server time to respond with its own Close frame, which would normally result in running closeWithCode: again, but for the following block at the top of that method:
if (self.readyState == SR_CLOSING || self.readyState == SR_CLOSED) {
return;
}
Because the readyState is changed on the first iteration of closeWithCode:, this time it simply won't run.
emp's bug fix is necessary to make this work as intended, however: otherwise the Close frame from the server doesn't do anything. The connection will still end, but dirtily, because the server (having both sent and received its frames) will break down the socket on its end, and the client will respond with an NSStreamEventEndEncountered:, which is normally reserved for stream errors caused by sudden losses of connectivity. A better approach would be to determine why the frame never gets out of _innerPumpScanner to handleCloseWIthData:. Another issue to keep in mind is that by default, close just calls closeWithCode: with an RFC-nonconforming code of -1. This threw errors on my server until I changed it to send one of the accepted values.
All that said: your delegate method doesn't work because you're unsetting the delegate right after you call close. Everything in close is inside an async block; there won't be a delegate left to call by the time you invoke didCloseWithCode: regardless of what else you do here.
I have following concern..
My application downloads 6 MB of data when it is started for the first time.
During that process UIView with information about ongoing download is presented, and generally there is no interaction with user.
Because of that I do all downloading of data in main UI Thread, using dispatch_async, but now I don't know if this is the best solution and what will Apple say when I will submit my application.
Could you please guide my if this is Ok or not ?
Update
Dispatch code
//Called at the end of [UIViewController viewDidLoad]
-(void)splashScreenAppeared
{
myTabBarController_.loadingLabel.text = NSLocalizedString(#"Checking for updates",#"launch progress");
dispatch_queue_t d_queue = dispatch_get_main_queue();
[self launchActionCheckIfDataIsStored:d_queue];
}
//...
-(void)launchActionCheckIfDataIsStored:(dispatch_queue_t)queue
{
dispatch_async(queue, ^ {
//If there is no data stored in core data then download xml data files and images
if (![self isAnyDataStoredInCoreData]) {
launchNoDataStored_ = YES;
[self launchDownloadData:queue];
} else {
launchNoDataStored_ = NO;
[self launchCheckNewVersion:queue];
}
});
}
//...
-(void)launchDownloadData:(dispatch_queue_t)queue
{
myTabBarController_.loadingLabel.text = NSLocalizedString(#"Downloading catalog data",#"launch progress");
dispatch_async(queue, ^ {
[self loadMenuData];
if (seriousError_) {
[self launchSeriousError:queue];
return;
}
myTabBarController_.loadingLabel.text = NSLocalizedString(#"Downloading products details",#"launch progress");
dispatch_async(queue, ^ {
[self loadProductsData];
if (seriousError_) {
[self launchSeriousError:queue];
return;
}
//...
//And so on with other parts of download
}
Just to set the background, I have written & submitted 2 successful apps to the App Store, so you know that I am not hypothesizing.
Coming back, you can push the download to a background thread and update the progress in the form of a slider (for the benefit of the user). But if in this scenario the user does not get to do anything anyway then there is no point.
Plus I dont think Apple would reject your app just 'coz of this. One of the main things they check is if you are using any Private API's or something more basic like app crashes. So go ahead and submit for APP store review...
Now I know that network communication in UI Thread can be a good reason to reject your application by Apple.
Consider the following scenario:
Application is for iPhone.
There is no interaction with user.
Application is run on iPad!!
Even though there is no interaction with user, application does not react when user presses 2x button on iPad.
So network communication in UI thread works, but if application is not for iPad only, then application will be rejected in Apple review process.