I'm adding a bunch of stackviews(horizontal) to the vertical stack view programmatically inside a VIEWDIDLOAD method.Im adding this in almost 10 screens but while navigating to the respective screens it is taking almost 30 seconds to load and at some point while navigating it is taking too much and crashing the app.
Here is my view hierarchy for adding the views.
Vertical stackviews-->horizontal stackviews (view1+view2+view3+------depends will up to 7views)
In the above hierarchy I'm adiiding multiple views to the horizontal stack view and finally adding to the vertical stack view where it can iterate through 100 or 1500....
Please help me out of this problem to increase the app loading time and app crash issue....
I have to agree with both Leo and Losiowaty -- UIStackView is meant for elementary layouts -- collection view is a much better option if you want performance.
Edit:
What you're trying to do is difficult no matter which technique you
use. Since you already have it working with auto layout alone, you
probably understand it much better than you did when you set out.
(and better than you will a week from now if you stop here)
It will be worth your time to
implement this with a collection view, since you'll have this issue
again as you evolve your app. You'll find it can do what you need.
Just tackle it in steps. There just isn't any "easy" solution if
your data isn't easy. 💩 Get started and ask questions when you get
stuck. Include the code that illustrates how you're stuck. People here
will be glad to help if you show your efforts. I know I will.
Related
Today I heard about new approach of design views in storyboard
Lets consider one page contain image , label and button now out storyboard as follow
1] our one UIViewController divides in three part i.e 3 UIViews for 3 components like one UIView for image
2] for keep image responsive take another UIView and keep imageView inside that and then set constraints and keep wight and height of imageView aspect ratio.
3] I given different colour for different UIViews for understanding
final hierarchy is as below
So as per screenshot you can see view are more responsive and changes made in one UIView is not reflect is another one and our hierarchy of view are maintained .
Finally come to the questions
1] is this approach correct?
2] is there any impact of this much UIView views on application in terms of memory and performance?
Answer on first question:
The approach how to handling lot of views? No it is not correct. If you had lot of views in scrollView use UITableView or UICollectionView, because of better handling, reusing and layouting - features provided by UIKit for free. If you have lot of views on one screen without scrolling - try to use UIStackView - it will provide you lot of automatic layouting and very easy editing and updating layouts instead of using autolayout / layout masks. UIStackView can be considered as AutoLayout generator machine.
Answer on second question:
No. Using large storyboards has no much bigger impact on memory and performance, than generating it via code.
There is two main problems with storyboards:
1) Large storyboard has performance impact on XCode. Especially with older Macs.
2) If two or more people working in one storyboard simultaneously, you need to be aware, not to edit same ViewController together, or creating new, otherwise you will have repository conflicts (same as 2 persons edit same piece of code at same time), but you have to resolve it in xml, what is readable, but it takes some time to understand.
I tried this method a lot and I realise this approach solve lot of problems of setting constraints. This approach is similar as Bootstrsp . We are going to divide hole screen by UIViews and Finally put our main design views in it. Till now I don't know what is bad impact of this approach in application in terms of memory and speed. That I will explain in future.
Thanks a lot.
I am making modifications to an existing iPad application, and I'm having a hard time dealing with really messy scenes in storyboards. Almost every scene in the app consists of multiple views laid one on top of the other, each containing a different set of controls. Depending on the situation or data coming into the scene, some views are hidden, and others are shown.
It takes a LOT of time to decipher such scenes, and even when I figure out what changes I need to make it's terribly difficult to make those changes, and easy to screw up other things.
As an example, the following scene has 3 views that could appear (Start View, End View, Drawer History), depending on the situation, and they are all laid out on top of each other...
This seems like a terrible way to handle this, and I'm having a hard time believing this is standard practice, but I'm not finding much in the way of alternatives. I find very little in the way of questions where people are dealing with this problem, and the tutorials on how to design user interfaces seem to be too simplistic and never deal with scenes that are complex enough to run into this problem.
Unfortunately, this app is my primary introduction to doing user interfaces in iOS, so it has apparently become the default solution in my head. I've tried many tutorials, but they take a long time and don't seem to ever get to a situation that needs such a technique to solve it.
I would hope there would be a solution where each alternate view in the scene could be laid out on its own, and be made to appear within a placeholder view as needed.
What would be a more enlightened / more manageable approach?
That's what you'll get with Storyboards/Nibs/Xibs. I'm not saying coding your UI is better than using interface builder, but it is, at least for me. I believe, as far as I know, there's no other way to handle such multiple layers of views in one view controller in interface builder. I actually used to use interface builder before and that's how I add multiple layers of controls too. Sometimes some views are initially made hidden, but that would probably confused me or the other developer looking at the layout. Sometimes I extend the viewcontroller height to know that there's a view container with a constraint a thousand constant or a negative thousand constant to make it hidden and ready to animate when it's needed to be shown.
There are ways to somehow improve and organize your Storyboards. You can separate modules into different storyboard files; you can use references; avoid segues; and whatnot. It's still an individual or team's preferences.
Some ref:
https://cocoacasts.com/organizing-storyboards-with-storyboard-references
https://medium.com/#stasost/xcode-a-better-way-to-deal-with-storyboards-8b6a8b504c06
EDIT:
I'm thinking you could also layout separate view containers into a separate xibs, and then call them or layout them when needed. But that would add more files to your project.
I'm creating an app that will have a quick onboarding at the beginning with some pretty simple scroll through animations and finish with a button to basically "GO" into the app's content.
I'm looking for suggestions as for how to most effectively and efficiently develop this, here's some things that it needs:
there should be paging so that it locks onto about 4 different positions throughout the onboarding.
the animations progress should be dependent on the scroll view's position (I'm guessing the x value of the content offset)
there needs to be views that stay on screen through multiple pages and some that move on screen and off screen throughout the onboard, it can not just be one picture moving on then off
there needs to be a button that pops up on the last page
I have a good understanding of Scroll Views, Page Views, and Page Controls. I also just bought Core Animator (the app) if anyone can suggest how implement that.
The way that I'm thinking of doing it is basically creating a Scroll View with paging that is empty and just use it to control animations with its content offset. Is there a faster way to do this or maybe a open source library that would work better? I'm only proficient in Swift currently :?
Thanks for any suggestions! This my first app and I'm very excited to hear your suggestions
I would look at UIPageViewController as its setup to do the scrolling by page for you, although you have control over what kind of animation it uses. You are responsible for feeding it view controllers to display using this method:
setViewControllers(_:direction:animated:completion:)
here is the link to the apple documentation UIPageViewController docs
I created a scrolling credits screen for one of my company's apps, FaceDancer, that would be a decent starting point for what you are after. The app is free. You can download it to check it out at this link: FaceDancer. The credits screen is off the info button on the main screen.
It's not hard to use UIView animations to simply animate a series of views. I think that might be easier than working with a scroll view.
I can give you some guidance if you think it would be helpful.
My question is essentially what it says in the title--I would like to create a scrolling view similar to the one that appears under the 'Home' tab of the HBO GO iPad application.
I have looked into circular/infinite UIScrollViews, but they only discuss infinite content in one direction (either horizontal OR vertical) and bring up many problems when scroll speed gets too high. So my question is twofold:
A) Could they have created this scrolling view by subclassing UIScrollView? If so, please do let me know how?
B) If not, does anyone have ideas as to a starting point for how they could have created it? It runs very, very smoothly even at fast acceleration, and I'm trying to figure out how they created this.
Thanks in advance!
Reposting to get answer ;-)
The sample is named StreetScroller.
Referenced video is here.
I believe the successful technique will be to apply the techniques in the video in either a 2x2 or 3x3 grid and handle scrolling in both directions.
I have put together a library that provides an infinitely scrolling view in all directions. It allows you to very easily achieve the effect you’re looking for and much more. As the user scrolls around, the framework lays out the tiles and lets the delegate know so it can set up the tiles' presentations. This is indeed done by subclassing UIScrollView and as for performance, the framework introduces no lag: full 60 fps no matter how fast you scroll.
The framework with a sample app that displays Flickr images in an infinitely scrolling wall is here: https://github.com/vovagalchenko/scroll-for-days. Additionally, here's a video of the sample app in action: https://cloud.box.com/s/d6bgvlot175au5a3jeh5
I don't think there is an easy way to do it by sub classing UIScrollView
I have done something similar with a UIView and a custom gesture recognizer, moving views around nice they disappear off the side of the screen.
I hope this helps you.
I'm making a role-playing game, and I want to have a Map View and a Battle Screen. With the possibility of other screens as well.
I thought the best way to achieve this was to use multiple NIB files.
When I prototyped this by have one view that creates content, switching to the next view, and then back, the content on the original view was reset.
How do I make it so that the first view doesn't reset the data each time it's loaded?
Your question is a little vague. A view usually does not get "reset" unless you run into a low memory warning. That said, even then it's just up to you to keep the right references and setup your view correctly. Maybe have a read through Apple documentation or provide some code. Adrian also has a good write-up about this.