If I wanted to ignore a touch event in UIKit on the iPhone I would simply do:
// Begin ignoring events
[[UIApplication sharedApplication] beginIgnoringInteractionEvents];
//Do my code
// Stop ignoring events
[[UIApplication sharedApplication] endIgnoringInteractionEvents];
This allows my code in between the "ignore" calls to operate without having to worry about user interaction changing any state of the application.
My question is, how can I do this if I am writing a Mac OS X app (AppKit vs. UIKit)? I basically want to "lock-out" the user during some operations (specifically, making network calls, and changing state quickly would queue up a ton of network calls that would quickly get in the way of each other).
Do I need to manage this manually with AppKit? I.e. put up a progress bar, and disable all UI Elements by hand?
On the desktop you really don't want to do such a thing. It only works on the iPhone because there is nothing else a user might reasonably want to do with your app at the time. On the desktop there are possibilities for multiple windows etc. and anytime your app is unresponsive is considered a bug.
So more directly: No, there is nothing like this. You have to achieve the same effect with a sheet/modal panel, but most of the time should design the UI such that it's not a problem anyhow.
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'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.
I'm in the situation where I love the Terminal.app of the mac, but I would love to add some further enhancements, like split views, terminal sets, etc.
Basically I tried to rebuild the Terminal.app with an NSTask/PseudoTTY approach which basically works but just doesn't feel and behave like the beloved Terminal.app itself. There's also no need to reinvent the wheel, I think.
So is there any approach to start an cocoa application (b) from another cocoa application (a) and manage the window or view of b from a? Like I have a ManageTerminals.app that start 6 Terminals and puts the views of them fullscreen in a grid, every instance being a fully working Terminal.app?
I found the SIMBL that basically allows to do something like that. At least the website says so. But there are no manuals or documentation available.
Does anybody have an idea how to accomplish this? I don't want to change an App, I just want to manage the size and appearance of the window/view on the screen.
Thanks for any ideas or concepts!
-- EDIT
I tried Apples ScriptingBridge now which almost does the job. There's just one little last step missing that might be a show stopper. Right now I have the following:
terminal = [SBApplication applicationWithBundleIdentifier:#"com.apple.Terminal"];
[terminal activate];
if([terminal isRunning]){
TerminalWindow *terminalWindow = [[[terminal windows] get] objectAtIndex:0];
view = (NSView*)[terminalWindow contentView];
}
Of course it's giving me an unrecognized selector, because there's no method to retrieve the view from the terminalWindow in the Terminal header. But if that was possible I could create x instances of my application and replug the view of the terminals to an own window that manages only the views.
Does someone know how to accomplish this, or do you think it's totally capsuled away?
You can launch an application with [[NSWorkspace sharedWorkspace] launchApplication:#"iChat"]. However you can't manage views. Youre only allowed to change the windows frame. AppleScript might help you here out. I've never used SIMBL before but theres a [wiki page][code.google.com/p/simbl/w/list]
You should probably take a look at iTerm which is an open-source terminal emulator for Mac OS X. You might be able to modify it to your needs, or at least see how a terminal emulator works via Cocoa.
Otherwise, you can use the Accessibility framework to control the position of other apps' windows. The user has to specifically allow this via the "Allow access for assistive devices" preference in the Accessibility pane of System Preferences.
Doing much more than that becomes more complex. Apple Events/AppleScript may give you the tools you need. I know Terminal has an AppleScript interface but I'm not sure how complete it is. I really don't recommend using SIMBL. This does allow you to inject your code into another app's memory space but since you would need to reverse engineer the other app you cannot guarantee stability.
I have implemented inappsettings to have a preferences view in my application to be able to edit settings.bundle values straight in the app.
However now I wanted to read from settings.bundle but reading the iOS programming guide I found out that settings.bundle should be read on application startup.
So is it not possible to access this preferences any time in my code? Inappsettings would not make any sense if the user could not update preferences any time while the app is running.
Inappsettings offers the method InAppSettings registerDefaults
- (void)initialize{
if([self class] == [AppDelegate class]){
[InAppSettings registerDefaults];
}
}
But I am not sure if that makes it possible to read preferences any time. Any suggestions?
Edit: in my app I have three views, one is the dashboard. The other, a option and a mail view, are shown modally.
In the preferences the user can setup some basic things that I need to send the message. So when the user just started typing and wants to change e.g. the transmission gateway he opens the option view, which is the inappsettings view, and changes some things. I would like to read this changes without restarting the app.
Clearly Apple wants to impose external preferences UI paradigm on us. Please recall how Mail.app works. Sometimes that paradigm makes sense, sometimes doesn't. If you have immutable preference set, you don't have to think about events handling onPrefferenceChange, concurrency, synchronization, OS backup and replication issues,etc... However the facilities that Apple provided are very limited in what they can do. You can't even enter an arbitrary string there (Mail.app clearly uses some private API for that). So you have to make a choice whether you can use what Apple offers or implement your own preference system (may be based on top of NSUSerDefaults or something). I implemented my own once and I use it ever since. I prefer to have a real in-app preference system. The main advantage of that is to able changing its value without leaving an app.
I've been searching forever for a solution to this, so I thought I'd seek out the brainpower of greater minds than mine. I'm developing a Cocoa app that uses the Accessibility API to manipulate another program (it's a hotkey app). The app I'm controlling typically has multiple windows open, with some hidden behind others. What I would like to do, if it's possible, is to send mouse events to windows using the Accessibility API in a way that presses a button in the window without bringing it to the foreground (interact with the window but don't activate it). The reason I'm trying to do this is that sending the mouse event to this other window will force it to the foreground and disrupt the user's interaction with the foremost window.
This is possible on Windows - apparently, because apps similar to mine do it there - but I'm getting the feeling that this isn't possible with Cocoa, given the way the window manager works. Am I mistaken?
Accessibility is higher-level than that. You send, for example, AXPress actions to AXButton objects, but “press” is not necessarily a click—pressing the space bar while a view is focused, for example, is also a “press”. AXPress is a high-level action that means “do your thing”, which obviously has meaning for some views (such as buttons) and not others (such as fields).
Accessibility activating the application does make sense when you look at it from its intended purpose: Assistive devices for disabled users. If the user “presses” something by whatever means, they probably intend to activate the application and work in it.
Quartz Event Services will get you almost there: You can create an event tap for the process you want to control, and you can forge events and send them to a tap. The catch is that you can only send events to a tap when the tap fires—i.e., when the application already has an event to deal with. When it doesn't, you're stuck.