I am currently writing scenarios for the application. I came across these terms growler and modal. Can someone please explain what these term means.
Those are two types of notification:
the old one (growl): a Mac OS X program that show little popup windows in the corner of the screen that dissappear after an amount of time or have a little x on them
the new modal one, using the form and page sheet style can be dismissed with a pan down gesture, which changed with ios13
Related
Good evening everyone,
I am trying to code my first macOS app with SwiftUI in Xcode. Among other things, I pay a lot of attention to an appropriate design. I prefer padding around the window buttons as seen in this picture (example: finder):
But at the moment, there isn't much padding around the window button as seen in this picture:
Is it possible to change that in SwiftUI? Thanks for every answer!
(Sorry for my English)
You're gonna have to use a toolbar
Newbie iOS programmer here, so apologies in advance if I can't see the answer right in front of my face. :)
I just added iAd to my sample app. I'm running into a problem where when the user dismisses the ad, my numpad, that was displayed before clicking the ad, doesn't reappear. I need the numpad to display after the ad has been dismissed. Could you explain how I can capture the event for ad dismissal so that I can redisplay the numpad? I have not been able to find a solution to this simple problem.
My app is very simple and was built to teach me iOS programming. It's a speed converter app between miles per hour and kilometers per hour. I have two fields for each of those data. I had the numpad displayed at all times and it worked well, until I put in iAds.
I noticed that when I click on the ad, the numpad is dismissed before the bigger add is displayed. Then when the bigger ad is dismissed, I'm returned to my previous screen but the numpad is not displayed. I can get the numpad to reappear when I click on either the miles or kilometer field.
On viewDidLoad, I initially have the numpad displaying with [mile becomeFirstResponder]. "mile" is the name of the miles per hour field. If I knew how to capture the user clicking on the ad to dismiss it, I can then reissue the command: [mile becomeFirstResponder] to display the numpad.
I hope you understand my circumstance and what I'm trying to accomplish. Maybe my problem is in a different area. Is there another easier way to have the keyboard always displaying?
I'm using Xcode 4.2.
Thanks.
look to ADBannerViewDelegate and its property :
-(void) bannerViewActionDidFinish:(ADBannerView *)banner
http://developer.apple.com/library/ios/DOCUMENTATION/UserExperience/Reference/ADBannerViewDelegate_Ref/Reference/Reference.html#//apple_ref/occ/intfm/ADBannerViewDelegate/bannerViewActionDidFinish:
In terms of providing a nice text popup for users in an iPhone application, after they click on a help icon, what approach/style do people recommend?
In my view (re User Experience) I would have thought something that say:
has a thin border with rounded edges around it
takes up most of the screen
has a vertical scroll bar if there is more text than can fit on one screen
has a way for the user to dismiss
Interested in:
recommended approach re UI design
how to implement (which IOS UI objects to use)
nice to have - example code
The thing about designing iPhone UI elements, including popups, is that you're very strongly recommended to do it "Apple's way" - follow their Human Interface Guidelines and use standard UI controls. The two ways I can think to do this offhand:
Use a UIAlertView for a single chunk of text - it includes buttons for dismissal, properly shaded and colored for consistency with the rest of the OS and other apps. This is a quick, one- or two-line way of putting text on the screen and taking it off again. The downside: there's no scrolling capability, and the box scales with the text you put in it (i.e. you can't fix a size for the view).
Use a new view (in a UIViewController) presented modally. This option gives you more flexibility and the capability to scroll, but at the cost of greater setup.
If you decide to go the second route, follow your existing instincts for how to lay it out - you'll take over the entire screen on an iPhone, so you have some wiggle room. Your rounded-edges guess and vertical scrolling are right on (consider a UIScrollView for implementation).
I have a view (a couple of them actually) with a standard search bar at the bottom. When the user touches the search bar, I need to move the search bar up so it's not hidden by the keyboard, then down again when the keyboard is dismissed.
I do this the same way as everybody else, by observing UIKeyboardWillShowNotification and UIKeyboardWillHideNotification. From these notifications, I get the height of the keyboard, and that tells me where to put the bottom edge of the search bar. It works perfectly, except for rare cases when the search bar doesn't animate, or doesn't animate far enough, and vanishes behind the keyboard. I have seen this a handful of times out of hundreds of tries with myself and my QA people testing on iPhones and iPods. Just once, I saw the search bar fly off the top of the screen as the keyboard came up. We've never seen any of this on the simulator, and we see it more often on the iPod than the iPhone. We are running iOS 4.x, mostly 4.3.3.
So I can think of two possibilities. One is that very occasionally UIKeyboardWillShowNotification is not sent and the other is that the data in the notification is wrong. The second one would explain the one case where the search bar flew off the top of the screen.
And then of course it is possible that my code is wrong in some very devious way; but the scenario is so simple -- enter the view and tap the search bar -- that I can't see how a bug in my code could cause these rare and intermittent failures.
If anyone can offer insight, I would be very grateful.
I finally discovered the answer to my question, and it's interesting. To cut to the chase, my search bar is animating into the wrong position; in some cases it's still behind the keyboard, and in others it's off the top of the screen. This is not caused by wrong data in the notification, but by a bug in accessing the height member of a CGSize or the y member of a CGPoint.
Specifically: in certain scenarios, when you write mySize.height, the generated code accesses mySize.width. If you are reading, you get the value of mySize.width; if you are writing, you clobber mySize.width. Similarly, myPoint.y actually accesses myPoint.x.
You may never see this problem. I only saw it on older iPod touch devices running iOS 4.2.1, and only in Release builds, and only when compiling with Apple LLVM Compiler 3.0, and then maybe only sometimes. But I reported it to Apple and they say it's a duplicate of a known bug (#10043857) that they are addressing. Connecting a few dots, I am guessing that it's somewhere in the compiler chain in Xcode 4.2.
The workaround is to take the address of the CGSize or CGPoint struct, then use pointer arithmetic to access the desired member. I wrote a set of little helper functions to do this, and I call them all over my app's code.
When I've learned that I have to write some code to make the iphone keyboard go away. I was quite surprised. I was surprised even more when it become apperent that it is just the top of the iceberg.
What are the expected UI behaviors that aren't provided by system OOTB?
Is the list below complete?
The expected UI behaviors:
Focusing next text field when [done] is hit
Hiding the keyboard when background is hit
Using Touch Up Inside to fire a button action. (To give user opportunity to change his/her mind)
Supporting the screen rotation.
Some of that is silly, but some of it has uses as well.
Focusing next text field when [done] is hit
Which field is "next"? If you have a large form with fields both next to and above/below each other, next might not be so obvious. Even if they are in some linear layout, the iPhone would have to work to figure out which one is next. Do you want to wrap around at the end of the form, or dismiss the keyboard, or submit the form?
Hiding the keyboard when background is hit
I mostly agree with you here, though there are a few cases where this is useless. For example, adding a new phone number in the contact app.
Using Touch Up Inside to fire a button action
This one I really don't get. I can only guess that it's designed to allow you to use buttons instead of the touchesBegan/Moved/Ended methods. I guess it could be useful, but I've never used anything but Touch Up Inside.
Supporting the screen rotation
Many apps just don't work in any other orientation, such as games. If you want to use rotation, you only have to add two lines of code assuming you've done your layout well.
I hope this helps explain some of the strangeness. Aside from the keyboard dismissal, I've never really found anything too annoying. The one thing I wish they supported was using the highlight state of UIButtons for the set state. It would be a quick and easy toggle button, but I've taken to screenshotting a highlighted button and using that for the background image of a selected button.
Want a rounded rectangular button that isn't white? Since that one uses a background image, you can't just click something somewhere that makes it the color of your choice. You have to create your own image or you could even use CSS (WTF!?) to do it.
Unfortunately, the iPhone SDK lacks a lot of helpful things one would think would just be there. However, many people have taken the time to write wrappers for many of these kinds of things to help facilitate development - a quick google search into the functionality you are expecting may turn up a lot of useful answers!
For example, you could make the keyboard go away when you tap outside of it by creating a new view when it appears, and placing that view behind any user-interactable views on the screen. When that new view is tapped, it will become first responder and cause the keyboard to slide away (because the UITextField is no longer first responder).
Such a thing could be easily implemented as a drop-in fix for pretty much anything you'd need it for with very little code.
Still should have been included in the SDK in the first place, though!