From the documentation of UITableView / UITableViewController:
If you decide to use a
UIViewController subclass rather than
a subclass of UITableViewController to
manage a table view, you should
perform a couple of the tasks
mentioned above to conform to the
human-interface guidelines.
To clear
any selection in the table view before
it’s displayed, implement the
viewWillAppear: method to clear the
selected row (if any) by calling
deselectRowAtIndexPath:animated:.
After the table view has been
displayed, you should flash the scroll
view’s scroll indicators by sending a
flashScrollIndicators message to the
table view; you can do this in an
override of the viewDidAppear: method
of UIViewController.
So lets say I do my custom stuff here and I do not flash the scroll indicator, and I do not reset the selection (which I think is wrong anyways, the user wants to know from where he came from). Will they reject it?
Apple may reject it. In practice, they won't (this is practical experience, not inside knowledge). They will reject apps now for using their private api, although in the past they wouldn't. But if your app sucks, not flashing scroll indicators might be a reason they give for rejecting it. If not deselecting a cell is important to your UX, then you should be ok - or it's possible that you have a poor UX.
Deselecting the cell should be animated - so the user gets the hint of where they came back from, which they should be able to remember anyway. But retaining the selection could lead the user to think that the selection is somehow significant and will affect their subsequent actions, which from your description it won't. So lose the selection.
Related
I am implementing a UIScrollView which behaves mostly like a UITableView, a bit more advanced with that.. but most of the API used are the same signature.. cellForRowAtIndexPath.. etc. First before people start storming why not just use a UITableView, let me just say that I can't. The reasons are fairly complex, but that is a decision been made.
The issue is now I am implementing infinite scrolling, basically when I scroll down and I am at 65% of the full contentHeight I am doing an async request to the backend to fetch more data and adding it to the data source and then calling reloadData. The issue is that if I am calling reloadData while the user is scrolling, it doesn't provide a very smooth scrolling experience. So what is the best way to tackle this? Also I noticed that reloadData basically refreshes the entire table view (in this case my scroll view). In my table view cell I am animating a UIImage to fade in. So when reloadData is called, the image that is already presented is being faded in again, which is kind of annoying.
How do I avoid such things?
Any tips and tricks?
In case you're still working on this, check out PSTCollectionView. It works exactly like UICollection view but supports backwards of iOS 4.3.
Its difficult to answer without knowing why you need to create a custom view similar to the tableview. If you have a developer account you might want to check the new iOS 6 view based on tableview. Not sure if I can talk more about it as it is under NDA.
For the UIImage fading, how about flagging each UIImage as displayed and then do a check when reloading the data or recalling the fade statement. Only fade the images that are not flagged as already presented?
In new iOS 6.0 there is new controllers call UIContainer view,its similar to UITableview but we can also set more then one column with that.
delegate methods for that controllers are almost same as in UITableview.you can use that controller if you have similar requirements.
I do understand how to go about making the UIKeyboard push up the UIView if the active UITextView is blocked by the UIKeyboard as per this question: How to make a UITextField move up when keyboard is present?.
What I'm wondering is, from a design perspective, how do you go about implementing the keyboardDidShow and keyboardDidHide methods so that all of the views in your app, whether they be a UIView, UITableView, or UIScrollView all have this functionality and so you need to implement these methods only once?
The only way I could think of would be to have the view property of the UIViewController always set to a UIView, and if you have a UIViewController that needs a UIScrollView or UITableView, just attach it as a subview to this. Then if the UITextView is being blocked, just move the parent UIView up so it will move all of the views that are attached to it.
Does this sound like a good plan, or is it even worth it? Anyone else have any other ideas?
This is a little old, but it's a great article about using firstResponder methods to tell views to slide up. I, personally, like to put my UITextField in a parent container and move it all up. However, I do NOT suggest putting everything in there and moving it all up, because the UITextField "feels" better just above the keyboard. But I do like the background or certain items to move up with the UITextField.
See below: http://cocoawithlove.com/2008/10/sliding-uitextfields-around-to-avoid.html
This is a nice implementation that moves the field up based on the section of the screen it's in (upper, middle, lower). Works very well. May need to be updated for newest SDK, but should be pretty easy.
In experimenting with this, I noticed that if you want to make a BaseViewController that implements this functionality to work for everything that inherits from it, you have to attach another view on top of the UIViewController's view property in order to get it to work. Reason is, if you push the UIViewController's view property up when the keyboard appears, then it resets itself if the app comes back from being active and it's messy.
The problem with this however, is now in all of your child classes you have to attach your subviews to this new view property instead of the regular view property. Also, you probably have to make a custom UITableViewController which will inherit from your BaseViewController class so it can inherit the keyboard notification methods.
Ultimately, I've found it's not the worst idea to have another view on top of the UIViewController's property for a bunch of different scenarios. Making a custom UITableViewController isn't that big of a deal either. So if you have a lot of text fields in your app, this might not be the worst way to go.
I've decided that I don't want to ever use UIPickerView again... it's completely inflexible in terms of functionality, design, and size (height). It also occasionally gets stuck between rows, and the delay that occurs between letting go of a wheel and when the delegate method is fired indicating that a new row has been selected (because of the "settling in" animation) has caused lots of problems in the context of the apps I've been working on.
That being said, the user-friendly aspects of UIPickerView are good, and I'd like to try to replicate it. I've tried to research different ways that this might be done, but without much success. Does anyone have any ideas as to what would be involved to make something similar from scratch?
I was trying to get a UITableView subclass to behave in such a way that whatever cell was currently in the middle of the table (it would change while dragging, etc.) would change its background colour to something different implying that it was "selected". As soon as the table was dragged such that the "selected" cell was no longer in the middle, the cell would go back to normal and the new middle cell would change colour. So this would be like UIPickerView in a sense that you don't have to tap on a cell; instead you just drag to have one selected by default.
I figured it should have been easy enough to intercept the "touchesMoved" method of UITableView and add some code that looped through all currently viewable cells in the table, checking to see if their frames overlapped the center point of the table, and changing their appearance accordingly (plus sending a notification to other classes as needed to indicate the "selection" change). Unfortunately, I can't get this to work, as the "touchesMoved" method doesn't get called when I drag the table. Am I missing something obvious?
Any ideas or suggestions would be very much appreciated at this point... I made an app that relied heavily on UIPickerView objects, and because of the problems I've run into with them, I'll have to abandon it unless I can figure out a way to make this work.
Thanks very much,
Chris
Remember that a UITableView is a subclass of a UIScrollView, and the UITableViewDelegate gets all the UIScrollViewDelegate method calls too. scrollViewDidScroll: sounds like it would easily fit the bill for knowing when the table view was scrolled.
As for finding which row is in the middle of the view, just use indexPathForRowAtPoint:.
I'm writing a simple iPhone app which lets a user access a series of calculators. It consists of the following:
UITableViewController (RootViewController), with the list of calculators.
UIViewController + UIScrollView (UniversalScroller), which represents an empty scroll view - and has a 'displayedViewController' property.
UIViewController (Calculators 1-9), each of which contains a view with controls that represents a particular calculator. Each calculator takes 3-5 values via UITextFields and UISliders, and has a 'calculate' button. They can potentially be taller than 460px(iPhone screen height).
The idea is:
User taps on a particular menu item in the RootViewController. This loads and inits UniversalScroller, ALSO loads and inits the UIViewcontroller for the particular calculator that was selected, sets the displayedViewController property of UniversalScroller to the newly loaded calculator UIViewcontroller, and pushes the UniversalScroller to the front.
When the UniversalScroller hits its 'viewDidLoad' event, it sets its contentSize to the view frame size of its 'displayedViewController' object. It then adds the displayedViewController's view as a subview to itself, and sets its own title to equal that of the displayedViewController. It now displays the calculator, along with the correct title, in a scrollable form.
Conceptually (and currently; this stuff has all been implemented already), this works great - I can design the calculators how I see fit, as tall as they end up being, and they will automatically be accommodated and displayed in an appropriately configured UIScrollView. However, there is one problem:
The main reason I wanted to display things in a UIScrollView was so that, when the on-screen-keyboard appeared, I could shift the view up to focus on the control that is currently being edited. To do this, I need access to the UniversalScroller object that is holding the current calculator's view. On the beganEditing: event of each control, I intended to use the [UniversalScroller.view scrollRectToVisible: animated:] method to move focus to the correct control. However, I am having trouble accessing the UniversalScroller. I tried assigning a reference to it as a property of each calculator UIViewController, but did't seem to have much luck. I've read about using Delegates but have had trouble working out exactly how they work.
I'm looking for one of three things:
Some explanation of how I can access the methods of a UIScrollView from a UIViewController whose view is contained within it.
or
Confirmation of my suspicions that making users scroll on a data entry form is bad, and I should just abandon scrollviews altogether and move the view up and down to the relevant position when the keyboard appears, then back when it disappears.
or
Some pointers on how I could go about redesigning the calculators (which are basically simple data entry forms using labels, sliders and textfields) to be contained within UITableViewCells (presumably in a UITableView, which I understand is a scrollview deep down) - I read a post on SO saying that that's a more pleasing way to make a data entry form, but I couldn't find any examples of that online. Screenshots would be nice. Anything to make my app more usable and naturally 'iPhone-like', since shuffling labels and textboxes around makes me feel like I am building a winforms app!
I've only recently started with this platform and language, and despite being largely an Apple skeptic I definitely see the beauty in the way that it works. Help me solve this problem and I might fall in love completely.
Dan
If you have the particular calculator view, you should be able to get to the scroll view via the superview property (though there might be more than one intermediate view, so you might need the superview of the superview).
I'm about to start a new iPhone app that requires a certain functionality but I'm not sure if it's doable. I'm willing to research but first I just wanted to know if I should at least consider it or not.
I haven't seen this in an app before (which is my main concern, even though I haven't seen too many apps since I don't own an iPhone), but an example would be the iPhone shortcuts panels: you can hold on an app, and then drag it to another panel, sweeping while still dragging it. But this is the core app, is it possible to reproduce something similar within a normal app?
I only need to be sure it can be done before I start digging, I don't need code examples or anything, but if you have some exact resources that you consider helpful, that would be appreciated.
Thanks!
Yes. If you have your custom UIView subclass instance inside a UIScrollView, your view controller just needs to set the UIScrollView to delay content touches and not allow it to cancel touch events.
[scrollView setCanCancelContentTouches:NO];
[scrollView setDelaysContentTouches:YES];
When the user taps and holds in the custom view, the event goes to that custom view, which can process the touch events to drag an item around, but if the user quickly swipes, it scrolls the view.
The "panel" view that you're referring to appears to be a UIPageControl view — although, perhaps, the specific incarnation of this view that Apple uses for the iPhone's home page may be customized.
Instances of generic UIView views that you might touch-and-drag will receive touch events. By overriding methods in the view, these events can be processed and passed to the page control, in order to tell it to "sweep" between pages.
If I wanted to do what you're asking about, that's how I might approach it. It seems doable to me, in any case.
Start with this: Swip from one view to the next view
Try using a UIButton that tracks the time since the state of the button changed to "highlighted". You may need to do this in order to track the dragging and move the button around:
Observing pinch multi-touch gestures in a UITableView
Check to see if the button starts overlapping one side of the screen while being dragged. If s certain amount of time elapses since the button first started overlapping the edge and then manipulate the UIScrollView so that it switches to the next page on the corresponding side of the screen
You may need to use NSTimer to keep track of how long the button is held down, etc.
In any case there's no reason why this couldn't work.
If UIButton doesn't work then perhaps try a custom subclass of UIControl (which tracks the same touch down actions etc.). If that doesn't work then use the window event intercept thing to track everything.