Реализация на AsyncTask с помощта на NSOperation в iOS

Приложих AsyncTask(Android) в iOS, използвайки подклас NSOperation.

-(id)initWithParam:(NSArray *)params{

if (self = [super init]) {

paramsArray = params;
}
return self;

}

- (void)start {

         @autoreleasepool {

   if (self.isCancelled)
      return;
   NSInteger result;

   result = [self doInBackground:paramsArray];

dispatch_async(dispatch_get_main_queue(), ^{

    [self postExecute:result];
});
}
}


 - (BOOL) doInBackground: (NSArray *) parameters{

   BOOL status = false;
   int i;
 for (i=0; i<100000; i++) {
     NSLog(@"printing i::%d",i);
 }
 if (i == 100000) {
    status = YES;
 }

return status;
}
- (void) postExecute: (BOOL) deviceState{

   if (deviceState) {
      NSLog(@"Finished");
  }

}

-(BOOL)isConcurrent{

   return YES;
}

Това е начинът, по който внедрих в iOS. Моля, предложете и всичко, което искам да добавя за тази функционалност.

И също така, кога мога да извикам isExecuting и isFinished в NSOperation подклас


ios objective-c nsoperationqueue nsoperation
person iOS    schedule 26.12.2014    source източник

Отговори (1)


arrow_upward
2
arrow_downward

В отговор на вашия въпрос, за съжаление, не, това изпълнение не е правилно. Близо, но не съвсем там.

Няколко неща:

  1. Вашият пример не е едновременна операция. В случая на NSOperation терминът едновременна операция (сега наричана асинхронна операция) има специално значение. Асинхронна операция е тази, която продължава да се изпълнява асинхронно дори след като методът start завърши. И вие определяте това, като връщате YES от isConcurrent (в по-стари версии на iOS) и isAsynchronous (в съвременни версии на iOS). Но примерната операция във въпроса е напълно изпълнена, когато start приключи, така че следователно не е асинхронна операция и следователно isConcurrent и isAsynchronous трябва да върнат NO.

    Нека приемем в този пример, че сте променили isConcurrent, за да върнете NO, както би било подходящо с това, което изпълнявате в start. Това ще поправи тази операция. Но не позволявайте на това да ви обърква. Ако сте добавили тази операция към вашата собствена опашка от операции, тя все още ще работи асинхронно/едновременно по отношение на основната опашка, просто това е операция, която автоматично завършва, когато start завърши, и следователно isAsynchronous/isConcurrent трябва да върне NO.

  2. Питате кога мога да се обадя на isExecuting и isFinished? Е, обикновено не извиквате тези методи. Обикновено прилагате тези методи. По-конкретно, когато асинхронна операция в крайна сметка приключи, трябва да се уверите, че приложението (a) публикува KVN за ключовете isExecuting и isFinished; и (b) заменяте isExecuting и isFinished, за да сте сигурни, че те съответно връщат подходящите стойности.

    Трябва да внедрите този код isExecuting и isFinished само когато операцията е наистина асинхронна/едновременна операция. Вижте раздела Конфигуриране на операции за едновременно изпълнение на Ръководство за паралелно програмиране: Операционни опашки. Вижте също уводния раздел на NSOperation дефиниция на клас.

Не е ясно дали вашата операция трябва да бъде асинхронна или не (или дори дали изобщо трябва да подкласирате NSOperation). Зависи изцяло от това каква задача искате да изпълните и дали самата задача се изпълнява асинхронно или не.

person Rob    schedule 26.12.2014
comment
Благодаря много @Rob. Всъщност сложих проба там. Всъщност моята задача е да се свържа с персонализирано Wifi устройство и да прочета данните от устройството. Ето защо избирам подкласа NSOperation - person iOS; 26.12.2014
comment
Да, това може да е добър пример за нещо, което бихте обвили с NSOperation подклас. Въпросът е просто дали операцията е наистина едновременна (т.е. start просто ще инициира връзката и има някакъв модел на делегат или блок за завършване, който ще бъде извикан по-късно) или не (т.е. start ще отвори връзка с wifi устройство и няма да се върне, докато връзката с устройството беше готово). Предполагам, че е първото, но вашият пример във вашия въпрос е по-скоро вторият. - person Rob; 26.12.2014