Are there any well established criteria to help decide between building a universal iphone/ipad app versus building separate targets that share some code?
I have an iPad app working fine and now have a requirement to support iPhone. Since the iPad views are large and complex, I'll need to rework almost every one into 2 or 3 smaller iphone views. So it seems to me that it will be easier to have 2 separate targets with all different views and controllers that re-use the model and communication layers, rather than pepper the code with:
if iPad {
// do iPad view and controller
} else {
// do iPhone view and controller
}
TIA,
-Mike
From the users point of view universal is nicer, unless it makes the download substantially longer (artwork resources).
Related
I have a question about universal app. My app will not have storyboards or xib file. There is possibility to write universal iPhone/iPad application without it? I found some tutorial how to create universal app with storyboard, but i don't want (i can't) use this feature in my project.
If it is possible What should i do? If i have to made changes only in ViewControllers? I'm start to do this, i'm not changing old project so i can do anythng - what should i learn/what should i remember?
I'm targeting to iOS 5.
EDIT:
I have a screen information in resource file and my rootViewController or any other ViewController will be created in compile time, so i can't have xib file for that, i can't put button on xib with Interface Builder becouse i don't even know how many buttons i will have there. I don't know how many screens i've got till i hit run in my project.
Not only can you write any type of iOS app without Interface Builder, it is actually much more testable and pliable. Some auto layout tricks are difficult (not possible?) in IB style projects, as well.
There is an incredibly impressive library called Masonry that wraps the NSLayoutContraint syntax. This makes it quite pleasurable to subclass views while not having to use ugly VFL or incredibly verbose NSLayoutContraint syntax (not even going to address frame setting...blech!). IB style apps also promote bad software development practices and anti-patterns (just dumping everything in a view controller presentation-wise. No Separation of Concerns!). Also, it is more difficult to work on larger teams (IMHO even small teams) while utilizing Nibs, Xibs, and Storyboards due to merge issues.
On top of all of that, you gain a much deeper understanding of the classes you are working with (UIView, UIResponder, etc.) when writing code in this manner (once again IMHO). There is an interesting article outlining some of these issues in more detail: http://doing-it-wrong.mikeweller.com/2013/06/ios-app-architecture-and-tdd-1.html This is by no means the only article that discusses this problem. Also, this will help for your app delegate: creating a universal window-based iphone app without generated xib file
This is certainly possible, I have only used storyborads once in the many apps I have published. As for not using XIBs, I am not sure why you would want to do that. You can lay out your views at runtime in the init method, but I feel like that is just making things unduly hard on yourself. You can set a XIB up for the iPad and one for the iPhone so you can tailor the UI specifically to each device.
Perhaps if you go into a bit more detail about why you are imposing this requirement on yourself we can discuss if it si worth the effort to go down that road.
Good Luck.
I'm trying to figure out the best way to approach writing a universal app. I'm not sure how to add some new files (for a new view), and how to add both iPhone and iPad view controllers. I'm using Xcode 4.2.
Your question is pretty vague (and general), but does this tutorial give you the information you need? http://blog.corywiles.com/creating-a-universal-ios-app-tutorial
Can someone explain in simple words the difference between .xib and .storyboard?
Apple introduced the concept of "storyboarding" in iOS5 SDK to simplify and better manage screens in your app. You can still use the .xib way of development.
Pre-storyboard, each UIViewController had an associated .xib with it. Storyboard achieves two things:
.storyboard is essentially one single file for all your screens in the app and it shows the flow of the screens. You can add segues/transitions between screens, this way. So, this minimizes the boilerplate code required to manage multiple screens.
Minimizes the overall number of files in an app.
You can avoid using Storyboard while creating a new project by leaving the "Use Storyboard" option unchecked.
You could refer this tutorial to get started.
Yes, you can still create a Window-based application for iOS 5. If you use the "empty project" template, you will see that a window is created for you in the app delegate. From there you can add XIB files as normal, or a new storyboard.
I'm assuming you mean "storyboards" rather than "timeline". Storyboards allow you to map out, visually, all of the views in your applications and how they interrelate. If you are just starting out with storyboards, there's an introduction to storyboards in the WWDC 2011 videos here. The 2011 Stanford iOS course on iTunes-U is also iOS 5-specific and covers storyboards and more.
A storyboard is like a canvas where you put all your .xib files. You no longer have any .xibs, you just have View Controllers directly on your canvas.
storyboard is a new feature available since the release of Xcode 4.2.
It offers a complete new way for iOS developer to create and design
user interface. Before the introduction of Storyboard, it’s especially
hard for beginner to create navigation (and tab) interface. Every
interface is stored in a separate xib file. On top of it, you have to
write code to link all interfaces together and describe how the
navigation works.
With Storyboards, all screens are stored in a single file. This gives
you a conceptual overview of the visual representation for the app and
shows you how the screens are connected. Xcode provides a built-in
editor to layout the Storyboards. You can define the transition (known
as segues) between various screens simply using point and click. This
doesn’t mean you do not need to write code for the user interface. But
Storyboards significantly reduce the amount of code you need to write.
Source: http://www.appcoda.com/use-storyboards-to-build-navigation-controller-and-table-view/
XIB:
Xib files are used with a single UIView.
2)It's very difficult to implement complex auto-layouts in xib.
3)It's utilizes more memory as compared to storyboard and quiet slow.
It is compatible from iOS5 and onwards
You can do localizations for different languages and countries using
different XIBs .
It's difficult to use same Xib to support multiple devices.
Storyboard
1)You can layout all your Scenes like View Controllers, Nav Controllers, TabBar Controllers, etc in a single storyboard.
2)You can use Auto Layout easily that defines mathematical relationships between elements defining their position and sizing.
3)Usually fast and allocates less memory.
4)It's not compatible prior to iOS 5 .
5)"Dynamic" and "Prototype" cells can be used easily.
6)Storyboards best to use for the apps with a small to medium amount of screens.
The best Answer I have seen : Xib Vs Storyboard in iOS
XIB and Storyboard are used for creating interfaces for users.
One important point is,xibs are used for creating a single view(it has single file owner at the top of the xib file), but in-case for viewcontroller, multiple screens can be added and its flow can also be monitored(it has separate file owners).
I am creating a Universal iOs application as part of an assignment (iPad and iPhone :) ).
Naturally, they have a UI which I have been accustomed to create through the NIB files, using the fancy drag and drop schemes. This obviously seems like a great strategy when you are making a dedicated iOS device application.
However, with the universal application, I notice that this strategy can be a challenge since the 2 UIs differ and human error can promote a lack of consistency in the two UI's + double the work!!!
I noticed the solution to the assignment I am doing has the UI created through the AppDelegate file, I have never really done this, and from this stems the questions:
What is the appDelegate files for anyways?
Is it the way to create the UI for the Universal application through the App delegate? Or do you people still create the UI's through the NIB files meticulously for both iPhone and iPad?
P.S: Side question: This assignment requires me to create a Windows based application vs a View based application which is what I have naturally learnt to do. I understand a Windows based App can grow into a view based application and vice versa. However, I do not understand when you should choose to create a Windows based application?
The AppDelegate in Cocoa is your central Singleton that controls the app workflow. It's used by the underlying Framework to start the application, signal runtime envrionment changes and terminate the app. Being a singleton, it's always there and easy to reference ([UIApplication applicationDelegate]) and it loads up your first view controller.
It's generally common to let the application delegate keep refernces to model and controller objects. But what you describe, the whole UI programmed through the appDelegate, is bad style.
No matter if you use NIB's or you code your UI by manually adding UIElements to the view in code, you should do so in ViewController. Generally, the appDelegate will call the first view controller and that viewcontroller will call all view controller afterwards.
I have an iPad app that I would like to make Universal, however this seems alarmingly difficult. I've changed things around so that I support both builds, but when building, I get lots of errors about using UIPopOvers. Here're my questions:
Why does UI_USER_INTERFACE_IDIOM() not compile or register on 3.1.3?
Can I conditionally have variables in a class definition based on UI_USER_INTERFACE_IDIOM()?
If not, should I make two different view controllers?
Thanks!
Why does UI_USER_INTERFACE_IDIOM() not
compile or register on 3.1.3?
The UI_USER_INTERFACE_IDIOM macro is only available starting with 3.2. Same restrictions for the userInterfaceIdiom property of UIDevice. This means that you can only get universal application starting with SDK 3.2.
Can I conditionally have variables in
a class definition based on
UI_USER_INTERFACE_IDIOM()?
No. The UI_USER_INTERFACE_IDIOM macro is only a runtime shortcut to get the current UI idiom of the device.
If not, should I make two different
view controllers?
If you have very different UI between the two devices, it is wiser to use two different view controllers, and to create the right one at runtime (in the application controller for example) by using the UI_USER_INTERFACE_IDIOM macro.
I had pretty good luck with just selecting the target then going to Project->Upgrade current target for iPad.
My app is pretty simple, consisting mostly of table views and webviews, but it's worth making a backup and trying...
And yes, you have to submit it as a 3.2 app that can target 3.1.*
There are also a lot of other stuff that you have to do:
Make sure that it can be viewed at any orientation (got rejected the first time for this).
Make sure that you have all the new images created. you have to have 3 or 4 icons, instead of just one like an iPhone app needed. (iPad icon, iPhone icon, small icon for spotlight, etc).
And of course iPad sized screenshots for the store.
A really nice way that I use to test if it's an iPad or iPhone is to check if the device can use a split view controller, since for the forseeable future no device with a screen as small as an iPhone will be able to use the split view controller. I just created a function to do this for me:
+(BOOL)isIpad{ return NSClassFromString(#"UISplitViewController") != nil; }
Then anywhere in my app that I want to display something different depending on device, I just do a check for it:
int width = 150;
if([NabAppDelegate isIpad]){
width = 350;
} else {
width = 150;
}
UILabel *label = [[UILabel alloc] initWithFrame:CGRectMake(5,10,width,25)];
This is a lot better than checking against OS version like I've seen some suggest.