Странно как-то выглядит компонент минимум для iOS 5 и без поддержки ARC.
З.Ы. А со статическим словарём ничего плохого не случится, поскольку ему по дефолту ставится модификатор __strong и жить он подуть вплоть до вызова cleanup или завершения работы приложения.
В том то и дело, что такой индивидуальный подход в нашем меняющемся мире зачастую неудобен. Сегодня контроллер модальный, завтра не модальный. Сегодня вы работате над проектом, завтра пришло 5 джуниоров, послезавтра они целый день дебажат и не могут понять откуда у них BAD_ACCESS. Ведь в чем суть проблемы то? В том, что в поле в определенный момент времени будет хранится мусор. И кто-нибудь, когда-нибудь этот мусор словит.
А реализуя системный подход, который предлагает автор, всего этого можно избежать.
Как раз практика и показывает, что пока не программист не научит себя простым правилам он обречен постоянно иметь проблемы из-за неверного управления памятью. Не один десяток раз я сталкивался с такими на разных проектах.
Вот Вы сами себе противоречите. Говорите что не надо нагромождать сущности, но при этом говорите о дополнительных методах обслуживания. Вы, что при каждом обращении к какой-нибудь вьюшке контроллера проверяете isViewLoaded?
Я так понял, _label это поле класса?
В этом случае данный подход это распространенная ошибка. Заключается она в том, что когда self.view обнулится _label будет содержать мусор. И первое же обращение к этому полю приведет к крешу.
Чтобы этого избежать надо всегда пользоваться простым правилом «поля класса никогда не должны быть авторелизными или заретейнеными не самим классом» (естественно, что week reference исключение отсюда).
А вот еще нашел:
«If the view controller releases its view, it calls its viewDidUnload method. You can override this method to perform any additional cleanup required for your views and view hierarchy» — VC Guide.
Лажа в том, что метод хоть и заявлен парным для viewDidLoad, таковым не является. И когда программист расчитывает на то что его вьюхи созданные в loadView/viewDidLoad будут зарелизены во viewDidLoad, а на практике этого не происходит легко получаем как минимум memory leak после повторного вызова loadView/viewDidLoad.
1. Автор об этом пишет.
2. По чистой логике viewDidUnload является парным методом viewDidLoad. А значит и должен вызываться как минимум по одному разу на каждый вызов viewDidLoad в тречении жизни VC. Это так же подтверждается докой: «This method is called as a counterpart to the viewDidLoad method» VC Reference.
Хотя, нигде не говорится явно, что он должен вызываться когда обнуляется view (но сказано, что если он вызывается то view == nil). Это главная лажа :). Если честно, то Apple тут слажало хорошо. Например, во 2 версии сдк его вообще не было, как и isViewLoaded (вернее они был приватным).
Есть один интересный момент. Я часто наблюдал, что метод viewDidUnload далеко не всегда вызывается, когда обнуляется view контроллера.
Поэтому я всегда перегружаю метод:
[code]
— (void)setView:(UIView) value {
super.view = value;
if (![self isViewLoaded]) {
[self viewDidUnload];
}
}
[/code]
В данном случае важно понимать, что метод viewDidUnload может быть вызван несколько раз и он должен быть написан так, чтобы не возникало багов с этим связанных.
Кстати iTunes на Carbon'е(С) написан (Сафари таки Cocoa(ObjC) использует), по всей видимости в угоду производительности и низкоуровневым (относительно) функциям.
Советую проверить либы в теримнале по подобию:
З.Ы. А со статическим словарём ничего плохого не случится, поскольку ему по дефолту ставится модификатор
__strongи жить он подуть вплоть до вызоваcleanupили завершения работы приложения.- (void)dealloc{
delete impl;
[self dealloc];
}
= stack overflow.
А реализуя системный подход, который предлагает автор, всего этого можно избежать.
Вот Вы сами себе противоречите. Говорите что не надо нагромождать сущности, но при этом говорите о дополнительных методах обслуживания. Вы, что при каждом обращении к какой-нибудь вьюшке контроллера проверяете isViewLoaded?
В этом случае данный подход это распространенная ошибка. Заключается она в том, что когда self.view обнулится _label будет содержать мусор. И первое же обращение к этому полю приведет к крешу.
Чтобы этого избежать надо всегда пользоваться простым правилом «поля класса никогда не должны быть авторелизными или заретейнеными не самим классом» (естественно, что week reference исключение отсюда).
«If the view controller releases its view, it calls its viewDidUnload method. You can override this method to perform any additional cleanup required for your views and view hierarchy» — VC Guide.
Лажа в том, что метод хоть и заявлен парным для viewDidLoad, таковым не является. И когда программист расчитывает на то что его вьюхи созданные в loadView/viewDidLoad будут зарелизены во viewDidLoad, а на практике этого не происходит легко получаем как минимум memory leak после повторного вызова loadView/viewDidLoad.
2. По чистой логике viewDidUnload является парным методом viewDidLoad. А значит и должен вызываться как минимум по одному разу на каждый вызов viewDidLoad в тречении жизни VC. Это так же подтверждается докой: «This method is called as a counterpart to the viewDidLoad method» VC Reference.
Хотя, нигде не говорится явно, что он должен вызываться когда обнуляется view (но сказано, что если он вызывается то view == nil). Это главная лажа :). Если честно, то Apple тут слажало хорошо. Например, во 2 версии сдк его вообще не было, как и isViewLoaded (вернее они был приватным).
а. Ничего не знают.
б. Ничего не знают и много хотят.
З.Ы. А Вы откуда?
Поэтому я всегда перегружаю метод:
[code]
— (void)setView:(UIView) value {
super.view = value;
if (![self isViewLoaded]) {
[self viewDidUnload];
}
}
[/code]
В данном случае важно понимать, что метод viewDidUnload может быть вызван несколько раз и он должен быть написан так, чтобы не возникало багов с этим связанных.