Пользуюсь бетой. Очень удобно, когда тебе неясно куда уехала вью, или когда тебе дают на поддержку новый большой проект и мало времени чтобы разобраться в том как устроена архитектура вью контроллеров и где какие вью.
Могу рассказать про организацию тестирования в текущем проекте. Вообще это тема отдельной статьи, поэтому не буду особо вдаваться в причины выбора решений, можно в комментариях пояснить.
Мы разрабатываем iOS приложение соц. сеть, причем сервера своего нет, используем Parse.com
Были написаны интеграционные тесты с помощью SenTestingKit, которые тестируют некоторую бизнес логику приложения и код выполняющийся на сервере. Так же есть юнит тесты. Подняли сервер hudson-ci.org, который берет последний код с git, и запускает sh скрипты, которые запускают тесты. Для запуска тестов и красивого отображения логов используем xtool github.com/facebook/xctool
Так же есть скрипт, который мержит(что может) production с development.
Недавно подключился тестировщик для ручного тестирования.
Написал коллегам про appthwack.com, потому что раньше о таком не слышал. И сразу возник вопрос про NDA. Я нашел упоминание об этом appthwack.com/customeragreement в пункте: 11. CONFIDENTIAL INFORMATION
На сколько я понял, они пишут, о том что прилагают все усилия для сохранения конфиденциальности информации имеющей коммерческую ценность, бла, бла, бла, что так же включает подписание их сотрудниками NDA. А вы таким вопросом задавались? Сталкивались со страхом заказчика передавать билд приложения кому-то другому или заказчики обычно не знают таких деталей? :)
Надеюсь Apple будет добавлять поддержку большего числа методов. Только что решил два кейса через UIAppearance для UINavigationBar и задумался о кастомном UIToolBar, потому что выглядит как костыль:
кейс 1
заменить кнопку Back на маленькую картинку:
resizableImageWithCapInsets нужен для того чтобы нам не отресайзило картинку криво (фактически ее ресайзить не надо, но поскольку это bg image, то она растягивается по умолчанию)
кейс 2
убрать текст с кнопки Back (по дизайну не надо)
When accessing the x, y, width, or height of a CGRect, always use the CGGeometry functions instead of direct struct member access. From Apple's CGGeometry reference:
All functions described in this reference that take CGRect data structures as inputs implicitly standardize those rectangles before calculating their results. For this reason, your applications should avoid directly reading and writing the data stored in the CGRect data structure. Instead, use the functions described here to manipulate rectangles and to retrieve their characteristics.
For example:
CGRect frame = self.view.frame;
CGFloat x = CGRectGetMinX(frame);
CGFloat y = CGRectGetMinY(frame);
CGFloat width = CGRectGetWidth(frame);
CGFloat height = CGRectGetHeight(frame);
Not:
CGRect frame = self.view.frame;
CGFloat x = frame.origin.x;
CGFloat y = frame.origin.y;
CGFloat width = frame.size.width;
CGFloat height = frame.size.height;
Спасибо! Хотя тут сплошные синглтоны, но для быстрой разработки маленьких проектов пойдет — я сам так делал.
Снипет для синглтону сразу режет глаз. Уже давно пользуюсь потокобезопасным определением синглтона через GCD:
Последний загружает в себя наш тестовый бандл, находит там классы-наследники SenTestCase и дергает за метод setUp в начале, tearDown в конце, а между ними он вызывает все методы, название которых начинается со слова «test».
Маленькое уточнение.
setUp и tearDown вызываются до и после выполнения КАЖДОГО метода название которого начинается со слова «test»
Вот пруф:
ну они не вдавались в подробности, сами понимаете :) просто сказали что это типа симулятора самолета с множеством экранов, где отображается информация с большой fps и им важно чтобы они работали синхронно и быстро.
Да, я тоже был впечатлен, когда узнал что за движок написали ребята из Томска. Кстати их технологии используют на симуляторах у военных, а у видео карт nvidia и intel есть даже оптимизация под их бенчмарки. Я бы не сказал что им ни чего не светит :)
У меня самого такая проблема была, тут еще важно учитывать психологию. Организму достаточно употреблять пищу 3-4 раза в день, а если вы поглощены работой, то можно даже забыть про эту потребность. Я за собой заметил, что я часто ел, потому что мне не хватало ощущения комфорта. Маслоу называл это потребностью в безопасности :) За этим, на самом деле, в большинстве случаев стоит психологический фактор, и потом это становиться привычкой. Нужно покопаться в себе.
Если часто есть, это приводит к нарушению секреции желудочного сока, желчи, и прочих жидкостей необходимых для пищеварения. У вас нарушается режим и этих жидкостей либо мало, либо много(изжога, отрыжка), либо они находятся в желудке без пищи(гастрит, язва).
Для того чтобы отвыкнуть от этого действительно хорошо использовать воду. Вот несколько более точных рекомендаций:
1) Выпивайте не больше одного стакана воды каждые пол часа.
2) Добавляйте в воду немного лимона и соли(совсем чуть чуть). Обычная вода это хорошо, но с лимоном и солью полезнее :)
3) Не пейте за 1 час до и 1 час после еды и во время, чтобы не уменьшать огонь пищеварения
Да, написать можно было больше и конкретно про getter и setter, но мне показалась интересной информация о том где мы используем префикс get, хотя казалось бы логичным использовать его для getter'а. Возможно это не так важно как информация о @property/@synthesize, но я не ставил целью собирать важную информацию — она есть везде. Я хотел в одном месте собрать интересные и полезные факты.
К сожалению, на мой призыв добавить другие факты в комментариях ни кто не отозвался.
Вот вы написали про get/set — а кто мне мешает самому написать свой getter для любого объекта/переменной?
Извиняюсь, не понял вопроса. Ни кто не мешает. Я написал: «Слово get в Cocoa имеет особый смысл: в имени метода Cocoa оно обозначает, что метод возвращает значение посредством указателя, переданного в качестве параметра.»
Поэтому не стоит его использовать в других случаях, если вы конечно не хотите запутать программистов, которые будут читать ваш код.
Хотелось бы понять границу применимости unit тестов. Тут отметили, есть уже готовые инструменты от Apple для автоматизированного тестирования UI в Instruments (UI Automation tests). Было бы круто услышать чем нужно тестировать интерфейс(например, как можно автоматически, за раз протестировать перемещение по всем вью контроллерам и нажатие всех кнопок, мультитачи, смену ориентации), чем дату, чем связи между классами и т.д.
Можно попробовать поработать с коворкерами — снимать квартиру, так проще самоорганизоваться. Еще у тех кто работает дома один, теряется частично социализация и потом сложно будет работать с людьми. Поэтому нужно общаться с людьми в живую.
Мы разрабатываем iOS приложение соц. сеть, причем сервера своего нет, используем Parse.com
Были написаны интеграционные тесты с помощью SenTestingKit, которые тестируют некоторую бизнес логику приложения и код выполняющийся на сервере. Так же есть юнит тесты. Подняли сервер hudson-ci.org, который берет последний код с git, и запускает sh скрипты, которые запускают тесты. Для запуска тестов и красивого отображения логов используем xtool github.com/facebook/xctool
Так же есть скрипт, который мержит(что может) production с development.
Недавно подключился тестировщик для ручного тестирования.
Написал коллегам про appthwack.com, потому что раньше о таком не слышал. И сразу возник вопрос про NDA. Я нашел упоминание об этом appthwack.com/customeragreement в пункте: 11. CONFIDENTIAL INFORMATION
На сколько я понял, они пишут, о том что прилагают все усилия для сохранения конфиденциальности информации имеющей коммерческую ценность, бла, бла, бла, что так же включает подписание их сотрудниками NDA. А вы таким вопросом задавались? Сталкивались со страхом заказчика передавать билд приложения кому-то другому или заказчики обычно не знают таких деталей? :)
кейс 1
заменить кнопку Back на маленькую картинку:
resizableImageWithCapInsets нужен для того чтобы нам не отресайзило картинку криво (фактически ее ресайзить не надо, но поскольку это bg image, то она растягивается по умолчанию)
кейс 2
убрать текст с кнопки Back (по дизайну не надо)
When accessing the x, y, width, or height of a CGRect, always use the CGGeometry functions instead of direct struct member access. From Apple's CGGeometry reference:
All functions described in this reference that take CGRect data structures as inputs implicitly standardize those rectangles before calculating their results. For this reason, your applications should avoid directly reading and writing the data stored in the CGRect data structure. Instead, use the functions described here to manipulate rectangles and to retrieve their characteristics.
For example:
Not:
github.com/NYTimes/objective-c-style-guide советую почитать
Снипет для синглтону сразу режет глаз. Уже давно пользуюсь потокобезопасным определением синглтона через GCD:
Маленькое уточнение.
setUp и tearDown вызываются до и после выполнения КАЖДОГО метода название которого начинается со слова «test»
Вот пруф:
Conveniently, you can add a pair of methods to a test suite class that are called before and after each test case method is invoked: setUp and tearDown.Если часто есть, это приводит к нарушению секреции желудочного сока, желчи, и прочих жидкостей необходимых для пищеварения. У вас нарушается режим и этих жидкостей либо мало, либо много(изжога, отрыжка), либо они находятся в желудке без пищи(гастрит, язва).
Для того чтобы отвыкнуть от этого действительно хорошо использовать воду. Вот несколько более точных рекомендаций:
1) Выпивайте не больше одного стакана воды каждые пол часа.
2) Добавляйте в воду немного лимона и соли(совсем чуть чуть). Обычная вода это хорошо, но с лимоном и солью полезнее :)
3) Не пейте за 1 час до и 1 час после еды и во время, чтобы не уменьшать огонь пищеварения
Жду не дождусь бесплатных печенек, тенниса и живого общения с людьми.
К сожалению, на мой призыв добавить другие факты в комментариях ни кто не отозвался.
Но это очень интересно разобраться в чем-то до последнего бита.
Извиняюсь, не понял вопроса. Ни кто не мешает. Я написал: «Слово get в Cocoa имеет особый смысл: в имени метода Cocoa оно обозначает, что метод возвращает значение посредством указателя, переданного в качестве параметра.»
Поэтому не стоит его использовать в других случаях, если вы конечно не хотите запутать программистов, которые будут читать ваш код.