How to use :)
Just setup tag for your scrollview and you will get one with scroll indicators, which are shown all the time.

If you want both scroll it’s easy to change code.

Simple solution:

Add framework AudioToolbox and add import to file

Insert into init method or any other

Listener callback

SimpleEKDemo

The application uses table views to display EKCalendar object and EKEvent objects retrieved from an EKEventStore object. It implements EKEventViewController for viewing and editing existing EKEvents, and uses EKEventEditViewController for creating new EKEvents.

Example:

Tweeting

Что это?

Grand Central Dispatch, или, ко­рот­ко, GCD — это низ­ко­уров­не­вое API, ко­то­рая от­кры­ва­ет но­вый спо­соб ра­бо­тать с па­рал­лель­ны­ми (ори­ги­наль­но это concurrent, а не parallel, я не знаю нор­маль­но­го пе­ре­во­да, ес­ли кто ска­жет — на­пи­ши­те в ком­мен­та­ри­ях, прим. пер.) про­грам­ма­ми. На са­мом про­стом уровне по­ни­ма­ния, ме­то­до­ло­гия по­хо­жа на NSOperationQueue, ко­то­рая поз­во­ля­ет раз­би­вать про­грам­му на неза­ви­си­мые за­да­чи, ко­то­рые за­пус­кать па­рал­лель­но или по­сле­до­ва­тель­но. GCD ра­бо­та­ет на бо­лее низ­ком уровне, предо­став­ля­ет боль­шую про­из­во­ди­тель­ность и не яв­ля­ет­ся ча­стью Cocoa.

В до­пол­не­ние к сред­ствам па­рал­лель­но­го вы­пол­не­ния ко­да, GCD та­к­же предо­став­ля­ет пол­но­стью ин­те­гри­ро­ван­ную си­сте­му об­ра­бот­ки со­бы­тий. Об­ра­бот­чи­ки мо­гут быть скон­фи­гу­ри­ро­ва­ны та­ким об­ра­зом, что­бы ре­а­ги­ро­вать на со­бы­тия от фай­ло­вых де­скрип­то­ров, си­стем­ных пор­тов и про­цес­сов, тай­ме­ров и сиг­на­лов, и на поль­зо­ва­тель­ские со­бы­тия. Эти об­ра­бот­чи­ки ис­пол­ня­ют­ся па­рал­лель­но при по­мо­щи ин­фра­струк­ту­ры GCD.

API GCD пол­но­стью ос­но­ван на так на­зы­ва­е­мых бло­ках, о ко­то­рых я го­во­рил в преды­ду­щих се­ри­ях от­ве­тов на во­про­сы («Поз­воль­те пред­ста­вить»: бло­ки и «Об­суж­де­ние прак­ти­че­ских ас­пек­тов ис­поль­зо­ва­ния бло­ков в обыч­ном ко­де»). GCD мож­но ис­поль­зо­вать и без бло­ков, при­ме­няя тра­ди­ци­он­ные C-​шные ме­ха­низ­мы ука­за­те­лей на функ­ции и кон­тек­ста, но ис­поль­зо­вать бло­ки го­раз­до про­ще и неве­ро­ят­но удоб­нее с прак­ти­че­ской точ­ки зре­ния.

Для по­лу­че­ния си­стем­ной до­ку­мен­та­ции по GCD, мож­но на­брать man dispatch в ко­манд­ной стро­ке, ес­ли у вас Snow Leopard.

Зачем это нужно использовать?

GCD да­ет мно­же­ство пре­иму­ществ пе­ред тра­ди­ци­он­ным мно­го­по­точ­ным про­грам­ми­ро­ва­ни­ем:

