The Apple UI design guide suggests that a UIPageControl is ideal for presenting the top view of a utility app.
Would a paging view that appears at the 2nd or 3rd level down inside the main UINavigationController view trigger a fail during the App review process?
In my App I have inserted a 3 page view at the second navigation level down in my productivity style app. Each page presents a question and requires an answer that might by a multichoice tick or text box entry. The questions could be stacked vertically in a multi-section table but in my prototype flicking through the questions horizontally feels very natural.
However I have not seen an App store program that uses paging as I have.
I asked Apple a similar question recently and got back:
"Thank you for contacting the iPhone Developer Program. Apple is not able to provide pre-approval to developers for proposed application submissions."
In the end it really depends on the reviewer, the specifics of your app, full moon, etc.
Personally, I would simply try it. If the interface looks good and you think it will not confuse users, then just submit it.
Also, being rejected for stuff like that is not the end of the world. You just have to replace it with something similar. Happened to me once or twice. It is usually not a complete blocker.
Although you will probably not fail app review, I believe using a UIPageControl may be confusing to your users. As you pointed out, I can't think of any apps using the UIPageControl in this manner. The following quote from the iPhone Human Interface Guidelines is informative:
A page indicator gives users a quick
way to see how many views are open and
an indication of the order in which
they were opened; it does not help
users keep track of the steps they
took through a hierarchy of views.
Because the views in a utility
application tend to be peers of each
other, a page indicator is sufficient
to help users navigate through them. A
productivity application that displays
hierarchical information, on the other
hand, should offer navigation through
the elements in the navigation bar
(for more on this, see “Navigation
Bars”).
From your description of how this portion of your app is supposed to display, it doesn't sound like these pages with questions on them would be considered 'multiple views'. In addition, you probably want your users to answer each question sequentially and move on to the next. The UIPageControl is designed so that a user can switch between any of the views in any order they choose, not only in one direction.
This sounds much more like a hierarchical design, and this portion of your app would probably work a lot better if you used a navigation bar along with a UITableView. Requiring your users to answer a question by tapping a multichoice tick box, and then make them figure out that they need to swipe in a certain direction to get to the next question would not be obvious to a user, and could be much more intuitive. For example, as soon as the user selects a tick box, you could just programmatically navigate to the next question. Or, have a button at the bottom of each screen that's labelled "Next Question", which would transition to the next screen.
Hope this helps!
Related
I'm new to programming apps, trying to realize a project for iOs using xCode and swift.
As far as I've learned most people seem to work with the storyboard feature, but I've come across people that suggest to deactivate the storyboard and work with code only.
I'd like to know your opinion on what method fits my needs best for the intended project. As I am just getting started, I'd like to stick with the appropriate method right away for I'm probably going to invest a lot of time.
This is about what the app is going to look like:
myApp Layout
Now this is what it' basically supposed to do:
The "settings"-button (blue area, top left) is going to take you to a different view to set preferences. The "search"-button (blue area, top right) is going to change the title into a search field.
You can browse through 3 categories. Each of them contains a couple of questions. Those are stored in a database and are supposed to be displayed list style within the red area. The order of the questions is going to depend on the users preferences.
Clicking any of the questions is going to take you to another view that displays the answer. When viewing the answer the "settings"-button (blue area, top left) is changing to a "go back"-button.
Now as far as I've learned the blue area might be realized with a navigation controller, navigation bar.
The white section works pretty much like a toolbar. However I've read it's close to impossible to move the standard toolbar from the bottom to the top.
I've seen tutorials of people realizing this type of layout with (to me) complex code but without using the storyboard. Am I wasting time on figuring out how to manipulate storyboard objects? Coming from coding and programming websites the project looks so unbelievably simple. Is a project like this in fact rather complex to do as an app?
In any big project you will have to use all approaches, it is all about experience. For example, I am using StoryBoards to make 95% of my UIViewControllers elements, using XIB for static screens like error messages, some loadings etc. and using code to append some gradient views, shadows etc. It is possible that in future I will be doing all in a different way. But if you are a beginner - better use Storyboard, it makes getting into all of it much easier, understanding UIKit and iOS development overall.
I am a beginner to the iOS app development and working on a sample app that consists of just two "screens" - the first screen authenticates the user against user id and password saved in a SQLite database table and the second screen displays list of users in the database if user authentication is successful. If authentication fails I would just like an alert displaying appropriate message to the user.
I somehow can not connect how to "go to the second screen" if user authentication is successful. How can I tell the application that now that the user is authenticated it is time to go to the second screen and display the list of users?
I apologize if the terminology I use is not standard iOS app development terminology but I am new and would like to fill the gaps in my understanding. Please feel free to direct me to any links/tutorials/documentation.
Thank you.
Navigation is a fundamental and essential part of iOS programming and UX design. Traditionally, views are managed by ViewControllers, which in turn may be managed by NavigationControllers in stacks. To naivgate between and away from controllers, we define two new verbs: Push and Pop. To go to a new view, one pushes it onto the navigation stack. To transition away from a view, one pops it off the stack. And so, with these two paradigms, we can define simple transitions which are managed by the UINavigationController object. Have a look at the navigation guide in the docs before you proceed any further.
You don't appear to have sufficient understanding of iOS basics for any of our answers to be helpful. A word of advice: don't waste your time wrestling with code before you have a bit more of a foundation; you will just become frustrated.
Take a few hours and review some of the videos in Paul Haggarty's Standford iOS course.
Once you understand some of the building blocks and concepts of the API, things will move along much more quickly.
Are you developing against iOS with Storyboards?
If you start with the boilerplate "Master/Detail" template in Xcode for iOS 5 with Storyboards, you will get some sample code for a master view (uses a UITableView), detail view (uses a UIView with a label in it), and a segue between the two view controllers to go from master to detail, along with a "Back" navigation button that pops the detail view off and back to the master view.
The iPad boilerplate for that type of project is slightly different in the it uses a UISplitViewController to show both master and detail at the same time and doesn't use a segue between the two.
You could take a look at that boilerplate code, modify it, and go from there.
I have read a few posts about people putting in either their own icons or Apple's icons into a toolbar, or as a customview into the rightBarButtonItem. I was wondering if that's considered bad practice, ok practice, good practice, etc. I was looking around, and I saw this: http://www.techtree.com/India/Features/Top_5_Productivity_Apps_for_iPad/551-115236-899-2.html. In the Numbers app or Keynote App, it looks like they use a UINavigationController or some way to navigation + custom icons on the RHS. I'd like to do the same, but I didn't know if this was considered bad practice, or something to be avoided in case Apple changes things down the line. I basically want a couple bar button items and a UISearchBar. Having a search bar at the bottom looks funny to me. I noticed the Facebook app on the iPhone has a neat viewcontroller where you click the top left icon and it opens a way to navigate through their app. I don't know if anyone has a tutorial of what's going on there.
There are plenty of apps that do what your talking about, so Apple shouldn't give you any problems.
" in case Apple changes things down the line."
On the other hand, they can be finicky about any kind of app, so there are no guarantees. They may require all iPhone apps support landscape mode in the future. You never know.
Look over the Apple User Interface Guidelines if you want to know more about their "recommended" control use.
I am new to IPhone/iPad development and have a application design question.
1) I have about 60 different pages I converting from a Flash file. They are largely pretty devoid of stuff to do. Mainly reading and and some images.
2) There are a few interactive things (buttons, animations,etc.) on on about 50% of the pages
My initial thinking is to use a navigation controller (hidden, as I don't want as part of my design) to use the push and pop functionality. Each page would have it's own viewcontroller.
My other thought was to use hidden UINavigationController, but to group pages in specific areas and have multiple NIB files read from one view controller.
Is one better that the other? Or have more advantages than the other? Or is there a better way?
Not sure how to answer this, but you could probably have a few NIBs and ViewControllers and reuse them. There are a million ways to do simple navigation without UINavigationController -- it might be more of a pain that not using it.
For example, is navigation always like a tree (forward, forward, forward, back, back, back) --- or could it be more free form around a graph?
If navigation is simply push and pop, then use it, but try to keep the number of different viewcontrollers/NIBs to a minimum (for maintenance purposes)
The usual recommendation is one view controller per full page of content. However, if your content is remarkably similar, reusing the view controller is valid. Before proceeding, I'd think carefully about your navigation model:
Will users be able to jump from any page to another (say like a magazine)?
Do some pages require the user to visit other pages first?
For (2), the push/pop model works quite well, whereas for (1) the push/pop model of a UINavigationController may be too much trouble.
So focus on your presentation, and then let the code follow from that.
There are tons of resources concerning coding on the iPhone. Most of them concern "how do I do X", e.g. "setup a navigation controller", or "download text from a URL". All good and fine.
What I'm more interested in now are the questions that follow the simpler stuff - how to best structure your complex UI, or your app, or the common problems that arise. To illustrate: a book like "Beginning iPhone 3 Development" tells you how to set up a multi viewcontroller app with an top 'switcher' viewcontroller that switches between views owned by other view controllers. Fine, but you're only told how to do that, and nothing about the problems that can follow: for example, if I use their paradigm to switch to a UINavigationViewController, the Navigation bar ends up too low on the screen, because UINavigationViewController expects to be the topmost UIViewController (apparently). Also, delegate methods (e.g. relating to orientation changes) go to the top switcher view controller, not the actual controller responsible for the current view. I have fixes for these things but they feel like hacks which makes me unhappy and makes me feel like I'm missing something.
One productive thing might be to look at some open source iPhone projects (see this question). But aside from that?
Update
To clarify: I suppose what I'm asking about could be summarised as "Recipes and Gotchas for iPhone development". The sort of things that are of interest to developers, but aren't covered in any of the iPhone books etc. that I've seen, such as:
I'm writing an iPad app and want a UISplitViewController presented to the user only some of the time, which Apple seem to be saying I can't do. Is it possible? How?
Apple don't give me a way to stylise my app in a convenient, across the board way (e.g. font tweaks, or colours). How can I approach styling my app?
Memory management isn't made any easier by some of the inconsistencies in UIViewController method names (e.g. viewDidUnload is not the opposite of viewDidLoad, despite the name). Is there a consistent easy way to tidy that up and make view controller memory management less error prone?
How can I consistently and easily test my view controllers for behaving correctly when a memory warning comes in? It's easy to simulate a memory warning in the Simulator, but if the UI I want to test is showing (and is a 'leaf level' view controller), it won't get its view unloaded because it is currently visible.
N.B. I'm not actually asking the above questions here -- I think I have decent answers to them! -- just giving examples of 'good' questions that illustrate this stackoverflow question.
The WWDC talks available on iTunes U (at http://developer.apple.com/videos/wwdc/2010/) have some great information about structuring, especially in the Application Frameworks section.
If you're talking about code, use the Model/View/Controller pattern like in most Web applications:
The model code defines the objects that your program represents. A time tracker app, for example, might have model objects like Task, TimeSlice, and User (especially in a network setting).
The view code is provided for "free" with the iOS SDK, unless you need specialised view code. These are UIImageView, UIButton, etc.
The controller code bridges the 'gap' between the model and view. The controller will change the views to reflect the model selected by the user and facilitate the selection of model objects.
This is the base design pattern for any iPhone app, and it's the one that most will use.
If, on the other hand, you refer to what we in my company call UX (user experience) design, however, you can't beat the Apple HIG guidelines in the Apple iOS SDK documentation set, available online or in Xcode from the Help menu.
The other thing I recommend quite highly is to play around with some test/dummy code. Nothing can top experience. Experimenting with the iOS SDK and getting your hands dirty will allow you to truly learn the best ways to design apps.
Edit:
Also, delegate methods (e.g. relating to orientation changes) go to the top switcher view controller, not the actual controller responsible for the current view.
Can you clarify? In all of the apps I've written, the currently shown view controller receives the orientation change methods. Note that there are two methods. shouldAutorotateToInterfaceOrientation: allows you to decide if the view should rotate, and didRotateFromInterfaceOrientation: allows you to re-layout the view if necessary.
Please go through this link. In this they have explained clearly about design patterns.
http://www.raywenderlich.com/46988/ios-design-patterns
You might want to consider watching videos like the CS193p course from Stanford on iTunes U. They go through the most important parts of iOS development in deep, and give some source code.
As far as I can tell, there isn't a book or resource which deals with the sort of advanced gotchas and recipes that I was looking for. Loads of useful resources exist, but just not addressing the stuff I'm thinking about.