I just started iOS development (I've been web dev for 6+ years) and I'm struggling with understanding how to build my UI beyond the default elements.
I feel like I started at kind of an awkward time. The resources I can find on creating a custom UI forgo the use of storyboards. Yet Xcode5 seems to force the use of storyboards (granted it's in beta so this may change).
While my current goal is to make list items slide over to expose custom actions (similar to mailbox, cobook, and countless other apps), really what I'm asking is for good resources on creating more custom UI's while still using storyboards that will lead me in the direction I need to go in order to do that.
Any help is appreciated, I've been desperately fighting the urge to take the easy way out and just use PhoneGap.
Thanks guys.
Check out this guide. In it they show how to make UITableViewCells with horizontal pan gestures so you can create the sort of effect that you are looking for.
http://www.raywenderlich.com/21842/how-to-make-a-gesture-driven-to-do-list-app-part-13
It uses a .xib file (I agree with you about the degree to which people using xib files in tutorials is incredibly annoying when storyboards seem to be the direction Apple is going in). However, you can make a UITableViewController in the storyboard. I would mostly use this in order to learn how to make custom UITableViewCells that can then be used in any sort of UITableView. You simply need to select the cell in the tableview, make the class of the cell the type of UITableViewCell you want (under the "Show Identity Inspector") and then make it the class of your custom UITableViewCell. Then when you call dequeueCellWithIdentifier, make sure the identifier is the same as the cell in the storyboard, and also cast the cell to your custom type like so...
MySlidingTableViewCell * cell = (MySlidingTableViewCell *)[tableView dequeueReusableCellWithIdentifier:CellIdentifier];
And make sure you #import the class for the cell.
Related
I am building an app which enables user to drag a UIView onto another. Currently I have the implementation as a UIScrollView but that does not give me the best experience as to achieve an experience like Apple's drag and drop requires handling of many cases ( including edge cases).
I am curious if this can be done using a UICollectionView. I am looking to drag cells onto another cells after which the cells contents merge and the source cell is removed.
Any idea/ suggestion would be appreciated. I am not sure if adding what I have is neccessary but if needed I can certainly add the code which I have.
Yes, using a collectionView would be a good choice for scrolling and drag/drop. There are many built in methods that support drag and drop.
https://developer.apple.com/documentation/uikit/views_and_controls/collection_views/supporting_drag_and_drop_in_collection_views
Who is the best optimized way?
Create objects in my UITableView using storyboard (Drag and drop in my cell), or create objects programmatically (cellForRowAtIndexPath)?
When the project compile and run in device which of the two options will run faster?
In terms of pure performance, code created UI objects are faster than any nibs / storyboards objects, only because storyboards and nibs files are stored on disk until they are loaded in memory and translated in UIKit objects.
That being said, it also depends on how you are implementing it. If you use prototype cells in storyboard vs creating cells everytime in cellForRowAtIndexPath, then storyboards win because of the reuse cells (though you can also reuse code created cells).
And that being said again, the performance win you have by creating UI with code is ver small and not even close to be perceptible by the human eye. Therefore, for me, using the storyboard is a no brainer for the ease of creating interface without polluting your code.
You can see a nice article about that here: http://www.toptal.com/ios/ios-user-interfaces-storyboards-vs-nibs-vs-custom-code. The article is approx. 1 year old but it still is accurate.
The effective performance will be identical for the same layouts. I would choose one approach over the other based on different needs.
Storyboard prototype cells can be faster to setup, easier to get Autolayout constraints working correctly, but you cannot re-use that prototype cell outside of its Storyboard. If using the same cell layout across multiple views is required, writing your table view cell in code or using a nib file is required.
Also, it should be pointed out that cellForRowAtIndexPath is still required when using a Storyboard prototype cell in order to configure your cells, assuming you have some sort of dynamic data to display. Similarly, in the programmatic approach you should not be creating views in cellForRowAtIndexPath but rather configuring them.
Custom Cell For UITableViewCell
I'm developing an iOS application and i need to make a custom cell for my side menu, i have seen so many examples and i found out those two approaches :
Make a class (.h and .m files) that inherits from UITableViewCell and put the outlets in the .h file then apply the class on the cell and connect those outlets to the labels and/or images from your cell in the storyboard.
Or the easy way is to give a tag to the labels/images or whatever you have in the cell in your storyboard.
My Question: I'm wondering which way is more accurate and professional and used by most iOS developers ?
Definitely the first one. It's clear and maintainable in the future. The purpose of the tag is not to store arbitrary values. See my answer regarding this.
This article has some details on the usage of tags
For iOS 7 and iOS 8, we're implementing these things that look like drop-downs, but each just launch a modal window.
What makes more sense, using 3 UIButtons, 3 UITableViews with 1 row, or something else? In the past, there would be more than one of these all lined up, so I would put them in a UITableView and set the accessoryView of the UITableViewCell. Using the cell was nice, but three UITableViews seem like overkill here and a maintenance hassel.
The closest post I found regarding this was one about using an UITableViewCell outside of UITableView
What would make the most sense is to follow the iOS design guidelines. Instead of trying to create custom dropdown menus (or worse: showing a drop down menu, but displaying a modal view when the user is expecting a drop down view), that UI could be replaced with 1 UITableView that has 3 UITableViewCells in it. The text on each cell would be the name of the setting to be changed and selecting the cell would push segue to the next page. This will give the app a uniform iOS UX; allowing users to know exactly how to use your app because it works similarly to other apps on their phone. Check out the Settings app on the simulator to see what I am describing.
I don't see any advantage to using a UITableView or a UITableViewCell. I think this is clearly a case for three UIButtons. You can set constraints to keep them nice and clean. One cool thing that might be worth investigating is using a unicode character for the downward arrow. That way you could have the tap feedback on the whole "thing" as you called it.
When I need to create sort of dropdown menus, I usually take advantages from UITableView, one above all is when you will need to add one or more selections in the dropdown you just need to change the data model.
UITableViewCells are easily customizable that means that you can create almost everything you want.
I think that your design doesn't adapt well to a mobile application, those kind of menu are more web style, with 3 buttons and a UIPickerView you can really improve the user experience and also adapt in a really easy way on the ipad embedding the picker in a UIPopoverController.
as i agree with #keithbhunter, but still if you want then may this links will help you.
http://code4app.net/ios/DXPopover/54741ca3e24741c56db03ca0
https://www.cocoacontrols.com/controls/kxmenu
https://www.cocoacontrols.com/controls/nidropdown
I'm trying to develop a universal iOS app and ideally I'm trying to get as much code re-use as possible.
I'm using storyboards so the UI is segmented into scenes.
In the iPhone storyboard the particular scene in question is best suited to a table view.
In the iPad storyboard, the equivalent scene in the storyboard would ideally implement a UICollectionView and so render the content in a grid.
Both views should implement a pull-to-refresh control which in one case is going to call a [UITableView reloadData] and in the other a [UICollectionView reloadData].
Anybody any advice on how to get the maximum amount of code re-use, ie. what does the controller class look like?
1 option would be to have 1 monolithic class that conforms to both the UITableView protocols and the UICollectionView protocols but this doesn't feel right.
Another option would be to have a base class and then subclass it with specialisations for iPhone and iPad. Whilst this feels cleaner, I'm still thinking there might be a better way. In my first attempt at this it felt like there was more code in the specialisation classes than there was in the base class.
The third plan I've considered is simply to use a UICollectionView in both apps therefore eliminating the complexity of the controller. Hopefully I could force the layout of the collection view to be a grid on the iPad whilst tell it to mimic a table view on the iPhone.
Whilst on the face of it this sounds easy I'm struggling to make a UICollectionView work exactly like a table view would do normally.
Any advice guys?
Many thanks,
CA.
If you are not using some of the specific UITableView features[1], making UICollectionView look exactly like a table is trivial. I think I would go for using UICollectionView as it will allow more flexibility in the future and you will have to use it anyways.
When you are talking about code reuse you probably mean the DRY principle. It just says you should not write the same code or the same information twice, but I don't think this is your main issue here.
I would use a UITableViewController on the iPhone and a UICollectionViewController on the iPad. I think this is the cleanest and easiest way to go. What exactly do you hope to reuse among both controllers? The both require two different delegate protocols, so most of the methods will be specific to one platform. You will need two NSFetchedResultsController if you're using Core Data, but reusing the fetched results controller code only makes sense if you need the same data on both platforms.
If you create a new universal project in Xcode you will get a basic project setup that looks different on iPhone and iPad. Try to understand it (there are some details to pay attention to) before you start programming, I think it will answer at least some of your questions.