I have a huge app in process, and since updating to Xcode 7.3, doing anything in storyboard is like molasses!!
About a month ago, I had about the same speed using one HUGE storyboard, so I split the project up into 5 separate storyboards, and Hallelujah, a hundred times faster!
But now, after updating, even dividing to 7; slow as can be!
I'm about to back up, then try and recreate one big one, then back up again, then divide again - to see if that does anything; but I am doubtful.
Anyone know how to fix this, or what is wrong with the latest update?
Well, not a great solution but, all I can determine is that; if the number of items and constraints in the view gets over a certain amount (using Xcode 7.3), the speed suddenly drops horribly.
So what I ended up having to do with this last storyboard (8 of 8) is to take a slide out side pane full of buttons and subviews, and place it in a container view - so that I could give it its own VC and thereby make it a stand alone 9th storyboard.
Not a great solution that's for sure, especially since I had to tie all of the buttons and methods to the parent view controller. I was lucky in this event in that the parent view (my main app map) is a single instance occurrence so I was able to reference it at launch, and merely prefix my former methods with the reference. If this was not so, I guess I would have to have done some serious protocol / delegation.
So, a proper solution (or 'fix' if it is Xcode's doing) is still wanting :)
Related
I am currently updating my app, and I have been facing a very strange and complex problem for the last few days. The part of the application that is problematic is made of one UITableViewController that is a list of news, and (after you click on a news) a detail view which is in fact a UICollectionView with as many details CollectionViewCells as there are news.
Each of these can have an infinite amount of elements, and are loaded 20 by 20 when the user scrolls to the bottom of the TableView (or to cell that is at the furthest position right on the CollectionView). Also, inside a DetailsCollectionViewCell, there can be another UICollectionView, containing images.
My problem is that after scrolling a few details views, after behaving normally (ie memory is allocated when I change the page, then stabilize until I change the page again, and so on), the memory allocation start to ramp up slowly but steadily, even if I stop doing anything at all. Also, the CPU usage will go to 100-120% and stay there, whatever I do, even, again, if I don't touch anything. After a while, the UICollectionView and the UITableView will not render any animation anymore, thus loosing the paging, and the inertia when scrolling, and overall resulting in a very poor user experience.
The strange thing is, I can observe these behaviours via XCode 5's Debug Navigator, but when I try to use instrument to find the source of the leaks/allocations, the allocation graph is normal, and I get 40-60 MB mem usage, no more, despite still observing the animations/paging problems.
Has anyone already met such a strange behaviour, and can someone help me in finding the cause of all this fuss ? (maybe by fixing Instruments ?)
Thank you all in advance, don't hesitate to ask me for more infos if needed !
I found the solution to my problems in the meantime.
About the difference in Memory usage between Xcode 5's Debug Navigator and Instruments, it was caused by my use of NSZombies. I have the habit of always setting them on, and that just flew off my mind... To remove them : Product > Scheme > Edit Scheme > Diagnostics > Enable Zombie Objects (just unmark it).
The cause of my CPU usage was an animation that was going on indefinitely in the background on multiple pages. The solution was to first of all stop it as soon as it is not seen/useful anymore, the optimise it by changing my approach (I was using CAAnimation and moved on to using UIView's animate function).
I think I might have pulled the trigger a bit too fast here, but hey... if this can help someone later, then it will not be a waste !
I've inherited a project that uses ~100 Xcode storyboard scenes. Trying to add to this project has been a nightmare for the following reasons:
My machine (late 2011 Macbook Pro 13inch with non-SSD drive 16GB running 10.8 + XCode 4.4) crawls to a halt on storyboards. In some cases I'll move a scene and it will take 10 seconds to update its position.
When I modify a scene (create a segue between two scenes, etc) in some cases all the scenes disappear. I have to do a "select all" on the sidebar to get them back.
Navigating a specific storyboard scene is absolutely frustrating. There's no apparent way to sort the storyboard scenes by name.
The filter feature below the scenes sidebar kind of lets me find the scene I'm looking for, but has the frustrating side effect of filtering out the attributes (segues, views, etc) of the specific scene I'm looking for. So if I need to modify the "add_new_guy" segue for "Person View Controller", and I type "Person" in the filter, I get the Person View Controller sans the add_new_guy segue. If I delete the text in the filter to make the segue appear, I'm taken back to the top of the scene list and (most likely) away from the Person View Controller at the other end of it. I end up scrolling all the way down the scene list manually looking for the specific scene I want to change.
I've spent hours googling solutions and nothing useful has appeared. Any suggestions on how to improve the storyboards situation or pointers to things in XCode I've stupidly overlooked?
Disclaimers:
a) I am well aware that moving to nibs would solve the problem and 100 storyboard scenes is nuts, but I've inherited the code and I'm expected to do storyboards for at least the next year.
b) I'm aware that it's possible to split out the project into several storyboards. I might look into this if I have time.
c) I've heard that some problems may be caused by having two storyboards open at once, which I've tried to avoid as much as possible.
d) Filing a bug with Apple's regarding storyboards is already on my to-do list.
First, work on splitting your storyboard up into smaller storyboards. I would recommend a maximum of 4-5 view controllers per storyboard. It will be a giant headache at first, just work on it over time. Take a look at RBStoryboardLink, which allows you to connect them "by allowing 'pseudo-segues' between UIStoryboards. These segues can be built without leaving Interface Builder and without writing any extra code". This will give you:
The ability to make abstract super classes in storyboards for very similar view controllers
Smaller, more manageable files that don't bring your computer to a halt
Fewer merge conflicts when working as part of a team (assuming your project is under version control)
Second, tell your boss to immediately purchase you a new, way better development computer. They'll make back the $3-$4k in more efficient development time in a matter of days. (Or, if this is contract work… buy a new one yourself.)
And, please indulge my slightly off-topic comment.
Regarding this statement:
I'm expected to do storyboards for at least the next year
Work expectations are always negotiable. Your boss likely thinks "switching from storyboards to code will cost more time than it will save." If this isn't true, say so.
I am working with flex for the last two years on some desktop apps. Until now I never had any performance related issues but today as we completed a mobile application for the iPad, I'm facing a challenge, the application is incredibly slow on the iPad.
http://i.stack.imgur.com/qkbWn.png
Slow, means that when I press a button in the menu to change the splitview I must wait something like 5s. Then scrolling is really slow two, with less than one fps and my TextInput starts to bug (the text is not in his box anymore).
I started to read a lot of blog post and presentation about optimisation for the mobile platform and then I rewrite some of the components I use. I removed the SkinnableContainer for instance and replaced it by a VGroup including some actionScript based drawing.
Now what you see is a VGroup (the dark grey one) containing some others VGroup (the group with title here) and then each widget is an HGroup with a label and a Widget. I only use Label and TextInput for the text.
Creation time is slow even (several seconds to create the view) for another page where there is only 4 text widget on it, or another one with only a list with a custom item renderer where each row is a set of 4 labels.
The whole things is cabled with RobotLegs, with nothing fancy, one models is injected in the view and at the beginning I set a member variable on the view with this object to bind my variables.
Frankly my thinking right now is : it smells fishy because if I've done everything right it is impossible to have such low performance and thinks that flex is competitive on the mobile platform. So right now I'm trying to disable the application piece by piece to try to locate what could slow it like that. I've got a couple suspects to check, for instance I've got some binding warning to check, and then see if robotlegs has got its share of the problem.
So my main question here is what do you think, and could you have some ideas about "is there a problem" and "how do we solve it".
Thanks
Run profiler for startup and separatelly for each operation that takes longed that it needs. Then prioritize the problems and try to solve them with basic optimization techniques.
Some problems you will not be able to solve fast - e.g. time for creating big components. The only option there is to rewrite those components with AS3 without MXML, styles and anything. I'm sure that flash.text.TextField is created many times faster than mx.controls.Label. The same for other components.
When component is created, it can be reused at a very low price. In your app there must be a lot of places where you recreate while you can reuse old components. It will save you memory and time.
Layouts tend to redraw even when it's not needed. If you have a lot of nested layouts, find the most critical places and replace a series of layouts with one custom layout or even component.
This all is very developer time consuming. At the end you will not get a smooth app anyway, but I believe that it can become usable.
I'm new to developing on the Mac and am looking to implement an interface similar to Spotlight's - the main part which seems to be an expanding table/grid view.
I was wondering if there is a component Apple provides for creating something like this or is available open source else where.
Of course if not I'll just try and work something out myself but it's always worth checking!
Thanks for your help in advance.
New Answer (December, 2015)
These days I'd go with a vertical stack view ( NSStackView ).
You can use its hiding priorities to guarantee the number of results you show will fit (it'll hide those it can't). Note, it doesn't reuse views like a table view reuses cell views, so it's only appropriate for a limited number of "results" in your case, especially since it doesn't make sense to add a bunch of subviews that'll never appear. I'd go so far as to say outright you shouldn't use it for lists of things you intend to scroll (in this case, go with a table view).
The priority setting can be used to make sure your assumption of what should be "enough" results doesn't cause ugly layout issues by letting the stack view "sacrifice" the last few.
You can even emulate Spotlight's "Spotlight Preferences" entry (or a "show all" option) by adding it last and setting its priority to required (1000) so it always stays put even if result entries above it are hidden due to lack of space.
Lately all my UI designs for 10.11 (and beyond) have been making heavy use of them. I keep finding new ways to simplify my layouts with them. Given how lightweight they are, they should be your go-to solution first unless you need something more complex (Apple engineers stated in WWDC videos they're intended to be used in this way).
Old 2011 Answer
This is private Apple API. I don't know of any open-source initiatives that mimic it off-hand.
Were I trying to do it, I might use an NSTableView with no enclosing scroll view, no headers, two columns, right-justified lighter-colored text in the left column, the easily-googled image/text cell in the right column, with vertical grid lines turned on. The container view would observe the table view for frame changes and resize/reposition accordingly.
Adding: It might be a good idea also to see if the right/left justified text (or even the position of the columns) is different in languages with different sweep paths. Example: Arabic and Hebrew are read right-to-left. Better to adapt than to say "who cares" (he says flippantly while knowing full well his own apps have problems with this sort of thing :-)). You can test this by making sure such languages are installed on your computer, then switching between them and testing out Spotlight. Changing languages shouldn't pose an issue since the language switching UI doesn't rely on reading a foreign language. :-)
I'm new to Objective-C, Cocoa, Xcode and Interface Builder. I've got some C background in the past, as well as a fair amount of RealBASIC experience.
I'm working through Mark and LaMarche's iPhone 3 Dev book and I'm really just sort of stunned about how tedious some things are. Maybe someone can shed some light on this for me. My question really is, why does the process for seemingly simple actions involve such a complicated number of steps? Is there a benefit to the complexity which I'll come to love later? Or is it just a brute fact that is unavoidable?
For example, in RealBASIC, if I want a slider's value displayed in a text box, I simply add:
myTextBox.text = mySlider.value
to the slider's Changed event. I can program this in well under 1 minute.
In Xcode/Interface Builder, I have to physically type a declaration for both the text box and the slider, then type a property/outlet declaration for each as well, then create a method declaration and implementation for the ValueChanged even, then set up a (relatively) complicated typecast of the slider's integer value into an NSString using initWithFormat. I then have to return to Interface Builder to link up the controls with the control and method outlets I typed in. I don't see how this can be done in much less than 10 minutes. Maybe 5.
So, what's the benefit of this? Why doesn't Interface Builder automatically create, or at least suggest, control declarations and #property statements, as well as method declarations and implementations? Why can't double-clicking a slider in IB offer you a list of events and offer to automatically insert a skeleton method into your .h and .m file? And why does IB even have to be a separate application?
I'm willing to accept that some of this is my unfamiliarity with all things Xcode, but is this really as efficient as the development environment can be?
My apologies if this is a dead-horse, flame-bait topic with opposing sides on full aggro. If so, please just say "yes, that it is" and move on.
Thanks,
-Rob
A lot of the reasons behind the way IB works will become more clear as you get used to the MVC paradigm.
Once you start using Cocoa Bindings, which update your model when the UI changes and vice versa, you should see an enormous productivity improvement.
I too used to think that Xcode and Interface Builder were unnecessarily complicated, until I worked through a book on both (specifically, Beginning iPhone Development: Exploring the iPhone SDK).
If you're serious about working with Xcode and Interface Builder and are as confused as I was when I started, I highly recommend picking up a book like the one I used. Granted, that was for iPhone development, but I think there is another book by the same publisher (or author) that is straight Mac programming.
Once you work through it and understand what is going on behind the scenes it starts to make a lot more sense. In some ways I prefer IB to things like Expression Blend or XAML for WPF programming in .NET.
Give a book a try and see if it helps :-)
Good luck!