I need help to decide which way to go to reduce code pain.
Upon downloading a certain form from the web in html/text format, I will decide which parts of the form to display on the iPhone for the user to see and/or interact with.
There may be Labels, TextFields, CheckBoxs, RadioButtons and Pickers to name a few. Some pages can be “transformed” into one iPhone scene but others may need scrolling (run time decision).
Since a group of those pages relate to one kind of activity, I like to use one scene/storyboard and to make views/containers show up and/or disappear as needed for the current page.
My options:
TableViews with either Static Cell or Prototype cell (model to supply the correct view/container).
StackViews for ease of laying out.
Hybrid of both above, stackView inside each cell for easy layout and row/cellView deleting.
Plain vanilla views with in a container inside a scrollView (feeling some pain about this one)
Collection view (maybe an overkill).
What would you do?
Thanks
If your deployment target is iOS 9.0 then i would suggest to go for option 3. If deployement target is below 9.0 then stackViews is not an option for you so in that case go for option 1. That will give you scalability like if your fields get increased after sometimes so that change would be accommodate easily with TableViews and in this case approach 4 will definitely be painful.
Related
We are developing an iOS app using Swift.
We have a tableView where each TableCell is expandable.
It currently looks like this. (Ignore the abbreviation of the time label, this is not intended)
When executed on a tablet the labels from the expanded sub cell should be moved to the parent cell, depending on how much space is available.
It would not be a problem if we have to make a separate scene for tablets and phones.
It would be beautiful, if we could change the display of those scenes directly in the interface builder, depending on which device is selected on the bottom bar.
What is the best (cleanest) way to achieve that?
Thanks in advance.
What you need sounds like the "vary for traits" option in Xcode 8, it allows you to have different configurations of the same view depending on the device(actually based on Width and Height settings) but it narrow down to device as you use it, if you click the vary for traits button in Xcode you will see the various options for W and H and you can see in real time how the devices changes depending on your selection. Just be a little bit careful about one thing, when you introduce a new setting you use the vary for traits button but after that you access it from the right hand side picker as normal.
You will see in Xcode 8 that some attributes have a small + sign next to them, that is where you will find your different traits after you have introduced them, it takes some getting used to but is very powerful once you get your head around it. It is also the recommended way to make adaptive applications in iOS
This question already has answers here:
Adding Views. Storyboard VS. Programmatically [closed]
(2 answers)
Closed 6 years ago.
Is it more efficient to add views and subviews programmatically than using a storyboard to add them ?
What is be the best practice ? Does the best practice depend on the situation ? If so, when is it preferable to use the one method over the other ?
Storyboard vs Code comes up an awful lot. And I think looking at it as which is better often starts flame wars. So instead I'll list out pros and cons for each, then you can hopefully make an informed decision.
This is by no means an exhaustive list. I'd love to see edits or comments adding additional bullet points.
Storyboard Pros
Storyboards are great for getting a concept working quickly.
They're great for seeing your actual app and previewing it on multiple devices.
They make it really easy to customize appearances and explore whats possible.
They're fantastic for beginners as they remove one barrier and let you focus on code for your app rather than some boiler plate UI.
Storyboard Cons
Storyboards and Xibs are not great for merging. Its possible to read the XML and make decisions about merge conflicts, but its certainly not enjoyable.
Overtime as you customize your app and build the custom parts that make it special, Storyboards can't keep up. This means that the benefit of seeing and previewing your app as you see it on device slowly loses its value as more and more of your app is done in code out of necessity.
Storyboards don't have a huge performance hit for actual users, but they definitely slow Xcode down on even the fastest machines.
You can't customize everything in Interface Builder that you can in code, so its inevitable you'll have some code and some Storyboard customization. Later when you want to change something, you'll have to check at least two places for the right place to change it.
If you're using the same fonts and colors throughout the app, its easy to change in code in one place. In Storyboard you'll need to change it for every single label or view you've set up. You can easily set fonts and colors in code while using Storyboard for the rest of your layout, but over time you'll find your storyboards represent less and less of your actual app.
While its possible to have pixel perfect designs in Storyboard, drag and drop isn't as precise as entering specific numbers. Storyboard does support entering those numbers, but you need to navigate to multiple places and if you drag it later the numbers are all reset.
Reusing views typically involves copy and pasting them. These causes issues later when you need to make changes.
Showing and hiding views at certain times is doable, but again leaves your storyboard in an unrealistic state compared to your actual app.
Programmatic Pros
All your code is in one place making it easier to debug or change later.
Subclasses and custom properties are no different from first class views and properties. Your customizations will be easy to manage.
Views that are reused throughout the app only need to be created once.
Merge conflicts are often easy to understand and make decisions.
Dependency Injection is one of the safest ways to instantiate UIViewControllers and ensure necessary information is passed in, its not possible with Storyboards leading to less straight forward and more bug prone code.
Programmatic Cons
The additional complexity can be a stumbling block for beginners.
Writing a few lines of code can take longer than clicking a few checkboxes.
When working with layouts, you'll need to visualize it in your head or run your app to see what your layout looks like as you make changes. This can be difficult or slower for some.
Storyboard exposes checkboxes and buttons for many customizable properties like background color, font, etc. This makes it easy to see at a glance what you can customize. (Though as mentioned above its not everything) In Code, you'll need to look at documentation or headers to understand what you can customize.
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'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.
I've looked for this for a while, but I can't find any good guides or resources that explain it thoroughly (not even Apple's own documentation, which seems to not have as much information as I'd expect). I want to setup a basic interface that has 6 pages horizontally. Each page will have a bunch of labels and textboxes, but the layout will be the same for each page. Eventually, I want to be able to have each page scroll down to view all the content, but I'm assuming I just need to use scrollviews as the content for each page.
Also, each page will eventually have to have separate names for each textbox (and separate from the other pages too) because I'll need all the content of the whole app to be saved out later.
But really, for now, I just need to figure out how to get paging working. I tried following one demo but when I typed in the code, Xcode wasn't recognizing one of my classes (which I know I included it). Plus, I didn't understand what was going on really, and I feel that I need to understand what I'm coding.
Also as a side note, how do I start programming for iOS 5? I updated Xcode to the latest version which said it had support for iOS 5, but I only get up to 4.3 in my project target.
You can use this project http://cocoacontrols.com/platforms/ios/controls/icarousel, the only downside is it does not support cell reuse, so if you plan on having more than a 5 or so panels the app will really start to blog down.
For any future searchers that have found this thread, I was able to achieve what I wanted.
Basically, just make a scrollview the size of however many pages you want (multiply the width by how many pages you want and that will be the content width). Then just enable paging in interface builder and it will page through the view. Then you can just add content to the scrollview.
It's not hard. When I did it for some of my apps, I had a very detailed 'template view' which included primarily a tableview, but also lots of buttons and text fields and such. I was amazed at how well it all worked when put together -- no real trouble with gestures or anything. Apple's UIPageControl sample code is a good place to start.