Is this really the proper and only way to programmatically set the target of an animation in a Windows Store app?
Storyboard.SetTarget(animation, someElement);
Storyboard.SetTargetProperty(animation, "Width");
It just seems odd not to use an instance method or property on either a Timeline or Storyboard.
It's the programming equivalent of reaching in your car window and using the interior handle to open the door.
Luke
It is the correct way, yes. I do agree it could be made simpler, but it is how it has been since WPF.
Related
The NSTabViewController was only introduced in OS X v10.10, so NSTabView already provides everything you need for creating a tab view. When would you use a NSTabViewController, and is it only there to be subclassed?
I would use NSTabViewController to get rid of a lot of code I used to have to write to have a tab view and transition between those views (most often done in Preference windows in Mac apps).
You'd obviously have to be 10.10 only, but these days that's a safe bet.
As for subclassing it, judging by the api I'd start without sub-classing it. You can set the style, the transition options (a nice benefit of using it!), and then call addTabViewItem: and let it do it's stuff.
If you compare iOS & OS X, you will feel OS X is bit deviated from MVC. OS X default 'new project' opens with AppDelegate as compared to iOS with 'ViewController'!
Now, it seems, Apple decided to make it by adding Controller as well. So that the view NSTabView is controlled by NSTabViewController.
And yes if you design to subclass it and use that should reduce your job. Same thing is mentioned even in Apple Documentation.
Lately I have been playing around with the bluetooth framework and grew a strong enough knowledge to start building an application. The only problem is that all the examples I found and all the practice I have made consist in putting the core bluetooth core code inside the same file as the UIView with which the user is interacting.
I would like my future application to have multiple views in which the BLE scan occurs on the background. I initially thought about creating an object with a name similar to bleDeviceFinder and pass this object through each view. However, after thinking about it I realised that if I want something to happen in the current view I need the function didDiscoverPeripheral to have direct access to the UIView objects which it is supposed to affect.
I know it is probably a stupid question, what would be the best way to do so? I was thinking maybe to set and alert and subscribe every view to that alert; is this a good solution?
A quasi singleton BTLEManager that you pass around in the app. It sends NSNotifications for events like discovery, and your ViewControllers observe these notifications. The truth (i.e. list of discovered devices) stays in BTLEManager. Once a viewController has received such a notification it asks the BTLEManager for the list of current devices and then the viewController changes your views accordingly. The Views should never talk to the BTLEManager directly.
That's how I would do it.
I have a general question for Xcode programming and the usage of the Xcode tools.
I am quite new (4 months) in iOS development and I almost never used the Interface Builder for my purposes. I always created instances programatically. My question is basically if you think i should get used to work with IB or should/can i proceed like i do now?
If you are fine with defining your UI programmatically, then I do not see any issues with that.
Interface Builder allows you to "graphically" define your interface, and this can be an invaluable tool for playing with your UI prototypes, but apart from that there is nothing that you can do in IB that you cannot do programmatically.
In my case, I see that it depends on the kind of UI that I design. When I need a pretty basic UI, the IB is unbeatable for me. On the other hand, when my UI tries to be a bit custom, then I prefer doing everything programmatically.
An interesting point is that you could use IB to design your UI, deciding on sizes and positions of your elements, and the create it programmatically.
Yes you should use IB, basically xcode having IB for ease of development, no need to setting controlls by using coordinates and each time see their visibility by running the app.
just drag and drop and at the time of making the views, you can see hows your screen going to look.
Also using IB is not a typical task so,start development using IB.
Is there disadvantages to using WebKit WebViews compared to using NSViews?
I'm using a webview to create a UI for an application. The application itself does not have much interactivity. I have seen it mentioned, on this website & others, that using a WebView can be convient means of prototyping.
However, with our team this seems like an ideal way to produce the production ready UIs, especially with WebKit. Are we missing something?
Thanks,
Ross
Okay, so you seem to be asking if using an HTML interface (presented via a WebView) for your application has any disadvantages.
The answer to this is "no", at least "not necessarily". This is analogous to building an iPhone specific web application, and there are some excellent examples of those. The caveat would be that a lot of those sites end up recreating the look and feel of a native iPhone app, for consistency and to make the users feel "at home".
Given that you're developing a native app anyway, it seems a shame to throw away, or recreate, the responsiveness and appearance of the native chrome. Of course, for certain types of applications (games are an obvious example) a user has no expectations about the application's UI, so you're free to knock yourself out.
The other factor to consider is the amount of interactivity (although I notice that you say there isn't much in your case). The native controls will make coding a lot simpler than having to capture all user input through the "filter" of a WebView, even though using one might make the initial layout of the screens easier.
I hope that's the sort of answer you were looking for (although it's mostly non technical).
As you might have known if you spend some time in the documentation, you'd have seem that WebView is a subclass of NSView.
The documentation says about WebView:
WebView is the core view class in the WebKit framework that manages interactions between the WebFrame and WebFrameView classes. To embed web content in your application, you just create a WebView object, attach it to a window, and send a loadRequest: message to its main frame.
And about NSView:
NSView is a class that defines the basic drawing, event-handling, and printing architecture of an application. You typically don’t interact with the NSView API directly; rather, your custom view classes inherit from NSView and override many of its methods, which are invoked automatically by the Application Kit. If you’re not creating a custom view class, there are few methods you need to use.
So here's the answer to your question:
Is there disadvantages to using WebKit WebViews compared to using NSViews?
Yes. You can't display any web content with NSView. That's what you need WebView for.
I suggest reading some more documentation though.
I have multiple custom NSViews in my Cocoa program. I am looking for a way to force them to invalidate without having to add additional code while the program is running. If I were doing this with on Windows with the .NET framework, I would just drag part of my program offscreen and drag back on again. Areas that was offscreen get invalidated when they come back on screen. I haven't figure out how to do this with Cocoa - OSX.
The methods setNeedsDisplay should do it:
- (void)setNeedsDisplay:(BOOL)flag
- (void)setNeedsDisplayInRect:(NSRect)invalidRect
Docs here
Windows on Mac OS X are buffered by the Window Server and can't be forced to redraw by moving them around the screen. The only way the user can force a redraw is to resize the window.
Why do you need to do this, though?
Minimize the window and unminimize it. That happens to force a redraw.
I recommend you try F-script http://www.fscript.org/. It allows you to call methods on Cocoa objects while your program is running.
You could use it to call the setNeedsDisplay:(BOOL)flag or setNeedsDisplayInRect:(NSRect)invalidRect methods directly on the view you would like to invalidate.