Книга хорошая, однако предназначена в основном тем, кто только начинает пробовать TDD. Охватывает много тем но, к сожалению, поверхностно и не опускается в «мрачные глубины» техник, которые выходят за рамки «давайте напишем юнит тест и подменим сервис моком». Но для начинающих тэдедистов или для тех, кто переходит на тэдэдэ на c# — вполне годная книга.
Объект будет создан, и даже соберется в свой час мусорщиком, однако не будет вызова Dispose. Обычно это не страшно, но представьте себе ситуацию, когда в диспозере вызывается, например, не откат транзакции, а ее коммит (я понимаю, что пример так себе, но представим, что у нас программист-параноик, который журналирует ошибки конструкторов в транзакционное хранилище). Так вот в нашем случае записи в журнал не будет. Поэтому, как правильно сказал коллега выше по тексту, не усердствуйте с использованием инициализаторов там, где этого требуется, а если выхода нет, то отказывайтесь от сахара using в пользу специфической обработки исключений.
Ну чудес-то не бывает :) Понятно, что если бы MS изначально вел ASP.NET (да и вообще .NET) как мультиплатформенную технологию, то сейчас многие из нас были бы в шоколаде. Потому что, ИМХО, .NET как платформа намного лучше гораздо удобнее Java.*. Но и теперь начать выходить на другие платформы еще не поздно. Наверное даже лучше через OpenSource-модель, чем самим.
Конечным разработчикам таки да, придется, при необходимости, проверяться на совместимость с Mono. Но теперь есть стимул это делать, зная, что твой код работает на «официальной» платформе, а не на «ребята скопировали и вроде работает». Это, на мой взгляд, еще один очень правильный шаг в сторону построения/поддержки хороших, распределенно/облачных систем. И хочется порадоваться как за Мигеля, который дотянул проект до такой важной точки, так и за тех, кто продавил (или пропиарил) решение в MS.
Будет обязательно, но, к сожалению, не могу пока сказать дату релиза. Прошу отнестись с пониманием — www.kinopoisk.ru — это большой, удивительно мощный проект, с большим количеством функционала. Хочется аккуратно переводить его в мобильный вид, чтобы с одной стороны представить все функции, а с другой — не сделать приложение чересчур громоздким и выбивающимся из экосистемы. Так что «семь раз отмерь — один раз запрограммируй».
Поиск в кеше проходит достаточно быстро, а с загрузкой было сделано так — сначала изображение загружалось в кеш, а потом из кеша показывалось, то есть происходил двойной доступ к хранилищу, но экономился траффик пользователя. Конечно есть вариант сначала загрузить все изображение в память, а потом уже декодировать его в рисуемый объект и сохранять его в хранилище, однако это повышает пиковое использование памяти, что критично в некоторых ситуациях. Так вот, эта двойная операция обращения к хранилищу оказалась на удивление медленной, поэтому сейчас такое кеширование оставлено только для изображений главной панорамы, а все остальные изображения грузятся напрямую и не кешируются. Кстати, очень нехватает возможности определить сколько места занято под кеш, из за этого приходится изобретать хитрый скавенджер :(
Тут разговор шел, в основном, о синтаксическом сахаре паттерны Asynchronous Callbacks, который предоставляет компилятор C#. Если коротко, то код, который на «чистом» C# выглядит как цепочка методов (начало обработки/завершение обработки) с использованием Async CTP превращается (для разработчика) в один метод. А «на самом деле» компилятор сам пишет те самые «начало обработки» и «завершение обработки». В простых ситуациях это само по себе приятно, а особенно это приятно, например, когда по результатам одной асинхронной операции нужно запустить еще несколько. Такой сценарий, кстати, часто встречается — например мы получаем от сервера информацию о фильме и стартуем загрузку кадров из фильма.
1) Хочу C# под Android! Но MonoDroid, по рассказам очевидцев, пока недостаточно зрелый, что ли. Сам не пробовал, поэтому врать не буду. Хотя в большинстве случаев, кстати, Android == Java && iOS == ObjectiveC.
2) Да к этому удобству так привыкаешь быстро…
3) Еще раз, я не спорю, что асинхронные паттерны (begin/callback/end) есть сейчас в любой мобильной платформе. Я говорю именно про конкретную реализацию в том инструменте, который наиболее часто используется для разработки под конкретную платформу. Вот у VS/C# есть async/await который, согласитесь, уж всяко лучше тех конструкций, которые придется писать на Java || Objective C. Да, мы Челябинские металлурги олдскульные хардкорщики, не обломимся и напишем таки 4 экрана коллбеков и при этом не запутаемся в них. Но этот гадский инструмент VS лишает нас этого удовольствия и заставляет писать коротко и понятно :)
А я не сравнивал именно асинхронное программирование у WP7 и Android. Я говорил про общую дружелюбность платформы к разработчику. Да, Android очень гибок и позволяет очень много сделать. Мне ужасно нравится сама концепция общения между приложениями в Android — у WP7 этого пока нет. Да и сама платформа постарше (в смысле зрелости). Однако то, что в VisualStudio для WP7 делается за минуту, на Android нужно тщательно описывать. Про это я и говорил. А еще при разработке под Android ужасно нехватает свойств (C# properties), LINQ, связывания и ах да! async/await, но тут я, пожалуй, остановлюсь иначе начнется холивор :)
Нажал не ту кнопку и улетел недописанный текст :-(
@andrew_kane: В обработчиках ничего такого нет, а за пиксели спасибо, проверю шаблон. Да и кнопки действительно можно сделать побольше. Наверняка поправим в одном из ближайших релизов.
Уважаемые хаброжители! Прежде всего хочу сказать спасибо за добрые отзывы и конструктивную критику — и того, и другого так мало стало в современных интернетах :-) Мы продолжаем улучшать Кинопоиск ориентируясь, в том числе, и на ваши пожелания и замечания. Большая часть проблем, связанных с производительностью, была решена в версии 1.3, отдано мы не остановимся на достигнутом.
Одной из причин, по которой возникают задержки, является большое количество графики, которую приложение загружает из интернета. Вся загвоздка в том, что финальное декодирование изображения производится в потоке пользовательского интерфейса (сама загрузка идет в фоне) — и вот тут-то начинаются притормаживания. К сожалению элегантного способа решения проблемы мы пока не нашли, а уж совсем откровенных «гнусных хаков» делать не хочется, так что продолжаем борьбу на этом фронте :-)
намного лучшегораздо удобнее Java.*. Но и теперь начать выходить на другие платформы еще не поздно. Наверное даже лучше через OpenSource-модель, чем самим.2) Да к этому удобству так привыкаешь быстро…
3) Еще раз, я не спорю, что асинхронные паттерны (begin/callback/end) есть сейчас в любой мобильной платформе. Я говорю именно про конкретную реализацию в том инструменте, который наиболее часто используется для разработки под конкретную платформу. Вот у VS/C# есть async/await который, согласитесь, уж всяко лучше тех конструкций, которые придется писать на Java || Objective C. Да, мы
Челябинские металлургиолдскульные хардкорщики, не обломимся и напишем таки 4 экрана коллбеков и при этом не запутаемся в них. Но этот гадский инструмент VS лишает нас этого удовольствия и заставляет писать коротко и понятно :)@andrew_kane: В обработчиках ничего такого нет, а за пиксели спасибо, проверю шаблон. Да и кнопки действительно можно сделать побольше. Наверняка поправим в одном из ближайших релизов.
Одной из причин, по которой возникают задержки, является большое количество графики, которую приложение загружает из интернета. Вся загвоздка в том, что финальное декодирование изображения производится в потоке пользовательского интерфейса (сама загрузка идет в фоне) — и вот тут-то начинаются притормаживания. К сожалению элегантного способа решения проблемы мы пока не нашли, а уж совсем откровенных «гнусных хаков» делать не хочется, так что продолжаем борьбу на этом фронте :-)
@andrew_kane: В обработчиках