I'm trying to make a custom alert view that checks to see if a condition is true, and if so it builds itself and attaches itself to the window. However, if this condition is not true, I just want the view to deallocate itself, preferably in the init method. What is the best way to accomplish this?
Well it is better to follow SOLID principles in coding.
Singularity is an important thing.One function is supposed to do a single thing not many dependencies.
So Keep the view just to show the custom alert.And the check for showing must be done outside such that
//Please note this is the algorithm not the exact code in Obj-C.
if(condition==True)
{
//Display customView
}
else
{
//Do nothing
}
Related
trying a few things out in Swift. I’m trying to get some things that seem muddled to me straightened out - mostly to do with how I deal with variables and referencing them in a project.
What I am trying to do is keep a variable (based on a struct) defined in ViewController accessed and updated from various other functions within an application.
So, a brief outline of the code I have is here. I actually wrote a smaller app to test my ideas out before applying them to something more complex.
I started in XCode with a Swift document based application for Mac OSX.
In ViewController.swift I have:
import Cocoa
class ViewController: NSViewController {
var myText = "Hello, some text"
#IBOutlet weak var textView1: NSTextField!
#IBAction func Button1(_ sender: Any) {
myText = "This is button 1 clicked"
myText = setText( thisText: &myText )
textView1.stringValue = myText
}
#IBAction func Button2(_ sender: Any) {
print("Button 2")
myText = "This is button 2 clicked"
textView1.stringValue = myText
}
override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view.
textView1.stringValue = myText
}
override func viewDidAppear() {
let document = self.view.window?.windowController?.document as! Document
}
override var representedObject: Any? {
didSet {
// Update the view, if already loaded.
}
}
}
In SetText.swift, I have this:
import Foundation
func setText( thisText: inout String) -> String {
thisText = "Function"
return thisText
}
I liked the idea of sending variables to the Set Text function and then returning it, but thinking about it more makes me think that actually this could end up like a proverbial bowl of spaghetti with functions calling functions and who know what else. So I was thinking that something like this would probably make more sense:
import Foundation
func setText( thisText: inout String) {
let vc = ViewController()
// Read the variable from View Controller
var myTextHere = vc.myText
myTextHere = myTextHere + " More text"
// Set the variable in ViewController here
vc.myText = myTextHere
}
From my reading around on this subject, if I call ViewController(), it will create anew instance of the view (is that right, or am I misreading?). That’s already happened, so what I need is to reference the ViewController that called the function setText, or rather that owns that particular instance of code. As I’m thinking about a document based application, I’d obviously want to keep all instances of myText with each document’s ViewController.
My aim is to create something a bit more complex, using a variable based on a Struct to keep everything together. So:
myCard.image // holds a bitmap image
myCard.size // holds the size of the image
And so on. being able to access it in the form of ViewController().myCard to both read and write to is what I am thinking I need to do.
What I don’t want to do is use global variables.
Thanks.
I'm having a hard time seeing much correlation between the title of your question and the body of your question. In fact, I'm not even entirely sure that there's a question being asked. That said, I'll try to address the questions you appear to be asking (re-written how I think they're intended):
When you initialize a new view controller, does it create a new view?
Yes. There is a view property for every view controller, and it's not a shared component or a singleton or anything else like that. There is one main view for every view controller. It's almost certainly composed of dozens of other subviews, but there is one view that is the view for every view controller.
Is there a way to get metadata about the state of a view controller from outside, preferably in the form of a struct?
Absolutely. First, you'd need to define that Card struct. I'd recommend doing it in the same file as the view controller itself. You can define it outside of the view controller, or if you want stricter coupling and namespacing, you can do it inside the view controller. Just be aware that doing that latter would mean that the type name, when referenced outside the view controller, would be ViewController.Card rather than just Card.
Then you'd want to create either a computed property (var card: Card) or a method (func card() -> Card) on your view controller which builds and returns one of those based on the state. It sounds like you're already leaning toward the property approach.
Note: I would absolutely advise against having one that is a normal get/set property because then you'd have to constantly update it and modify it. The best thing to do is have a computed property which builds it on the fly. So when the property is called, it reaches into all your components to get the info you want (like image sizes, strings, etc) and then packages up and hands off the Card metadata struct. Doing it on-demand like this eliminates unnecessary complexity and consolidates the metadata logic into one place.
Some dangerous things in your code example:
I can't think of a good reason to implement viewDidAppear() but not call super.viewDidAppear(). Unless you have an enormously compelling reason to leave that out (I honestly can't think of a single one), do not do so.
I don't see any good reason for your first implementation of your setText(thisText:) method. The way you use it in your Button1(_ sender: Any) IBAction functionally does absolutely nothing. That method in general is screwy for several reasons: it's got an upper-case method name, sets the textView text by trying to assign to stringValue for some super strange reason, and does in three lines what could be done in one:
textView1.text = "This is button 1 clicked"
The second implementation of setText(thisText:) makes even less sense than the previous. The two biggest problems being 1) that you don't even use the thisText argument passed in, and 2) your method, which is called 'set text' is creating a whole new view controller every single time it gets called? That's a huge violation of "doing what it says on the tin." Methods should have a single responsibility and shouldn't do anything beyond that responsibility. I'd never in a million years look at a method called setText and think "I'll bet this initializes a view controller." Never.
I see this question has already been downvoted a bit (not by me), and I'd like to take a moment to coach you in using Stack Overflow: Ask clear, concise, specific questions about clear, concise, specific topics. As I said at the top of my answer, there doesn't appear to be a question anywhere in your post. I had to kind of make some up that I inferred from what you wrote.
Remember: coding isn't just wiggling your fingers while you think about an app. If you're doing the hard work of good engineering, you'll likely spend a ratio of about 10:1 (or more!) of staring at your screen to actually typing any code. Every time you write a line of code, you should be asking yourself, "Why am I writing this line of code? Is this necessary? Am I reinventing the wheel?)
Good luck!
I'm using Snapkit to simplify my autolayout code, however one scenario seems to popup very regularly, which i'm wondering if there's a way which involves less code.
So let's say that I need to pin the edges of a UIView to it's superview margins, we might do something like this:
subView.snp.makeConstraints { make in
make.top.equalTo(parentView.snp.topMargin)
make.bottom.equalTo(parentView.snp.bottomMargin)
make.left.equalTo(parentView.snp.leftMargin)
make.right.equalTo(parentView.snp.rightMargin)
}
This essentially results in the subview filling the parent view, except for a small amount of padding as defined by the parent views layout margins.I'm sure some variation of this is pretty common.
This seems overly verbose for this library. It has some really nice helper methods such as these
make.edges.equalToSuperview()
make.top.left.right.equalToSuperview()
What I haven't managed to find in their documentation however is how to do the two above helper methods, in relation to the margins.
What i'm looking for (if it exists) is something akin to:
make.edges.equalToSuperview().withMargins()
make.top.left.right.equalToSuperview().withMargins()
make.top.left.right.equalTo(someview).withMargins()
So, is there a way of doing this other than the very verbose way? Am I missing something in the documentation or maybe this could be added by extension?
did you try something like this?
subView.snp.makeConstraints { make in
make.edges.equalTo(view.snp.margins)
}
Edit after comment:
When you only want to constrain certain edges to the superview margin, you can do something like this.
subView.snp.makeConstraints { make in
make.top.leading.equalTo(view).inset(view.layoutMargins)
}
or
subView.snp.makeConstraints { make in
make.top.leading.equalTo(view.layoutMarginsGuide)
or
subView.snp.makeConstraints { make in
make.top.leading.equalTo(view.safeAreaLayoutGuide)
One nice way to do this is to use UIView.layoutMarginsGuide:
childView.snp.makeConstraints { make in
make.top.leading.bottom.equalTo(parentView.layoutMarginsGuide)
make.trailing.equalTo(otherView.snp.leading).offset(-8.0)
}
I was debugging a problem with a custom scrolling view using a subclass of JViewport. I was printing some information from the layoutContainer() method in my custom LayoutManager, and saw that it was being called continuously, without any resizing to trigger it. I looked at the source and it appeared as though JViewport.setViewPosition() revalidates on each call. I thought that can't be. So I went back to another project using a standard JScrollPane, and added this code:
myScrollPane.setLayout(new ScrollPaneLayout() {
#Override
public void layoutContainer(Container parent) {
System.out.println("Layout ScrollPane");
super.layoutContainer(parent);
}
});
which proved that the standard version suffers from this same problem. Is there a robust and accepted way around this? I'm using several instances of my JViewport subclass to display a waveform and other things scrolling in real time using JViewport.setViewPosition() and laying out the container (exactly the same each time) every 10 milliseconds is a big inefficiency. I can subclass JViewport and override this, but understanding why it was deemed necessary to revalidate simply for a change in the view position would help me to avoid making an new problem. Currently I'm puzzled as to why this is necessary.
So the corollary question is "why is JViewport.setViewPosition()" causing a revalidation?".
Simple question.
I have a tableViewController that will display a list of search results.
I want to create a block based callback (I think that's what you would call it)
I would present the viewController
[searchResultController showSearchResults //BlockCode here {
//did select this item...
}];
but use a block so that I can detect the selection made from the tableview instead of using a delegate method.
Problem is I have no idea how to implement this. Is there a good tutorial or a simple example on how to do this?
Your search results controller needs to have a block property. This block should be defined with no return type, and should take a parameter of whatever object you are going to use to represent the selected item.
Before presenting your search results controller, set the block property to whatever you wish to do for your callback.
Within the search results controller, when a row is selected, execute the block, passing in the selected object. Either this method, or the block itself, should also dismiss your controller.
I Have the following code:
-(void) changeAnimation:(NSString*)name forTime:(int) times {
if(currentAnimation != #"attack")
{
id action = [CCAnimate actionWithAnimation:[self animationByName:name]];
id repeatAction = [CCRepeat actionWithAction:action times:times];
currentAction = [self runAction:repeatAction];
lastANimation = currentAnimation;
currentAnimation = name;
}
else if(currentAction.isDone)
{
//Here is where I would change the animation
//but I commented the code for now
}
}
So when I run this and click on the button that changes the animation to "attack" (by calling [mysprite changeAnimation:#"attack" forTime:1];), I get a EXC_BAD_ACCESS error from the "currentAction.isDone" line, the next time the function is called (the joystick will call changeAnimation to try and change the animation to "run" or "idle", but I want the attack animation to finish first). Any thoughts on whyI get this? currentAction is declared in my class.
Edit: there is nothing in the rest of the class that interacts with currentAction, beside a getter. Its declaration is in the .h (CCAction* surrentAction). Do I need to initialize it? I thought the returned value from runAction would be sufficient? ANyways, when I run the debugger, it is not nil, and assigned to the correct action.
Thanks,
Dave
Edit:
I ended up creating a sequence when "attacking" that calls a function that changes the currentAnimation, so i avoided the issue. Still no idea what was happening.
Here's the answer if your interested:
Other Post
More of the class is probably needed to really answer this properly, but the EXC_BAD_ACCESS typically happens because you're accessing something that has been released and is no longer available in memory.
I'm guessing that somewhere in your class you're releasing, either explicitly, or implicitly, the "currentAction" object asynchronously - and when you're checking later, it's done & gone and you're hitting this crasher.
In general, keeping a state variable or two that you always have known values on is a good way to go, and for the "actions" that you're going through, if they're asynchronous and doing their own memory management, leave them as such and work through some state variables that you maintain and control all the memory management around. It's a pretty reasonable pattern for asynchronous callbacks, either with the classic stuff or as you move into using blocks with iOS 4.0