I am planning to use a couple of picker controls and segmented controls (as a kind of control panel) embedded in a container view controller to control the contents of a second child view controller. However, according to Apple iOS Human Interface Guidelines, on an iPad a picker may not be presented in the main screen and must be presented in a popover:
On iPad, present a picker only within a popover. A picker is not
suitable for the main screen.
How strict is this rule?
Would it be ok in my case to have the picker on the main screen in order to provide the required interactivity?
Clearly the answer to your question really depends on Apple, not on anything we developers might think or say. Your screen design looks very reasonable to me, but the issue is really whether Apple will approve it.
It might be better to ask if anyone has had an app approved with pickers outside of popovers.
Alternatively, you could ask if anyone has had an app rejected for using Pickers outside popovers.
Apple rules and common sense have a high degree of overlap, but where they differ the only thing that matters is Apple. Either ask them, or just submit your app for approval and see.
Good luck!
Here is my experience regarding picker.
I had an app (say appAA) approved, which use picker view in a modal view, three pickers, one followed by another.
I had another app (say appBB) which basically copies the modal view of appAA. This app was rejected because of a functional problem which I could not reproduce. I debuted in Resolution Center, then the reviewer rejected again with additional reason, saying the pickers are not presented in popover!
I guess I have to put the pickers into the popover if I want appBB to be approved since the review mentioned so.
I think the answer is simply How ugly does it make the UI look?
The left/right edges of the picker were originally intended to be flush with the edge of the iPhone screen (and it was hardcoded to be 320px wide, which failed to work sensibly in landscape mode). On the iPad, the UIPopover lets it be flush with the frame. The obvious way to achieve this effect without using a UIPopover is to draw your own frame, instead of leaving a flat grey background between the pickers.
However, the easiest (and better looking, IMO) solution is to take the picker background (as a 1px-wide image) and use a UIImageView to stretch it behind all the pickers so they look like part of a continuous bar. Remember to check both retina and non-retina versions.
Related
In our app we are tracking screen views manually by adding relevant codes in viewWillAppear functions. With iOS 13, with the non fullscreen modals, the viewWillAppear of the parent screen won't get called when the modal is dismissed and hence wrong screen names are reported there after, for events originating from the parent screen.
I have checked the Detecting sheet was dismissed on iOS 13 , but the solution to implement UIAdaptivePresentationControllerDelegate helps when you manually swipes down.
I then turned off manual tracking and turned on Automatic tracking and surprisingly the screen classes are determined right. Question is how Firebase is figuring that out?
Of-course I can't use auto tracking as we need custom screen names.
I believe this could be a generic issue for whoever using manual screen name tracking and have non full screen modals. Just wanted to check what's the best way to solve this.
Couple of ideas I had was
Make all modals full screen. Not nice for our app
Implement extra delegates in those modals to let the parent know its dismissed. Not sure its a nice way
Setting screen names on each event? Could that be even possible?
If there are any other nicer/ cleaner option let me know.
Currently it is cumbersome for the user to repeatedly scroll and take a screenshot if they want to capture more than what can fit on the screen at a time.
I would like to implement functionality such that at the request of a user (e.g. via tapping a special button on a custom keyboard), screenshots of the entire scrollable area of the currently opened app are automatically taken and stitched together.
Is this possible? And if so, how?
To clarify, the application containing the scrollable area is a third party application over which I have no control, e.g. iMessage or Facebook.
Edit: I am aware of answers like this one and this one that are about taking screenshots within an app that I control. As far as I can tell, these are not applicable in my situation. Please correct me if I am wrong about this.
This is not possible. Each app is contained in a protected sandbox that no other apps have access to.
You could make a custom keyboard, but you still wouldn't have access to any of the views in the app that you don't control.
I have issue when I try to push view controller in willTransitionToPresentationStyle:. The view was blinking for a split second before it fully expanded. It might be a small glitch or bug since iOS 10 and Xcode 8 are still in beta. But when I manually requested to change presentation style to MSMessagesAppPresentationStyleExpanded by calling requestPresentationStyle: after I push view controller, it went to expand mode more smoothly. Does anyone have similar issue?
I have had similar problems with transitions in iMessage apps. I think this should improve considerably when iOS 10 and Xcode 8 come out of beta, but for now we have to deal with Xcode's bugs.
There's a few things I've done to make this look better. Inside my extension I have a method that checks the presentation style every time the view changes. This method manages two different UIs - one for MSMessagesAppPresentationStyleExpanded and one for MSMessagesAppPresentationStyleCompact. This method hides and shows specific views accordingly. In my compact UI I have a button that allows the user to expand the interface by clicking it (this is basically the same as clicking the up arrow at the bottom right of the screen).
I've noticed that if you let the user expand the messages app after the view has been loaded for a while the transitions are much smoother and less buggy. Not sure why this is the case, but you should give it a try. Also, I've found segues to be extremely buggy, so that's why I went with keeping everything on one view controller.
New to iOS developing here. Basically I am creating a soundboard app. I have the app essentially working (aka buttons returning sounds).
However my app only looks proper on the iPhone 6. I just have one ViewController in my main storyboard. When I run the simulator for the 4S/5/6+ or iPads, my buttons are pretty much everywhere.
I tried playing with size classes/autolayout through Apple's documentation, but couldn't get it working properly. What's the best (easiest ;) ) route I can follow to have it basically looking the same on ALL devices?
PS: I have one background placed too, I don't mind if it looks different on all devices since it's pretty minimalistic, but if someone can shed some light here too, that would be great.
Thanks!
You have a few options:
1) Continue your plan spending time getting friendly with Auto Layout and Size Classes. This might be difficult at first, but it will really pay off later. You should use the Assistant Editor's Preview mode to let you see iPhone 4, 5 and 6 side-by-side as you work so you can make sure your layouts look great everywhere.
2) Use a component like UIStackView where layouts are automatically adjusted to fit various devices. If your soundboard is as simple as a grid of buttons, you can do that in just a few minutes using a stack view.
3) Use a component like UITableView or UICollectionView where content is designed to scroll. Using this method you design only one sound button of your app (i.e., enough to play one sound) then have iOS replicate that across all the sounds you want. When your interface is presented on a device of a different size iOS will just make the content scroll.
Very roughly, option 1 makes you do all the work; option 2 makes your layout shrink down until it fits the available space; and option 3 makes your layout stay the same size no matter what, but you should expect it to scroll on some devices.
There is no right solution; it's entirely down how you want your app to work.
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.