I am putting about 100 UITextFields programmatically into a UIScrollView for an elaborate data entry app (don't ask....bletch) and I am finding that it is taking too long to generate all of these UITextFields... something like 4 seconds.
Is there a better or quicker way to programmatically make so many user interface objects?
For instance would it be wiser to load a Xib/Nib and try to modify it as needed?
Thanks.
Have you thought about just creating a couple of UITextFields and reusing them once they're offscreen just as the UITableView does with cells?
Ouch, 100 textfields as data entry are harsh. But i know the problem when the client insists on a very dumb idea.
Back to topic: The problem is not the actual generation of your UITextFields. It is the way cocoa touch handles views. Views are terribly slow. Your idea with nibs is even worse, because they are in fact even slower.
The only way to avoid that is to simply not draw (add) many views. Just add the views which are currently in the visible area of the scrollview and remove the others.
Cocoa touch has actually already a very good control for that, it is called UITableView. ;)
Apple created the dequeue/reuse pattern in the UITableView exactly due those reasons.
So my suggestions for you is to use a tableview instead of a scrollview with custom cells (to avoid separators, etc.) and dequeue/reuse these cell and fill them with UITextFields which you store inside an array somewhere.
my first idea is to write a timer and load them 1 by 1 (or more) in small steps so that the UI doesn't freeze (it will still take 4 sec but at least user can input into into the loaded text fields)
here is how to make a timer
Related
I Know this question has been asked a lot in a hundred different ways (and thats just on this site). But I'm struggling to put all the pieces together.
I would like each UITableViewCell to look like this:
It has multple legends and several fields. The legends are static and wont change but the corressponding labels will vary in width and height. Therefore so will the cells. I need the legends to always align with their labels.
I have tried to do this using the Interface Builder but don't really understand the autoresizing. Though I'm happy to do this in code.
Does anybody know how to do this or at least have some good links to tutorials, source code etc?
Putting a full table view inside a cell is crazytalk. Maybe somebody got it to actually run - that doesn't mean it's best practice or good practice.
I will answer your question after making one very down to earth suggestion. Please consider following Apple's guidelines by putting just a summary of each event in your cells for this table, and allow the user to push down to another view controller to see the details of a particular event. This will probably help you develop your app faster and get to market, then you can think about advanced stuff like customizing individual cell heights at runtime.
That being said, if you insist on putting all your eggs in this basket, then I think you will need to implement your table view cell in IB, note the details for all of your content label frame dimensions, then, at run time, use one of NSString's sizeWithFont:constrainedToSize: methods to determine how big your labels will be. Make them that big. Then from that data compute the height of your cell, and return that value from your table view's tableView:heightForRowAtIndexPath:. This is how I implemented this functionality in an app a few years back. (Frankly I'm not sure that it's still working.) There may be some better methods for figuring out the label size in CoreText, I haven't looked.
A better bet will be to constrain yourself to a limit on the length of text you can put in each label. Then you can just define the labels statically and use a constant-sized cell. Putting it together in IB isn't tough. Just lay everything out, and make sure that you create an IBOutlet and XCode/IB connection for each object you want to manipulate in code.
Good luck!
Add a tableview to each UITableViewCell. The outer tableView will be responsible for holding all your cells and each cell will be a Event with cells for each parameter.
This tutorial will give you insight on how to set that up.
http://iosstuff.wordpress.com/2011/06/29/adding-a-uitableview-inside-a-uitableviewcell/
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:.
So I have a UITableViewController. The cells in this tableview have the following UIControls:
2 UILabels, one of which has a shadow and a clearColor background color.
1 Custom Progress view resized to be larger and with a different color
3 UIButtons
Functionally, they do exactly what they are supposed to do. However, I've noticed when looking at it on device that scrolling performance quickly tanks and has dropped frames all over the place, even with other interactions like pushing one of the buttons.
So I was reading around today and found http://blog.atebits.com/2008/12/fast-scrolling-in-tweetie-with-uitableview/ this article by the Tweetie guy about how to achieve fast scrolling performance by subclassing UITableViewCell and doing the drawing yourself.
The example works extremely well, but when I tried to adapt it to work with my desired configuration I realized that he isn't using any predefined UI Controls, he's mapping out everything by hand.
While I can see how this would be an extremely efficient way to do things, it strikes me as problematic for things like the progress view and the buttons, and even one of my labels to a certain extent.
So my question is this: Do I need to completely write my controls from scratch if I want my scrolling performance to be good, or is there a way to use the standard UI Controls and get good scrolling performance?
If you're adding custom controls to your cell, you should still be subclassing UITableViewCell, adding your controls in the init function, laying them out in layoutSubviews, etc. - just like any other view. As VdesmedT says, make sure you're re-using cells via the dequeue mechanism, so that you aren't allocating new cells with each scrolling operation.
OK, I will propose something obvious but to achieve UIScrollView performance, you need to be sure that the dequeue mechanism works well. I often see developers not properly set the identifier in IB and therefore missing the UITableViewCell cache benefit
I'm new to iPhone development. I'm working on a table view (default UITableView subclass) that contains complicated custom cells, with multiple subviews and controls. Scrolling is not very smooth, but I'll just leave that for now.
The question is, when I'm scrolling the table view with quick swipes, the table sometimes suddenly stops scrolling and the scroll indicator will not disappear, and I have to swipe again to make it scroll.
If the table contains very few rows, say, 5 or 6, it never stuck. The custom cell class I used is from the example provided here: http://blog.atebits.com/2008/12/fast-scrolling-in-tweetie-with-uitableview/
Can anyone give a hint or solution to this problem? Thanks in advance.
Table cells are only created when needed, that is when they come into view and they are usually unloaded and released when they go out of view.
Put in an NSLog( #"Cell loading" ); in your cell creation code and check the console to see this happen as you scroll.
Are you using caching? The docs demonstrate how you can cache table cells to improve performance. What else are you doing when you're creating table cells? If there's any performance slow downs you should probably not have that happen while creating cells.
What I do is I generate all my content before the table loads and when cells are created all that content is simply placed into the view.
Any kind of drawing will drastically reduce performance especially if you're using transparency.
For posterity, and only valid if you are using Unity-iphone: this problem was driving me insane and I fixed it with the suggestion in this post:
http://forum.unity3d.com/threads/113815-quot-Sticky-quot-scrolling-in-UITableView-and-UIScrollView-when-interfacing-Unity-and-Obj-C
Changing the preprocessor flag to
#define USE_DISPLAY_LINK_IF_AVAILABLE 0
gave the issue a happy ending.
I'd take a look at your cellForRowAtIndexPath method - for a couple of possible problems.
If you aren't using the cell reuse that will slow things down a lot and if you are re-allocating or re-initializing your custom cells in the cellForRowAtIndexPath delegate method that can cause big performance issues.
If you post your code for that method we can give you some hints as to what might be causing it.
I'm curious just how expensive in as far as resources go is UITableView's reloadData? I have an app which will make roughly 10 subsequent HTTP requests, and as it gets data / preps, it reloads the tableView. As the data set grows larger and larger, it's becoming very sluggish. I'm trying to figure out if it's because of the amount of times I'm reloading the tableView or because of how I'm grabbing/parsing the data.
What's the best practice in this case?
From UITableView.h:
- (void)reloadData; // reloads everything from scratch. redisplays visible rows. because we only keep info about visible rows, this is cheap. will adjust offset if table shrinks
"This is cheap."
implement your table view methods well and it'll be no big deal to call this function all the time.
On a side note, you should try to use the appropriate methods to animate adding and removing rows if you are thinking of using reloadData for that.
The best practice is to have your implementation of cellForRowAtIndexPath: do as little work as possible. In fact, it really shouldn't be doing any work except populating the UITableViewCell instance with the data it needs to display.
You should be using cached UITableViewCells so you don't have to allocate a new cell each time. If you can do your parsing and such in a separate thread and make the parsed data, ready to present, accessible to cellForRowAtIndexPath:, you shouldn't have any performance problems.
You didn't say if you were using a custom UITableViewCell subclass, but if you are, deep view hierarchies can also present a performance problem, since each view in the hierarchy gets drawn. The flatter you can make UITableViewCells, the better.
Hope that gets you moving in the right direction.
Best thing to do is profile your app to see where it is slow.
That said, if your table cells are all the same height, then I think
reloadData
only has to call
cellForRowAtIndexPath
for cells that are visible on screen.
Table view reload expense is:
Figuring out how many sections and
rows per sections you have
getting row heights.
Row heights in particular are figured out for all elements of the table, anytime you call reload data.
The remaining expense is cellForRowAtIndexPath, which is usually not too bad because it only is called for as many rows as are on the screen. It can be bad when scrolling if you do not reuse cells like you are supposed to.
The key for you is probably, to ask yourself what triggers the HTML load and possibly move that into a background thread.
Boot To The Head is correct.
I'm doing a progressive one-by-one article list update in Instapaper, and I call -reloadData on each completed download. Sounds similar to what you're doing. It doesn't result in any noticeable performance slowdowns.