I'm gonna create an app that supports both iPhone & iPad. Before proceeding, I just want to know the best practices about both app development.
Here is some points that I know:
Consider that I have a tableview that shows N number of records and say it as PAGE-1. When the user tapping on the cell, it will load the PAGE-2 to show details about the tapped record. This is more common scenario that used in every app.
For iPad, this is not the case. I can show PAGE-1 along with PAGE-2 in the same page.(Consider landscape mode)
So, iPhone's PAGE-1 will be displayed in the left panel of the iPad & iPhone's PAGE-2 will be displayed in the right side panel of the iPad.
Conclusion:
So, I can make a common class for both iPhone & iPad. That will handle the PAGE-1's common functionality to both iPhone & iPad.
The device specific functionality may separated into separate classes for both iPhone and iPad.
Other than that, network related methods, parsers, utility methods, categories, custom controllers can be written commonly for both iPhone & iPad.
The only addon to the iPad is, it should have a controller that will hold and handle PAGE-1 and PAGE-2. This make sures that the PAGE-1 does not hold PAGE-2 and they both are independent like iPhone's PAGE-1 & PAGE-2.
Refer the below attached image that will demonstrate clearly.
Questions:
Is this approach correct?
I really don't know about iPad's "Container" controller. Should I need it? Or is there any other better proposal to group the things effectively?
This may be a basic question, but I need a clarification for better code pratice.
Thanks
It doesn't sound like you need specific page 1 & 2 subclasses, though that depends on exactly what the differences are between the pages on each device. It may be that a collection view suits your needs better so you can simply set the item width and the layout will organise your content into columns where appropriate.
It sounds more like all you need is 2 different container classes for the top level which decides how to display page(s), or more specifically, how many pages to display and where they are on screen. For iPhone that's really simple, for iPad slightly more complex (mainly due to rotation handling).
Note also that if you create a new master-detail project in Xcode and ask it to support iPhone and iPad you will see that a split view controller is used, optionally, for exactly this situation. This bypasses the need for 2 container classes by having the app delegate decide whether to use a 'special' container or not (for iPad).
Related
New to iOS developing here. Basically I am creating a soundboard app. I have the app essentially working (aka buttons returning sounds).
However my app only looks proper on the iPhone 6. I just have one ViewController in my main storyboard. When I run the simulator for the 4S/5/6+ or iPads, my buttons are pretty much everywhere.
I tried playing with size classes/autolayout through Apple's documentation, but couldn't get it working properly. What's the best (easiest ;) ) route I can follow to have it basically looking the same on ALL devices?
PS: I have one background placed too, I don't mind if it looks different on all devices since it's pretty minimalistic, but if someone can shed some light here too, that would be great.
Thanks!
You have a few options:
1) Continue your plan spending time getting friendly with Auto Layout and Size Classes. This might be difficult at first, but it will really pay off later. You should use the Assistant Editor's Preview mode to let you see iPhone 4, 5 and 6 side-by-side as you work so you can make sure your layouts look great everywhere.
2) Use a component like UIStackView where layouts are automatically adjusted to fit various devices. If your soundboard is as simple as a grid of buttons, you can do that in just a few minutes using a stack view.
3) Use a component like UITableView or UICollectionView where content is designed to scroll. Using this method you design only one sound button of your app (i.e., enough to play one sound) then have iOS replicate that across all the sounds you want. When your interface is presented on a device of a different size iOS will just make the content scroll.
Very roughly, option 1 makes you do all the work; option 2 makes your layout shrink down until it fits the available space; and option 3 makes your layout stay the same size no matter what, but you should expect it to scroll on some devices.
There is no right solution; it's entirely down how you want your app to work.
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.
I'm starting to think about how to solve the problem of developing an app for all iOS devices with different screens (resolution, ratio, retina, etc). I'm working with Adobe Air (AS3), but that really doesn't matter because I'm in a conceptual phase and I'm concerned about the patterns to use.
If I was only developing for iPad, the problem would be as simple as doubling measures and sizes to adapto to retina and non-retina devices. But I need to take into account iPhones, iPods, and eventually Android too with it's myriad of screens.
So far I see those possible options. I'm sorry if there's already some terminology for those options, but I'll just say in it my own words.
Intelligent views that have some sort of liquid layout, and also intelligent components that adapt to the space the view is assigning to them, and to the screen dpi for font sizes, and image sizes. For example: the view says "here goes a button on the bottom with this width/height". The button already knows what font size the text must be depending on the screen dpi.
Factorization with parameters of different UI view classes. So I'd have one view class for iPad, another for iPhone, etc. and there would be one class that would factorize the instantiation of the view depending on the device. Each of those classes could be hand tailored to be completely different from each other, but the underlying model and (hopefully) the controller would be the same on every device.
A middle way approach: One UI View class for tablets, another for phones, and each of those with some sort of liquid capacity to fine tune the position and size of elements (buttons, texts, images, etc).
External config files that give the View some parameters depending on the device. That would be some sort of custom CSS.
I'm sure I'm not the first person to find this rock on my path.
So how is this problem usually solved?
Is there some stablished pattern for those scenarios?
Is there some reference (book, article) I should read?
I haven't been able to find an in depth answer to this. If it's already been asked/answered please don't downvote. Post the link in the comments and I'll just delete this question.
You are describing Responsive Web Design. There are multiple approaches and ways to make you site responsive (i.e. capable of running on multiple screen sizes without having to modify or reconfigure the codebase or rely on user-agent to detect the browser info).
Start from here: http://msdn.microsoft.com/en-us/magazine/hh653584.aspx
Also consider various open-source CSS frameworks that will simplify your life. For example, Bootstrap and HTML5 Boilerplate. Both of those are fairly independent of your development platform and should work well with MVC.
What commonly expected user-visible design idioms need to change from an iPad app to a Mac app for an app, that is to provide basically identical functionality, to seem at least reasonably Mac OS X native?
Some of these changes, commonly expected by users, might include:
Move the Settings button and Info button to Menu selections for Preferences... and About...
Move the Settings view and Info view or popover to their own independent Preferences and About windows instead of being views in the main window.
Add some menu items and menu keys for commonly used buttons (like the forward and back buttons in a browser).
Support arrow keys for scrolling any custom view items.
Support mouse-over for help popups or dynamic menus.
If the app supports "documents", allow more than one document to be open at a time, each in their own windows.
What else? What's the minimum change required for a simple generic 2D game?
Added clarifications:
Note that I do not consider re-coding similar UI classes to NS classes (for instance UIButtons to NSButtons), with similar look, positions and behaviors, to be a significant change. Those changes are pretty much invisible to the user.
The goal is to change as little as possible so that a user who purchased app X to do Y on an iPad might purchase app X to do Y on their Mac, as a Mac application, but with as close to zero learning curve as possible. But it seems that some changes need to be made, or the app would not seem to be a Mac app (for instance, a missing About... menu item would seem a bit strange.)
to provide basically identical
functionality, to seem at least
reasonably Mac OS X native?
You've gone off the rails right there. Consider adding this to your list:
Forget everything you know about how your iPad app works. Step back and consider that a user's interaction with and expectation of a desktop application are very different from those of a tablet. Re-think what you're able to do and what the user will want to do with a faster processor, more power, significantly more available storage, less mobility, much faster text entry, and a different user interface model.
We are in the same boat and faced the same question.
Our conclusion is to start with a "fresh" real application for Mac and make it look similar, i.e. using the same or similar UI components and graphics. The app should be otherwise developed as if there was no iPad version.
First, there will be many users that don't have the iPad version. Those users expect a full-blown Mac application and it doesn't make sense to make it feel iPad in any way.
Second, users coming from the iPad version will feel ripped of if the Mac app is just a pure clone of the iPad version with no added value. Think of the first transitions from iPhone to iPad - paying again for nothing but pure upscales is frustrating and might harm your business in the long run.
Starting out designing a fresh streamlined UI and then think of what you can reuse and make similar. Functionality may differ in one direction or the other. Your model code should work in all places anyway.
Not exactly an answer to your question, but take a look at Chameleon. It's essentially a port of UIKit to the Mac. It was created by The Icon Factory to make it easy for developers to port their iOS apps to the Mac. IIRC Twitterific was ported to the Mac using Chameleon.
So here's what I did to create a Mac app from an iPad app, and have it accepted into the Mac App store.
Ignored the suggestions to completely redesign the app (users reasonably liked the iPad design).
Create a Mac app project and include a branch of all the iOS source code.
Manually recode all the UI elements with their corresponding NS elements. Resize them to Mac UI guideline sizes. Check that they all show up in some reasonable place when the main window is resized. Deleted iPad only delegates, such as rotation handlers, etc. This resulted in completely new view controller code, but almost all the code was just a parallel translation of the other paradigm.
Set the view coordinates to flipped so the Y coordinates won't have to be recalculated for any Core Graphics drawing routines. (The Model and CG drawing code pretty much ported straight over without change, except for scale factors for window size, and such.)
Remove settings and help views from the main window view controller(s). Implement a Preferences window xib and a Help window xib, and put all the settings and pref views and controls there. Add one more top level controller to show/hide the 3 windows.
Add some menu selections with hotkeys for equivalent UIButton actions that a user might want to hit without reaching for the mouse/trackpad.
Add a credits.html file.
Add an outline shape and transparency masks to the icon design, and stuff into an .icns file.
Pad the one window screen shot out to the much larger required size.
I'm refactoring one of my apps from the iPhone to the iPad and this has resulted in the removal of tabs as I've been able to combine functionality onto 1 screen and use popovers to enable the user to select stuff that previously required a new tab.
I'm basically left with 2 tabs now. One (which is best viewed landscape) shows a map of the world with some overlays drawn on it plus an indication of where you are. The second is a data display with a few graphs which is best viewed portrait.
I note what Apple say about requiring apps to run in all orientations on the iPad, and of course I could do this, and keep my 2 tab bar buttons to switch views.
HOWEVER
In this case, there is 1 view that is best suited to landscape view and 1 view that is best suited to portrait view. Would be be appropriate (or even Apple permissible) UX design to drop the tab bar and switch views on an orientation change instead?
From a user perspective, you wouldn't need to be switching back and forth much, you tend to use the landscape view to change location (if you need to) and then work mainly in the portrait view - so I don't think it would be frustrating and dropping the tabs seems to make more sense to me.
What do you think? Any best practice in these situations?
Roger
London
I would say that the best practice is not to restrict the orientation of views.
The central idea here is not to force the user to hold the device a certain way. For example, a lot of people use iPads in a stand or holder and input with a keyboard. Do you want to force your users to stop and physically adjust the device in the holder/stand before they can read the view in the other orientation? Other people simple prefer holding the device one way or the other and lock the orientation (I do that a lot.) Forcing users to change from their preferred device orientation won't win you happy customers.
Apple will not penalize you for a non-standard UI unless it reflects badly on the device itself. As long as the end users can tell it's your apps non-standard behavior, Apple does not care. However, in my experience, end users tend to interpret non-standard interfaces as flawed or broken because they don't understand them.
In this case, if I launch your app for the first time, how am going to know that changing orientation changes to another view altogether and another data set? Nothing in the standard UI teaches me to expect that. I will have to discover it by trial and error. If I have the orientation locked, not even trial or error will help. At that point, I might well conclude that the app is broken.
You could try adding instructions but just the thought that they might be necessary is a red flag for a potentially poor UI.