• Про­сто­та ис­поль­зо­ва­ния. GCD ис­поль­зо­вать го­раз­до про­ще, чем по­то­ки. Так как ос­но­вой яв­ля­ют­ся эле­мен­ты ра­бо­ты, а не по­то­ки вы­чис­ле­ний, мож­но про­сто за­пу­стить на вы­пол­не­ние ра­бо­ту, не за­бо­тясь о стан­дарт­ных за­да­чах, та­ких, как ожи­да­ние за­вер­ше­ния ра­бо­ты, от­сле­жи­ва­ние де­скрип­то­ров фай­лов, ис­пол­не­ние ко­да с ка­кой-​то пе­ри­о­дич­но­стью, вре­мен­ная при­оста­нов­ка ра­бо­ты. API, ос­но­ван­ные на бло­ках поз­во­ля­ют с необы­чай­ной лег­ко­стью пе­ре­да­вать кон­текст меж­ду раз­лич­ны­ми ча­стя­ми ко­да.
• Эф­фек­тив­ность. GCD ре­а­ли­зо­ван лег­ко­вес­ным спо­со­бом, что де­ла­ет го­раз­до бо­лее прак­тич­ным и быст­рым ис­поль­зо­ва­ние GCD в тех ме­стах, где вы­де­лен­ные по­то­ки слиш­ком за­трат­ны. С этим тес­но свя­за­на про­сто­та ис­поль­зо­ва­ния: от­ча­сти, то, что поз­во­ля­ет так лег­ко ис­поль­зо­вать GCD, поз­во­ля­ет и не силь­но при его ис­поль­зо­ва­нии за­бо­тить­ся об эф­фек­тив­но­сти.
• Про­из­во­ди­тель­ность. GCD ав­то­ма­ти­че­ски мас­шта­би­ру­ет­ся (со­зда­ет и уда­ля­ет по­то­ки) в со­от­вет­ствии с за­груз­кой си­сте­мы, что ве­дет за со­бой мень­шее ко­ли­че­ство пе­ре­клю­че­ний кон­тек­ста и боль­шую вы­чис­ли­тель­ную эф­фек­тив­ность.

Посылки (Dispatch Objects)

Не смот­ря на то, что GCD — это чи­стый C, он спро­ек­ти­ро­ван в объ­ект­ном сти­ле. Объ­ек­ты GCD на­зы­ва­ют­ся по­сыл­ка­ми (Dispatch Objects). По­сыл­ки ис­поль­зу­ют под­счет ссы­лок, как и объ­ек­ты Cocoa. Для под­сче­та ссы­лок (кон­тро­ля за па­мя­тью) мож­но ис­поль­зо­вать функ­ции dispatch_retain и dispatch_release. Сто­ит пом­нить, что, в от­ли­чие от объ­ек­тов Cocoa, по­сыл­ки не участ­ву­ют в сбор­ке му­со­ра, то есть ими нуж­но управ­лять вруч­ную, да­же ес­ли вклю­чен сбор­щик му­со­ра (к iOS это по-​преж­не­му по­ка не от­но­сит­ся, прим. пер).

Оче­ре­ди по­сы­лок и ис­точ­ни­ки по­сы­лок (что это — чуть позд­нее) мо­гут быть при­оста­нов­ле­ны и за­пу­ще­ны сно­ва, мо­гут со­дер­жать про­из­воль­ный ука­за­тель на кон­текст, с ни­ми ас­со­ци­и­ро­ван­ный, и «фи­на­лай­зер», то есть за­вер­ша­ю­щую функ­цию. Для бо­лее по­дроб­ной ин­фор­ма­ции мож­но по­смот­реть на man dispatch_object.

Очереди посылок

Фун­да­мен­таль­ная кон­цеп­ция в GCD — оче­редь по­сы­лок. Это объ­ект, ко­то­рый по­лу­ча­ет ин­фор­ма­цию о за­да­ни­ях и ко­то­рый вы­пол­ня­ет их в той же по­сле­до­ва­тель­но­сти, в ко­то­рой по­лу­чил. Оче­редь мо­жет быть ли­бо па­рал­лель­ной ли­бо по­сле­до­ва­тель­ной. Па­рал­лель­ная оче­редь мо­жет ис­пол­нять мно­го за­да­ний од­но­вре­мен­но, на­сколь­ко это адек­ват­но те­ку­щей за­груз­ке си­сте­мы, при­мер­но как и NSOperationQueue. По­сле­до­ва­тель­ная оче­редь бу­дет вы­пол­нять по од­ной за­да­че еди­но­вре­мен­но.

Все­го в GCD три ти­па оче­ре­дей:

