I am writing a "journal" app using MvvmCross for IOS. For the first View I wanted to have a scrollable list of books which is sourced from a List.
My current implementation is using the viewDidLoad method to dynamically resize the content size of the UIScrollView and add a number of SubViews for each of the books I want to display.
I'd prefer to data bind this but I can't work out the best way to implement a bindable scrollview. I'd be interested if anyone else has tried something like this before, and if there is a recommended way to do it?
I'm thinking of sub-classing UIScrollView with an ObservableCollection and using collectionchange notifications to re-populate the scrollview content as required.
Thanks for any guidance
Related
I am trying to implement the same style of UI as the new Uber iOS app, at least the pull-up view. I am wondering if this is a UICollectionView or a UITableView. How are the inner horizontal scrollable views implemented? I have done something like this before in iOS back in 2009, but that was UITableView inside a UITableView. Just wondering if UICollectionView is what should be used now?
Also, how do they allow you to drag the view up and then switch to a new view?
They seem to be simply animating transitions. There are similar questions here on SO addressing this for the card implementations used in Apple’s Music and Mail apps. As for the horizontal swiping, I would use a collection view nowadays but I don’t see it wrong using a tableView.
Hope this will help
I have design the UI for the below screen as I am little bit confuse that what should have to use for the below screen. As you seen the on the screen below things:
1.Scrolling part of Images swap.
2.Again another Scrolling images Swap.
So here for the scrolling Images what should I use its Collection View for both or Pagecontrol for one and Collection view for other. Please suggest me.
Thanks and Appreciate for the help...
Use UITableView and in its cell use UICollectionCell so that you can scroll horizontally and vertically.
see Back image, this is how you can implemented output looked like.
As Tinu Dahiya pointed it correctly, You should use tableView and custom tableViewCells to achieve your UI design. This approach will also make your coding easy to handle dynamic contents which you might be fetching from server. For your reference you can directly use this control from cocoa controls. This control is ready made dish for you, you just have to implement your logic to achieve your functionality.
Is the iOS 7 Apple Mail app is using a UITableview for the composing and viewing message screens? If so, why?
The composition screen appears to be using a UITableView with a UITextfield for the subject row and a UITextView for the message row. What is the benefit? There aren't any table rows similar enough to be reused (Max is 6 if you include cc and bcc), so I don't see a performance benefit. There is no Edit mode (i.e. move, delete rows) on these two screens. The resizing table rows necessary to accommodate long messages seems like an unnecessary headache.
I'm working on an app with a similar text input layout and number of fields. I initially planned to use a UIViewController with UITextField and UITextView placed on a UIScrollView. Examining the Mail app, I'm assuming there's a reason Apple would use a UITableView. Though I don't see what it is.
Insight appreciated.
Table views are REALLY good at a few things, and one of those things is creating forms. All you really need to do is add the fields to the cells and do a little cell customization, and the table view handles all the spacing, formatting, rotation, scrolling, etc.
I built an open source iOS form building library that is build on top of UITableView for just these reasons. (https://github.com/mamaral/MAFormViewController) In my case, if you need to move around or add a new field to the form, it's as simple as updating the data source with a new form-field cell, as opposed to creating a totally new textField, configuring it, determining the frame, moving everything above and below it around accordingly, etc. I would suspect these reasons are similar to why Apple would use table views for forms like the above.
The class chain is:
NSObject - everything subclasses this. you have to be really crazy to not subclass it
UIResponder - anything that responds to user input should be a subclass of this. the message view responds to user input
UIView - anything that draws to the screen should subclass this. the message view draws to the screen
UIScrollView - anything that scrolls should subclass this (note: that's not how it works on OS X! Only on iOS!). The message view scrolls, so it needs to subclass UIScrollView
UITableView - anything that has rows of data should subclass this. The message view has four rows, so it should subclass it.
Basically, it subclasses UITableView because it needs all of UITableView's functionality. So why not subclass it? You are saving yourself thousands of lines of code by doing so.
Duplicating all of UITableView's functionality is very difficult.
Chances are if you write an app without subclassing UITableView, it will be so sucky Apple might even reject it from the store, telling you to go back and make it work properly. Which would mean subclassing UITableView or else writing thousands of lines of code — for example Voice Over is a huge pain in the ass if you don't subclass UITableView.
If you don't want to restrict yourself to rows of data, consider using a Collection View.
I'd like to implement a feed in iOS 7 that is only pulling new data if it appears the user has a chance of viewing it. I know UITableView is a subclass of UIScrollView that does this well, but I can't get the cells to behave the way I'd like - I'd like it to look similar to facebook or twitter's newsfeed where you can reload by pulling down and load more by hitting the bottom.
I've seen other questions such as this but I'm looking for vertical scrolling only, with absolutely no horizontal movement. I'd like to use a method calling (for example) nextTenPostsFromIndex: that instantiates from zero, and applies to whatever index was the last on the screen if hitting the bottom.
My question: Is the best way to go about this to create a UIScrollView, place a subview inside of it, and programmatically space them on the available scrollview space, and apply the same drawing methods again with repopulated data if nextTenPostsFromIndex is called or checkForNewPosts (if pulling down from the top)? Would this be a reasonable way to implement Facebook's iOS7 newsfeed, or others like it?
Short answer: No. You really ought to use UITableView for things like this. You can use a custom cell or whatever you want. If it helps you, also know that since UITableView is a subclass of UIScrollView, you can do anything you would normally do with a scrollview, including assigning a delegate which acts based on the current position when scrolling.
Ok, so I have a normal viewController that has a UIScrollView in it that gives details about distilleries. What I wanted to do was have a list of spirits that are distilled at the distillery that they are reading about. So I attempted to implement a UITableView inside of my UIScrollView, and after hooking everything up and writing all the delegate and datasource methods I come to find out that a UITableView will not work inside of a UIScrollView. So does anybody have any ideas as to what kind of User Interface Object I can use to accomplish something like a UITableView's dynamic characteristics? I don't want to use a UITextView because it just looks cheap and unstructured. I need something that can dynamically change the number of items shown because not all distilleries will have the same amount of spirits distilled there.
If you are implementing a UITableView, there is no need to create a UIScrollView.
As a UITableView will automatically increase its size and behave like a scrollable view whenever the content size is larger than the screen.