As I understand, Apple does not provide the source code for UIKit. In order to answer another question, though, I am trying to understand how UITextView works (or could be made to work) under the hood.
How would I set up a minimal UITextView myself?
I see from the documentation that it inherits from UIScrollView so I assume that I would start there.
import UIKit
class MyUITextView: UIScrollView {
// ???
}
Again looking at the text view docs, it looks like I would need to at a minimum implement the init method and the text property. (I can ignore all the editing aspects and formatting attributes for now.)
The init method takes the following form:
init(frame frame: CGRect, textContainer textContainer: NSTextContainer?)
So I would also need a property for an NSTextContainer. This TextKit component works together with NSTextStorage and NSLayoutManager so I need to work those in somewhere, too. I could set the NSTextStorage with the text property but I really don't know how NSLayoutManager would interact here.
Has anyone (outside of Apple) done this before? Is this a simple enough question to answer here or would the answer be to long?
Update:
This question shows my latest attempt: How to Initialize NSTextStorage with a String in Swift
This is definitely complicated. I've had to reimplement a subset of UILabel before, and that was tricky. I think the first thing you should think about is what level you're interested in working in. At it's most basic, UITextView is responsible for manipulating a bitmap graphics context and turning a string into pixels on your screen. That in itself is a pretty big challenge, and if you want to reimplement that functionality from scratch you're going to be busy for a while.
At a higher level, UITextView does things like breaking text up into lines, displaying different fonts; higher still and you have things like the UITextInput Protocol, which handles letting the user enter and manipulate the text view's contents.
In terms of implementation details, those obviously aren't available. The closest we can get is a header dump, which is interesting but might not tell us much.
Until iOS7 and TextKit, text rendering was actually handled by WebKit, which means the implementation is potentially more of a mess for having undergone that transition.
Anyway, some things to point you in the right (or at least a) direction:
NSAttributedString Class Reference, especially the UIKit Additions, which let you actually blit text into a graphics context;
Introducing TextKit, some sample code from WWDC13 (there's an accompanying video as well)
Intro to Text Kit from AppCoda.
I apologize that this answer probably isn't as useful as I'd intended. Basically: this is a really big question; it's probably multiple really big questions.
You can use the below sources to understand what happens under the hood. Apple'e implementation need not be the same though.
https://github.com/BigZaphod/Chameleon/blob/master/UIKit/Classes/UITextView.h
https://github.com/BigZaphod/Chameleon/blob/master/UIKit/Classes/UITextView.m
Related
I want to practice creating simple apps using no storyboard. I am able to do the constraints programmatically (slowly) but I want to also practice separating my code into MVC. Is there a particular place/method that I am supposed to write the programatic constraints? Or does it not matter?
Good discussion in the comments. My thoughts, based on that discussion?
With an understanding that the question is subjective, you place your constraints:
The earliest in a view controller's life cycle where they work.
As "close" to the view as possible.
If it's something common, make it as universal as possible.
Understand how your specifics fit into everything.
(Understand, the question isn't limited to constraints. It could apply to hierarchies, UI, even database tables when you get down to it!)
Sticking to constraints, and my answer....
(1) Use the UIViewController and UIView lifecycles.
Generally the view life cycle is loadView, viewDidLoad, viewWillAppear, viewWillLayoutSubviews, viewDidLayoutSubviews, and viewDidAppear. great SO answer detailing this.
I believe that loadView is too early for constraints, but not viewDidLoad - **provided you aren't expecting to know the frame size. While many say viewDidLayoutSubviews is the right place for that, I've found that viewWillLayoutSubviews most times works just as well. Either way, get your constraints set as soon as possible!
(2) Do it as close to the view as possible.
If you have subviews - I have a "ToolBar" class of objects - you want the constraints, at least as much as possible, to be coded inside the class. For instance, in my tool bar, it slides out, has buttons, and even rotates upon orientation. The only constraints not inside these classes is for orientation - that owner is (and I believe should be) the view controller instantiating it.
(3) Make it universal.
I plan to use this tool bar across a few apps. So the first thing I did was add it to a framework. This framework was needed because I had an app that I delivered a photo editing exension - and the "edit" screen is as much the same as possible. In the end I move all my constraints there. (At least as much as possible.) Anything that I believe is reusable.
(4) Understand the specific requirements of your app.
This should be obvious. If you need to code for various orientations, use arrays and activate/deactivate them. (YES, a common mistake is replacing them! That's setting yourself up for some major headaches.)
If you can keep things active, declare the constraint, set `isActive = true1, and forget about it. If you need to adjust that constraint's constant or multiplier, in the declaration name it and then where you need to alter it, do it.
My conclusion? Auto layout is a very useful tool - more so in code. But the placement of code is like asking "how does one code an OOP app for auto rentals" or " how does one design a database for auto rentals". It not just an art, there are many answers. These are the "rules" I try to follow - YMMV.
To get started with this style of development I recommend checking out Let's Build That App as he goes through very in-depth examples of setting up complex apps entirely in code, without storyboards.
The way he structures the constraints is using a custom implementation of UIView, that way your view code is separated from the ViewController. Then, in the viewDidLoad method you can instantiate your implementation of UIView with something like self.view = MyView().
I wrote a few apps like this. The major drawbacks are that it can become very difficult to make quick adjustments, and you really need to learn about all the different types of constraints you can use.
Here's a pastebin of some extensions I used when doing this. I hope this helps.
OK, this may sound very basic (especially for someone who has written tens of thousands of Objective-C code), but I've always tried to avoid all this... or just tweak existing solutions. The result? I've never learnt how to do something simple like that.
So, here's my ultra-simple scenario:
I want to create a custom NSView (let's say a simple view with an image and a text in it), which I'll be able to assign in the Interface Builder (take an NSView element and set its class to MYCustomView - that's all - nothing more complicated)
I know I can write an NSView subclass and have it draw all my elements programmatically in drawRect: and all this - but I most definitely don't find any point in that.
What I do want is to simply draw the view in the Interface Builder (in our example, with a "placeholder" image and textfield), be able to use it as the "basis" of our NSView subclass, and also maintain pointers to the two elements in the view so that I can programmatically access them.
I know it's doable - I'm not asking about that. What I need is an ultra-simple walkthrough. Is there anything you can point me to?
Rephrasing the question in a... one-liner:
How can I replace the programmatic approach (seen in like 99.9% of NSView subclasses) in drawRect:, with a layout taken from a XIB?
P.S.
(A) Trust me, it must have been the 100th time I've been reading about NSViewControllers and all these, but not having used them, probably means that I still haven't found the point in using them...
(B) Please, don't shoot me with "what have you tried" questions. In the course of time, I've tried loads of things and at times I've somehow made it. However, it always feels like a crappy, messed up thing I just managed to get working. Nothing more, nothing less. All I want is to know if there is a simple tutorial on the above simple scenario.
(C) If I get an actual explanatory answer to this one, I guarantee I'll re-post it myself. You simply can't believe how many seasoned Cocoa developers have serious trouble dealing with this...
I've always wanted "custom" Storyboard classes as well!
This may not totally answer your question but this is just how we do it now, in iOS: just use container views.
Full extremely long tutorial: https://stackoverflow.com/a/23403979/294884
Everything's a container view in iOS now.
What we do is just have a scene, and then duplicate it: then change the colors or whatever as you describe.
Here's a literal example from the storyboard that was open behind this browser window!
Notice the small class/scene thing, we just copy it. Notice in the example it is slightly customised, just as you say. They are all the same class (it happens to be caled "BookBist") {"bist" == "bouncy list" btw}
Then as I say container views are the secret because, well, it's for exactly this purpose, it's why apple finally introduced "container views".
(BTW on that long container view tutorial. Search down to What if you want (say) a table controller or a page view controller instead of a UIViewController? it's a critical trick when making container views! Ridiculously Apple gives you a "default" VC when you drag in a container view; of course you never want that; in the example at hand I put the small BookBist scenes connected to the container views wherever they are needed.) Example...
Now, I 10000% understand what you are asking and have always wanted to know the answer myself!
For use HALF the answer, is, as I say, "copy the scene" so that works perfectly in modern storyboard. I appreciate that sucks, because what you want is a prefab, like in any game engine such as Unity3D, right? Me too!
But do note that THE OTHER HALF of your answer is certainly "container view magic" - "everything's" a container view now in iOS, indeed Apple finally put them in to make a rational way to do exactly the sort of thing you describe.
Is there any possible way to detect every change on User Interface during runtime??
I'm trying to find all objects in the current app interface.
I'm trying to to get all nodes inspecting recursively the main Window, but, for example, how to know if the top viewcontroller changes or if it's added a uiview dynamically, or is presented a modalview??
The main objective is to have a library to do this..
Any idea, help?
Thanks!
You could write your own library based on this, using advanced Objective-C techniques. I do not recommend you to do this, since it mostly breaks MVC patterns on iOS. Depends on what do you want to use it for, maybe analytics?
So these are the options I believe, if you want to actively inspect UIView hierarchy. All options are pretty complicated though.
Swizzle methods such as addSubview and removeFromSuperview of UIView, so you could know when changes like that happens. Including the getters of frame and bounds, if you wish to know the position.
You could use KVO to watch properties such as: subviews, frame, bounds, superview to notice any changes. But at one point you would have to add the same object as the observer (could be singleton).
Decide for an interval that is fired by a NSTimer and go through the hierarchy recursively beginning at keyWindow on UIApplication. This would have a big performance impact though.
There may be other options, but these are the ones I believe to be the best choices.
I have a custom UITextInput-based text editor. It works very well, except for multi-stage input via marked text.
My marked region renders correctly, and marked text is inserted, but the candidate list above the keyboard is blank.
For example, here is the Japanese (Kana) keyboard showing suggestions on a standard UITextView:
And here is my custom editor displaying the same marked text:
I have spent several days debugging this issue and have found that the cause is private class UIKeyboardImpl returning NO for the method delegateSupportsCorrectionUI
If I override this method in a category on UIKeyboardImpl and return YES instead, then multistage input suggestions correctly display for my text editor. However this does not address the underlying cause of the problem (and it's not usable).
I have also looked very closely at Apple's SimpleTextInput sample code. This implements a basic Core Text editor. SimpleTextInput correctly displays multistage input suggestions, however I cannot seem to find a single difference in its implementation of UITextInput that causes it to work and mine to break.
(In fact, I am unable to "break" the SimpleTextInput sample's ability to display multi-stage input. Which leads me to think that my focus on the UITextInput implementation is the wrong track. And it is something else altogether.)
Okay, this is a bit embarrassing. I just now noticed:
#property(nonatomic, readonly) UIView *textInputView
Discussion
The view that both draws the text and provides a coordinate system for
all geometric values in this protocol. (This is typically an instance
of the UITextInput-adopting class.) If this property is unimplemented,
the first view in the responder chain is selected.
In the documentation.
I had stupidly #synthesize'd this property and forgot about it, meaning my UITextInput implementation was returning a nil textInputView. Simply leaving it unimplemented chooses the first view from the responder chain as described, which provides the text system with the necessary coordinate system to handle auto-correction and multistage input suggestions.
This was after three days of debugging. Now I feel stupid.
I am just starting out with iOS app development and it's been a great experience so far. Apple documentation is great, but there are some questions I have that are not as technical and only someone with experience might be able to answer.
I have a bunch of UIViewController which handle the "dynamic skinning" of the custom UIViews that they control. This leads to a controller with big chunks of code which seems a bit unpractical to me.
So the question is: Following the MVC pattern, should I give the responsibility of setting a UIFont, UIColor, etc to the view itself? Or should I create "micro" controllers that handle this task using some kind of input?
Thanks for the response.
Creating UIView subclasses that handle the layout works. Override layoutSubviews in the UIView subclass to do the positioning layout (setting frames etc). I find the init method to be a good place to set fonts, colors etc.
Now the UIViewController has relatively little code related to the custom UIView. The viewController just needs to position an instance of the custom UIView and perhaps set a few properties (like a textLabel's text).