Alternatywa dla dispatch_get_current_queue () dla bloków uzupełniania w iOS 6?

Mam metodę, która akceptuje blok i blok uzupełniania. Pierwszy blok powinien działać w tle, a blok uzupełniania w dowolnej kolejce, w której wywołano metodę.

W przypadku tego ostatniego zawsze używałem dispatch_get_current_queue(), ale wygląda na to, że jest przestarzały w iOS 6 lub nowszym. Czego powinienem użyć zamiast tego?

Wzorzec „uruchamiaj w dowolnej kolejce, w której był dzwoniący” jest atrakcyjny, ale ostatecznie nie jest to świetny pomysł. Ta kolejka może być kolejką o niskim priorytecie, kolejką główną lub inną kolejką o nieparzystych właściwościach.

Moim ulubionym podejściem jest stwierdzenie, że „blok uzupełniania działa na kolejce zdefiniowanej w ramach implementacji z następującymi właściwościami: x, y, z” i pozwolenie blokowi na wysłanie do określonej kolejki, jeśli wywołujący chce mieć większą kontrolę. Typowy zestaw właściwości do określenia to coś w rodzaju „szeregowy, niewprowadzający ponownie i asynchroniczny w odniesieniu do każdej innej kolejki widocznej dla aplikacji”.

** EDYTOWAĆ **

Catfish_Man umieścił przykład w komentarzach poniżej, po prostu dodaję go do jego odpowiedzi.

- (void) aMethodWithCompletionBlock:(dispatch_block_t)completionHandler     
{ 
    dispatch_async(self.workQueue, ^{ 
        [self doSomeWork]; 
        dispatch_async(self.callbackQueue, completionHandler); 
    } 
}

Jest to zasadniczo niewłaściwe podejście do opisywanego interfejsu API. Jeśli interfejs API akceptuje blok i blok uzupełniania do uruchomienia, muszą być spełnione następujące fakty:

1. „Blok do uruchomienia” powinien być uruchamiany w kolejce wewnętrznej, np. Kolejce prywatnej dla API, a zatem całkowicie pod kontrolą tego API. Jedynym wyjątkiem jest sytuacja, gdy interfejs API wyraźnie deklaruje, że blok zostanie uruchomiony w głównej kolejce lub w jednej z globalnych kolejek współbieżnych.

2. Blok uzupełniania powinien zawsze być wyrażony jako krotka (kolejka, blok), chyba że te same założenia, co dla # 1 są prawdziwe, np. Blok uzupełniania zostanie uruchomiony na znanej globalnej kolejce. Blok uzupełniania powinien ponadto być wysyłany asynchronicznie w kolejce przekazanej.

To nie są tylko punkty stylistyczne, są one całkowicie konieczne, jeśli twoje API ma być bezpieczne przed zakleszczeniami lub innymi zachowaniami skrajnymi, które w przeciwnym razie spowodują zawieszenie cię kiedyś na najbliższym drzewie. :-)

Inne odpowiedzi są świetne, ale dla mnie odpowiedź jest strukturalna. Mam taką metodę, która jest na Singletonie:

- (void) dispatchOnHighPriorityNonMainQueue:(simplest_block)block forceAsync:(BOOL)forceAsync {
    if (forceAsync || [NSThread isMainThread])
        dispatch_async_on_high_priority_queue(block);
    else
        block();
}

który ma dwie zależności, którymi są:

static void dispatch_async_on_high_priority_queue(dispatch_block_t block) {
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), block);
}

i

typedef void (^simplest_block)(void); // also could use dispatch_block_t

W ten sposób scentralizuję wywołania, które mają być wysyłane w drugim wątku.

Przede wszystkim należy zachować ostrożność podczas korzystania z dispatch_get_current_queue. Z pliku nagłówkowego:

Zalecane tylko do debugowania i rejestrowania:

Kod nie może przyjmować żadnych założeń dotyczących zwróconej kolejki, chyba że jest to jedna z kolejek globalnych lub kolejka, którą sam utworzył. Kod nie może zakładać, że synchroniczne wykonanie w kolejce jest zabezpieczone przed zakleszczeniem, jeśli ta kolejka nie jest kolejką zwróconą przez dispatch_get_current_queue ().

Możesz zrobić jedną z dwóch rzeczy:

1. Zachowaj odniesienie do kolejki, w której pierwotnie opublikowałeś (jeśli utworzyłeś ją przez dispatch_queue_create) i używaj tego od tej pory.

2. Korzystaj z kolejek zdefiniowanych przez system za pośrednictwem dispatch_get_global_queuei śledź, z której korzystasz.

Skutecznie, choć wcześniej polegałeś na systemie, który śledzi kolejkę, w której się znajdujesz, będziesz musiał to zrobić samodzielnie.

Firma Apple wycofała się dispatch_get_current_queue(), ale pozostawiła lukę w innym miejscu, więc nadal możemy uzyskać bieżącą kolejkę wysyłek:

if let currentDispatch = OperationQueue.current?.underlyingQueue {
    print(currentDispatch)
    // Do stuff
}

Działa to przynajmniej dla głównej kolejki. Pamiętaj, że ta underlyingQueuewłaściwość jest dostępna od iOS 8.

Jeśli potrzebujesz wykonać blok uzupełniania w oryginalnej kolejce, możesz również użyć OperationQueuebezpośrednio, tj. Bez GCD.

Ci, którzy nadal potrzebują porównywania w kolejce, mogą porównać kolejki według ich etykiety lub specyfikacji. Sprawdź to https://stackoverflow.com/a/23220741/1531141

To jest odpowiedź dla mnie też. Więc opowiem o naszym przypadku użycia.

Mamy warstwę usług i warstwę interfejsu użytkownika (między innymi). Warstwa usług uruchamia zadania w tle. (Zadania manipulacji danymi, zadania CoreData, połączenia sieciowe itp.). Warstwa usług ma kilka kolejek operacji, aby zaspokoić potrzeby warstwy interfejsu użytkownika.

Warstwa UI polega na warstwie usług, aby wykonać swoją pracę, a następnie uruchomić blok ukończenia sukcesu. Ten blok może zawierać kod UIKit. Prostym przypadkiem użycia jest pobranie wszystkich wiadomości z serwera i ponowne załadowanie widoku kolekcji.

Tutaj gwarantujemy, że bloki przekazywane do warstwy usług są wysyłane w kolejce, w której usługa została wywołana. Ponieważ dispatch_get_current_queue jest przestarzałą metodą, używamy NSOperationQueue.currentQueue, aby uzyskać bieżącą kolejkę wywołującego. Ważna uwaga na temat tej nieruchomości.

Wywołanie tej metody spoza kontekstu działającej operacji zazwyczaj powoduje zwrócenie wartości nil.

Ponieważ zawsze wywołujemy nasze usługi w znanej kolejce (nasze kolejki niestandardowe i kolejka główna), działa to dobrze dla nas. Mamy przypadki, w których serviceA może wezwać serviceB, który może wezwać serviceC. Ponieważ kontrolujemy, skąd jest wykonywane pierwsze zgłoszenie serwisowe, wiemy, że pozostałe usługi będą podlegać tym samym regułom.

Zatem NSOperationQueue.currentQueue zawsze zwróci jedną z naszych kolejek lub MainQueue.