• Replies 11 replies
  • Subscribers 18 subscribers
  • Views 1915 views
  • Users 0 members are here
Options
Related

What does  ConfirmationDelegate.initialize() do?

Alan.raceQs
I'm getting stuck in some UI code and have tracked it down to the fact that I don't understand the ConfirmationDelegate documentation that includes:.
function initialize() {
ConfirmationDelegate.initialize();
}



I am using the initialize() function to receive an argument with which to modify its behavior of in its onResponse() callback, like:
function initialize(_openNavMenuOnClose) {
openNavMenuOnClose = _openNavMenuOnClose;
ConfirmationDelegate.initialize();
}


But I am getting different responses from my code when running in the Sim and on a device.

So my question is : what does the call to ConfirmationDelegate.initialize() actually do?

  • Probably, the same thing that the initialization does for any delegate. It doesn't seem it would need to be doing anything special.

    Your problem might not actually be in the delegate initialization.

    What are the "different responses"? It seems like information about that might be useful to people to know about.

    (You are assuming the problem is in X. The problem might be Y. You don't provide any information about what you are seeing.)
  • What are the different responses you see in the sim and device?
    I doubt the ConfirmationDelegate.initialize() is involved, as you are just initializing the parent.
  • Probably, the same thing that the initialization does for any delegate. It doesn't seem it would need to be doing anything special.

    Yes, but what is that "same thing"?
    It seems to make no difference whether I call ConfirmationDelegate.initialize() or not.

  • Yes, but what is that "same thing"?
    It seems to make no difference whether I call ConfirmationDelegate.initialize() or not.

    ??? You said that you got different behavior in the sim and the device and attributed it to this function.

    Try not calling it for other types of views...

    Are you sure it "makes no difference" in every use of the function?

    If it "makes no difference", why not just call it?

    If the documentations says to call it, you have to call it (it's part of the "contract").

    It's possible that it doesn't do anything now but may in the future.



  • ??? You said that you got different behavior in the sim and the device and attributed it to this function.

    I'm sorry I ever mentioned it. It was just to add some context to my question.
    Try not calling it for other types of views...

    In this thread, I'm really only interested in understanding the ConfirmationDelegate.
    Are you sure it "makes no difference" in every use of the function?

    No, I'm not - proving a negative is logical impossibility, that's why I'm asking the question:D
    If it "makes no difference", why not just call it?

    Are you really happy following rules that seem to have no basis? This isn't the military where you don't ask questions.
    If the documentations says to call it, you have to call it (it's part of the "contract").

    See previous comment.
    It's possible that it doesn't do anything now but may in the future.

    That's what I suspect, but I'd like to get a better handle on it.



  • As I said, by calling it, you are initialing the parent. Something you want to do when you extend a class.

    What are you seeing that works differently if you call ConfirmationDelegate.initialize() vs not calling it?
  • Errr, nobody is blindly "following rules that seem to have no basis".

    I think you mentioned that you have a background in Java? Well, in Java, it just so happens that when you extend a class, the superclass constructor is called automatically/implicitly, provided a default constructor exists.
    https://stackoverflow.com/questions/...or-inheritance

    In Monkey C, there is no implicit call to the parent class constructor, therefore it must be called explicitly. (This is mentioned in the programmer's guide.)

    So if you were unaware that Java calls the superclass constructor automatically, I can see why this might be confusing.

    IMO calling the super/parent class constructor (implicitly or explicitly) goes beyond following a programming contract -- it goes to the very heart of OOP and class-based inheritance.

    When I extend a class for any reason, I want my subclass to have same behaviour/properties as the parent, with the exception of the changes I explicitly make. To accomplish this, I have to make sure that the parent class initializes itself properly -- this is done by calling the parent class constructor. Another fundamental aspect of OOP is encapsulation/data hiding: according to these principles, you don't want to know the details of what the constructor does and you shouldn't need to know. (Unless of course there are parameters which affect the externally visible behaviour and state of the class). That way, the API/library provider can change the implementation down the road without breaking existing code.

    These aren't arbitrary rules that people made up to frustrate coders and alienate noobs, these are conventions and guidelines that have purpose behind them.
  • As I said, by calling it, you are initialing the parent. Something you want to do when you extend a class.

    In the context of the ConfirmationDelegate, I don't know what it does; you don't know what it does, so why don't we just hope someone with access to the code provides an answer (Coleman.ConnectIQTravis.ConnectIQ ) ?

    What are you seeing that works differently if you call ConfirmationDelegate.initialize() vs not calling it?

    As I said, I'm sorry I mentioned it. It's not actually relevant to my enquiry.
  • Are you really happy following rules that seem to have no basis? This isn't the military where you don't ask questions.


    You are assuming the rules "have no basis". (Nor, is anybody saying don't ask questions.)


    With class (and other) libraries, it's a normal thing to indicate that you have to do things (like calling initializers).

    Unless, you have the source code, you won't know what it does (the code could even be proprietary!). That's a common situation too.

    Programmers deciding that "it's not necessary" (often, based on insufficient information) is a common source of defects in programming.
  • In Monkey C, there is no implicit call to the parent class constructor, therefore it must be called explicitly. (This is mentioned in the programmer's guide.)

    But certainly in the case of the ConfirmationDelegate, this is appears not to be the case, as it works as well without the call to the parent class's initialize(), and indeed, will run without the initialize() function at all.
    It would seem that the call to initialize the parent class in MC, as in Java, is indeed called "implicitly/ automatically" and thus is superfluous in our code.

    [RESOLVED?]
    I believe the answer to my initial question should have been:

    This is a documentation error, there is no need to call ConfirmationDelegate.initalize() from the optional initialize() function.
    The documentation for ConfirmationDelegate should read:
    "Optional :
    function initialize(context){
    // receive local variables from context passed from class instantiation.
    }
    "


    My reading of the documentation reveals a similar documentation error for the following delegate classes:
    Menu2InputDelegate, MenuInputDelegate, TextPickerDelegate.