I have a menu bar app, which out of nowhere (no code changes) stopped working. Oddly the app continues to execute once I select it, or if I use any of the system keys (volume, brightness, iTunes, etc...). My code uses GCD to manage behavior. Is there a way to debug this and see what's going on behind the scenes? My confusion is why using the system keys (which pop up a window to show volume level, brightness level) makes my software continue execution?
DispatchQueue.main.async() { doSomething() }
func doSomething() {
//run a bunch of things in a background process
//so far works ok
let fooFrame = NSMakeRect(0, 0, 100, 100)
print("tag1") //this prints just fine
DispqtchQueue.main.sync() {
print("tag2") //this doesn't print and doesn't execute until I click on the app or use the volume keys.
//run code to update UI works fine once I use volume keys (no idea why)
self.window.frame = fooFrame
}
}
Also I am not getting any messages or exceptions raised. Just the app freezes. I have also noticed that if I have multiple displays and activate a second display, where the menu bar activates, then my process continues again and everything is normal.
Calling AnyQue.sync from the the same queue (AnyQueue) causes a deadlock, as the calling task is waiting for the called one. But the called one will start after the calling one finished.
As written by matt, using async fixes the issue. This code:
func doSomething() {
print("tag1")
DispatchQueue.main.async() {
print("tag2")
}
}
DispatchQueue.main.async() {
doSomething()
}
prints:
tag1
tag2
Figured it out, I had a CFRunLoop running which needed to be stopped and then everything seems to work fine now. Also additionally, the entire process was running as a background dispatch process, that's why using sync worked.
Related
I want to achieve lock mechanism in XF 4.5.0 Shell app.
I have static timer that counts how much seconds passed, and based on some logic present either screen that user was before put the app in behind (user went to instagram, but app is in the background running)
So, my OnResume() method looks like this:
private bool IsUserExists()
{
if (!string.IsNullOrWhiteSpace(GlobalAppSettings.Email) && !string.IsNullOrWhiteSpace(GlobalAppSettings.Password) && !string.IsNullOrWhiteSpace(GlobalAppSettings.Pin))
{
return true;
}
else
{
return false;
}
}
protected override void OnResume()
{
if ((!OnSleepOrPauseTime.HasValue || OnSleepOrPauseTime.Value.AddSeconds(5) <= DateTime.Now)
&&(IsUserExists()))
{
Xamarin.Forms.Device.BeginInvokeOnMainThread(async () =>
{
await Shell.Current.GoToAsync(Routes.LoginPinPage, false);
});
}
}
The problem: user sees for a like half second the screen where he was before, and then it redirects to LoginPinPage.
The happy path: Should be that user doesnt see that flickering page that was before exiting form an app, just immediately lock screen.
Possible solution: That crossed on my mind, before leaving the app to somehow redirect in background app to login pin screen?
PushAsync has 2 overloads - docs
By default the PushAsync method pushes the new page with animation. I think that this is the so-called "flickering" that you are referring to.
You can try to use the second overload and pass false for the animated property and see if it makes any difference.
PushAsync(new LoginPinPage(), false);
If you want to redirect the user on app leave - you can use another of the Application's lifecycle methods - OnSleep and invoke your navigation there. But I suggest to try it without animations first.
Keep in mind that, should you choose to use the OnSleep method, you will also have to push the page without animations. I have just tested pushing with animations and I do indeed see the flickering that you are mentioning. Setting the animated flag to false, removed any flickering for me.
I have a watchface with a companion app for phone. It uses Wearable.DataApi to sync changes between the phone and watch. I have a DataApi.DataListener setup and sync changes made on the watch or phone side. I have no issue with a phone and ONE watch communicating.
The issue is when i have multiple watches using the same watch face if changes on watch or phone side are made quickly it seems to go into a loop and start flashing the changes on all devices. So if im changing the color by tapping watch if I press a few times quickly to do that all devices start cycling through all colors and takes some time before it catches up and stops.
If I change options slowly there is no problem. I put a log in the DataApi listener and I see both uri's making the change but just seems to loop for some reason when changed quickly. Is there anyway to prevent this?
I know this might not seem like a big issue but if a user has 2 watches and accidently changes an option or options quickly it will start with the options and or colors changing. I want to prevent that from happening.
This is how im adding my listener in the onConnected method
Wearable.DataApi.addListener(mGoogleApiClient, dataListener);
And this is my listener method
DataApi.DataListener dataListener = new DataApi.DataListener() {
#Override
public void onDataChanged(DataEventBuffer dataEvents) {
Log.d(TAG, "onDataChanged");
for (DataEvent event : dataEvents) {
Log.d(TAG, "dataEvent.uri: " + event.getDataItem().getUri().toString());
DataMap item = DataMapItem.fromDataItem(event.getDataItem()).getDataMap();
/////other code to set data/////
}
updateCanvas();
}
};
You should be able to avoid this by filtering out dataEvents that originated from the local node (i.e., the device that the code is running on).
Get the local node ID with code like this:
NodeApi.GetLocalNodeResult nodeResult = Wearable.NodeApi.getLocalNode(googleApiClient).await();
String localNodeID = getLocalNodeResult.getNode().getId();
Then, put code like this inside your for loop to do the filtering:
Uri uri = item.getUri();
String nodeID = uri.getHost();
if (nodeID.equals(localNodeID)) {
// Skip changes originating on this device
continue;
}
I am building a simple single window app using Swift on Xcode (using storyboard) where I display data from a BLE device. The BLE device is given a command to switch on certain sensors by the app, and the data can be seen using the app. While exiting, I need the application to ask the BLE device to switch off the sensors.
For this purpose, I overloaded the function viewWillDisappear in ViewController.swift and performed the BLE commands needed there. I can see that if I close the window, my BLE device switches off it's sensors and goes to sleep.
But, when I simply press Cmd+Q or "Exit" from the menu, the app exits without performing the viewWillDisappear function! Is the Cmd+Q supposed to be an ungraceful exit?
How do I make sure that the "viewWillDisappear" function gets called on Cmd+Q too? Or, is there some other function that I need to overload for the same purpose?
Thanks and Regards,
Anup
A suggestion for a workaround:
Define a variable
var sensorsAreON = false
In the function to switch on the sensors add
sensorsAreON = true
Define a function switchSensorsOFF() which switches the sensors off if they are still on. Call this function in viewWillDisappear() and applicationWillTerminate()
func applicationWillTerminate(notification: NSNotification) {
switchSensorsOFF()
// do other stuff
}
func viewWillDisappear()
{
switchSensorsOFF()
// do other stuff
}
func switchSensorsOFF()
{
if sensorsAreON {
performTheRealFunctionToSwitchSensorsOff()
sensorsAreON = false
}
}
If you want to terminate the app when the window is closed, implement the NSApplication delegation method applicationShouldTerminateAfterLastWindowClosed and return true. Then you could put all your cleaning code into applicationWillTerminate rather than viewWillDisappear
I wrote a simple program with SFML and OpenGL which draws a spinning square that can be moved around the screen with the arrow keys.
It works fine on all the Linux and Mac computers I've tested it on, but when I try to move the square on Windows (by holding down an arrow key) it moves a small distance and then stops moving and spinning. I'm pretty sure the program is getting stuck in the GetEvent method - my guess is that when I've held the key down long enough for it to start repeating, the event stack keeps getting new events added to it before I can pop everything off it (and if I turn the key repeat rate on Windows right down to the minimum then the problem goes away - I don't really like this as a solution though).
I found that pressing and holding Alt, Ctrl, Delete, Page up, Page down, Home, End etc all cause this behavior too (even though I don't specifically detect any of these keys in the program), but all the letter keys, as well as space, enter, backspace and the keypad arrow keys work fine (i.e. they don't cause the program to pause if I hold them down for too long).
I don't have the exact code (I just turned my laptop off), but it looks like:
while(running) {
while(app.GetEvent(event))
if(event.Type==sf::Event::Closed) running=false;
if(input.IsKeyDown(sf::Key::Right)); // move right
// etc etc
// update rotation
// draw everything
}
Any ideas as to what the exact problem might be, and how I could fix it?
I know this is an old question but I would like to answer it in the interest of helping others who may find themselves here experiencing similiar problems.
SFML 1.6 has two ways you can get input from the user. One is event-based where you process each event sent to you via sf::Window::GetEvent(). The other is query-based where you check the sf::Input class of your window directly.
You have used the query-based method here but put it inside an event loop which isn't really the way it was intended to be used. It was meant to be used like this. This is a nice feature because SFML essentially keeps a boolean table of keys automatically for you so you don't need to manage key states yourself. IMHO for using repeating input this is more elegant since you won't be spamming your event queue, just checking a boolean value.
while(app.GetEvent(event))
if(event.Type == sf::Event::Closed) running=false;
if(event.Type == sf::Event::KeyPressed && event.Key.Code == sf::Key::Right)
{
// move right
}
}
If you wanted to just query sf::Input directly then you use the same code as above, but you put it outside the event loop.
while(app.GetEvent(event)
{
}
if (myWindow.GetInput().IsKeyDown(sf::Key::Right))
{
}
By default automatic key repeat should be enabled for sf::Windows but you can make sure by using sf::Window::EnableKeyRepeat(true). This means it will send a KeyPressed event repeatedly while a key is held down.
Try using the query-based method outside the main event loop and see if that works for you.
I am developing a cocoa application which downloads firmware to the device. The progress of downloading is showed using NSProgressIndicator. I call the -incrementBy: method of NSProgressIndicator after DeviceRequestTO method in a while loop. But the progress indicator gets updated only after the entire firmware is written to the device. It shows 100% completion at one go itself. So I added the -displayIfNeeded method of NSView class. Now it shows progress smoothly but this too occurs after the firmware download is complete. How can I achieve the progress indication and write operation simultaneously?
Following is the code:
while(1)
{
int result = (*dev)->DeviceRequestTO(dev, &request);
printf("\nBlocks Written Successfully: %d",DfuBlockCnt);
[refToSelf performSelectorOnMainThread:#selector(notifyContent)
withObject:nil
waitUntilDone:NO];
}
//In main thread
- (void)notifyContent{
[dnldIndicator incrementBy:1];
[self displayIfNeeded];
}
The method you need to call is setNeedsDisplay:, not displayIfNeeded. The latter means “send yourself display if somebody has sent you setNeedsDisplay:YES”. If you don't do that last part, the view doesn't know it should display, and displayIfNeeded will do nothing.
And once you add the setNeedsDisplay: message, you may be able to cut out the displayIfNeeded message, as the framework sends that message to the window (and, hence, to all its views) periodically anyway.
Your code looks exactly like some that I use for updating UIProgressIndicators and NSProgressIndicators on the Mac and iPhone, code that works perfectly for me. I'm assuming, like menumachine, that your while loop exists on a background thread (created using performSelectorInBackground:withObject: or NSThread's detachNewThreadSelector:toTarget:withObject:).
Are the minValue and maxValue of the progress indicator set correctly (0 and 100 or whatever your scale is)?
How frequently do updates occur? Maybe you're sending too many events too quickly and the UI is not having a chance to update properly.
This code should work, as far as I can tell.