I'm trying to figure out the best way to display a long list of controls that go off screen? If you have played or seen IMobsters, it's kind of like the missions tab. There are 15 jobs, each job "section" would have 4 labels, 2 buttons, and an image. I want some static info at the top, then be able to scroll through all the jobs.
Also, do you ever run into a "Feasibility" limit for how many controls you have to code and connect using IB? There would over 200 different labels and controls here I would have to make IVARS etc. Is there a better way?
I'd suggest using UITableView for your purpose. Each cell will correspond to job 'section' you described and will contain 4 labels, 2 buttons, and an image (or whateve you want). UITableView will handle scrolling your contents if it is too large, proper reusing of its cells will also allow you to avoid creating >200 instances of UI elements and will improve your app performance and memory usage.
Related
So, I'm a bit of a noob to iOS (PHP dev). I have a UITableView in a UIViewController. The cells consist of a combination of any of three different custom prototype cells. Which cells are loaded is based on a service that loads the questions and types. One has a segmented control with 2 choices, another with 8 choices and the third has a UITextView to receive a comment. This is essentially a survey. I can grab the values of the controls as they are answered, but I'd like to be able to just gather them up when the 'submitResponses()' method is called as an action attached to the 'Submit' button.
Any ideas? Should I be going about this in another way?
The "correct" way to do this is definitely to collect the data as it is entered!
One of the biggest problems with the approach that you suggest is that for larger tables it simply won't work because if a table view cell is off the screen, you can't access it or the controls/views that it contains (and it may not even exist yet!).
I have a horizontally scrolling UIScrollview with paging enabled. Each page represents a data feed. Each data feed consumes a fairly large amount of memory including text and images displayed in a UITableView. Since the user can have an unlimited amount of data feeds, I need to lazy load them to prevent maxing out my memory usage. My thought is to keep up to 5 data feeds in memory at any given point, and release anything outside of that range. My initial take is to keep the page in the viewport in memory, and the 2 pages to either side of it. This way when the user scrolls, the next sequential page will always be in memory and will display quickly.
Here is my problem:
We also need to support a scenario where a user can skip to a specific data feed, possibly 10 or more pages to the right or left, which throws my entire lazy loading scheme out the window.
Might there be a better strategy to support this scenario?
Yes, what you can do is create an outer scroll view, which houses individual cells akin to a tableview. In this respect, the cells have a content view which you can place your data, let's just assume you know how to do that since it seems you do.
Once you have this architecture in your mind, it becomes fairly clear: You can, knowing the width of your cells, and the size of the screen, some simple math can tell you how many you have on screen, and you can add one to the left or right so you're preloading some data for when the user scrolls.
This will say, give you the ability to have in memory, at most 5 feeds, if 3 are visible, at the start or end of the content view in the scrollview, 4 feeds, regardless of whether or not you have a billion feeds.
One critical part of this is cell reuse. You maintain a couple NSSets, one for recycled cells, and one for visible cells. Add items that have gone off screen to the recycled cells, dequeue items from recycled cells when setting up the cell, as to save additional memory allocations, which can be expensive. Just remember, using this strategy, you are still subjective to the same caveats as a UITableView with respect to cell reuse.
I'm plugging some software I wrote here, so forgive me for that, but I'm doing so as an example of what I'm talking about if you get stuck implementing what I discussed here, it's available here for your perusal.
One final note. To support skipping of cells, it's just simple math again to adjust the point in the scrollview you are at. The action for this can be done with a gesture, though now we're talking a pan gesture recognizer, with some specific properties that will be specific to your application, as an example. Or you can use buttons if you really must. Just ensure you know how to calculate your offsets to your cells, and scroll to that point. You'll be fine.
It's hard to give accurate advice with the information provided in the question. So I will just present a few thoughts I got when reading the question.
Does it take long to download a feed? Would it be possible to just download a few item (a screenful) to get the first few items showing right away? Perhaps lazy load the images if possible.
Have you considered caching the feed data on disk? That way you can present some data right away and then update the feed as new data gets downloaded.
Since each page is a feed view, would the user just scroll past a feed without looking at it? Do you really need to load 2 views on each side or can you get away with just 1 view on each side.
I don't think your lazy loading scheme stops working just because the user can skip directly to any page. You would have to start loading the data for that page when it is selected but by using a disk cache or downloading a small sample could make the app feel faster. I also think that using some kind of animation to animate to the selected page could buy you a little time.
Here is my problem: We also need to support a scenario where a user can skip to a specific data feed, possibly 10 or more pages to the right or left, which throws my entire lazy loading scheme out the window.
Then you need to fix your data structure. I wrote pretty much exactly this (a UITableView-like paging scroll view) and it works fine (there are some reloading quirks, but hey...).
Keep track of which pages you've loaded. I used a ring-buffer-alike modulo 8 and spent a while getting the code right; it's probably a lot easier to just use an NSDictionary with NSNumber keys and UIView values. This means when you change from page 1 to 10, you can still tell that the loaded views are for pages 1, 2, and 3, and drop them.
Load the required pages in -layoutSubviews. I would load 1 or 3; 5 is probably too many (but you need to load at least 2 if you're between pages).
Load 3 (one to either side) in -scrollViewDidScroll:. This is so that when you scroll from page 1 to 2, it doesn't try to load page 4 (which hasn't been loaded yet).
Load 5 (two to either side) in –scrollViewDidEndDragging:willDecelerate: if willDecelerate is NO, –scrollViewDidEndDecelerating:, –scrollViewDidScrollToTop:, and –scrollViewDidEndScrollingAnimation:. The idea is that the animation's over, so you can load the extra views without the user perceiving lag.
Possibly load 5 in –scrollViewWillBeginDragging:, to make sure that page 3 is loaded if you're currently on page 1.
I decided to do "two pages either side" because when you flick from page 1 to page 2, it often shows a pixel-wide sliver of page 3 when it bounces. This can be avoided with scroll view insets, but we didn't think of that at the time (oops). There's otherwise not that much of a reason to choose 5 over 3.
It's a bit of work to get right, but otherwise seems to work flawlessly.
1) I want to create a List by touch and dragging icons from a Master List.
2) Also have the ability to Delete items in this newly created List or Rearrange their order.
Is there some code sample one could look at or possible design pointers on cleanly accomplish this functionality.
I realize UITableView could accomplish this. But doing it visually in a single screenful is intuitive as it maintains the overall context of the task at hand.
Thanks
None of the API UI classes will let you do this. Both tableviews and scrollviews want the entire screen. You're going to have to write a lot of stuff from scratch.
I think you will find that a dual list design is a poor interface choice. You really don't have room on an iPhone screen to display and manipulate two list within the same view. Remember as well that you won't be able to see all of both list if they run off the screen (which is likely.)
"Intuitive" is just marketing speak for "familiar". There is nothing intuitive about a nonstandard interface. Since iPhone users don't routinely drag items between list it will not be readily apparent to them how to work the interface. You will most likely be better off with a single master table in which users can check individual cells to be added to a sub list. This is a common interface on the iPhone and therefore more "intuitive".
Before spending a lot of time on this, I suggest you do a mockup that will display on the device itself. You can simply draw mock interface in a graphics program and then display it as an image in an imageview. This will let you test if you can display enough information in dual list to be useful and whether you can hit elements in both list reliably.
In reference to my previous question, I would like to know how to implement a large grid of cells in an iPhone application.
I'm working on an interface which would be similar to an Excel spreadsheet, with many rows and columns. Do I have to handle each cell separately? How can I handle user interaction in each cell?
Is there a standard way to create this type of control?
There is no real standard mechanism.
If all of the cells in a given row will always fit in the width of the screen, one way to do it would be to create a UITableViewCell with several UILabels and vertical separators between them. If all of these rows had "columns" of the same width, you would get the appearance of a grid.
If that isn't possible, it might be helpful to think about what the table view control truly is. A table view is just a scroll view that automatically adds, removes, and recycles its subviews so that only the ones that are visible at a given time are in memory. There is no reason you could not write a GridView control that did the same thing, but in two dimensions. It wouldn't be as easy as using the built-in table view, of course, but if the table view can't do what you need, well, that's why Apple isn't writing all the apps.
Sounds like the exact thing that UICollectionView was made for!
http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UICollectionView_class/Reference/Reference.html
Look at my answer to this question: MS Excel type spreadsheet creation using objective-c for iOS app.
Basically there's no standard way to do this. You will need to made everything by hand and there's 3 ways to go:
Use a UIWebView and layout everything using html/js.
Modify a UICollectionView.
Make everything by hand using Core Data.
I wanted to generate one fix view using interface builder, but the size of that view is exceeding the size of iphone screen,and I am not able to maximize screen. I wanted to show table view in that screen.
I did enabled scrolling but that didn't work,
Update 1:
Actually I wanted to show thumbnail image inside cell and i want to show 5 cell so 5 thumbnail image,those images are static. So which is a better way to achieve this ,interface builder or programming?
Hope this is clear enough.
Your question is not terribly clear, so this is the question that I am attempting to answer here:
You want to have a table view which has five rows, each of which has a small image.
Short answer: you can't do this entirely in the Interface Builder. What you can do is define your table view, including the "look," scrolling abilities, etc. And then in the same XIB file you would define the table cells (which can include your pictures, captions and what have you).
You then have to connect the two together programatically. Apple provide plenty of examples in the SDK on how to do this.