I'm creating a universal iOS app.
I have a different UI for each one of them in most of the screens.
There are about 15 screens.
I'm coming from Android and trying to find the best solution for that.
on the iPhone i use portrait mode.
on the iPad i use landscape mode.
I use Constraints / Auto layout.
Some of the views have nibs, some in code.
because of that, the logic is a bit different in each one.
iPad have 2 menus you can swipe from top to bottom and left to right.
iPhone has no draggable menus.
both use same Api calls to the server.
I looked a bit on stack overflow, and got some of those methods:
Should I use 2 different classes, and 2 nibs?
Or maybe 1 class with tons of if else?
Use different targets?
Is one of those is the best way? Is there any other way?
different targets
same class with if/else
IPAD::
IPHONE::
When I need to design a universal app I look at the interface I think I need to support and try:
Can the different layouts be handled by autolayout constraints? If so great, I only need one view.
If the views are significantly different can I define a common IBOutlet/Action interface to a view controller? If so I can use one view controller (which is not full of conditional branches) to support views defined in multiple nibs.
If the view structure is radically different or the presented view controllers vary greatly (split view controllers for example) then I probably need multiple view controllers, each with their own views/nibs but those controllers should be as thin as possible and share a common set of models, data sources, networking services, and other business logic.
Related
I am currently working on a Spy app with different modules of Spy tools. For my Night Vision module for every mode I use a different View Controller. I also linked all 5 View Controllers together with different Segues, although you can't seem them in this picture.
I have noticed the performance is not as stellar compared to running an single mode out of a single project. Is it likely the amount of View Controllers slowing the performance down? If so what method do you recommend to cure this problem? The only other difference in the individual project module and the full App project besides the amount of View Controllers/Segues is I use imageViews that work like buttons instead of using buttons.
You can add as many as view controllers in a single storyboard. No performance degrade issue in app but that storyboard will take a time to load in xcode when you open that storyboard.
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.
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 discovering storyboards and would like to use them for a new application.
I would like to know if it makes sense to have two separate storyboards, one for the login/signup related views and one for the main application views.
The purpose is to keep both storyboards clean and easy to maintain.
What would be the drawbacks of such approach ?
Thank you
I would suggest only having separate storyboards if it becomes an issue for you. I have gone down the path of having separate storyboards, and didn't find any advantage organizationally. It wasn't worth keeping track of which view was in which storyboard.
Once you move to a universal app it is probably more useful to have one storyboard for iPhone and one for iPad. I currently have 3 storyboards, and they are not organized according to what type of view, but which environment will be using the views.
iPhone Storyboard
iPad Storyboard
Shared Storyboard(some views you will use between both)
For me, storyboards are nothing more than just a container to dump my views, and prevents a bunch of separate .xib files all over the place(initialization of ViewControllers from the storyboard is much simpler though). I used segues for maybe a week, but then the app's needs quickly outgrew the limited benefit of transitions.
It is actually really easy to copy and paste between storyboards, so don't be afraid to try a bunch of different arrangements to see what you like. You'll just need to adjust which storyboard you instantiate the object from obviously.
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.