I am trying to figure out how to best convert many of may apps to Split View apps for the new iPad. What are some of the best ways to go about this, minimizing the amount of transition code needed?
Remember, the code is under NDA, but discussing generalities on the design architecture is not.
One thing I have done is making screenshots of the Keynote and that Ive movie. They show a lot of application in them and for now those are the best hints on how to do good UI design for the iPad I'm afraid. The mail app is a really nice example of the split view I think.
Related
I have just spend a lot of hours re writing my app to have it all in code instead of using storyboard.
Mainly because I wanted to understand what the storyboard did for me.
Obviously with this, I have noticed that my files have become severely big in terms of lines of code.
Apple seems to be more in favor of storyboard then writing lines of code, as per their WWDC videos.
As fellow developers do you still feel that writing everything out in code is the better way to go? I hope to get a good few opinions on this as I want to see if my feelings on the matter are supported by your ideas, having done this for a longer period of time no doubt.
Thanks in advance.
There are few advantages and disadvantages of both.
Advantages of adding controls by Code
You can prefer writing everything to code if most of controls are dynamic. So that you can load controls whenever required.
Its easy to reuse code and make application more dynamic e.g you want to make UI themes for application
Advantages of Storyoard/ XIB
Using Storyboard/ XIB load all controls(Better if application is static) at once for that view you have to just bind properly.
Design UI with storyboard/ XIB is easy as compare to code.
These are few advantages of both as per my understanding.
making application through the code, helps developer lot, it gives flexibility.but going through the storyboard decreases lines of code. for mobile application development decreased number of lines codes or less code is always welcome.
I am relatively new to Objective-C / iPhone programming, and have only created single view applications thusfar. I am interested in creating an app soon than will have a "wireframe" in a sense that allows me navigate the various views of my app using buttons. So I guess my questions are:
What do I need to do to make an app that has more than one view
How to I link them with UIActions in buttons to navigate the various screens (ex a back button to go to a previous screen)
and I may have more as I go, but this is a start.
Thanks!
Since no one really had a clear helpful answer, I will share my own conclusion. Xcode 4 offers a very intuitive and interactive way to create multiple MVCs and segue between them even providing the interface to travel between views. I found out how to use this feature from Paul Haggarty's iOS course on iTunes U. I highly recommend it.
Joey
You'd can use a combination of, multiple UIViewController and or UINavigationController's. Utilizing methods such as presentModalViewController:animated: and pushViewController:.
For my job, I've been writing an iPad application that the user can enter data into, view some pictures, etc. It's been annoying me that I'm reaaaallly slow at writing in Obj-C and I find myself bogged down in the UI (an example would be I always have to put in a UITableView which is time consuming...) I think that I have a pretty good handle on the language and Apple SDK.
Does anyone have any tips regarding how to speed up the development process from a UI perspective? Are there alternative tools to xCode and IB? Are there libraries with classes that are faster to program w/? Anything is appreciated,
mj
Interface Builder can already speed up your development considerably if you learn to use it. For example, see this custom table cell with IB tutorial.
For example, at my current employer I've seen a Cocoa Mac OS X app where the settings dialog was done completely in IB... there was no code for modifying or sync'ing the values in the NSUserDefaults with the interface elements, everything was done in IB.
Also, see this interesting article: Striking the Balance: Interface Builder vs. Code.
Avoid UITableViewController if you aren't already.
For speeding up TableView dev, I always keep a pretty generic implementation of TableView handy that I can copy and paste snippets from.
If you are constantly doing TableViews for different object types, try using Protocols to make the implementations more uniform.
Don't be afraid of UIViews as subviews as opposed to constantly using UIViewControllers. Sometimes a VC is just an extra layer of complexity that you don't need.
My experience is that the biggest thing you can do as an iPhone developer to become more efficient is to know when and when not to use Controllers as opposed to Views when doing complex interfaces.
Wish I could be more specific but your question is a little vague... there's nothing wrong with Interface Builder, it's just a steep learning curve.
If you look at the Notes app on the iPad, you can see it uses all native iPhone controls, but they're "skinned" to look like a pad of paper. What's the best way to implement something similar to that? Could I use interface builder and simply change the background image for each of the controls, including the TableViews?
Thanks in advance for all your help! I'm going to continue researching this question right now.
This article from Dr Touch will probably come in handy: Stuff you learn from reverse engineering Notes.app
It's a little more complicated than that. My suggestion is manifold:
Hire a real designer to make the artwork.
Subclass whatever controls you want to skin, and handle this business directly in drawRect:. Interface Builder will not help you in this instance.
Consider drawing your controls programmatically instead of using images; a really cool thing would be to cache the programmatic drawings so that they only have to be performed once.
Best of luck!
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.