MBPR 15 inch late-2013. Особенно заметно на темплейтах, у меня одинаковые шаблоны допустим для генерации проперти, соответственно я их набираю одинаково) XCode прекрасно успевает, а в AppCode приходится ждать примерно пол секунды — секунду прежде чем шаблон кода прогрузится.
Жестко тормозит, по сравнению с XCode. Возможностей у AppCode конечно больше, рефакторинг и автогенерация кода божественная. Но автокомплит у XCode быстрее, как и практически любой элемент интерфейса.
К сожалению нет, на тестирование беты у меня никогда не хватало времени. Как только выйдет финальный релиз, я обязательно проверю основные баги, и обновлю этот пост.
Речь идет именно об обновлении интерфейса. UITableView обновляет его синхронно, UICollectionView, несмотря на отсутствие каких-либо анимаций — асинхронно.
Я тоже думал изначально датасорс делать отдельным обьектом, но в итоге отказался от данной затеи, все-таки слишком сложная получается архитектура. Для себя я решил данную проблему таким способом — везде, где используется UICollectionView или UITableView, и контроллер достаточно сложный, я просто добавляю DTCollectionViewController как childViewController. А события при необходимости прокидываю через протокол. Таким образом родительский контроллер можно унаследовать от чего угодно.
Статья и не претендует на обучалку, как правильно работать с UICollectionView. Документация же, к сожалению, не содержит ответов на те проблемы, с которыми я неоднократно сталкивался. Я тоже считаю, что костыль — это просто признак того, что разработчик в каком-то смысле сдался, и не нашел корректного и стабильного решения проблемы. Но UICollectionView не оставляет другого выбора. Над некоторыми из проблем, перечисленных в статье, я убил по неделе времени, и не нашел решения лучше, чем описал сейчас.
А самый печальный факт — то, что стабильно работает с UITableView, при абсолютно идентичном использовании — не работает с UICollectionView. Моя библиотека для работы с UITableView — не содержит ни одного костыля в принципе, там все работает стабильно и безошибочно. Хотя архитектура абсолютно идентична тому, что я использую для UICollectionView.
Я согласен, что есть ситуации, когда написание тестов не оправдывает себя. 100% покрытие тестами — это сферический конь в вакууме, такого не бывает практически никогда. Но вообще без них — это перебор.
Заставить разработчика использовать TDD невозможно. Нужно, чтобы сам разработчик понимал плюсы данного подхода. Потому что если требование использовать TDD спускается сверху, вы получите боль, мучения, и совершенно бесполезный набор тестов, пишущийся для галочки. Юнит-тестирование как бронежилет — можно продолжать утверждать, что от выстрела из базуки бронежилет не спасет, а от пуль проще увернуться, но на практике бронежилет спасет вам жизнь =)
Согласен, системные жесты лучше оставлять такие, как они есть. Что характерно, сами Фейсбук уже прибрали это меню из своего приложения, заменив на таб бар =) Теперь у них свайп только с правой стороны экрана. Возможно, меню с левой стороны уже доживает свои последние дни на iOS.
Согласен с вами, однако как это сделать в случае Facebook-style меню, которое по умолчанию открывается именно таким жестом? Это кстати большая проблема данного контрола в iOS 7.
Пара комментариев с точки зрения iOS — разработчика:
1. Выносить информацию о поиске в заголовок наверное не стоит, потому что искать можно по множеству полей, не только по дате и количеству гостей, но и например по рейтингу отелей, или наличию вайфая в номерах. Все эти вещи в заголовке не покажешь. В текущей версии приложения этот элемент выглядит очень плохо, особенно если искать по текущему местоположению.
2. Вам нужно продумать цвет нажатых элементов, например избранное.
3. Свайп с левого края экрана можно отключить в случае необходимости.
Нахожусь в Украине. Российский AppStore, iTunes Store. До открытия AppStore в Украине проблем не было, когда AppStore открыли — российский перестал принимать украинскую карточку. Пришлось создать Qiwi-карточку, продолжаю пользоваться российским аппстором, пока проблем не было.
Насколько быстро работает поиск? Есть мнение, что на большом наборе данных он будет занимать порядочное количество времени, ведь на каждую добавленную букву вы открываете и закрываете базу, прогоняете запрос и полностью перегружаете таблицу.
А самый печальный факт — то, что стабильно работает с UITableView, при абсолютно идентичном использовании — не работает с UICollectionView. Моя библиотека для работы с UITableView — не содержит ни одного костыля в принципе, там все работает стабильно и безошибочно. Хотя архитектура абсолютно идентична тому, что я использую для UICollectionView.
Пара комментариев с точки зрения iOS — разработчика:
1. Выносить информацию о поиске в заголовок наверное не стоит, потому что искать можно по множеству полей, не только по дате и количеству гостей, но и например по рейтингу отелей, или наличию вайфая в номерах. Все эти вещи в заголовке не покажешь. В текущей версии приложения этот элемент выглядит очень плохо, особенно если искать по текущему местоположению.
2. Вам нужно продумать цвет нажатых элементов, например избранное.
3. Свайп с левого края экрана можно отключить в случае необходимости.
А так все здорово, понравилось.
http://www.youtube.com/watch?NR=1&v=LwrNy2lgITY&feature=fvwp
А что делать с такой клавиатурой — не совсем понятно.