I have an app that has an UIScrollView as the main subview of a view controller. User can scroll left/right between different UIViews. And each view will have its own UITableView.
My question is just how many views and table views can one view controller handle before it will get laggy and slow?
Will it be possible to have 10 views and 10 table views and still run smooth on iPhone 4 or should I come up with another way? And if so, how can I improve this?
EDIT:
I have been thinking about using UIPageViewController but I want so have parallax like scrolling between screens (yahoo weather like).
How does Yahoo weather handle so many views?
You can have massive amounts of views and subviews that are all handled by the same controller. Views are not drawn unless they are currently being displayed.
That being said, there are definitely some recycling solutions you can utilize to speed things up if you start noticing performance issues (like removing the memory of a table if it is no longer immediately needed).
The main reason you would start having complications is because of calculations to populate the data. If you have 10 tableviews all of the datasource and delegate methods could get slowed. You could use container views to encapsulate view logic. Also, as mentioned in comments, a UIPageViewController may be a good solution.
Related
I'm trying to create a generic, reusable view, that looks like a lined notepad. The way I decided to approach the problem (after a couple design iterations) is to create a custom view that is composed of a UITextView and a UIView.
When the user scrolls through lines of text I want the UIView to track the scroll direction. The key here is: Within my custom view, I need to change the position of one subview in response to events in another subview. Something needs to coordinate these changes...
Now, one approach I thought of taking was to use a MVC design pattern. A view controller could handle all events and move the subviews around accordingly. This MVC could then be embedded in other MVCs.
Normally when using a MVC design pattern, a controller would handle user events and manipulate the model and view. However, my custom view doesn't have a model - all I'm trying to do is have the view manage it's own subviews when a user does something like scroll. It seems to me that the MVC design pattern isn't a good fit here for two reasons:
There isn't a model or logic that is specific to the program it's being used in.
It seems to me that the view should be responsible for handling user events that change how the view should appear.
... but I could be wrong, which is why I'm asking for help. The question, for those who are more experienced than I and who may have done this many times before, is:
What type of design pattern is appropriate in this situation? MVC or...
You want a view to manage its own subviews? Then do that! So what if that pattern doesn't have a TLA?
A typical approach is to implement layoutSubviews in your container view. Have it check its current state, or the state of the other views in the window (e.g. the contentOffset of a scroll view), and then set up its subviews appropriately. (Resize them, reposition them, etc.)
Just try to keep it fast, since it's likely that layoutSubviews will be called frequently.
I have an application i'm currently developing for iOS which is suffering from some performance issues.
The app takes user input through a navigation controller with 5 views, the last view generates a view with a UIScrollView which has a paging effect.
Each page in this UIScrollView has 16 buttons arranged in a grid, each of these buttons is loaded with an image.
Unfortunately when I scroll to a new page in the UIScrollView, the app stumbles across in a jerky animation rather than a smooth one.
I was wondering if anyone had any suggestions on how to improve the performance for the paging UIScrollView effect.
Many thanks.
Is it smoother the second time you navigate to that view?
If so, it's probably the loading of the images that is taking the time. You can fix that by preloading your button images when the app first loads using [UIImage imageNames:...] in your app delegate. That way they will already be cached and available to render when the view is displayed.
If it's not faster the second time, it's probably the actual rendering of the views that is too slow. You can fix that by preloading the views themselves. If you store a reference to your scrollview's subviews in an array, you can preload those views in your app delegate and just keep them in memory ready to display whenever the scrollview is shown.
I doubt that those views will use up too much memory (probably a couple of MB, max), but if you are worried about it, just add a memory warning handler that flushes out the array and then re-create it next time it's needed.
I have a UIScrollView with textviews as subviews. Now in my app there are multiple UIScrollViews like these. And depending on the selection I display the appropriate UIScrollView on top of the previous view. This works fine in all cases except when the previous view has been a UIScrollView as well. In this case the behavior I get is of two UIScrollViews stacked on top of each other and both the views capture the scrolling events. The textViews from previous scrollView is also visible (not editable though) and overlaps and causes all sorts of issues. The thing is a full screen UIScrollView placed as subview to a previous view causes problems when the previous view is a full screen UIScrollView as well.
Any pointers on how to overcome this would be great. Is there anyway to notify the parent scrollview of the child's scroll events and move it the exact same way so this mess is masked?
Thanks!
UIScrollView documentation says:
Important: You should not embed UIWebView or UITableView objects in UIScrollView objects. If you do so, unexpected behavior can result because touch events for the two objects can be mixed up and wrongly handled.
As far as I know, it is generally not recommended to embed a UIScrollView subclass instance in a UIScrollView. In one of my projects, which is an IM application, I have a UIScrollView that contains many UITableViews, it works when you try enough but it really takes a lot of effort to handle subtle bugs and make it work properly.
It is really hard to say something useful for your problem without diving in to code, but i can recommend you to not add UIScrollViews one on to another like a stack. I'd try doing it by allowing only one UIScrollView at top, and removing others. When you need to show another one, remove the top one from view hierarchy and add the new one. I wish this helps, good luck.
Found a crude solution by presenting an empty view before I present the next scrollView. Added the scrollView as subview to this empty view (with a BG image) and added the to-be presented scrollView as a subview to it and then presenting this on top of the previous scrollView.
As title says, I'm wondering if stacking subviews can slow down an iPhone application.
For example, I have a UIViewController, which has a view occupying the whole screen. When the user presses a button, I create a second view controller and add its view as a subview of the original VC, making the second view completely hide the first one.
Does the application have some kind of automatic optimization which would be something like "ok, I know what to draw for every pixel of the screen, I stop seeking for subviews" ?
If not, I don't think stacking 2 full-screen views can really slow down the app, but could 3, 4 or more views be problematic if they include many subviews themselves (labels, images)?
Read the View Controller Guide sections on Modal View Controllers and memory management. Prefer to use modal Views instead of subviews when you want to present a new screen temporarily and a UINavigationController for "drill-down" views.
You can always set UIView#hidden = YES on the views not seen. That should prevent redraws.
This is largely dependent of what the subviews contain and what is the total memory load of the app. Memory is very crucial for devices like iPhone and you should never keep the things which you don't require. When you are adding many subviews without releasing any, your memory requirement obviously will increase. This may slow down the app, even may crash the app. Stacking of two may not be a problem, but stacking many is not a very good design.
So the summary is you should always check the memory load of the app through instrument and always properly respond to memory warnings.
For a vertical scroller are there any advantages to using UIScrollView over UITableView?
I ask because I am currently using two vertical UIScrollViews with UIImageViews inside of them and am having memory issues and poor scrolling performance. I am not doing much with the scrollers, only highlighting images as they scroll into the center of the scrollviews and adding a delete button above an image if the user wants to remove it. I've started to look at lazy image loading/reuse and it seems that most of these issues have already been resolved in the UITableView class, so I'm wondering if there's any reason to stick with UIScrollView?
You should be able to use a UIScrolLView with no problem if you just, like you said, lazy load the controllers, when scrolling (assuming your views are full size) you dont need to have more than 3 views loaded at any one time, all you need is the current view, the view that goes behind it and infront of it, as you scroll your view you can unload and load the appropriate views. You should look into Page Control sample application, it does exactly this and you can pretty much get all the lazy loading code from there. Link is here https://developer.apple.com/iphone/library/samplecode/PageControl/index.html