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.
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'm developing an app in IOS using Storyboard for the Ipad. I want to add UISplitViewController as a subview of my app. I want to generate this kind of output (see below image). when user click on FirstView's 'Next' button, a second view-splitview should appear.
Output:
But Apple's guidelines says that we can't push UISplitViewController as a subview of module. if we use a UISplitViewController, it has to be visible at all the times in our app.
so
when i tried to add any splitviewcontroller directly into the storyboard, it generated the error .
Split View Controllers cannot be pushed to a Navigation Controller
I dig around the net but unfortunately couldn't find any proper help.
is there any official alternative to use such a kind of facility by Apple itself?
or any link to the working code or samples to implement such a kind of functionality.
If i'm using third party solution, will my app get banned by Apple App store as they don't allow to do so?
I think this is a very basic kind of functionality which many people needs to implement in their app as a submodule. So there must be a inbuilt facility by apple. may b i don't know about it.
any help would be greatly appreciated.
This isn't an answer to your exact question, but may help in part.
I have an app that uses a UISplitViewController that is a subview of a UITabBarController.
This goes against Apple guidelines, but was desirable for my design that started originally as an iPhone app, and that I wanted to convert to a Universal app. I also wanted to maintain the UI convention of my app that the iPhone users were familiar with.
Unsurprisingly, there were problems with the notification of the orientation to the various UISplitViewControllers that weren't visible (though it would seem that Apple could support this if they chose to).
The workaround was to use the new API added in iOS 5.0,
splitViewController:shouldHideViewController:inOrientation:
...and always return NO. Not the ideal UI arrangement, but it works, and was accepted by Apple as an app update.
So, (clearly) you'll need to do this programmatically, rather than use Storyboards, but I think if you can get it working, Apple may approve. I wouldn't recommend you risk this if you can avoid it, however.
What options do I have when creating menu with options (contextual menus). What is allowed and what does Apple provide?
I have a toolbar with buttons and a click of a button opens a menu with options:
Examples:
UIPopoverControllers are only available on iPads, but it's ok to create similar looking things for iPhone
What you see in the picture, is entirely custom. a UIView subclass likely. There are pretty much no limits to what you do with your UI, within reason, so no ugly highly contrasting primary/secondary colours, and it's best to keep it at least similar to the native UI. If you say use a windows 7 phone ui style in an iPhone app it's more likely to get rejected by Apple, than keeping to the style of iOS.
So make it look as "professional" as possible, using gradients and shadows, edge arrows, like in the above picture.
Apple provides pretty much nothing that your looking for,
Similar built-in widgets would be UIPopoverController (iPad-only) or UIActionSheet. I like your menu better though.
I would also recommend looking at the guidelines for such custom UI elements. I can not say what is 'allowed', but Apple is not shy about how your app should look/feel/function.
Towards the top of this link talks about toolbars, status bars, etc.
http://developer.apple.com/library/ios/documentation/userexperience/conceptual/mobilehig/UIElementGuidelines/UIElementGuidelines.html#//apple_ref/doc/uid/TP40006556-CH13-SW1
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.
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!