Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
I would like to start with an excerpt from Segue Types: "In iOS, the segues are further divided into segues that adapt to size classes and the older, now deprecated types."
So, adaptive for segues means the same thing as it does for layouts: we can specify a set of segues wherein the segue that is actually used is determined by the size classes that are in effect (the same as we do when we create a set of size class dependent auto layout constraints). Great! However, as far as I have been able to discover, there is no way to actually do that. Can anyone help to clarify this?
New segues adapt to presentation style, not so much to the size classes (although the two go hand-in-hand).
The idea is to help you build a storyboard that targets both iPhones and iPads, with their different styles of presenting data hierarchies arranged as master-detail.
Building a universal application with old-style segues required your app to see if you are in a split view controller (bigger screen) or in a navigation controller (smaller screen), sending a Push or Replace segue based on a situation. New segues let you send a Show or a Show Detail segue, which sense the view controller kind, and do the right thing for your UI style.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have list of mail items in one View and I have nav bar button "New" to create new message.
All samples I've seen online say that this "new message" screen should be modal. We open it, write message and send it. Thats it. Since there is no navigation from this screen - it's use case typical modal view.
But I find that I really like "Push" this view. I get title for free, I get back button for free, I can add "Send" button to preconfigured title bar.
In code I can do "pop" on navigations stack after entered message processed. What's bad about it? So, it sounds like it should be modal but "push" much easier to do via storyboard.
According to Apple's Human Interface Guidelines:
Use a modal view when you need to offer the ability to accomplish a
self-contained task related to your app’s primary function. A modal
view is especially appropriate for a multistep subtask that requires
UI elements that don’t belong in the main app UI all the time.
Modal Views
This is largely a preference thing and depends upon what you are trying to accomplish and whether you care if the user explicitly acknowledges his edits or not (i.e. save/cancel). It sounds like you have a reasonable case for push in your example so I would go with that. If you find that you are moving toward implementing features of a modal VC while using a push, then switch over to modal. I do not believe there is a hard and fast rule for this.
The following answer provides some additional nice reasons to go modal or push
Modal vs. Push
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 8 years ago.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Improve this question
I would like to create something like the image below in my iOS app. What is the best way to approach this, note the rows and the columns can vary.
The easiest way I thought of was to insert html table into UIWebView, but not sure if there is a way to intercept radio button clicks like there is for a regular button by making it a "href link"
A little unrelated to what you have as the title of your question, but maybe look at using UISegmentedControl. It's the closest thing to radial buttons that exists in the Objective-C world.
If you went with a segmented control, you no longer need to worry about columns, intercepting touches, and a lot of the other problems you mention in your Question - it could all be done in a normal UITableView. You would have to create some custom UITableViewCell subclasses to get the segmented controls in, but there are a lot of good tutorials (YouTube, Apple Docs, SO) on how to set those up.
From iOS 6+ you could use the UICollectionView class to build up a grid. Managing the values in the data source (representing if a radio is checked or not) is something you'd have to implement yourself.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
We are working on a layout design for our social media area and wondering if a layout like the following would be rejected by Apple ? Is a double Tabbar design on the bottom allowed for a use case as shown ?
Generally - you won't get a definitive answer about what will and will not be approved by Apple. Because it's not something that a definitive answer can be given for. They have guidelines, and apply them as they see fit.
However - in this case I would say no. For the following reasons.
Tab bars are generally supposed to be used as the root view of an application. If you have one embedded with the other, what is the root view.
It takes up a lot of screen space to have two rather than one, it's not like it's a toolbar
It's ugly.
Apple reserves the right to reject any applications that violate their Human Interface Guidelines (HIG). Stacked UITabBars violate the HIG. That being said, this isn't the place to ask. No one here can tell you what a particular reviewer on a particular day will do.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I am trying to learn some of the basics about creating views and view controllers on iOS. All the samples and documentation I've come across use the Interface Builder and NIB files to create UIViewControllers and UIViews. How to create the controller and the UIView programmatically and not use the interface builder?
You may do that, that's for sure. But you should see the pros and cons here;
You create and manage everything in code, neat huh?
Well this means, you will retain/release everything yourself.
You will write lots of boilerplate code just to create a complex view with more than one layer of component hierarchy.
You will not see the properties you may change, instead you need to see the Class Reference document for each component.
You need to play with pixel values a lot, i cannot emphasize how long this "a lot" will eventually be.
So, consider Interface Builder, it is easier to keep everything seperate, and then bind them as needed. Code maintenance is much more important in the later phases, as the app becomes mature.
I have been through both ways, and my vote is +1 for Interface Builder, and override stuff only when needed. That is in practice less than like 5% of your UI development time.
The short answer is that yes, of course you can create views and view controllers programmatically.
As someone who had this same feeling when I first started out, let me impart this short bit of wisdom: Do not try and remove all .xib files from your project until you know a lot more about what you are doing!
There are tutorials out there on how to remove the .xib files entirely from your project, and remove dependency on MainWindow.xib. In my experience it is definitely not worth your time. Just leave the .xib files in your resources folder, close it up and pretend they don't exist.
Eventually, you may even be happy they are still there.
Yes,
You can create UIViewController and UIView programmatically,
See the Apple documentation for UIViewController and UIView, there are many function which start with init, used to create programmatically.
Suggest you to invest some time reading Documentation.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
is there any code difference between ipad and iphone? How can we convert iphone application to ipad application?
Codewise, the main difference is in the very different screen sizes leading to different user interface considerations. But there are a number of differences. For example,
Some classes, such as UIPopoverController and UISplitViewController, are only usable on one type of device.
Some classes behave differently, for example UIActionSheet doesn't come up from the bottom on iPad and doesn't display the cancel button (as cancelling is done by touching anywhere outside the bounds of the sheet).
Some methods don't work right on one or the other device. For example, some of the methods for presenting a UIActionSheet should only be used for iPad, and others should only be used for iPhone.
Some behaviors are only available on one or the other device. For example, UIViewController's modalPresentationStyle is ignored on iPhone.
Most of these are documented, some only show up as warnings in the console when using the "wrong" method, and some you just have to figure out they don't work right. Fortunately, UI_USER_INTERFACE_IDIOM() makes it easy to tell which device your code is running on so you can easily handle these differences.
It is exactly the same except for the dimensions of the screen. There are still some code changes though to enable iPad mode if you are writing a cross compatibile app.
Resource:
http://iphonedevelopment.blogspot.com/2010/04/converting-iphone-apps-to-universal.html