Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 13
Главное не увлекаться, и не забывать iOS Human Interface Guidelines:
Start InstantlyЛадно если приложению действительно нужно при запуске обработать что-то «тяжёлое», но если простенький калькулятор при открытии показывает 5-секундную заставку…
Display a launch image that closely resembles the first screen of the app. This practice decreases the perceived launch time of your app.
Avoid displaying an About window or a splash screen. In general, try to avoid providing any type of startup experience that prevents people from using your app immediately.
Абсолютно с Вами согласен и ни в коем случае не подталкиваю использовать данную механику в каждом приложении, даже наоборот. Просто часто с «верхов» приходят «хотелки», которые приходится реализовывать, и лучше когда это делается логично, нежели чем костылями.
Поэтому:
Автор топика не несёт ответственности за нарушение iOS HIG, а так же любых других сводов разумных правил. Ни одного приложения при написании статьи не пострадало и не получило reject:)
Поэтому:
Автор топика не несёт ответственности за нарушение iOS HIG, а так же любых других сводов разумных правил. Ни одного приложения при написании статьи не пострадало и не получило reject:)
С другой стороны, раздражает, когда аппликуха показывает «картинку похожую на первый экран», на которой нельзя ничего ткнуть потому что сама аппликуха еще прогружается.
Читал как-то давно уже про хак со сплэш-скрином, когда в Info.plist делается указание не на реальный файл, а на несуществующий файл в /Documents приложения, а приложение во время работы делает и сохраняет по этой ссылке скриншоты себя. В итоге, при первом запуске — черный экран, а при всех дальнейших — экран последнего состояния, то есть так, как работают системные приложения iOS — почта, калькулятор… Только вот для реализации этого всего надо еще озаботиться и реализовать процедуру восстановления последнего состояния приложения после рестарта.
Вот она:
habrahabr.ru/post/119593/
А по поводу сохранения состояния — у фейсбука даже есть кусок фреймворка под это дела (правда, имхо не юзабельный):
three20.info/showcase/persistence
habrahabr.ru/post/119593/
А по поводу сохранения состояния — у фейсбука даже есть кусок фреймворка под это дела (правда, имхо не юзабельный):
three20.info/showcase/persistence
Мне было лень создавать отдельный view controller, поэтому прямо в делегате приложения, в
я сделал такую штуку:
и туда же добавил
В итоге вышло, что после того, как сплэш отыграл свое, я показываю прогресс, ну а уж потом появляется первый по логике работы view controller.
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptionsя сделал такую штуку:
UIImage *backImg;
if ([UIScreen mainScreen].scale > 1.0 && self.window.bounds.size.height > 480)
{
backImg = [UIImage imageNamed:@"Default-568h"];
} else
{
backImg = [UIImage imageNamed:@"Default"];
}
UIImageView *background = [[UIImageView alloc] initWithImage:backImg];
[self.window addSubview:background];и туда же добавил
UIActivityIndicatorViewВ итоге вышло, что после того, как сплэш отыграл свое, я показываю прогресс, ну а уж потом появляется первый по логике работы view controller.
Да, это классический способ создания таких вещей и имеет место существовать.
Просто я не люблю «засорять» AppDelegate, а так же очень люблю Storyboard и стараюсь по максимуму использовать его возможности, а так же расширять их. Я визуалист и стараюсь по-максимуму использовать доступные средства визуализации, чтобы видеть то, что я делаю, и появления Storyboard я ждал очень давно:)
Просто я не люблю «засорять» AppDelegate, а так же очень люблю Storyboard и стараюсь по максимуму использовать его возможности, а так же расширять их. Я визуалист и стараюсь по-максимуму использовать доступные средства визуализации, чтобы видеть то, что я делаю, и появления Storyboard я ждал очень давно:)
А не было ли у кого опыта работы с отображением видео «вместо» сплеша? Просто в свое время хотел отдать игру паблишеру он прислал видео и попросил проигрывать в начале, но я тогда забил и так до конца и не разобрался как проигрывать видео, никак не мог при начале воспроизведения скрыть кнопки плеера.
PS По теме могу только сказать, что лучше поддерживать 4.3, еще очень актуально для любого уважающего себя приложения.
PS По теме могу только сказать, что лучше поддерживать 4.3, еще очень актуально для любого уважающего себя приложения.
Думаю Вам поможет вот эта ссылка и конкретно:
А про 4.3 — у Apple политика «хочешь получить новую версию продукта на всех устройствах — добавь решающие функции, недоступные на предыдущих платформах», я понимаю, что это в какой то степени плохо, но я стараюсь прислушиваться заветов монастыря, в который пришёл. В какой то степени ARC и Storyboard — это инструментарий любого уважающего себя программиста:)
mMoviePlayer.controlStyle = MPMovieControlStyleNone;
А про 4.3 — у Apple политика «хочешь получить новую версию продукта на всех устройствах — добавь решающие функции, недоступные на предыдущих платформах», я понимаю, что это в какой то степени плохо, но я стараюсь прислушиваться заветов монастыря, в который пришёл. В какой то степени ARC и Storyboard — это инструментарий любого уважающего себя программиста:)
ARC — неотимизированный код и во многих случаих им пользуються те кто не знает как устроена memory management, писать с ARC вам никто не мещает и под 4.3 насчет стори-бордов не могу сказать, так как точно не знаю. В реальных проектах надо поддерживать 4.3 так как очень много клиентов не обновляют прошивку — ознакомтесь со статистикой. И политика Apple тут совсем не при чем. И вообщем-то мне совсем непонятно к чемы вы написали эту фразу «хочешь получить новую версию продукта на всех устройствах — добавь решающие функции, недоступные на предыдущих платформах».
ARC на оптимизированность кода напрямую никак не влияет, на самом деле. Зато я встречал проекты, где повсюду было [[[SomeClass alloc] init] autorelease], и я думаю Вы осведомлены, какой результат даёт такой код.
Статистику я неплохо знаю, про 10-15% 4.3 слышал, но в собственных проектах я могу себе позволить их игнорировать, ибо это ускоряет разработку приложений раза в 2.
А по поводу политики Apple — попробуйте Xcode 4.2 поставить на 10.6. Ну и тому подобное:)
Статистику я неплохо знаю, про 10-15% 4.3 слышал, но в собственных проектах я могу себе позволить их игнорировать, ибо это ускоряет разработку приложений раза в 2.
А по поводу политики Apple — попробуйте Xcode 4.2 поставить на 10.6. Ну и тому подобное:)
Вызывающе неверная информация.
ARC местами производит даже более оптимальный код, чем ручное управление памятью.
Пример 1: в ручном управлении памятью Вы явно посылаете сообщения retain/release объектам, ARC же вставляет не посылку сообщений, а прямой вызов objc_release/objc_retain. Это как минимум быстрее чем посылка сообщений (т.к. это прямой вызов, без поиска метода, соответствующего селектору).
Пример 2: в ручном управлении памятью прежде чем вернуть объект как результат метода обычно делается autorelease. В вызывающем коде обычно сразу же после возврата объекта делается ему retain. ARC за счет хитрого рантайм-анализа стека вызовов и наличия в функциях вверх по стеку дальнейшего вызова retain, он 1) не вызывает autorelease 2) выставляет флаг, превращающий retain в caller'е в nop. Т.е. вот это вот передергивание retain -> autoreleae -> retain исключается.
Пример 3: реализация autorelease pools под ARC.
Подробности: www.mikeash.com/pyblog/friday-qa-2011-09-30-automatic-reference-counting.html
ARC местами производит даже более оптимальный код, чем ручное управление памятью.
Пример 1: в ручном управлении памятью Вы явно посылаете сообщения retain/release объектам, ARC же вставляет не посылку сообщений, а прямой вызов objc_release/objc_retain. Это как минимум быстрее чем посылка сообщений (т.к. это прямой вызов, без поиска метода, соответствующего селектору).
Пример 2: в ручном управлении памятью прежде чем вернуть объект как результат метода обычно делается autorelease. В вызывающем коде обычно сразу же после возврата объекта делается ему retain. ARC за счет хитрого рантайм-анализа стека вызовов и наличия в функциях вверх по стеку дальнейшего вызова retain, он 1) не вызывает autorelease 2) выставляет флаг, превращающий retain в caller'е в nop. Т.е. вот это вот передергивание retain -> autoreleae -> retain исключается.
Пример 3: реализация autorelease pools под ARC.
Подробности: www.mikeash.com/pyblog/friday-qa-2011-09-30-automatic-reference-counting.html
KysokZla,
>ARC — неотимизированный код и во многих случаих им пользуються те кто не знает как устроена memory management
Не хотелось бы вас расстраивать, но вы, кажется, не понимаете суть ARC. Это не сборщик мусора. И если следовать Cocoa naming conventions код не будет отличаться от кода с ручным управлением памятью.
Storyboards только с iOS 5.
>ARC — неотимизированный код и во многих случаих им пользуються те кто не знает как устроена memory management
Не хотелось бы вас расстраивать, но вы, кажется, не понимаете суть ARC. Это не сборщик мусора. И если следовать Cocoa naming conventions код не будет отличаться от кода с ручным управлением памятью.
Storyboards только с iOS 5.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Хитрости разработчика под iOS. Splash Screen