The UI for many iOS applications are either wireframed or fully designed prior to implementation.
The process of building a UI within IB is generally visually mimicking placement and design, but isn't there an easier and more accurate way to to this? Can't the design be loaded as a temporary background to aid placement?
Does IB support the ability to load an image as a temporary view background so that UI elements can be placed and scaled using the image as a guideline?
If not, is there a trick to this? Using an UIImageView, perhaps? Devoting a new layer to it? If so, what's the best way to incorporate a tracing image that without creating problems getting rid of it later?
The best way to do this, as you mentioned, is adding a UIImageView to your view controllers’ views with the frame of the view’s bounds. To prevent unintentional focusing/replacing, lock it.
To ensure maximal accuracy, set the size of your VC in Interface Builder to the size of the reference design.
For a third-party solution, you can also try out Flawless, although it only works in the iOS Simulator.
Related
I (hopefully) watched all the relevant WWDC2014 session videos and read the docs, so this question is mostly to confirm my suspicions, but please educate me.
What I want to do is animate views using Auto Layout. That in itself is not a problem. But these animations' endpoints change with different orientations. I thought I might be able to use size classes to move the views automatically on rotation, but Apple's developer guide says that animations have to be done programmatically, and from what I can gather, size classes are an Interface-Builder-only thing.
Another idea I had was using custom layout guides like the top/bottom ones IB provides, but those seem to be hardcoded.
The last thing I could do is update constraints by hand after listening to rotation events, but that is nothing new, and I feel like size classes should be useable for more than just static interfaces. Am I overestimating their purpose?
TLDR: Given two points A and B that a view can have its origin at (due to animations), how can I move both points using size classes or something similar?
After some more digging in the docs I have finally found something useable. The UIContentContainer protocol defines willTransitionToTraitCollection(:withTransitionCoordinator:), and that method's first parameter (a UITraitCollection) contains horizontal and vertical size classes as well as a UIUserInterfaceIdiom (that can be used to know whether the app is running on a iPhone or iPad, although size classes should be used for most things).
Additionally, since iOS 8 hides the status bar in landscape view, traitCollectionDidChange(previousTraitCollection:) is the corresponding method that gets called after the change happened, so the value of UIApplication.sharedApplication().statusBarHidden has changed when this method is called. Can be useful for UIScrollView's contentInset for example.
Lastly, if you need the exact screen sizes (in points, of course, but the above mentioned trait collection also knows about pixel density), there is viewWillTransitionToSize(:withTransitionCoordinator:).
Hope this helps someone else as well.
I am new to iOS programming and I have been building the UI for an app entirely programmatically. (I deleted the storyboard file + removed a property from the plist file and have been purely doing it through the code.) I want to understand for certain, in iOS7, is autolayout still occurring automatically? Or is this not the case?
Secondly, how can I manage it entirely programmatically? AKA, I have a nice interface for portrait mode. However when I go to landscape, it is obvious the UI is not adjusting properly. This makes me think autolayout is not on or it is not using proper constraints.
Is it suggested that I actually use interface builder instead?
Thanks.
I want to understand for certain, in iOS7, is autolayout still occurring automatically? Or is this not the case?
There are two ways to use auto layout: you can set it inside your storyboard, or you can define it programmatically. If you do not do either, auto layout is not applied.
how can I manage it entirely programmatically?
As the comments above suggest, have a look a Apple Docs as a start. There are also a couple of frameworks on github to make things easier, e.g., Masonry, but you will need anyway some understanding of how auto layout works.
Is it suggested that I actually use interface builder instead?
This could be a highly opinionated issue. It depends entirely on whether you prefer using Interface Builder or not. IB makes possible setting the constraints visually, but it is still not a trivial task, especially if your UI is a complex one. If you do it programmatically, you will have more code (and ugly code, at that). IB will also not fix "conflicts" between constraints, but it will make easier testing your constraints. But if you prefer defining things visually, vs. programmatically, IB is a good choice.
I'm working on an iPad-App with ARC which have to display thousands of UIImageViews in a UIScrollView...
When I load them all at once (or more accurately in a queue with GCD), I run out of memory after a while of loading..
Now, I thought i have to use lazy-loading and load only those UIImages which are necessary and a kind of release those which are no longer visible, but I don't know if this is possible with ARC..
Anybody have an idea to do this, or a better idea to handle this case..?
Thanks, tonistair
Make something that implements UIScrollViewDelegate, and in its viewDidScroll method, calculate the currently visible rect from contentOffset and bounds. Then remove things that are no longer visible, and add things that have just become visible (or some other appropriate algorithm). ARC has nothing to do with this.
We have an out-of-memory crash on the iPad 3 which we traced to the following scenario:
A UIView which uses a CATiledLayer and draws content (say, a PDF) has subviews with their own drawRect methods (which, for example, highlight search results). This makes Core Animation consume tons of memory (100+ MBs in the VM Tracker instrument), and can easily lead to a crash. While this issue exists on all devices, only on the iPad's Retina display does the cache size grow too large.
This can be reproduced with Apple's PhotoScroller example: subclass UIView, uncomment drawRect, and add an instance to the TilingView. The app will crash on iPad 3. Commenting drawRect resolves the memory usage.
Now, we can drop the subviews and do the drawing in the top-most UIView. However, working with subviews is convenient (since we're representing different, independent layers on top of the PDF). Two questions:
What is a good work-around? Preferably one that allows us to continue working with multiple views.
Why is this happening, exactly? I guess the cache mechanism is working overtime, but it would be great to understand the technical details behind it.
Thanks!
EDIT:
I want to elaborate on Kai's answer. The problem was indeed unrelated to CATiledLayer, but to the usage of UIViews that implemented drawRect.
In the case of PhotoScroller, I created a UIView which was of a size of the image - 2000x2000 and more, which creates a huge backing store if drawRect is present.
In the case of our app, the overlay views are full-screen (=~11 MBs on iPad 3) and we have about 5 of them per page. We keep up to three pages in memory while scrolling, and that means more than 150 MBs extra memory. Not fun.
So the solution is to optimize drawRect away, or use less such views. Back to the drawing board it is :-)
To 2.: Whenever you implement drawRect in a UIView subclass and have lots of instances of that class, your memory usage will grow dramatically. Reason is that a lot of optimization tricks in UIKit view/subview handling (e.g. when zooming or scrolling) don't work with such objects, because the framework doesn't know what you're doing/what you are drawing.
So - independent of retina or not - avoid implementing drawRect, especially when having many objects or many layers of subviews.
To 1.: I didn't exactly get what you are trying, but I implemented an PDF-Viewer which is also able to show additional content on top of the PDF. I did it all with normal UIView hierarchies, images etc. and I fear that's the only reliable work around you'll get
My experience:
Never add subviews to a UIView that's backed by a CATiledLayer
Never add sublayers to a CATiledLayer
Unfortunately, that seems to be the only practical answer - Apple's implementation goes horribly wrong in many different ways (not just performance - the rendering itself starts to exhibit visual artifact bugs, some of Apple's rendering code goes weird, etc).
In practice, I always do this:
UIView : view
+-- UIView w/ CATiledLayer : tiledLayerView
+-- UIview : subViewsView
...and safely add views and subviews to "subViewsView". Works fine.
OK so in my game I need the users to scroll between items, just like you scroll a web page in Safari. Is there any way to do that? If not, maybe scrolling them to the side, like you do in the spriboard? Thanks.
I am not really sure I have understood what you would like to do, but there is a cocos2d extension that seems appropriate to it: CCScrollLayer.
CCLayer subclass that lets you pass-in an array of layers and it will then create a smooth scroller. Complete with the “snapping” effect.
If you are looking for a generic scrolling within your view, I suggest this tutorial or this topic rom cocos2d list.
EDIT:
I have never done it, but I think it should be possible to scale the CCScrollLayer to the size you need.
Otherwise, you might change the contentSize of the layer, or even put the CCScrollLayer into a clipping node.
Anyway, I think that it is much easier to start from this and find a way to adapt it to your specific requirements than start from scratch.