My problem is that my application's window blocks when I raise a method that represents values in a NSTableView. I want to do an animation with a NSProgressIndicator (spinner), but my window is blocked and spinner doesn't show animation.
I want if anybody can give me any hint? I thought in threads or something like this, but I'm not pretty sure how to solve this issue.
You're right, you need some kind of multithreading. Fortunately, it's rather easy to do simple operations on threads in Cocoa.
You should look into NSOperation and NSOperationQueue.
You may find this blogpost useful: turbo charging your apps with nsoperation
Related
Want to create a loading view that matches the speed of the UIActivityIndicatorView depending on the network type.
Is it accessible via the SDK or at the very least disclosed?
How fast it spins? Short answer is no :(
Not with a simple property or something like that. You do have a few options though:
Create it yourself. The images are available when you use iOS Artwork Extractor, so you could give it the same look. Perhaps a little tedious. Maybe you could even subclass it.
Do some hackery with the current startAnimating and stopAnimating methods. Basically start and stop it for a period of time using a timer. This may not look great though as NSTimer doesn't always give you the precision you'd want in this case.
Since UIActivityIndicatorView inherits from UIView, you can access its layer property. This is a CALayer, which has instance methods like animationKeys and animationForKey. This is probably the best way to go about it, though it's not very future-proof since you're modifying the internals which can always change.
Currently, when selecting components or swiping the UIPickerView, the default is a lengthy animation time waiting for the selection, with a "gravity" effect near values. Is there a simple way to speed up this animation? I've looked at the delegate protocols as well as UIPickerView's methods and properties. Will I have to subclass and overload the animation method? Any help will be useful.
There is no way to do this. If you'd like for there to be a way to do this, please file a bug asking for it.
Also, relying on implementation details and a particular interval view hierarchy, as Fabian suggests, is a really excellent way to introduce a ton of fragility into your application and open the possibility of your app breaking in the future, should UIKit ever change anything.
I don't know of a way to achieve that using public API, but UIPickerView uses a UIPickerTableView as a subview somewhere in its view hierarchy. That is a subclass of UITableView which is a subclass of UIScrollView which has a decelerationRate property.
You shouldn't use private API, though. If you really need this and it's not for an App Store app this might be okay, but you should be careful and code defensively.
I don't have 50 rep, so can't comment on this (which is where this should really go). This question shouldn't have been downvoted since the question is legitimate. The valid answer is "no, you can't do that without private API hacks"), but the question is still valid.
I'd like to know which is the best way to setup an NSView.
The only method suitable for this purpose, seems to be viewDidMoveToSuperview.
In this method I can add subviews and inviewWillMoveToSuperview I can do geometry operation on frame etc.
But these are only my suppositions... I can't find a useful documentation that explain where is the better function to perform setup operations.
What do you think about that?
The reason you don't find any documentation on where to set up your NSViews is probably that you can set up views, add subviews, etc. in pretty much any method, as long as it is called on the main thread.
For simple apps, applicationDidFinishLaunching: of the application delegate is a useful place.
When the app grows, you might want to consider doing this lazily, when a new window is opened or when a view is added.
For normal apps, you won't need to do anything in viewWillMoveToSuperview/viewDidMoveToSuperview.
I have started to implement cvDisplayLink to drive the render loop instead of nstimer, as detailed in this technical note https://developer.apple.com/library/archive/qa/qa1385/_index.html
Is it better to do the actual rendering within the displaylink callback itself, or should I instead call setNeedsDisplay on the view and let the main thread do the rendering?
In order to render directly in the callback, I need to lock the opengl context, which I was hoping to avoid.
Is it possible to use cvDisplayLink for timing and still render on the main thread?
Thanks in advance for any feedback....
There’s no intrinsic problem with locking the context; it should be uncontended and unlock quickly. Redrawing on the main thread, via -setNeedsDisplay:, has a chance of missing the VBL window just because of the runloop round-trip.
I'm doing usability testing and would like to log all user input events: mouse movements, clicks, drags, and keyboard input. I'm not having much luck figuring out how, or finding any code to do so. Any hints? I took a look at the CoreGraphics EventTap mechanisms, but I'm worried that it will be too low-level; I'd like to actually know what particular UI elements the user clicks on.
Edit to clarify:
I'm doing usability testing, so I want to keep track of what parts of the interface the user uses and doesn't use. So, I want to keep track of "Button 'foo' was clicked 7 times at these particular timestamps, the user scrolled through this list and selected such-and-such item" and so forth.
If you're just looking to track them for your application, you could override -[NSApplication sendEvent:]. It's responsible for dispatching all the events your application receives to the appropriate responders.
I think you'll need to do a lot of swizzling.
Try swizzling tryToPerform:with: first; if that doesn't work, you'll need to swizzle such methods as mouseDown:, mouseUp:, the drag event methods, keyDown:, keyUp:, and the undocumented gesture methods.
One complication in the latter solution is that you'll need to swizzle those methods on not just NSResponder, but on several of its subclasses, because many view classes provide their own implementations, which may or may not call up to their ancestors' implementations.
Instruments has a way to record user interface events. It seems like you might be able to use the dtrace calls that underlie this to accomplish what you're going for.
This is completely different than what you're thinking about right now, but consider something like Silverback if you haven't yet.