In Visual Studio 2015, the solution for this is to switch debugging modes so that instead of the debugger monitoring our managed C# code, it’s monitoring our JS context instead.
You can do this by setting the Application process under Debugger type to Script:
Now when you debug the app and run into a JS exception, the debugger will stop and you’ll have full code context:
This includes inspecting the values of variables, stepping into/out of code and doing basically anything you’d normally want to do with the debugger in a JS app.
A good Hybrid WebApp is one that feels more app than website and most importantly, presents a compelling reason to use the app instead of opening the website in a browser.
Lets avoid creating websites in a box, ok?
In order to become masters of our craft and create a great experience for our end users, we’ll need a solid understanding of the website the app will be based on.
- Decide which elements don’t make sense in our app. These typically include footers, links to download apps (we’re already in an app!), navigation items, etc
- Decide which features of a native app, such as secondary tile pinning, background audio, etc make sense to support
The way I typically do this is a combination of the IE dev tools:
And Visual Studio DOM Explorer:
For Windows Phone I tend to use the Visual Studio DOM explorer more as it loads the site in the emulator, if you weren’t aware you can debug a website in any of the Windows Phone emulators via:
Once we have an idea of our integration, start mocking it up live in the tools mentioned above (IE Dev tools, DOM Explorer).
In practice my environment looks something like this when I’m starting to work on a new Hybrid WebApp (although usually across multiple screens):
Then as I work out a new style change, I copy it over to
app.css. Likewise for scripts, which end up in