What's the best way to control orientation changes when they happen too rapidly and overlap in time? In my application, I display a PDF document and scale it according to the current aspect ratio. It works OK if the new orientation changes occurs after the previous one completed. Otherwise, I seem to get an inconsistent state (e.g. portrait aspect ratio display in landscape mode).
Thank you,
Sam
I don't know which event you are using your code in.
If you are using -didRotateFromInterfaceOrientation or -willRotateToInterfaceOrientation it should work correctly. But if you are using the deviceoriention notification for this it can cause a lot of trouble.
Related
I am designing my first iOS app at the moment. Every view of the app needs to be available in portrait aswell landscape. Also all iPhone versions need to be supporrted.
As someone always working with windows and never owning any apple product it was a pain in the ass getting started but slowly things seem to work out. But before the whole design approach takes a wrong direction I rather ask here:
What I want to do is have constraints based on multipliers as much
as possible.
I will try to avoid constant values as much as possible since from
my understanding they arent scaling. I read that you can change them
programmatically but if possible I want to stay in the designer for
frontend related stuff.
Since the multiplier cant be changed based on the current size class
I plan to have a set of constraints for all kind of portrait size
classes and another one for landscape (using installed feature of
xcode)
To up and downscale labels and textviews I want to have a height
constraint to the superview with a very tiny multiplier (will
probably be complicated to keep all textviews the same height when
there are different parents across them?)
In theory this should produce views which up and downscale well and look the same on all kind of iPhone screens. Now I am curious what more experienced iOS designers think about my "plan":
Do you have different approaches?
Is there any book/tutorial/page you can suggest?
Thanks in advance! :)
i have issue with zoomed display.
on IOS until today i did not see any changes on my apps when user turn on zoom display .
now i developing an application, use auto layout constraints like always ,
but this is the first time that i saw that when user change setting to zoom display zoomed mode all my app get zoomed and the resolution get messy.
i tried every thing to understand the difference and stil get nothing.
i want to ignore the zoom, that the app act like normal mode,
is this possible?
You can't ignore the scaling... I think adding proper launchscreen file in your target settings may solve your problem.
I'm taking a few first steps in Xamarin for iOS and having a very hard time figuring out how to create a view that is resolution independent.
I have a single textbox in the view, aligned so that its edges meet the edge of a iPhone 6S. When I change the View to a Iphone 4S the edges of the textbox are outside of the view.
I have tried to drag the constrains to the edges, pretty much clicked every button and tried to find some example of how to make it so the view resizes to fit the viewport but I cannot make it work. Ive also fiddled with the different modes of the View (Aspect Fit, Scale to Fill, etc) but that makes no difference.
I would love to se a simple example of how to create a resolution independent or multi-resolution form or view that is displayed similarily no matter the screen resolution on the iPhone.
Having gone through very much the same pain as you, my recommendation is two-fold:
Have a look at the Cirrious FluentLayouts package, which you can
get from NuGet.
A tremendous help in simplifying various issues with auto-layout, especially if you decide (like I did) to just give up on the GUI layout tools and go with a full programmatic approach.
It will allow constructs like:
this.AddConstraints
(
_navBar.AtTopOf(this, UIApplication.SharedApplication.StatusBarFrame.Height),
_navBar.AtLeftOf(this),
_navBar.WithSameWidth(this),
_navBar.Height().EqualTo(Hamburger.HamburgerHeight),
_scrollView.Below(_navBar),
_scrollView.AtLeftOf(this),
_scrollView.WithSameWidth(this),
_scrollView.Bottom().EqualTo().TopOf(_pageControl),
_pageControl.Above(_toolBar),
_pageControl.AtLeftOf(this),
_pageControl.WithSameWidth(this),
_pageControl.Height().EqualTo(pageControlHeight),
_toolBar.Above(_button),
_toolBar.AtLeftOf(this),
_toolBar.WithSameWidth(this),
_toolBar.Height().EqualTo(toolHeight),
_button.AtRightOf(this),
_button.AtBottomOf(this),
_button.Height().EqualTo(buttonHeight)
);
Be aware that since... iOS 8 I believe? ... you now need to use a
LaunchScreen.xib to have your app correctly pick up device
resolution which will then be used by auto-layout.
This was the one area I still needed to use the graphical layout tool for - just once, happy to say.
Now I adapt my app for tablet PC. I ask how can I fixate form when the screen was rotated. Good people says that I must adapt my app for portrait orientation and they're right.
Some forms is very specific and it's very hard (maybe impossible) to re-design they for portrait orientation. So I think I can create a illusion that my app works only in landscape orientation.
That's why I need rotate standard VCL components in Delphi XE2. For example for standard memo I need write text not only from left to right (or right to left) and from up to down (and from down to up).
Also I need rotate button. Now I use standard TButton and TRxSpeedButton.
I think enough to rotate the text for TButton but I don't know how I can do this?
In case of TRxSpeedButton I use glyphs. In theory maybe I can override canvas and change pic. Another way is create 2 buttons (one for portrait orientation, one for landscape. Each one will have their special glyph) and change their visibility. But I don't like 2nd variant because in this case exe file will be very plump, I don't like plump exe))
Thanks for advises.
You've no realistic chance of making this work using standard VCL controls. VCL controls don't have a mode that allows them to be rotated through 90 degrees. I see no easy prospect for making any control that displays text do so rotated. That's just text output. What about text input? There's also the issue of shadows and 3D effects which are based on a specific orientation. The list goes on and on.
In my view, if you want to make this work well you'll almost certainly need to write an entire GUI framework from scratch.
Whilst it is clear possible to do this it doesn't seem like a realistic choice when set aside the alternative of making your app work in both portrait and landscape orientations.
You have no chance with fake landscape approach.
There are three solutions for your problem:
Best one - make your application work with any screen size / orientation combination. This is the Windows way.
If your application "must" work in landscape mode, inform users when you detect wrong orientation, that application only functions in landscape mode. Show either message box, or special form with message that cannot be missed, while you hide your other forms, or something like that.
Lock device in landscape mode, like described in How to prevent the screen from automatically rotating on a tablet? But you should know that this is not the way Windows are meant to be used in Desktop mode.
The VCL was not built for this, so I dont really see that happening without major work done to the presentation layer of the RTL.
The have been skinning engines that were capable of this, but they essentially patched the RTL and took over rendering. Rotation data was held in a lookup table for each control that you had to set separately from the actual class.
If Delphi had support for partial classes like Smart Pascal does, then perhaps (if the architecture allowed it) this could be postfixed. But as of writing the VCL is simply not made for this. I am writing a tweening library as I type this, so I have looked into this.
One way that might work for you would be to use the PaintTo method of various controls. Have them paint their fully drawn image onto a bitmap and then rotate the bitmap by 90 degrees to get the portrait versus landscape effect. Then draw that image on the canvas of your form in its OnPaint method (you would want to make the actual controls invisible when in the portrait mode, showing only your painted and rotated bitmaps.)
There are some controls (like TRichEdit) whose PaintTo Method doesn't work correctly, though. So this may be of limited use for you. Another way is to grab a screen capture of the entire client area of the form on the desktop and then rotate and display that. that works even with TRichEdit...
I'm refactoring one of my apps from the iPhone to the iPad and this has resulted in the removal of tabs as I've been able to combine functionality onto 1 screen and use popovers to enable the user to select stuff that previously required a new tab.
I'm basically left with 2 tabs now. One (which is best viewed landscape) shows a map of the world with some overlays drawn on it plus an indication of where you are. The second is a data display with a few graphs which is best viewed portrait.
I note what Apple say about requiring apps to run in all orientations on the iPad, and of course I could do this, and keep my 2 tab bar buttons to switch views.
HOWEVER
In this case, there is 1 view that is best suited to landscape view and 1 view that is best suited to portrait view. Would be be appropriate (or even Apple permissible) UX design to drop the tab bar and switch views on an orientation change instead?
From a user perspective, you wouldn't need to be switching back and forth much, you tend to use the landscape view to change location (if you need to) and then work mainly in the portrait view - so I don't think it would be frustrating and dropping the tabs seems to make more sense to me.
What do you think? Any best practice in these situations?
Roger
London
I would say that the best practice is not to restrict the orientation of views.
The central idea here is not to force the user to hold the device a certain way. For example, a lot of people use iPads in a stand or holder and input with a keyboard. Do you want to force your users to stop and physically adjust the device in the holder/stand before they can read the view in the other orientation? Other people simple prefer holding the device one way or the other and lock the orientation (I do that a lot.) Forcing users to change from their preferred device orientation won't win you happy customers.
Apple will not penalize you for a non-standard UI unless it reflects badly on the device itself. As long as the end users can tell it's your apps non-standard behavior, Apple does not care. However, in my experience, end users tend to interpret non-standard interfaces as flawed or broken because they don't understand them.
In this case, if I launch your app for the first time, how am going to know that changing orientation changes to another view altogether and another data set? Nothing in the standard UI teaches me to expect that. I will have to discover it by trial and error. If I have the orientation locked, not even trial or error will help. At that point, I might well conclude that the app is broken.
You could try adding instructions but just the thought that they might be necessary is a red flag for a potentially poor UI.