I'm making a mac app that appears as a popover from the menu bar. The view has several components, when everything is running and the popover is open I see that it is taking up about 3% CPU. However when I minimize the popover and let it run it the background it jumps up to 6-7% CPU. This does not make any sense to me since the view is no longer being shown so I would imagine less would be required to run.
However I am not doing anything when I close the popover, just sending a [popover close] message.
Is there something else I should be doing when I close the popover to keep down CPU usage?
Thanks
Without knowing your code, it is hard to say what's going on. You will need to find that out by using Instruments Time Profiler. Once you know what the application is doing while minimized, you should be able to locate and fix the issue.
Related
I have an Alloy app. It has got 7 windows and opens at same time. When user close a opened window $.removeListener(); $.destroy(); codes runs at window close event. But I am getting memory leaks on Android device. %90 windows has got ListView, every window has got max 2 Listview. What is the right approach for multiple windows?
First of all, why you would want to open 7 windows at same time when user can only see max 1 window at a time.
It's dead simple, open only that window which user should see first, & create a link-flow to other window in previous window.
Can you think of any app on Play Store which does so, if you have, then please send me its link, I would really love to review it?
But if you mean to say that user will see all windows at same time in a scrolling behaviour or like paging, then go to Ti.UI.TabGroup
Are you 100% sure that your event listeners are being removed?
I don't know the function $.removeListener(); is this a custom function?
As a general rule I try and put as many of my event listeners into the xml, as these are automatically removed, and have a custom function destroyMe() that runs onClose which removes any other listeners that I may have used and $.destroy()
Ti.App.addEventListener is a killer too, make sure these are removed if you use them!
ps: i totally understand the 7 windows bit :-)
I've just encountered a really bizarre scenario and can't find any info on this elsewhere. When Xcode breaks at my breakpoints, all keyboard entry for the whole system is unresponsive. I can switch to another app but no key strokes are recorded. Xcode itself is unresponsive to keyboard input.
Anybody else seen this?
I'm running 10.10.1 and Xcode 6.1.
Based on the comments above it would seem that this issue has to do with behind the scenes details of Powerbox. To explain further: my app is sandboxed and calls NSOpenPanel. When breaking (Xcode breakpoint) in the completion block of NSOpenPanel I experience system-wide keyboard input loss.
Keyboard entry behaves normally in breakpoints outside of the call to NSOpenPanel. After working past this area of code I observed that my subsequent operations (queued in the background from the completion bock) often finish before the NSOpenPanel is completely torn down (disappears from the screen). My assumption is that until NSOpenPanel is removed from the screen (and maybe further after), Powerbox won't release control of the keyboard.
Much of this is assumption since I don't have the actual Powerbox code and can't step into it but it seems to fit.
I worked around my debugging issues by utilizing print statements and stepping through code with the variable inspector open. Mouse input continues to function so you can right-click (if you have a two-button mouse) on the variable and print its description at least.
Thanks for the help Ken.
UPDATE
I am now delaying execution of any of my post-NSOpenPanel actions using dispatch_after. On my system a delay of 1 second is doing the trick. I really don't like adding arbitrary delays but this seems to work.
Is it possible to use a certain image for a loading screen when it's the first time the app is ever opened, and then after that use a different image for the loading for all visits after that?
Basically I'm creating about 10 files (not large in size) when the app is first launched and I wanted to display a message to the user so they don't think that the app normally takes more than a second to load up. I know I can display a popup on the home screen, but I have an animation that fires when you go to the home screen and also I need those files created before the user arrives there. Any ideas? Or maybe a different view point that I didn't mention?
You can't change the splash screen. Maybe you should rethink how your initial 10 files are created, and take Paul's suggestion of showing a popup control while you do the work, or better yet, offloading it into the background? I guess it depends if your created files are required for something in the UI
--edit--
Actually, the more I think about it, the more I favour a background thread doing the work while you have a popup control displayed to the user. It would allow you to give the user feedback on what is actually going on. If your popup says something like "Preparing this application for its first run...", and then shows a progress bar that updates when each file is created, the user is getting feedback on exactly why the app is taking so long to load the first time. Otherwise they may think "This app is very slow, I wonder if there is a better one out there"
I'm not sure if this is what you were thinking when you said "Popup", but you could create a full screen Popup (in the System.Windows.Controls.Primitive sense of Popup) that completely covers your main UI so that the user can't see it.
Your temporary loading UI would be defined as a UserControl described in XAML/C# in the same way as a normal PhoneApplicationPage.
When your files are ready and you close the popup you should send a message to the View (i.e. .xaml.cs) of your main page that will cause the animation to be replayed with all contents visible.
I'm trying to get my NSWindow to:
Be visible on all Spaces
Be visible when showing the Desktop (by pressing F11)
Not be visible in Mission Control/Expose
The following does exactly that, but with a side effect:
[self setCollectionBehavior: NSWindowCollectionBehaviorCanJoinAllSpaces
| NSWindowCollectionBehaviorStationary ];
When switching to the Dashboard on Mac OS X Lion, the window remains visible alone with Dashboard items for a second, then it is hidden.
Is this expected behavior or a bug? Users of my app find it confusing to see the window on the Dashboard before they disappear. I would have expected them to only show on Spaces and not the Dashboard.
I looked at http://cocoadev.com/wiki/DontExposeMe searching for workaround
nothing really worked except.
self.window.level = kCGDesktopWindowLevel;
now maybe DETECT changes to expose and set that then :) ...
see How can one detect Mission Control or Command-Tab switcher superseding one's program in OS X? for that :)
maybe an answer will come up there
I was able to reproduce this behaviour and I think it's just a bit of faulty animation on Apple's side.
Just so I can explain this better, create a new project, add these two lines to applicationDidFinishLaunching:, and run it.
[self.window setCollectionBehavior: NSWindowCollectionBehaviorCanJoinAllSpaces | NSWindowCollectionBehaviorStationary ];
[self.window setHidesOnDeactivate: YES];
(self.window is the window that is created automatically when creating a new project. it doesn't really matter here anyway, just as long as it is a window that appears on the screen)
Now notice this behaviour: when changing from one space where you can see your window to another in which there are other windows from other apps (and so your window is supposed to disappear since your app will be deactivated), your window only disappears when the animation finishes. So, what is happening?
Here's what I think it happens: when switching from one space to another, windows that show on all spaces only react to the change after the animation, hence the brief appearence of your window on the dashboard. I think you'll notice it disappears exactly when the slide animation ends.
So, unfortunately, I don't know how to fix your problem. It just seems to happen this way.
I would like to show the user a splash screen (a picture) while my Cocoa-based application launches. How would this be possible?
First thanks a lot. because my app running for a while time , so I want to show a splash before app running . Now if I show a window inside with a image , after that how to run the app? How to make sure that the app running after the splash showing ? How to do to get the sequence ?
First Thank you very much. And I show the window in applicationWillFinishLaunching method use orderFront,then hide it in applicationDidFinishLaunching: use orderOut,Now I found that the mainWindow not to show and the app terminate ,why ? How to do to resolute this question? Thanks!
Although Peter's answer is ultimately correct (you should rewrite your app to launch faster), sometimes that's not a practical option. For example loading code later in the application may take too long (e.g. a data acquisition application), forcing it to be loaded at startup. If you decide that you want to show a splash screen, the easiest way is to show it in the application delegate's applicationWillFinishLaunching: method. Create a splash window in your applications MainMenu.nib and add an outlet to your app delegate referencing that window. You can then put the window onscreen in applicationWillFinishLaunching: and hide it in applicationDidFinishLaunching:. Note that the main thread's NSRunLoop is not iterating during this time, so if you want to update the splash screen (with status, a progress bar, or such), you'll need to manage those redraw events yourself.
Again, think very hard about whether the long startup is necessary. If it is, showing a splash screen with a progess indicator is the minimum that you owe your users.
Why do you hate your users?
Seriously, don't do this. Don't make your users wait to use your app. Make your app launch quickly instead.
(And just in case you insist on an answer: Show a window with the image in it, then hide the window when you feel the user has waited long enough.)
Just put up a window with the image and close it when you are done with your launch initialization.
Barry's answer above does not seem to work for document-based apps. Showing a splash window within applicationWillFinishLaunching: interferes with the startup sequence of the app such that the document window isn't created. I've uploaded an example project here. In applicationWillFinishLaunching:, comment out [_splashWindow orderFront:self ] and the document window will come up.