It seems that a UIWebView included in a view controller that is in a split view controller, the web view reports itself as being in portrait mode, with a 768-px-wide viewport from the standpoint of CSS3 media queries.
I have built a couple of minimal-test-case apps to reproduce this bug/feature. It is not present when the web view is in a view controller that is the root view of the window. It is also not present if the split view controller is inside a tab bar controller. You can even place the web-view-bearing view controller inside a tab bar controller inside the detail pane of the split view controller and avoid this bug.
However, I would like to simply have a split view controller that is the root view of the window and includes a detail view controller that nonetheless properly honors media queries. Does anyone know of a way to achieve this?
I've tried:
overriding the detail view controller's parentViewController property (returning nil)
overriding the detail view controller's splitViewController property (ditto)
overriding the detail view controller's didRotateToInterfaceOrientation method
overriding the detail view controller's willRotateToIntefaceOrientation method
I'm investigating:
using a different media query
using a third-party split-view replacement (e.g. MGSplitViewController)
manually injecting the appropriate stylesheet with JavaScript
If anyone has run into this issue and figured out a solution, please let me know.
It turns out that it's not the split view controller per se (or the tab bar controller, for that matter) that's causing the portrait/landscape mixup.
Basically if a UIWebView is taller than it is wide, the OS considers it in portrait mode, and if it's wider than it is tall, the OS considers it in landscape mode.
The presence of a tab bar controller was enough to make the height (768 - 20 - 49 = 699) just smaller than the width (1024 - 320 - 1 (gutter) = 703).
Related
I'm developing an Xamarin Android Mvx5-beta application. When running on a small-screen device, I want to show a drawer navigation using the Toolbar and the hamburger-icon. On larger devices, e.g. tablets, I want a different layout conaining three columns. No drawer navigation but a static panel with navigation options and two other panels for content.
I started with the examples XPlatformMenus and Fragments to get a drawer navigation layout combined with the use of activities (with fragments) in different layouts qualifiers, like:
Question:
Using this approach, Android automaticly looks for an activity with the same name (e.g. main_activity.axml) in the appropriate layout-qualifier folders. But on the larger screens I don't need a drawer layout and I do need an extra column. The Mvx-viewmodel does not yet know what layout to render, so it just calls:
ShowViewModel<HomeViewModel>();
ShowViewModel<MenuViewModel>();
These ViewModels, for example MenuViewModel, are registered for fragments that require a navigation_frame, as shown in here:
[MvxFragment(typeof(MainViewModel), Resource.Id.navigation_frame)]
[Register("mydemoapp.droid.views.fragments.MenuFragment")]
public class MenuFragment : MvxFragment<MenuViewModel>, NavigationView.IOnNavigationItemSelectedListener
{
<..>
}
So, rendering this same Activity in layout-sw600dp requires a navigation_frame. Which I don't want on these larger displays.
What would be the preferred design choise in this situation? I can think of two:
Show/hide elements in the Activity programmatically by querying the screen info
Don't make use of layout qualifiers, but design complete seperate Activities for larger screens and based on screen size let MVX Show ViewModel-A or ViewModel-B.
Any advice would be appreciated, many thanks in advance.
I think it depends how different your layout need to be between large screen and small screen form factors.
Few UI differences
In addition to using different layouts, you can define a bool property in your XML values resources that is different between standard and sw-600dp
values
<bool name="is_large_screen">false</bool>
values-sw600dp
<bool name="is_large_screen">true</bool>
You can then read this value in your Android views and prevent methods like ShowViewModel<MenuViewModel>(); firing when on large screens by altering the method calls from the view.
Many differences/Structural differences
If they share the same business logic but have very different UI requirements and you want to keep large screen code separate. Then I would suggest sharing the ViewModels but creating two separate Activites and layouts to handle the UI presentation. Using this method requires a bit more setup as you have to override some default MvvmCross behaviors as by default you can not register multiple Activities/Fragments to the same ViewModel. Overriding the MvxViewModelViewTypeFinder view lookup FindTypeOrNull you can intercept the lookup and filter types base on naming conventions. For example all large screen views end with "Tablet". Using the is_large_screen bool you can flag which views to register.
A little confused on how to implement this into my main view controller. The example project shows it as a navigation controller, but I wasn't able to add an existing class on a fresh navigation controller or my current UIViewController. I could just be implementing it wrong though. Much appreciation if I can gain some traction on how to work with these.
If you could share some code that would be great.
How things work:
Navigation Controllers
There are currently 4 different Navigation Controllers that each offer their own features. The controllers can be used individually, or together.
SideNavigationViewController
The SideNavigationViewController offers 3 bodies to display content: mainViewController, leftViewController, and rightViewController.
MainViewController
The mainViewController must always exist, and has a facility for transitioning between view controllers using the transitionFromMainViewController method. Using this method is as easy as passing a UIViewController in its first parameter.
sideNavigationViewController?.transitionFromMainViewController(InboxViewController())
There are further parameters that allow for animations, completions, etc... to be set when transitioning between view controllers.
LeftViewController and RightViewController
The leftViewController and rightViewController can be set only once. To make them dynamic, you would need to use another Navigation Controller as its view controller.
NavigationBarViewController
The NavigationBarViewController offers a NavigationBarView along side the ability to manage two UIViewControllers, the mainViewController and the floatingViewController.
MainViewController
The mainViewController is like the SideNavigationViewController's mainViewController, and has a transitionFromMainViewController method that transitions from view controller to view controller in the body portion of the NavigationBarViewController.
FloatingViewController
The floatingViewController is a modalViewController and when set, it pops over MainViewController and NavigationBarView. Setting that value is like so:
navigationBarViewController?.floatingViewController = InboxViewController()
To close and hide the floatingViewController set it to nil, like so.
navigationBarViewController?.floatingViewController = nil
SearchBarViewController
The SearchBarViewController offers a single transitioning mainViewController, as well, has a SearchBarView at the top. Transitioning the mainViewController is like so:
sideNavigationBarViewController?.transitionFromMainViewController(InboxViewController())
MenuViewController
The MenuViewController is another controller that has a mainViewController, which takes the entire screen. Floating above it, is a MenuView that is used to transition between mainViewControllers.
menuViewController?.transitionFromMainViewController(InboxViewController())
Final Notes
These Navigation Controllers can be used in any combination and any amount of times creating a robust and intricate stack of controllers that act like one.
I hope this helps :)
A have many subviews in my view controller which I design in storyboard with autolayout. Those subviews don't fit the view controller box. I can only make those subviews fit view controller if I make them smaller than their actual width/height constraint value. But if I do that - it shows "misplaced view" warnings. I already have 25 of those and it starts to get messy.
It would be handy if I could increase the height of this view controller box in the storyboard. Is it possible?
I am talking only about designing in the storyboard, not the actual view controller erin the app.
Select the view controller and open size inspector in the right column (5th icon). There's an option called "Simulated size". Change it to freeform and you'll be able to set any size you want.
I'm trying to accomplish switching views without using a navigation controller, tab bar controller etc. I am currently accomplishing this using Cocos2d director class replaceScene method. My application will need to have around 40 view controllers, each with a few UIButtons that could take them to any other view controller.
For instance View controller 1 may have buttons that take you to view controller 2
View Controller 2 may have buttons that link to 3,4,5,12
view controller 4 may need to link to view controller 17, 5 and 3
Every tutorial and bit of documentation I've read only discusses using Navigation Controllers, Tab bars or pushing views modally. None of these solutions fits my particular requirements.
Cocos2d has the "replaceScene" method which does exactly what I need, but mixing the many UIKit controls that I need makes developing this entire project in Cocos2d a nightmare.
I'm looking for something where I can have the user tap a button which will load a specified view controller/view transition to that view, and unload the previous view controller from memory. Any ideas?
Have a root view controller which has references of your view controllers. Also make a weak reference to the root view controller in each view controller, as in a delegate pattern. If one of the view controllers wants to make a view transition, send a message to the root view controller. Let the root view controller hide the current view and unhide the next view, using an animation if you want.
Basically you are implementing a view container much simpler than UINavigationController and UITabBarController. You could probably achieve the same thing using the tab bar controller and hide the tab bar view, but I would implement a custom one.
my question is about view controllers, delegates and all that in general. I feel perfectly comfortable with UIView, UIViewController, Delegates and Sources, like UITableView does for instance. It all makes sense.
Now I have implemented my first real custom view. No XIBs involved. It is an autocomplete address picker very much like in the Mail application. It creates those blue buttons whenever a recipient is added and has all the keyboard support like the original.
It subclasses UIView. There is no controller, no delegate, no source. I wonder if I should have either one of those? Or all, to make it a clean implementation.
I just cannot put my finger on the sense a view controller would make in my case. My custom view acts much like a control and a UIButton doesn't have a controller either.
What would it control in my view's case?
Some of my thoughts:
For the source: currently the view has a property "PossibleAutocompleteRecipients" which contains the addresses it autocompletes. I guess this would be a candidate for a "source" implementation. But is that really worth it? I would rather pass the controller to the view and put the property into the controller.
The selected recipients can be retrieved using a "SelectedRecipients" property. But views should not store values, I learned. Where would that go? Into the controller?
What about all the properties like "AllowSelectionFromAddressBook"? Again, if I compare with UIButton, these properties are similar to the button's "Secure" property. So they are allowed to be in the view.
The delegate could have methods like "WillAddRecipient", "WillRemoveRecipient" and so on and the user could return TRUE/FALSE to prevent the action from happening. Correct?
Should I maybe inherit from UIControl in the first place and not from UIView?
And last but not least: my custom view rotates perfectly if the device is rotated. Why don't all views? Why do some need a controller which implements ShouldAutoRotateToDeviceOrientation()?
Does it make sense what I wrote above? In the end I will provide the source on my website because it took me some time to implement it and I would like to share it as I have not found a similar implementaion of the Mail-App-like autocomplete control in MonoTouch.
I just want to learn and understand as much as possible and include it in the source.
René
I can answer part of your question.
I just cannot put my finger on the
sense a view controller would make in
my case
The ViewController is responsible for handling the View's state transitions (load, appear, rotate, etc) These transitions are used mainly when you use a navigation component (UINavigationViewController, UITabBarController). These components needs to received a ViewController that will handles the view's transitions.
For exemple, when you push a ViewController on a UINavigationViewController, it will cause the ViewDidLoad, ViewWillAppear, ViewDidAppear. It will also cause the ViewWillDisappear, ViewDidDisappear of the current ViewController.
So, if your application has only one portrait view, you don't need a ViewController. You can add your custom view as a subview of the main window.