[
https://issues.apache.org/jira/browse/CB-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Grieve resolved CB-508.
------------------------------
Resolution: Won't Fix
Let's re-open or file a new bug if this comes up again.
> better diagnostic capabilities for startup code
> -----------------------------------------------
>
> Key: CB-508
> URL: https://issues.apache.org/jira/browse/CB-508
> Project: Apache Cordova
> 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 was sent by Atlassian JIRA
(v6.1.5#6160)
