I have a carousel view who's itemsource property is set in Xaml. When clearing the bound collection from within the view model I get an object instance exception thrown. But on further inspection it's not the collection which is null, it's the clear method itself which is indicated as an "unknown member". The carousel page works fine on Android an Windows phone, but on iOS I receive this problem.
It seems that on iPhone the lifetime of the carousel view is disposed when navigating away from the view. When re-visiting the view the carousel view would throw all sorts of errors because it had been disposed. On Windows Phone and Android there is no such problem. I would have been handy if in the documentation it would state that the lifetime of the control would be disposed when navigating away from the view.
To solve the problem I simply new'd up the view and view model every time they're re-visited, in other words making their lifetime transient.
Related
I'm creating an application in which there's the Main Page that holds a header, a footer, and a dynamic ConventView in the centre.
Depends on the button that was clicked (either in the footer or inside the page that is shown in the contentview) the view in the ContentView is updated/changed.
Thus, I needed to make the ContentView act as a bindable control.
To make it work, I maintain in the ViewModel of the MainPage, a stack of tuples .
Every time the content should be changed in the ContentView, I push the current BindingContext (some ViewModel instance) into that stack, paired with the page that is currently displayed in the ContentView. (or pop from the stack if I need to go back to the previous view)
After that, I set the ContentView to the requested View with its matching ViewModel as the BindingContext.
I noticed that the procedure of changing the BindingContext - is a performance issue. most of the time, changing the BindingContext can take 4-6 seconds(!!).
How can I solve this performance problem (without destroying the navigation mechanism I built)?
Thanks,
I have two UICollectionViewControllers - lets call them master and slave. The master view controller is configured with layout A and the slave with layout B. I set useLayoutToLayoutNavigationTransitions on master to YES and push the slave onto the navigation stack. The layout changes from A to B and I can navigate < back and see layout A. All is good.
However, in response to the user typing some text into a search box in the master view controller, I need to change the layout of the master collection view controller to layout C. This works as expected, but when I push the slave collection view controller onto the stack (configured with layout B) and navigate < back, I end up back at the master collection view controller with layout A, not layout C, as expected.
So far, I've tried:
putting a symbolic breakpoint on -[UICollectionView setCollectionViewLayout:] (and it's related/sibling methods) to check whether something was messing with the collection view layout before pushing the slave onto the stack. I see the break point getting hit when I expect the layout to change, but nothing unusual in the process of popping the slave collection view controller off the navigation stack.
stopping in the debugger and verifying the type of the collection view's collectionViewLayout property and I can see it is set to an instance of layout C before pushing the slave collection view onto the stack. After navigating backwards, I can see the layout has returned to the type of layout A and not layout C (as expected), which tallies with what I'm seeing visually.
implementing -navigationController:willShowViewController:animated: delegate callback and setting the collection view layout to what's required. However this appears to get over-written.
implementing -navigationController:didShowViewController:animated: and setting the collection view layout, but this results in an infinite loop and errors logged to the console.
Does anyone have any ideas what's going on here and how to solve this? I'm wondering if it's a straight-up UIKit bug, and if so, if there are any potential workarounds.
While I have made great strides in customizing an NSCollectionView, thanks to hints I've gleamed here and across the web, I am having a bit of difficulty I'm hoping someone can help with. I have a Core Data entity that contains information about Video files and a NSCollectionView that displays a thumbnail image preview of each of these videos. I have bindings setup on the NSCollectionView.
On my first attempt at setting up bindings, I setup my Array Controller in Class mode and tied it's content to an NSMutableArray that I was filling with all of the objects from my Videos entity in windowDidLoad. I was performing addObject on the array controller to get them to show up. This works fine except for the fact that it takes quite a while if you have a lot of objects to load.
So... It seemed silly to me to copy all of the objects to an array when it's possible to bind a NSCollectionView directly to Core Data. I changed my ArrayController to Entity mode and setup the Managed Object Context to point to my App Delegate's managedObjectContext. When I launch my application, there is a delay before the Window displays on screen. In fact, the other things I'm doing in windowDidLoad process immediately, but it takes another 5-10 seconds for the window to display. Once it does, nothing is showing in the NSCollectionView.
I initially thought it just was not working until I accidentally resized the Window and all of the items showed up in the collection view. I've tried to see if there is a way to know when the Window is actually displayed so that I can call [collectionView setNeedsDisplay:YES] but either it doesn't work or I'm not calling it in the right place.
Does anyone have an idea why the objects are not just showing up? I'd also like for the Window to display immediately and then for the Collection View to load the items from the Core Data. Loading directly from Core Data seems much quicker than copying the items to an array. I'd be happy to post any code you'd like to see although since the bindings are setup in IB, there is not much to show. :)
Thanks!
I have a simple iPad application with 5 views. On the first view, the user is asked to make some selections and set some options. From this information, the other 4 views are programatically changed after an NSNotification message is sent to them. (i.e controls are added, updated).
My problem is that when the application is first loaded, the user sees View1, but View2, View3, View4 and View5 have never been opened yet, so any changes I make programatically to those views are not done and when the user navigates to them (via the tab bar) for the first time, no changes are shown.
[EDIT: I should point out that the code for making the changes to each view is contained within the ViewController itself, and is executed when the view observes the incoming NSNotification. When the view is not loaded, it understandably never received the incoming NSNotification.]
Only after the user looks at any of those screens at least once and then goes back to View1 and makes changes, are the other Views updated properly.
I thought I could get around this issue by actively loading Views 2,3,4 and 5 into memory on application start, so that they are ready to begin receiving notifications right away.
Is there an easy way to do this in iOS 5?
Why do the view changes straight away?
I would store an indicator of the changes needed when the users answers the questions on the first view and then apply the changes on -viewDidLoad of each view that needs to be changed.
Instead of trying to load the views into memory, I'd suggest you initialize these views with the options that the user set on the first view. What I usually do in such situations, when I have a global parameters that are used in many places, I create a utility class to keep the data, make it a singleton, then access the shared instance in the viewDidLoad in the views that use the data during initialization.
Specifically, I have something like a game, with a menu screen made out of standard components. I want a button to switch to another view controller that the user will interact with for a while, then return to the menu screen. It seems like having the menu controller present the 'game' mode as a modal view controller is the most straightforward solution, but is this the best way to essentially replace the entire view? Is the whole menu (which may later become a deep nav or split controller) kept in memory as long as the modal controller is in front, and is this something I should bother to worry about?
There are really two parts to this question:
Which method of transitioning from one view to the next in an iPad application provides the best experience to the user?
Which method of transitioning from one view to the next is easiest to implement and best handles memory management?
I'm not going to try to address the first part of this question other than to point you to Apple's 'iPad Human Interface Guidelines' which says (among other things):
Reduce Full-Screen Transitions
Closely associate visual transitions with the content that’s changing. Instead of swapping in a whole new screen when some embedded information changes, try to update only the areas of the user interface that need it. As a general rule, prefer transitioning individual views and objects, not the screen. In most cases, flipping the entire screen is not recommended.
When you perform fewer full-screen transitions, your application has greater visual stability, which helps people keep track of where they are in their task. You can use UI elements such as split view and popover to lessen the need for full-screen transitions.
http://developer.apple.com/library/ios/prerelease/#documentation/General/Conceptual/iPadHIG/DesignGuidelines/DesignGuidelines.html
However, in your case I'd have thought a full-screen transition is entirely appropriate (but then I'm not a user experience expert).
In answer to the second part, yes displaying a new view controller modally seems like a good approach to take.
By default both the objects used by the menu view and those used by the modal view will be kept in memory - but the great thing about using UIViewController sub-classes is that they've got some default memory management built-in. If your application receives a memory warning whilst the modal view is being presented in full-screen mode, the menu view controller's views will be removed and it's 'viewDidUnload' method will be called. So in your implementation of this method you should release any objects you don't need and then recreate them as needed in the menu view controller's viewDidLoad method (which will be called again before the menu view is shown).
This is explained in more detail in the UIViewController class reference:
When a low-memory warning occurs, the UIViewController class purges its views if it knows it can reload or recreate them again later. If this happens, it also calls the viewDidUnload method to give your code a chance to relinquish ownership of any objects that are associated with your view hierarchy, including objects loaded with the nib file, objects created in your viewDidLoad method, and objects created lazily at runtime and added to the view hierarchy. Typically, if your view controller contains outlets (properties or raw variables that contain the IBOutlet keyword), you should use the viewDidUnload method to relinquish ownership of those outlets or any other view-related data that you no longer need.
http://developer.apple.com/library/ios/#documentation/uikit/reference/UIViewController_Class/Reference/Reference.html