Я понял, что подход ниже очень прост.
Я объявил интерфейс для обратного вызова
public interface AsyncResponse {
void processFinish(Object output);
}
Затем создал асинхронную задачу для ответа на все типы параллельных запросов
public class MyAsyncTask extends AsyncTask<Object, Object, Object> {
public AsyncResponse delegate = null;//Call back interface
public MyAsyncTask(AsyncResponse asyncResponse) {
delegate = asyncResponse;//Assigning call back interfacethrough constructor
}
@Override
protected Object doInBackground(Object... params) {
//My Background tasks are written here
return {resutl Object}
}
@Override
protected void onPostExecute(Object result) {
delegate.processFinish(result);
}
}
Затем вызывается асинхронная задача при нажатии кнопки в классе активности.
public class MainActivity extends Activity{
@Override
public void onCreate(Bundle savedInstanceState) {
Button mbtnPress = (Button) findViewById(R.id.btnPress);
mbtnPress.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
MyAsyncTask asyncTask =new MyAsyncTask(new AsyncResponse() {
@Override
public void processFinish(Object output) {
Log.d("Response From Asynchronous task:", (String) output);
mbtnPress.setText((String) output);
}
});
asyncTask.execute(new Object[] { "Your request to aynchronous task class is giving here.." });
}
});
}
}
Спасибо
Можно использовать его для переопределения &&
и ||
операторы.
&&
и ||
операторы не могут быть переопределены, но если Вы переопределяете |
, &
, true
и false
точно правильным способом, которым компилятор будет звонить |
и &
, когда Вы запишете ||
и &&
.
, Например, посмотрите на этот код (от [1 113] http://ayende.com/blog/1574/nhibernate-criteria-api-operator-overloading - где я узнал об этом приеме; заархивированная версия @BiggsTRC):
public static AbstractCriterion operator &(AbstractCriterion lhs, AbstractCriterion rhs)
{
return new AndExpression(lhs, rhs);
}
public static AbstractCriterion operator |(AbstractCriterion lhs, AbstractCriterion rhs)
{
return new OrExpression(lhs, rhs);
}
public static bool operator false(AbstractCriterion criteria)
{
return false;
}
public static bool operator true(AbstractCriterion criteria)
{
return false;
}
Это - очевидно, побочный эффект а не способ, которым он предназначается, чтобы использоваться, но это полезно.
Shog9 и Nir: спасибо за Ваши ответы. Те ответы указали на меня на статья Steve Eichert, и она указала на меня на msdn:
операция x & & y оценен как T.false(x)? x: T.& (x, y), где T.false(x) является вызовом лжи оператора, объявленной в T и T.& (x, y), вызов выбранного оператора &. другими словами, x сначала оценен, и ложь оператора вызывается на результат определить, является ли x определенно ложью. Затем если x является определенно ложью, результатом операции является значение, ранее вычисленное для x. Иначе y оценен, и выбранный оператор & вызывается на значение, ранее вычисленное для x и значения, вычисленного для y для приведения к результату операции.
Страница, которую Вы связываете с http://msdn.microsoft.com/en-us/library/6x6y6z4d.aspx , говорит, для чего они были, который был способом обработать nullable bools, прежде чем nullable типы значения были представлены.
я предположил бы в наше время, что они хороши для того же вида материала как ArrayList - т.е. абсолютно ничто.
AFAIK, это использовалось бы в тесте для лжи, такой как тогда, когда &&
оператор играет роль. Помните, & & короткие замыкания, таким образом, в выражении
if ( mFalse && mTrue)
{
// ... something
}
mFalse.false()
назван, и после возврата true
выражение, уменьшаются до вызова к 'mFalse.true ()' (который должен тогда возвратиться false
, или вещи станут странными).
Примечание, которое необходимо реализовать &
оператор для того выражения для компиляции, так как это используется если mFalse.false()
возвраты false
.
Это появляется из статьи MSDN, которую Вы связали с ним, был обеспечен для обеспечения nullable булевых типов до Nullable (т.е. интервал?, bool?, и т.д.) тип, являющийся introducted на язык в C#2. Таким образом Вы сохранили бы внутреннее значение, указывающее, является ли значение TRUE или FALSE или пустым указателем, т.е. в Вашем примере> 0 для истинного, < 0 для лжи и == 0 для пустого указателя, и затем Вы получили бы семантику пустого указателя стиля SQL. Необходимо было бы также реализовать.IsNull метод или свойство, чтобы ничтожность могла быть проверена явно.
По сравнению с SQL, вообразите таблицу Table с 3 строками со значением набором Foo к истинному, 3 строкам со значением набор Foo ко лжи и 3 строкам со значением Foo установленный в NULL.
SELECT COUNT(*) FROM Table WHERE Foo = TRUE OR Foo = FALSE
6
для подсчета всех строк, необходимо было бы сделать following:-
SELECT COUNT(*) FROM Table WHERE Foo = TRUE OR Foo = FALSE OR Foo IS NULL
9
, Это 'ЯВЛЯЕТСЯ ПУСТЫМ' синтаксисом, имел бы код equivilent в классе как.IsNull ().
LINQ делает сравнение с C# даже clearer:-
int totalCount = (from s in MyTypeEnumerable
where s || !s
select s).Count();
, Предполагая, что MyTypeEnumberable имеет точно то же содержание базы данных, т.е. 3 значения, равные истинному, 3 значения, равные лжи и 3 значениям, равным пустому указателю. В этом случае totalCount оценил бы к 6 в этом случае. Однако, если бы мы переписали as:-
int totalCount = (from s in MyTypeEnumerable
where s || !s || s.IsNull()
select s).Count();
кода Тогда totalCount, то оценил бы к 9.
пример DBNull, данный в связанной статье MSDN о ложном операторе, демонстрирует класс в BCL, который имеет это точное поведение.
В действительности заключение - Вы, не должен использовать это, если Вы не абсолютно уверены, что хотите этот тип поведения, лучше просто использовать намного более простой nullable синтаксис!!
Обновление: я просто заметил, что необходимо вручную переопределить логические операторы!, || и & & сделать эту работу правильно. Я верю ложной подаче оператора в эти логические операторы, т.е. указанию на истину, ошибочность или 'иначе'. Как отмечено в другом комментарии! x не отделается от летучей мыши; необходимо перегрузиться!. Странность!