Иво Салмре - Программирование мобильных устройств на платформе .NET Compact Framework

//Класс, который будет управлять выполнением нового потока

private ThreadExecuteTask m_threadExecute;

//Класс, метод которого мы хотим выполнять в асинхронном режиме

Test1 m_testMe;

//----------------------------------------------------------

//Этот код должен быть запущен ранее другого кода, поскольку

//он запускает новый поток выполнения!

//

//Создать новый поток и обеспечить его выполнение

//----------------------------------------------------------

private void buttonStartAsyncExecution_Click(object sender, System.EventArgs e) {

//Создать экземпляр класса, метод которого мы хотим вызвать

//в другом потоке

m_testMe = new Test1();

//Упаковать точку входа метода класса в делегат

ThreadExecuteTask.ExecuteMeOnAnotherThread delegateCallCode;

delegateCallCode = new ThreadExecuteTask.ExecuteMeOnAnotherThread(m_testMe.ThreadEntryPoint);

//Дать команду начать выполнение потока!

m_threadExecute = new ThreadExecuteTask(delegateCallCode);

}

//Проверить состояние выполнения

private void buttonCheckStatus_Click(object sender, System.EventArgs e) {

//Запросить у класса управления потоком, в каком состоянии он находится

System.Windows.Forms.MessageBox.Show(m_threadExecute.State.ToString());

//Запросить класс, метод которого выполняется в потоке,

//о состоянии выполнения

System.Windows.Forms.MessageBox.Show(m_testMe.m_loopX.ToString());

}

//Принудительно вызвать запрещенное изменение состояния

//(это приведет к возбуждению исключения)

private void buttonCauseException_Click(object sender, System.EventArgs e) {

m_threadExecute.setProcessingState(ThreadExecuteTask.ProcessingState.notYetStarted);

}

//Послать асинхронному коду запрос с требованием отмены его выполнения

private void buttonAbort_Click(object sender, System.EventArgs e) {

m_threadExecute.setProcessingState(ThreadExecuteTask.ProcessingState.requesAbort);

}

Время от времени приходится слышать вопрос: "Следует ли использовать несколько потоков для выполнения пользовательского интерфейса?" На этот вопрос почти однозначно должен быть дан отрицательный ответ. Привлекать для управления различными частями пользовательского интерфейса несколько потоков практически никогда не имеет смысла. Это особенно относится к мобильным устройствам, в которых пользовательские интерфейсы приложения, как правило, занимают весь экран.

Обычно окна связываются с потоком, который является их владельцем; это справедливо для операционных систем Windows СЕ, Pocket PC и Microsoft Smartphone (а также для таких настольных операционных систем, как Windows XP и более ранние версии Windows). Для каждого окна имеется поток, которому оно принадлежит и который им управляет. Один и тот же поток может владеть несколькими окнами. Поток играет роль "генератора сообщений" по отношению к этим окнам и пересылает им сообщения, когда окно должно быть перерисовано, когда нажимается клавиша, когда выполняется щелчок на кнопке и так далее.

Хотя и можно организовать приложение таким образом, чтобы пользовательский интерфейс обслуживался несколькими потоками (например, по одному потоку на одно окно верхнего уровня), это почти никогда не принесет никакой пользы. Это только усложняет структуру приложения, ничуть не ускоряя его работу. Если вы считаете, что для пользовательского интерфейса необходимо задействовать несколько потоков, задайте себе вопрос, а для чего это в действительности вам надо и нельзя ли при этом использовать один основной поток пользовательского интерфейса и несколько рабочих фоновых потоков, что сделает модель гораздо более понятной.

В подавляющем большинстве случаев намерением использовать несколько потоков, каждый из которых связан с пользовательским интерфейсом, движет желание обеспечить постоянную информированность пользователя о состоянии задач, выполняемых различными фоновыми потоками. Гораздо лучше периодически запрашивать эти данные при помощи одного высокоприоритетного потока интерфейса, используя таймер, чем управлять несколькими окнами на экране посредством нескольких потоков. Проектирование фоновых задач в виде классов, использующих конечные автоматы, упрощает получение соответствующих данных от потока пользовательского интерфейса. Вот вам еще один веский довод в пользу применения подходов, основанных на использовании конечных автоматов.

Даже если ваша оконная модель и не связана с какими-либо специфическими потоками, обычно целесообразнее иметь только один поток выполнения, который "берет на себя попечительство" над пользовательским интерфейсом.