Let me get this out of the way: I'm used to to UIKit, where you can push/pop view controllers to your hearts content. That just doesn't work on the Mac.
With TwUI, this works extremely well on the Mac. For example, look at #joshaber's push/pop example using TwUI. If TwUI was completely stable and capable of embedding AppKit controls inside a TUIView, I would ditch AppKit completely. However, not everything can be done in TwUI, and I need to retain AppKit for some things.
Thus brings my question. How can something like this be accomplished using AppKit? Is there a library that has made this easy? Or do we need to make it ourselves? Just using replaceSubview:withSubview: isn't enough, and isn't really pushing/popping views.
You're asking about how to push/pop NSViews? I have another example on GitHub at https://github.com/joshaber/ReederDemo that does that. You can take the guts of PPNavigationController from TwUIPushPopTest and replace it with the stuff to do the animation in ReederDemo. It'd still be far from complete, but it'd at least get you pushing and popping view controllers with a kinda-right animation.
Ah, I think I found what I was looking for.
Behold PXNavigationBar:
Combining this and Josh's push/pop example I've come up with a good system. I'll leave Josh's example selected because that fixes the root problem.
Related
I'm trying to get to grips with using Chipmunk (not the Obj-C version) with UIKit components on iOS, and still struggling immensely.
I'm trying to establish how, in the ChipmunkColorMatch example in the documentation, the UIButton instances are actually hooked up to any of the physics calculations. I see that the UIButtons are created inside the Ball class, and some of their properties are set, (type, image, etc.), but I'm not understanding where the cpBody or cpShape or whichever it is is actually attached to that UIButton. I assume it needs to be, else none of the physics will be reflected in the UI.
I've looked in the SimpleObjectiveChipmunk tutorial on the website too, but due to the fact that it uses libraries unavailable to me (the Obj-C libraries), I can't establish how it works there, either. Again, I see a UIButton being created and positioned on-screen, but I don't see how the cpBody (or in that case, ChipmunkBody) is linked to the button in any way.
Could anyone shed some light on how this works? Effectively what I'm going to need are some UIButton instances which can be flicked around, but I've not even got as far as working out how to create forces yet, since I can't get the bodies hooked up to the buttons.
Much obliged, thanks in advance.
EDIT: Should also point out that I am not, and do not want to use cocos2d in this project at all. I've seen tutorials using that, but that's a third layer of confusion to add in. Thanks!
Assuming this source is the project you're asking about, it looks like the magic happens in Ball's sync method -- it creates a CGAffineTransform representing the translation and rotation determined by the physics engine, and applies that to the button.
In turn, that method is called by the view controller's draw: method, which is timed to occur on every frame using CADisplayLink, and updates the physics engine before telling each Ball to sync.
I'm working with some code that I need to refactor. A view controller is acting as a container for two other view controllers, and will swap between them, as shown in the code below.
This may not be the best design. Swapping the view controllers in this way might not be required. I understand that. However, as I work with this code I want to further understand what happens with the addChildViewController call. I haven't been able to find the answer in Apple's docs or in related questions, here (probably an indication that the design needs to change).
Specifically - how does the container view controller handle a situation where it is asked to add a child view controller, which it has already added? Does it recognise that it has already added that view controller object?
E.g. if the code below is inside a method - and that method is called twice...
[self addChildViewController:viewControllerB];
[self.view addSubview:viewControllerB.view];
[viewControllerB didMoveToParentViewController:self];
[viewControllerA willMoveToParentViewController:nil];
[viewControllerA.view removeFromSuperview];
[viewControllerA removeFromParentViewController];
Thanks,
Gavin
In general, their guidelines for view controller "containment", when one contains another, should be followed to determine whether you will need to implement containment.
In particular, worrying about adding the same child view controller twice is like worrying about presenting the same view controller twice. If you've really thought things through, you shouldn't need to face that problem. Your hunch is correct.
I agree that Apple's docs should be more up-front about what happens with weird parameters or when called out of sequence, but it may also be a case of not wanting to tie themselves to an error-correcting design that will cause trouble down the road. When you work out a design that doesn't ever call these methods in the wrong way, you solve the problem correctly and make yourself independent of whatever error correction they may or may not have - even more important if you consider that, since it's not documented, that error correction may work differently in the future, breaking your app.
Going even a bit further, you'll notice that Apple's container view controllers can't get in an invalid state (at least not easily with public API). With a UITabViewController, switching from one view controller to another is an atomic operation and the tab view controller at any point in time knows exactly what's going on. The most it ever has to do is remove the active one and show the new one. The only time where it blows everything out of the water is when you tell it "you should blow everything out of the water and start using these view controllers instead".
Coding for anything else, like removing all views or all view controllers no matter what may in some cases seem expedient or robust, but it's quite the opposite since in effect one end of your code doesn't trust the other end of your code to keep its part of the deal. In any situation where that actually helps you, it means that you've let people add view controllers willy-nilly without the control that you should desire, and in that case, that's the problem you should fix.
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'm trying to use that MGSplitViewController (already mentioned here, but some one told me I have to ask a new question...), because some ideas will have one or more splitviews and Apple's reviews are not that easy to pass, so I thought I just use some time to test some existing frameworks, like the MGSplitViewController.
But I don't get it working for about 4 long and hard days(and some nights, too ;) ) - any help would really be really great!!!
My problem is the following:
I have just a simple start view with a segmented control. after the launch and some checks I would like to load the splitview in that simple view. I'm using the storyboard for the simple view and I added the xibs from the example (because I had no idea how to integrate them in the storyboard as well - seems to be the next topic, I'll take a look at...)
Sounds very easy, but with the commented header file and the demo project I'm absolutely not able to reproduce it for a non root controller loading...
I have packed the source code for better understanding, downloadable at
http://www.file-upload.net/download-3866273/mgsplittest.zip.html
.
If any one can help me with this, correcting the project, this would be really, really, really great!!!
Greetings,
matthew
I have solved the issue -
FORGET MGSplitViewController :)
Write it your own, really not difficulty:
need two views(navigation_left_sided, detailsview_right_sided) in the YOURSPLITVIEWController in the storyboard
all detailviews should be build with xibs, in storyboard I have not found a way doing this in a clean way (any tipps appreciated)
the leftsided view delegates calls/view loadings to the other
load your detailview controller and display
finished ;)
It is also a good training to work with delegates, observer and asynchronous dispatching. At the time I asked the question, I have not worked much with them - blame on me ;)
Advantage of writting your own:
- reusable
- fully customizable
- in portrait mode also visible, you can just change the sizes of both
- custom animations for changing the detailsview (move details from bottom to top or curl or anything)
- after this you have a lot of basic knowledge like delegates, etc... (it was in my case)
Or use the iOS6 feature for grids also very simple, but iOS6 based devices only...
That's it, very easy :)
Any questions? Just ask :D
But I have written the code for my company, so I cannot share, just answering questions and giving you the tipps from above ;)
Greetings,
matthias
I have seen a lot of different ways of implementing custom cells in a table view.
Like different file owners, get it from bundle and call the the latest obj of the array and a lot more.
But all did not feel right.
What is the best and correct way to create and use custom table view cells (with interface builder).
I think Storyboards are the new proper way. I use this method:
http://iphonedevelopment.blogspot.com/2009/09/table-view-cells-in-interface-builder.html
And it works quite well. I think it's somewhat proper in that you are asking the OS to do most of the work, although it's a little sneaky that the cell is assigned to a property as part of the NIB loading as a side effect.
Had the same problem. For me it is now solved with storyboards in ios5.