This question may looks like silly. But I want to know & check the correct way to write & group my code.
Consider I'm writing an app for both iPhone & iPad. I'm writing by code and not using storyboard.
What is the suggested way to keep the code?
I hereby explained what did I make the code more visible and more reusable. Please correct me in case of any mistake.
Say, my controllers are iPhoneListViewController and iPadListViewController
This both controllers are totally customized controllers and they are the child of ListViewController which contains some common methods (both UI related and function related). ListViewController is the child class of UIViewController.
Other custom controllers, custom views, singleton classes, protocols was separately saved.
Questions:
Am I using optimal way to code?
Should I separate HD/non HD code?
1). As you are targeting both iPhone & iPad, you can have two separate classes for these. According to my opinion, there is no better way of segregating the code other than this.
Just a piece of advice for the UI part though: You can use file names as MyListViewController~iPhone.xib & MyListViewController~iPad.xib for your files. The advantage of this approach is, iOS will automatically pick the correct xib according to the type of device your app is running on. i.e. You can make an instance like: MyListViewController lvc= [[MyListViewController alloc]initWithNibName:"MyListViewController" bundle:nil];.
2). Separating HD/Non HD code doesn't look good at all. By looking into the number of different device sizes, I think you should use autolayouts to make your UI responsive irrespective of device size.
In iOS8, Apple has sizing class to deal with such things. The iPad is a regular-width-regular-height device, the iPhone is compact-width-regular-height device and so on. So if your interface is not too different, it's better to use the same class for all devices and depend on the sizing class (which means screen's capacity) to do layout. And auto layout is also helpful to make adaptive ui. We will never know if Apple will have how many size of devices in the future.
Related
I'm looking to use size classes for the first time with my iOS8+ project to port my iPhone app to iPad. I've used autolayout to create my storyboard but I intend on using a UISplitViewController for the iPad to make use of the extra screen real estate.
From my googling on the subject it appears size classes may be limited to changing constraints rather than changing the type of controller used? I've not read this specifically but cannot find any example of changing the type of controller used. Are size classes not usable for this scenario?
Size classes allow you to enable / disable a constraint based on the size of the device. There is no facility to run conditional logic. If you need a fundamentally different UI, you will need separate storyboards. Having 2 completely different UI's in the same storyboard, toggled on / off via size classes will get very complex, very quickly. Size classes are best used for small changes.
That being said the UISplitViewController is more complex than you think. You can hide / show the detail in varying ways using size classes. This can then be used as the starting point for both iPhone / iPad and toggle it on / off as need be using size classes (assuming that the rest of the app will remain largely the same).
I'd suggest doing more research on the topic. Try reading article such as this one. It will then be up to you to decide if your use case needs 2 sets of storyboards or 1 set with size classes.
For an iOS app i am currently working on, I need to manage the controls displayed on the screen based on the type of device the app is running on.
I will try to explain with a theoretical example (the actual numbers used below are not important, what interests me is best method to achieve the desired result).
Example:
In the case of the app in the screenshots, the button that overlaps the UIImageView should not be displayed at all OR displayed in another place on the screen.
So far I've worked with autolayout , but , from what i could figure, there's no way to say to xcode something like: hey, for a class size "Compact Width / Compact Height" , I want you to hide these buttons...but show them for "Regular Width / Compact Height" .
I also did some googling and saw some people talk about using different storyboards based on the device; I am also thinking, I could add/remove buttons dynamically based on the device type , but I think it's not so pleasant to have to add all of the constraints by hand (programatically that is).
So to resume, I would appreciate a suggestion of a 'best' way to do this , best meaning a combination of 'not so hard' + ' not so long'. Also, some code example (or links) would be highly appreciated.
Thank you all in advance !
I think it all depends how sophisticated it gets what you are doing overall. When you look at developer's code for large app projects very little is actually done in interface builder since the apps are so dynamic it's just too much work in IB.
Using multiple storyboards 'sounds' like a good idea, but often isn't. If you want to update/change one, in most cases you then have to change the other ones as well.
What I think is handy:
Use one storyboard (or multiple but for different parts of you app and not parallel ones) and then put in very 'special' cases multiple ViewControllers of the same class for the different size into the single storyboard. That way you won't forget about updating the second (and third) because they are all right there.
I would only use multiple 'parallel' storyboards for apps that support iPhone and iPad and it makes sense to really split them up..
Also:
I would as fas as possible still use just one representation and derive the other 'versions' from that in code. If you build a structured user interface you can then reuse (or just inherit) the code that 'hides' parts of the first viewController in the next. That way your code AND your IB files won't get cluttered.
Also think about internationalisation (if that is part of your future plans), since multiple IB documents and multiple instances of the same viewController layout really don't help for that ;)
I've read around that Apple is hinting to developers at a larger-screen iPhone by pushing developers to use Storyboard and auto-layout. I understand why auto-layout would be useful, to organise items according to screen size, but what do Storyboards have to do with anything?
I may be missing an obvious advantage (in relation to larger screens), so any help would be much appreciated. :)
A. You say that there are some notice from Apple about the larger screen of the iPhone6: This is impossible because Apple doesn't release any information until the date of Keynotes and WWDC.
B. You can or not use Storyboard, and you can or not use AutoLayout: the 2 things are separate because you can also use AutoLayout in nib or programmatically.
C. What developers don't know, is that Storyboard are just a market move. I spoken directly with a my friend engineer in Apple about this and the information is real. The reason is also obvious. Is not the topic to speak about this but you can search on google and you will find a lot of information about the advantages to don't use storyboard.
Yes, storyboard are easy, but are not developer friendly if you think to work in a serious project with a big team. In a team you can use GIT, you can use shared repositories, you can export a part of code with the interface...in all this thing, Storyboard are BAD!
So i encourage developers to DON'T USE storyboard and use at max NIB file, or write the UI directly by code.
There currently doesn't appear to be any advantage to using storyboards versus XIBs or programmatic layout as far as multiple screen sizes are concerned. Auto-layout is definitely advantageous as it allows you to define your interface elements in relation to each other (and the screen), as opposed to using fixed numerical values for location and size. This would allow the UI to then easily adapt to varying screen sizes and aspect ratios.
The only potential reason storyboards could become useful for multiple screen sizes in the future is if Apple adds functionality to them to allow you to define entirely separate views based on device/screen size. So for example, they might make it easy to show a view with an extra sidebar on a larger screen, but show a separate view without the sidebar on a smaller screen (they might make it possible to configure this easily in a storyboard, versus writing a bunch of code to detect the screen size and load the appropriate view programmatically). As of now, though, no such functionality exists, but that could be a potential source of the rumors regarding storyboards being useful for multiple screen sizes.
When developing a universal binary for both iPhone and iPad apps, I noticed that many developers use a unique ViewController and add the
if(UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)
to separate their logic. I've also seen this many times in Apple's iOS documentation.
However, I'm really not a big fan of this approach, since it clutters the code and makes it harder to maintain, especially when the iPad and iPhone logic are quite different.
So I was thinking of using an abstract ViewController class and instantiating a specific ViewController for iPhone or iPad (depending of the platform) every time. I would then have a single "if" at every ViewController transition, and I could use polymorphism to make the code cleaner.
Is this the recommended way of doing things? Thanks!
Both ways will work. It's partly about personal preference and partly about how different the 2 platform implementations will be. If they are similar then you should find that there are very few places where you need conditional code. Likewise, if they are different and you choose to use different classes then likely the only conditional code will be to load the root view controller. After that each class will be platform specific (or have a platform specific subclass) so special logic and handling pushing / presenting view controllers would usually be handled there.
Actually if you use two different storyboards then there is no need for an "if" at all. You have a main storyboard that loads if this is an iPad and a different main storyboard that loads if this is an iPhone (you set that up in the info.plist file). Now you can actually have completely different sets of view controller if you so desire (and if the interfaces are quite different, that might not be a bad idea).
I have used subclassing in this situation but I always find it terribly confusing. That can be a problem with subclassing! There are better ways to express the common code (i.e. do it in a different class, not the view controller).
I'm working on building a universal iOS configuration application for the iPhone/iPad. But the layouts ('views') for the iPad are considerably different from that of the iPhone. Considering that only the appearance of the application ('views') change w.r.t the device, what is the most efficient design approach i could follow?
Things I've already looked at
I've looked at one strategy where different View controllers are loaded depending on the device in use. But this might be an overkill considering that the 'controls' are the same across devices and only the appearance of the application changes.
The use of functions to resize the view frames to layout views as needed automatically. This does not help me much because there is a need to not only change the size of the views but load different views altogether depending on the device.
To keep the viewController unchanged but configure the views inside the viewController differently. Right now this seems like the best way to do it, but the application is kinda heavy and it might become very messy in the long run. Or is there a very efficient way to do this?
Is there a design strategy for this?
Or is there any way i can accomplish this efficiently while optimizing effort?
The standard approach is to have different XIB files for iPhone and iPad, which the platform will select automatically if you name them right, e.g. myview~iPhone.xib and myview~iPad.xib.
You are concerned about inefficiency: I wouldn't worry about the file size as compiled XIB is quite compact.
In my apps I mostly use this approach, with some fragments of code to add or remove buttons for each platform. Simple views can just be set up to resize automatically using the standard struts-and-glue techniques.