This question maybe already asked in stackoverflow. But, I did not get any clear idea to my scenario.
I have a viewcontroller (Say, MyViewController).
I have a scrollview(Say, MyScrollView) and I have N number of views (Say MyView1, MyView2, ...) in it.
Those views can be scrolled horizontally. Refer the below image for more clarification.
This image was taken from here.
So, the red area is the scroll view that holds multiple views which are yellow color.
Scenario:
I want to call API's for each view, when the API calling and parsing data occurs, I need to show some loading activity indicator in the views. After successful parsing, I need to update corresponding view with UITableView.
Questions:
In my case, the number of views may vary from 3 to 6. Should I maintain 6 separate UITableViews and UIActivityIndicator's?
I tried with three pointers like left, middle & right to hold reference of tableview and activity indicator. But the problem is, before the first three pages are loading, if the user goes to the fourth view, this system will collapse with so many conditions.
Suggestions needed. Confused!!
I think you have to use UIPageViewController with UITableView. it will solve your problem.
Related
I'm currently creating an update of my iOS application and I'm a bit stuck. I've tried to googling around but cannot find a decent answer on this.
I've a menu which links to different views. And I'm not really sure if I've done it the best method.
I've created a view, and added the links into a stack view. Should I considering changing it all to a tableview? or a collection view? Or maybe there's another way?
The current look:
Should I change this to a tableview? collection view? or something else? Or just let it stay as it is?
If the number of items in your menu changes at runtime and is large, you should use a table view, because a table view is good for efficiently displaying a screen's worth of items from a large list of items.
If the contents of your menu is small (under maybe two screenfuls of items) and fixed at compile time and you are using a storyboard, then you could use a table view with static cells, if you can make it look the way you want.
If the contents of your menu is small, then you can use a stack view (inside a scroll view) if that is easier for you. There is no particular advantage to using a table view over a stack view to display a small amount of content, unless you need other features of the table view (like the ability to select/deselect rows).
Based on the screen shot you posted, I'd either use a table view with static cells (since the screen shot is from a storyboard) or a stack view, depending on whether I can get the appearance I want from a table view. If, as in the screen shot, the buttons must be centered vertically, I'd use a stack view, because it's easier to vertically center the content with a stack view.
Look, the fact of have many itens on your screen is clear on the mobile applications, to make it easy, we have collecions view like UITableView and UICollectionView. On the UITableView's case, this implements the scrolling and have methods do handle the operations' list, you can see the documentation to check these methods: https://developer.apple.com/documentation/uikit/uitableview.
Main reasons to use UITableView
Implements scroll behavior.
Independent of size screen you can access all itens.
Easy to detect interactions like tap on cell.
Easy to make changes, like insert and remove content.
The UITableView exists precisely to solve problems like you has.
I'm trying to build a tabbed bar with swipe-able pages exactly similar to Android's ViewPager. Each page is supposed to hold one UITableView only.
I don't know what's the better way to achieve this but so far I have 2 ideas. Also the tabs are dynamic. I can have one tabs or 10 tabs. It depends on the API I'm communicating with. (The tabs represent shop categories and the table views represent the products)
The tabs will be a UICollectionView and then I'll use one of the following options:
First approach is to build two UIViews, each of which will hold a UITableView. One UIView will be outside the screen bounds and the other one will be the one being displayed. When the user swipes and the tabs change, the UIView being displayed will move outside the screen bounds, either to the right or left and the other UIView will be displayed. As soon as the swipe action begins, I will change UIView's (the one that's about to be displayed) datasource and reload its data.
Second approach is to have a number of ViewControllers OR UIViewContainers equal to the number of tabs (which is dynamic). I'm not sure how I'd implement this because I'd have to worry about reusing UIViewControllers/UIViewContainers inside of my main UIViewController as well as handling a large number of them.
Using one big UICollectionView to host a UITableView in each UICollectionView cell. It's pretty much the reverse of the old App Store.
UICollectionView in UITableView Tutorial
So, how do most people implement similar UIs? Is there a different approach I should consider? Any other tips that can help me implement it?
EDIT: I may have left a final detail. I actually have 2 sets of tabs (categories and sub categories). They may both be displayed, one of them, or none. It depends on the API's response. For that reason, using a 3rd party library may be hard or even impossible.
EDIT2: Added 3rd approach.
I'm trying to create an app where multiple lists can be switched between using a button. Does anyone have any advice on the best way to do this, preferably using storyboard (my Swift skills leave a lot to be desired)? Right now I only have one list (a TableView) which is contained in a Container View, along with two other regular Views, one at the top and one at the bottom of the Container View, with the TableView in the middle. I want to have a button in the top regular View that switches between multiple TableViews. I want the number of TableViews to be dynamic, starting with one, but then the user can add additional tables as they need. Any advice on how to set this up would be greatly appreciated! Is it even possible to create a prototype TableView? Is that the way to go here? I've found a couple of Answers on Stack Overflow regarding multiple tables on a single screen, but these lists wouldn't be on a single screen, they would only be viewable one at a time: if you want to see the second list, you have to press the "Next List" button (in the View at the top of the Container View), and the first list disappears and is replaced with the second. Thanks everybody!
Don't change table views, change datasources. Use a single table view as you have it, and one array for each mode that the table is in (call those arrayA and arrayB). Another array-type variable -- call it theModel -- should be set to point to A or B.
The datasource methods will answer the count of theModel, and get values for the cells from theModel. When the user presses the button...
self.theModel = (self.theModel== self.arrayA)? self.arrayB : self.arrayA
self.tableView.reloadData()
// everywhere else, use theModel as the datasource
I am writing a Swift app, and on my main screen I have a long scrollview with several regions of content in it (upcoming events, announcements, and then featured products, and finally some basic info). So it's this really long scroll, and you can swipe down to the bottom.
So visualize 4 boxes, if you will, stacked vertically.
The 3rd box shows featured products. This can be anywhere from 1 to 30 items, depending upon any filters the user has in their settings.
My first try was using a UITableView for region#3 inside of this parent scrollview, but the problem is it only shows the first few items/rows and then the rest you scroll inside the table (which is the default/natural behavior of a table, right?). Unfortunately, the requirement I have is that the inner table can't scroll - it needs to display everything at once and you have to scroll (in the main UIScrollView) to get to the bottom (not scroll inside the inner uitableview scroll). Also, everyone seems to say don't use UITableView inside of a scroll.
So how do I create some sort of list where I create one template (like how you would in a xib/tablecell, and then assign a data source to it, and then repeat down without scrolling? Should I use a tableview after all, and just make the height of it very high and turn scrolling off?
Do I somehow instantiate xibs in a for loop and assign them dynamically to some view?
Thanks so much!
Sounds like you want a Table View with Grouped style. That would make it fairly easy to keep your "4 boxes" segregated, and your "3rd box" would simply be 1 to 30 rows in that section.
On note: you don't want to have a "very tall" table view - or any other type of view, for that matter. You want to allow iOS to manage memory for you, and to load and display only those parts of your content that is visible at any one time.
In other words, use a table view like its designed to be used :)
I am trying to achieve the following effect:
A UICollectionView displays a grid of cells for a parent type of object, e. g. a photo album. When I tap one of these items, I would like to scroll that element to the top of the screen and open a Springboard like folder from it. Inside that folders area, another collection should be shown, consisting of the detail items, i. e. the individual photos of that album. Tapping in the remaining "parent" view closes the folder again. See this schema:
What I have done so far is a regular collection view for the albums. When I select one, it scrolls to selected item to the top and then uses JWFolders to open an empty folder at that place. Once that is shown, I trigger the surrounding UINavigationController to push my 2nd view controller with the detail items. That one is layed out so it appears to the user as if it were still the same view.
There are several problems with this approach, and I would like to know how to do this better:
JWFolders takes a screenshot and animated two halves of it up/downwards to achieve the opening effect. This is ok, but pretty slow on an iPad3, because it moves a lot of pixels and the iPad3's GPU is not quite up to the task.
The 2nd view needs to be pixel-perfect to match on top of the first one. This is likely to break accidentally.
I am limited as to what animations are possible for the view controller transition. The default UINavigationController's push from the right is not fitting. I override that to do a cross-dissolve, but still it is far from ideal.
I would like to get pointers as to how to approach this problem in a maintainable manner that does not require to much creative hacking against what the frameworks are designed to do. I might be missing something obvious here, so pointers to examples or general advice are appreciated.
Update:
I changed the approach a bit. Now I use a container view controller that has two embedded collection view controllers. One for the "Album" and one for the "Photos" part at the bottom. Using a UIImageView in the middle between the two I can get the triangle pointing upward done. This is also nice from a maintenance point of view, because it makes maintenance easier with the two collections being handled completely separately.
The app uses Auto Layout, so I can change the amount of space each of the two embedded views takes by modifying the constraints. This is way faster than the screenshot based approach with JWFolders and works nicely on an iPad3 as well.
This almost gets me where I want to be. The one thing that remains is to get the opening animation right. I would like to simultaneously scroll the Albums collection, so that the tapped item goes to the top and expand the photos collection with the triangle pointing at the Album cell.
Can I somehow "connect" the lower view to that cell via layout constraints, so that the scrollToItemAtIndexPath:atScrollPosition:animated: call drags the lower view open?
To get around it I would lose the library and cause iOS to move those display elements around without screenshots or other tricks. On the tap, cause the tapped icon to retain its normal appearance while you dim all the others. Find the contents of the collection view from the top to the end of the line where the tapped icon is. Create two new collection views - one which contains the top half, including your tapped icon and one containing the rest, below. Animate those views apart to make room for the folder view.
The folder view is another UICollectionView that appears in the gap created.
In the main view there are either one or three views presented depending on whether the drawer is open or closed. I would probably look at creating a view controller with a collection view, and using view controller containment to manage all three views. You have complete control over how those views are presented, so you could animate top and bottom views up and down simultaneously to reveal the folder view in place, as Springboard does.
When that's all working then you could generalize and start doing things like deciding to make the tapped icon part of the bottom collection with the folder appearing above if the icon was low on the screen.
(I hesitate to answer this because of the large number of upvotes yet no answers, so I may have missed something - but that is how I would begin trying to achieve the Springboard effect.)
To solve this problem in a relatively easy way, you could try to make the folder a simple UICollectionView subclass and then insert that cell when the albums cell is tapped.
In the collection views data source you would have to return different size etc. for the folder cell.
In the folder you would have to create the folders collection view, avoid making the folder cell the data source of the cell folder collection view tho.