• Глав­ная оче­редь. По­хож на глав­ный по­ток. На са­мом де­ле, за­да­ния, ко­то­рые от­прав­ле­ны на ис­пол­не­ние в глав­ную оче­редь, ис­пол­ня­ют­ся в глав­ном по­то­ке про­цес­са. Ссыл­ку на глав­ную оче­редь мож­но по­лу­чить, вы­звав функ­цию dispatch_get_main_queue(). Так как глав­ная оче­редь за­ви­си­ма от од­но­го глав­но­го по­то­ка, это по­сле­до­ва­тель­ная оче­редь.
• Гло­баль­ные оче­ре­ди. Гло­баль­ные оче­ре­ди — это па­рал­лель­ные оче­ре­ди, ко­то­рые сов­мест­но ис­поль­зу­ют­ся всем про­цес­сом. Все­го их три: оче­редь с низ­ким при­о­ри­те­том, оче­редь с обыч­ным при­о­ри­те­том, оче­редь с вы­со­ким при­о­ри­те­том. Ссыл­ки на гло­баль­ные оче­ре­ди мож­но по­лу­чить при по­мо­щи функ­ций dispatch_get_global_queue, ука­зы­вая, оче­редь с ка­ким при­о­ри­те­том вам нуж­на.
• Поль­зо­ва­тель­ские (custom) оче­ре­ди. На са­мом де­ле у них нет на­зва­ния, по­это­му бу­дем на­зы­вать их «поль­зо­ва­тель­ски­ми». Эти оче­ре­ди со­зда­ют­ся при по­мо­щи функ­ции dispatch_queue_create. Это по­сле­до­ва­тель­ные оче­ре­ди, ко­то­рые мо­гут ис­пол­нять од­но за­да­ние в каж­дый мо­мент вре­ме­ни. Бла­го­да­ря это­му они мо­гут быть как ме­ха­низм син­хро­ни­за­ции, при­мер­но как mutex в тра­ди­ци­он­ном мно­го­по­точ­ном про­грам­ми­ро­ва­нии.

Создание очередей

Ес­ли вы хо­ти­те ис­поль­зо­вать поль­зо­ва­тель­скую оче­редь, ее пред­ва­ри­тель­но нуж­но со­здать. Для это­го про­сто вы­зо­ви­те функ­цию dispatch_queue_create. Пер­вый па­ра­метр — мет­ка, ко­то­рая ис­поль­зу­ет­ся ис­клю­чи­тель­но в це­лях от­лад­ки. Apple ре­ко­мен­ду­ет ис­поль­зо­вать «об­рат­ное DNS» име­но­ва­ние для со­зда­ния уни­каль­ных имен, на­при­мер, «com.​yourcompany.​subsystem.​task». Эти име­на бу­дут отоб­ра­жать­ся в про­то­ко­лах оши­бок при сбое и мо­гут быть по­лу­че­ны из от­лад­чи­ка, что очень по­мо­га­ет по­нять, что пошло не так. Вто­рой ар­гу­мент функ­ции не под­дер­жи­ва­ет­ся и в на­сто­я­щий мо­мент ту­да нуж­но пе­ре­да­вать NULL.

Передача заданий в очередь

Пе­ре­да­ча за­да­ния в оче­редь очень про­ста. Нуж­но вы­звать функ­цию dispatch_async и пе­ре­дать ей оче­редь и блок. Оче­редь вы­пол­нит блок, ко­гда смо­жет. Вот при­мер ис­пол­не­ния дли­тель­ной фо­но­вой ра­бо­ты в гло­баль­ной оче­ре­ди:

dispatch_async воз­вра­ща­ет управ­ле­ние сра­зу же, а блок бу­дет про­дол­жать вы­пол­не­ние асин­хрон­но в фоне.

Ко­неч­но, вы­зы­вать NSLog по­сле окон­ча­ния ра­бо­ты бло­ка не ин­те­рес­но. Обыч­но вам нуж­но об­но­вить что-​то в Cocoa-​ин­тер­фей­се, то есть вы­пол­нить ка­кой-​то код в глав­ном по­то­ке. Это мож­но сде­лать, ис­поль­зуя на­сле­ду­е­мые по­сыл­ки, то есть по­сыл­ку в глав­ную оче­редь внут­ри за­да­чи, вы­пол­ня­е­мой в фо­но­вой оче­ре­ди. При­мер­но вот так:

