При работе с задачами из пространства имен Microsoft.Phone.Tasks существуют две стандартные ошибки: разработчики не думают о том, что на время, когда запущена задача, ваше приложение может перейти в tombstone mode. Проще говоря – это когда ваше приложение убьют, и сохранят только State страницы и State приложения, которые вам нужно будет потом восстановить. Вторая стандартная ошибка скрывается в том, что при вызове метода Show у задач, если данная страница уже не активна, то есть, например, происходит навигация, то метод бросит исключение InvalidOperationException, который убьёт ваше приложение (если вы не перехватываете исключение), и при возврате из задачи – вы попадете на главный экран самой операционной системы.

Итак, давайте напишем наипростейшее приложение из разряда, как выбрать картинку из библиотеки и отобразить ее на контроле. User Interface у нас будет такой:

А код такой:

Итак, сколько проблем вы здесь видите?

Я теперь понимаю, почему отличные книги по программированию получаются у людей, которые проработали в огромных компаниях, существовавшие ни один десяток лет. Ничто так не учит, как Legacy (старый) код. Он заставляет совсем по-новому смотреть на добавление функционала и исправление ошибок методом «по-быстрому».

До работы над Visual Studio я не так часто сидел в отладчике, так как проекты не были такими большими, мой код не так сильно зависел от кода соседних команд, и все что мне нужно я быстро мог понять из тестов/кода, и только, когда уже ничего не помогало, я шел отлаживать приложение. Основная причина для этого была одна – так для меня было намного быстрее и легче работать, так я быстрее находил проблемы.

С Visual Studio такое не пройдет, кода очень много, влияение чужого кода огромное, не мало legacy кода, который еще писался до того, как разработчики начали усиленно думать о том, что код должен быть понятен не только компьютеру, но и разработчикам. В общем, отлаживать приложения приходиться теперь намного больше. А еще я познакомился вплотную с отладкой дампов (dump) памяти.