I have an NSMenu that I want to update with items pushed to my app through pusherapp and received using the libPusher client library. But events seem not to be received in NSEventTrackingRunLoopMode.
Given the following snippet:
[channel bindToEventNamed:#"my_event" handleWithBlock:^(PTPusherEvent *event) {
NSLog(#"event received");
}];
And I wait for a push to occur while I maintain the menu open, I expect to receive the event immediately but I only receive it when I close the menu.
I also tried passing the main queue to bindToEventNamed:handleWithBlock:queue: (using dispatch_get_main_queue();), to no avail.
So I'm left wondering whether I'm doing something wrong or there's a bug in libPusher?
I'm the author of libPusher. The reason you are seeing this problem is because the underlying WebSocket library used by libPusher, SocketRocket only works in the default run loop mode.
The good news is that this has been fixed in the latest HEAD of SocketRocket. I have tested libPusher agains the latest SocketRocket and can confirm that it fixes this issue and I intend to roll these changes in to the next release.
Now, I've just checked the outstanding Github issue and realised that you were the original reporter of this bug, so you probably know all this already but I'm going to post this answer anyway for posterity.
libPusher issue
SocketRocket issue
Related
I am trying to simply load in a picture from firebase storage into my IOS app, but my completion block is not being called.
I use a TableViewController initially which loads plenty of pictures just fine. When I click on an item in the tableview it presents a simple view controller modally. I use the same code that successfully loads pictures in the TableViewController. In this modally presented view controller, my FirebaseStorage completion blocks do not execute. When I exit this view controller, the TableViewController can still load load pictures as necessary as I request.
I have enabled logging with -FIRAnalyticsDebugEnabled
and still do not receive any errors in my log.
I have allowed all read and writes temporarily in my rules for FirebaseStorage.
I have seen this question iOS setValue withCompletionBlock not called which states in the comments that a specific version of firebase had some issue with FirebaseDatabase blocking some other completion blocks.
The documentation said "Fixed a race condition where performing a transaction or adding an event observer immediately after connecting to the Firebase Realtime Database service could cause completion blocks for other operations to not be executed." from https://firebase.google.com/support/release-notes/ios#3.6.0
In the above question the asker fixed the problem by upgrading to Firebase 3.7.1, I am using 5.0.1
Here are the versions I am using
Using Firebase (5.0.1)
Using FirebaseAnalytics (5.0.0)
Using FirebaseAuth (5.0.0)
Using FirebaseCore (5.0.1)
Using FirebaseDatabase (5.0.0)
Using FirebaseInstanceID (3.0.0)
Using FirebaseStorage (3.0.0)
Using GTMSessionFetcher (1.1.15)
Using GoogleToolboxForMac (2.1.4)
Using leveldb-library (1.20)
Using nanopb (0.3.8)
Generating Pods project
I have logged all along my code to find that my code is being called, but the completion block is never executed. I am using the proper children ids, so I know that the storage reference does exist. I also know it is not a connection problem because the other pictures load fine just seconds before.
- (void)loadPicture {
NSLog(#"Attempting to load picture");
FIRStorageReference *ref = [[self.storageRef child:self.detailItem.faction] child:[self.detailItem firebaseEntry]];
[ref dataWithMaxSize:1024*1024 completion:^(NSData * _Nullable data, NSError * _Nullable error) {
NSLog(#"Got a result!");
}];
I am completely lost on what steps to take next. Has anyone experienced something similar or have any advice?
I appreciate any feedback that might help! Thanks!
Import this first
#import "UIImageView+FirebaseStorage.h"
and then for load image From reference use this
FIRStorageReference *gsReference = [[self.storageRef child:self.detailItem.faction] child:[self.detailItem firebaseEntry]];
[yourImage sd_setImageWithStorageReference:gsReference placeholderImage:nil];
I have solved the problem by creating a new ViewController to do the same action from scratch. Unfortunately I don't know what the original problem was or how to reproduce it. My original ViewController was about as simple as possible. The problem seemed like a strange glitch/flaw in the API, xcode, or emulator since no errors were present and it fixed itself in the new ViewController using the same exact code.
Everything else I saw online pointed to a issue involving Firebase 3.6.0 and below. Make sure you are using a recent Firebase version and then recreate the same ViewController and your problem will likely be fixed.
Im developing an app on OSX that uses CoreBluetooth. I have encountered a problem on OSX Mavericks that i cant seem to get around. (All of this works perfectly on OSX 10.8).
First lets go through the flow of the application
This flow is fairly established and has been used used successfully in iOS apps and works on 10.8. So on Mavericks, the first run completes successfully. It scans, finds and connects to the device correctly. It also saves out the UUID of the device to a .plist file along with other properties.
Upon relaunch of the app, it attempts to go down the left hand column of the flow which is where the problems seem to occur.
So the first issue i noticed was that my call to self.central retrievePeripherals: never calls my delegate callback of -(void)centralManager:(CBCentralManager *)central didRetrievePeripherals:(NSArray *)peripherals
. It simply never gets the callback on Mavericks.
My next thought was "oh they have a new API for fetching peripherals on Mavericks and the old one is deprecated, lets try that". So i added in my calls to NSArray *identifiers = [self.central retrievePeripheralsWithIdentifiers:#[uuid]]; and i get caught in a sempahore wait trap. Upon closer debugging of what was going on it turned out that sometimes my CBCentralManager gets into a state of CBCentralManagerStateUnknown and never updates the state to a newer one.
The next thing i tried was to fire up Activity Monitor and kill the blued process. Finally, my delegate callback for -(void)centralManagerDidUpdateState:(CBCentralManager *)central was called with the correct CBCentralManagerStatePoweredOn so i performed retrievePeripheralsWithIdentifiers again and received an empty array.
So all of these problems seem to be linked to blued in some way. Does anyone have more insight into this process to elude as to what is going on?
My main question is. Why does this work the first time through the app but not the second? Upon quitting the app after the initial scan and connection it seems i can no longer use the system bluetooth for anything without resetting blued (which even then doesn't retrieve peripherals). Is there some sort of shutdown sequence i need to do on the CBCentralManager to keep blued from going AWOL?
Any advice would be greatly apprecciated!
While this is obviously a very old thread, I stumbled upon the same issue today and decided to post a fix for posterity.
I was trying to hack together a simple app based on the HeartRateMonitor example provided by Apple. Unfortunately, it does not work on 10.9 if autoConnect is set to TRUE, what's worse, it brings blued down on its knees.
In 10.9, a call to the (deprecated) retrievePeripherals freezes blued without a chance to restore. CBCentralManager goes into CBCentralManagerStateUnknown, Bluetooth cannot be turned on/off using OS functions etc. The only solution that I found is to killall -9 blued.
However, the synchronous retrievePeripheralsWithIdentifiers worked well for me (on 10.9.4). Here's the relevant excerpt from the modified HeartRateMonitor code:
/* Retreive already known devices */
if(autoConnect)
{
NSArray *peripherals = [manager retrievePeripheralsWithIdentifiers:[NSArray arrayWithObject:(id)aPeripheral.identifier]];
NSLog(#"Retrieved peripheral: %lu - %#", [peripherals count], peripherals);
[self stopScan];
/* If there are any known devices, automatically connect to it.*/
if([peripherals count] >=1)
{
[indicatorButton setHidden:FALSE];
[progressIndicator setHidden:FALSE];
[progressIndicator startAnimation:self];
peripheral = [peripherals objectAtIndex:0];
[peripheral retain];
[connectButton setTitle:#"Cancel"];
[manager connectPeripheral:peripheral options:[NSDictionary dictionaryWithObject:[NSNumber numberWithBool:YES] forKey:CBConnectPeripheralOptionNotifyOnDisconnectionKey]];
}
}
I'm running the proj.mac version of their sample (that comes with the cocos2d-x files).
I saw that the Mac version has EAGLView.mm which has:
- (void)mouseMoved:(NSEvent *)theEvent
{
DISPATCH_EVENT(theEvent, _cmd);
}
I made sure to enable the mouse moved events in the AppController.mm:
[window setAcceptsMouseMovedEvents:YES];
I can see that it's going there, but what I'm trying to find out is how to make my custom CCLayer "register/listen" to the mouse and keyboard events.
The cocos2d-x forums mentioned that they have a KeyboardTest in their TestCase folder, but I was only able to find a KeypadTest which doesn't do much. Also some examples mentioned CCKeyboardDispatcher, which is nowhere to be found.
Thanks in advance!
I think they may be talking about this patch: https://github.com/cocos2d/cocos2d-x/pull/1849/commits
It's not yet in the mainline. If you do apply it directly you'll hit a few patch rejections and you'll need to manually add the new CCKeyboard* files to your XCode project (Build Phases).
I just pushed up the changes I made to get it to compile (and get KeyboardTest to run in the samples dir):
https://github.com/therealdpk/cocos2d-x/
however, most of the work was not authored by me. I don't know if I'll be able to keep this maintained, either, so use it as a starting point at best.
I have console applicaiotn that currently uses CAsyncSocket.
I need to implement SSL so after some searching I found this project: http://www.codeproject.com/Articles/3915/CAsyncSslSocketLayer-SSL-layer-class-for-CAsyncSoc
For some reason same simple code that works fine on GUI code does not work in console app.
Has anyone exp. with CAsyncSslSocketLayer ?
Thanks.
CAsyncSocketEx uses a window as a sort of cheap thread to handle the event notifications that come from select(). Unfortunately, if you don't have a message loop, then the window which it creates will not receive these events.
http://support.microsoft.com/kb/90975
This article explains that a call to CreateWindow() needs to be called from a thread which has a message loop. And if you don't, then anything sent via PostMessage() won't get there.
I've recently started to tinker with this -- I want to remove the annoying hidden window and replace it with a normal thread. Their code relies on WSAAsyncSelect() in order to receive socket events... to a window. Yuk!
It's been a while since I had the same problem, but if I remember correctly, to use CAsyncSocket in a console app you need to add something like DECLARE_CONSOLEAPP (first two links shown below) to your console app. This should give your console a message pump to generate the socket notifications (OnReceive, etc.) GUI apps have these pumps but console apps don't, generally. The third (msdn) link below might also apply, it has more info and a different way.
If these still don't work, you should put breakpoints in your socket code and make sure your socket isn't instantiated in a thread or callback other than the main console app (the one that now has the message pump).
I think googling around for 'CAsyncSocket WinApp' or 'CAsyncSocket console app' would show more.
http://www.codeguru.com/cpp/misc/misc/consoleapps/article.php/c243/Console-app-using-MFC.htm
http://troels.knakkergaard.dk/code.htm
http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/a6f1b72a-21d8-4046-a3dc-d7d29ece2ef6
I'm working with a document-based core-data OS X application. The problem I'm having is that whenever I edit any field on the document, after I press tab or click to something else (i.e. I finish editing/change focus), the document is marked as clean and undo is reset. When I try to save the file, however, the resulting document opens without the data I entered. What might be the problem, or, any pointers on where to look to fix this? Here's some stuff I know and things I've already tried:
I know it's not somehow saving because it never stops at the breakpoint in my overridden writeSafelyToURL:(NSURL *)inAbsoluteURL ofType:(NSString *)inTypeName forSaveOperation:(NSSaveOperationType)inSaveOperation error:(NSError **)outError and it also never sends an NSManagedObjectContextDidSaveNotification.
The documents are packaged in an NSFileWrapper directory with the core data store inside (and also some other files). I access the entities through an NSObjectController and a couple NSArrayControllers. It happens with both core data properties and manually registered changes in the rest of the file wrapper.
Update: At the suggestion of Martin, I tried NSUndoManager's notifications, and all I can seem to glean from it is that more than one undo manager is in play. If I add an observer for NSUndoManager, it won't post if I specify an object, and then if I don't, the notification object is not equal to [self undoManager]. I added updateChangeCount to my category on NSPersistentDocument, and it never gets called. setDocumentEdited basically confirmed that something about losing first responder is passing NO into that method. What could be causing this, and how can I fix it?
You could break on the method setDocumentEdited: of NSWindow to see which operation updates the change status.
In addition updateChangeCount: of NSDocument might be a place to take a look at.
NSUndoManager also posts several Notifications which can give additional hints what to look at.
The answer is actually pretty silly considering how long this stumped me. I was working on some objects on load, and I accidentally set [[self undoManager] disableUndoRegistration] at both the points where I should disable and enable. It was a little more than that, though. A related element in Interface Builder needed to be checked Prepares Content. When I had done both those things, the problem vanished.