Та­к­же есть функ­ция dispatch_sync, ко­то­рая де­ла­ет то же са­мое, но при этом ожи­дая, по­ка блок за­вер­шит ис­пол­не­ние пе­ред тем, как вер­нуть управ­ле­ние. Вме­сте с ти­пом __block, это мо­жет быть ис­поль­зо­ва­но для по­лу­че­ния воз­вра­ща­е­мо­го зна­че­ния из вы­пол­нен­но­го бло­ка. На­при­мер, ес­ли у вас есть ка­кой-​то код, ис­пол­ня­ю­щий­ся в фо­но­вом по­то­ке (или, еще луч­ше ска­зать, не глав­ной оче­ре­ди по­сы­лок), ко­то­рый дол­жен по­лу­чить зна­че­ние из GUI-​кон­тро­ла. Это мо­жет быть лег­ко сде­ла­но при по­мо­щи функ­ций dispatch_sync и dispatch_get_main_queue:

// use stringValue in the background now
Прав­да, воз­мож­но, луч­ше все-​та­ки ис­поль­зо­вать асин­хрон­ный стиль на­пи­са­ния ко­да. То есть вме­сто син­хрон­но­го вы­зо­ва, пе­ре­дать по­сыл­ку в глав­ную оче­редь, ко­то­рая, по­сле за­вер­ше­ния, пе­ре­даст по­сыл­ку об­рат­но в фо­но­вую оче­редь. Код бу­дет при­мер­но вот та­кой:

В за­ви­си­мо­сти от то­го, что вам тре­бу­ет­ся, myQueue мо­жет быть ли­бо поль­зо­ва­тель­ской оче­ре­дью или од­ной из гло­баль­ных оче­ре­дей.

Замена блокировок

Поль­зо­ва­тель­ские оче­ре­ди мо­гут быть ис­поль­зо­ва­ны как ме­ха­низм син­хро­ни­за­ции вме­сто бло­ки­ро­вок (locks). В тра­ди­ци­он­ном мно­го­по­точ­ном про­грам­ми­ро­ва­нии, ес­ли вам необ­хо­ди­мо бы­ло со­зда­вать спе­ци­аль­ные объ­ек­ты, ко­то­рые пред­на­зна­ча­лись для ис­поль­зо­ва­ния в несколь­ких по­то­ках, со­зда­ва­лись спе­ци­аль­ные бло­ки­ров­ки, при по­мо­щи ко­то­рых мож­но бы­ло за­щи­тить до­ступ к та­ко­му об­ще­му объ­ек­ту. Псев­до­код при­ве­ден ни­же:

В GCD пе­ре­мен­ную lock мож­но за­ме­не­нить на ло­каль­ную пе­ре­мен­ную ти­па «оче­редь»: dispatch_queue_t queue;. Что­бы ис­поль­зо­вать оче­редь как ме­ха­низм син­хро­ни­за­ции, оче­редь долж­на быть поль­зо­ва­тель­ской, а не гло­баль­ной, что­бы мож­но бы­ло ее про­и­ни­ци­а­ли­зи­ро­вать при по­мо­щи dispatch_queue_create. По­сле это­го мож­но весь код до­сту­па к об­щим дан­ным внут­ри dispatch_sync или dispatch_async:

Сто­ит от­ме­тить, что оче­ре­ди по­сы­лок ис­клю­чи­тель­но лег­ко­вес­ны, по­это­му ис­поль­зо­ва­ние их в ка­че­стве ме­ха­низ­ма бло­ки­ров­ки пол­но­стью оправ­да­но.
В этом ме­сте вы, долж­но быть, ду­ма­е­те, что это все хо­ро­шо, но в чем смысл? Мы пе­ре­шли с од­но­го ме­ха­низ­ма на дру­гой, ко­то­рый вы­гля­дит при­мер­но та­к­же. За­чем? До­сто­инств у ме­ха­низ­ма GCD несколь­ко:

