incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Filip Maj (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CB-508) better diagnostic capabilities for startup code
Date Sat, 14 Apr 2012 01:59:16 GMT

    [ https://issues.apache.org/jira/browse/CB-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253934#comment-13253934
] 

Filip Maj commented on CB-508:
------------------------------

I would love adding the queue-of-logs to the -debug version of the file (and possibly feeding
them into {{console.log}} once {{deviceready}} fires) - I think that's a great idea. It is,
after all, a debug version.

One question that comes with this is: do we then "vendor" in the -debug versions into the
platform repositories?
                
> better diagnostic capabilities for startup code
> -----------------------------------------------
>
>                 Key: CB-508
>                 URL: https://issues.apache.org/jira/browse/CB-508
>             Project: Apache Callback
>          Issue Type: New Feature
>          Components: CordovaJS
>            Reporter: Patrick Mueller
>            Assignee: Filip Maj
>
> I just sent the day yesterday debugging the common-js modules on iOS, for the lifetime
of when the script is loaded through when deviceready is fired.
> *PAIN!*
> Couple of things:
> * there are still some lingering console.log() calls in code that gets run before deviceready
> * even the new utils.alert() or whatever doesn't help here, as it can't do anything before
deviceready
> * we need to be able to diagnose issues when deviceready is never called
> That last one is something I looked at yesterday.  How do you "debug" your web app that
isn't firing deviceready?  Even tools like iWebInspector can't really help for issues that
occur at startup - the time window is very small and there's A LOT OF SHIT going on.
> We need to do something, but I don't have concrete ideas yet.
> What I ended up doing yesterday was writing a small function {{HackLog(aMessage)}} which
"logs" a message.  Works anywhere, anytime.  Logging the message means appending it to an
array.  :-)  After a fixed timeout, I dump the contents of the log to the DOM in a <pre>
(or whatever).
> This sort of "log to the DOM" is a nice approach, because we usually do have a DOM available.
 The trick is to figure out how folks can enable this sort of thing, which you clearly don't
want in production.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message