В статье приведены изменения в сравнении с ios 4.1
Для ипада нужно смотреть изменения: 3.2->4.0, 4.0->4.1, 4.1-4.2 (то что в статье и что еще будет дорабатыватся).
Не совсем так :)
По умолчанию все приложения что уходят в бекгаунд — перестают работать (загруженные ресурсы не освобождаются).
Если же разработчику надо — он может указать что некоторые функции должны продолжать работать на фоне. Этих функций пока 3: воспроизведение аудио, работа с gps, voip (в этом режиме не рвутся сетевые соединения).
Придумайте какойнибудь альтернативный способ преобразования тепловой энергии в электрическую :)
Причем чтобы кпд был хотябы приблизительно как у турбин.
И чтобы более менее надежная система получилась…
Другие способы есть (например термопары) но они не настолько эффективны как старый добрый способ :)
Крайности — это всегда крайности :)
ИМХО для стандартных случаев — лучше использовать стандартне подходы.
Для какихто чуть более сложных случаев — свои компоненты (IB тут действительно почти ничем не поможет, хотя опять же расстановку элементов можно сделать там и не перегружать этой инфой код).
В тяжелых ситуациях (например куча кнопок, анимаций и картинок на фоне сложных расчетов) — наверно стоит подумать про OpenGL (тут уж IB почти не при делах).
И это зря. Саппортить проекты построенные не интерфейс билдером — гораздо сложнее.
Особенно если понадобилось поменять, допустим, цвет шрифта или еще какую мелочь, а создатель проекта не удосужился сделать дефайну (или еще чего подобного) для этого.
В этом случае интерфес билдер ускорит подобный фикс в разы :)
Да и в коде меньше хлама в итоге. Остаются только вещи которые действительно связаны с програмированием (локализиция например).
Кроме того работать с дизайнером гораздо проще получается в IB чем постоянно перекомпиливая проект…
З.Ы. Скорость загрузки данных из xib конешне ниже чем кодом, но в большинстве случаев это абсолютно не критично.
Все хотел вам написать про баг с трофеями жирными. Да все руки не доходили :)
Не знаю есть ли сий баг в новой версии клиента (не часто сечас играю).
Вобщем смысл бага в том что после:
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
Шрифт надписи делался жирным. Но для обычного трофея не сбрасывался в не жирный.
В итоге при определенной последовательности жирных/не жирных трофеях получалась бяка (жирный трофей ушел за экран при скролле, после этого взялся из очереди для выползающей снизу ячейки, но фонт там оставался жирный).
Уже 2 года пишу под ифоны. Проблем с дебагом не возникало…
Разве что в случаях когда я юзаю помесь c++ и Objective-c — то чтобы gdb понял с каким языком я работаю — приходится писать в консоли чтонибудь типа: set language c++
А вообще среда разработки XCode tools — это лучшее что я видел (тем более что еще и без дополнительных затрат, кроме покупки мака).
Обжектив-с — не для игр. Говорю как разработчик игр под iphone. Стоимость посылки одной мессаги в обжективе на несколько порядковы выше чем вызов обычной сишной функции.
Такчто либо тратим кучу процессоронго времени на обработку мессаг, или пишем на старом добром с/с++ (обжектив только для обработки событий от юзера, да на всякие менюшки итп).
Я и скрипты тоже часто юзаю :)
Весь вопрос в скорости создания скрипта (на баше, питоне итп).
В автоматоре быстрее получается. Да и очень удобно сделать себе на рабочем столе папку. Кинул в нее картинку — а там уже пвр :)
Автоматор — это просто вещь. Особенно для программера :)
Часто юзаю когда:
1) дизайнер пришлет 100 картинок с элементами дизайна под ифона разрешением 1351х4587. И нужно перегнать в 320х480…
2) Поменять названия 100 файлов :)
3) из 100 картинок сгенерировать консольной коммандой 100 pvr текстур для opengl.
Возможное решение проблемы — изменить стиль вызова функции. Я точно не помню как он зовется (вроде pascal), но его суть такая:
1) Мы в стек заносим параметры
2) Функция делает сове черное дело
3) Перед выходом — сама очищает стек
Т.е. логично сделать проеверку по вершине стека, если после выхода из функции она сместилась — вот тут и кидаем кесепшен или еще чего :)
Для ипада нужно смотреть изменения: 3.2->4.0, 4.0->4.1, 4.1-4.2 (то что в статье и что еще будет дорабатыватся).
По умолчанию все приложения что уходят в бекгаунд — перестают работать (загруженные ресурсы не освобождаются).
Если же разработчику надо — он может указать что некоторые функции должны продолжать работать на фоне. Этих функций пока 3: воспроизведение аудио, работа с gps, voip (в этом режиме не рвутся сетевые соединения).
А так не работает :)
Причем чтобы кпд был хотябы приблизительно как у турбин.
И чтобы более менее надежная система получилась…
Другие способы есть (например термопары) но они не настолько эффективны как старый добрый способ :)
ИМХО для стандартных случаев — лучше использовать стандартне подходы.
Для какихто чуть более сложных случаев — свои компоненты (IB тут действительно почти ничем не поможет, хотя опять же расстановку элементов можно сделать там и не перегружать этой инфой код).
В тяжелых ситуациях (например куча кнопок, анимаций и картинок на фоне сложных расчетов) — наверно стоит подумать про OpenGL (тут уж IB почти не при делах).
Особенно если понадобилось поменять, допустим, цвет шрифта или еще какую мелочь, а создатель проекта не удосужился сделать дефайну (или еще чего подобного) для этого.
В этом случае интерфес билдер ускорит подобный фикс в разы :)
Да и в коде меньше хлама в итоге. Остаются только вещи которые действительно связаны с програмированием (локализиция например).
Кроме того работать с дизайнером гораздо проще получается в IB чем постоянно перекомпиливая проект…
З.Ы. Скорость загрузки данных из xib конешне ниже чем кодом, но в большинстве случаев это абсолютно не критично.
Не знаю есть ли сий баг в новой версии клиента (не часто сечас играю).
Вобщем смысл бага в том что после:
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
Шрифт надписи делался жирным. Но для обычного трофея не сбрасывался в не жирный.
В итоге при определенной последовательности жирных/не жирных трофеях получалась бяка (жирный трофей ушел за экран при скролле, после этого взялся из очереди для выползающей снизу ячейки, но фонт там оставался жирный).
Разве что в случаях когда я юзаю помесь c++ и Objective-c — то чтобы gdb понял с каким языком я работаю — приходится писать в консоли чтонибудь типа: set language c++
А вообще среда разработки XCode tools — это лучшее что я видел (тем более что еще и без дополнительных затрат, кроме покупки мака).
Такчто либо тратим кучу процессоронго времени на обработку мессаг, или пишем на старом добром с/с++ (обжектив только для обработки событий от юзера, да на всякие менюшки итп).
Весь вопрос в скорости создания скрипта (на баше, питоне итп).
В автоматоре быстрее получается. Да и очень удобно сделать себе на рабочем столе папку. Кинул в нее картинку — а там уже пвр :)
Часто юзаю когда:
1) дизайнер пришлет 100 картинок с элементами дизайна под ифона разрешением 1351х4587. И нужно перегнать в 320х480…
2) Поменять названия 100 файлов :)
3) из 100 картинок сгенерировать консольной коммандой 100 pvr текстур для opengl.
news.tut.by/84891.html
1) Мы в стек заносим параметры
2) Функция делает сове черное дело
3) Перед выходом — сама очищает стек
Т.е. логично сделать проеверку по вершине стека, если после выхода из функции она сместилась — вот тут и кидаем кесепшен или еще чего :)