• Па­рал­ле­лизм. По­смот­ри­те, как -setSomething ис­поль­зу­ет dispatch_async во вто­рой вер­сии ко­да. Это обо­зна­ча­ет, что вы­зов из -setSomething тут же вер­нет управ­ле­ние и вся осталь­ная ра­бо­та бу­дет вы­пол­не­на в фоне. Это мо­жет быть су­ще­ствен­ным вы­иг­ры­шем, ес­ли updateSomethingCaches — за­трат­ная опе­ра­ция, в то вре­мя, как вы­зы­ва­ю­щая функ­ция то­же долж­на бу­дет вы­пол­нить что-​то объ­ем­ное.
• Без­опас­ность. Невоз­мож­но слу­чай­но на­пи­сать код, ко­то­рый нераз­бло­ки­ру­ет объ­ект, пред­ва­ри­тель­но его за­бло­ки­ро­вав. В тра­ди­ци­он­ном под­хо­де до­ста­точ­но лег­ко, на­при­мер, по­ста­вить ка­кой-​ни­будь return внутрь ме­то­да, тем са­мым оста­вив бло­ки­ров­ку в «под­ве­шен­ном» со­сто­я­нии.
• Кон­троль. Воз­мож­ность при­оста­но­вить и воз­об­но­вить вы­пол­не­ние за­да­ний в оче­ре­дях от­сут­ству­ет при ис­поль­зо­ва­нии тра­ди­ци­он­ных бло­ки­ро­вок. Та­к­же от­сут­ству­ет воз­мож­ность кон­тро­ли­ро­вать при­о­ри­тет вы­пол­не­ния за­дач «внут­ри» бло­ки­ро­вок и ис­пол­не­ния там же ко­да в дру­гих по­то­ках (на­при­мер, в глав­ном по­то­ке, ес­ли это необ­хо­ди­мо).
• Ин­те­гра­ция. Со­бы­тий­ная си­сте­ма GCD ин­те­гри­ру­ет­ся с оче­ре­дя­ми со­бы­тий. Лю­бые со­бы­тия или тай­ме­ры, ко­то­рые нуж­ны объ­ек­ту, мо­гут быть пе­ре­на­прав­ле­ны в оче­редь это­го объ­ек­та, та­ким об­ра­зом за­ста­вив их там вы­пол­нять­ся, то есть, ав­то­ма­ти­че­ски «син­хро­ни­зи­ру­ясь» с объ­ек­том.

Заключение

Те­перь вам из­вест­ны ос­но­вы GCD, про­це­ду­ра со­зда­ния оче­ре­дей, как от­прав­лять за­да­ния в оче­ре­ди и как их ис­поль­зо­вать для син­хро­ни­за­ции вме­сто мно­го­по­точ­ных бло­ки­ро­вок. В сле­ду­ю­щей ча­сти бу­дут по­ка­за­ны тех­ни­ки ис­поль­зо­ва­ния GCD для уве­ли­че­ния про­из­во­ди­тель­но­сти мно­го­ядер­ных си­стем. А по­том зай­мем­ся еще бо­лее глу­бо­ким ана­ли­зом GCD, вклю­чая си­сте­му со­бы­тий и пла­ни­ро­ва­ние оче­ре­дей.

Ресурсы

Ори­ги­нал ста­тьи: Intro to Grand Central Dispatch, Part I: Basics and Dispatch Queues

Чтоб отслеживать версию репозитория нам нужно добавить слдеющий код bash скрипта.

Чтоб добавить скрипт, необходимо выполнить следующие действия:
1. Зажать Ctrl+клик на фаил проекта в дереве проекта
2. Add->New Build Phase -> New Run Script Build Phase
3. Откроется окно в которое нужно вставить скрипт.

В самом проекте, пример на сплеш скрине, создаем лейбл и читаем версию программы к примеру как-то так.

Существует и второй вариант, более простой. (На самом деле можно придумать еще много разных способов.) Добавляем следующий bash скрипт в проект и добавляем фаил revision.h.

Желательно фаил вставить в один какой-то дальний хидер, чтоб при компилировании не пересобирался весь проект.

Для этого варианта можно написать что-то типа этого:

Но часть плейлистов осталась на iPhone! И их то мы и востановим.

Востановив Mac OS X и iTunes, вкинул всю музыку в iTunes снова.

Подключил iPhone и сделал export плейлиста.

В формате xml:

Далее сделал import

Готово! Плейлист востановлен! Мелочь, а приятно, что не нужно опять перебирать музыку.