[
https://issues.apache.org/jira/browse/CB-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253771#comment-13253771
]
Patrick Mueller commented on CB-508:
------------------------------------
If we end up doing some "instrumentation" - adding code - we could do this in
the -debug.js files the build is currently building.
Kinds of instrumentation:
- supplying new versions of require()/define() to track module loading/requires
- hooking event handlers, to try/catch around them, and log when they're running
Could even go whole hog, and process the JS into instrumented JS via Uglify
parsing/annotation. Prolly don't need to go to that level, yet.
> 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
