Есть ограничение, максимум 100 зарегистрированных девайсов на одну учетную запись в год, обычно этого более чем достаточно
Справедливости ради, сейчас 100 девайсов одного типа (Apple TV, Apple Watch, iPhone, iPad, iPod Touch). Т.е., например, можно зарегистрировать 100 iPhone и 100 iPad.
Хорошо бы рассмотреть варианты в контексте использования size class'ов.
Ну и не забыть про такой важный момент как наглядность верстки.
Считаю, что нужно отталкиваться от задачи. Начинать однозначно со storyboard/xib. Autolayout'ы использовать в коде, когда есть необходимость (а такое, конечно, бывает). На фреймы переходить только в крайнем случае, исключительно для повышения производительности.
Раньше id возвращался, теперь __kindof UITableViewCell *. Последнее более точно передает смысл и помогает компилятору выявлять ошибки. Если бы возвращался просто UITableViewCell, то нужно было бы делать приведение типов каждый раз, когда нужна кастомная ячейка.
Я тоже с этим столкнулся уже больше недели назад. Написал в поддержку — вроде знают о проблеме, но когда исправят не обозначили. Так что джунглями сейчас не получается пользоваться…
Значение, которое привело вас к «Остался последний шаг» нужно трансформировать. Посмотрите на клавиатуру (это первый маленький шаг) и вспомните какие символы может содержать ответ (это второй маленький шаг)
Повторюсь проблема в том, что мы имея до конца не созданный объект, вызываем некоторые методы, которые в общем случае (кроме случая, когда метод написан специально для инициализации) полагают, что объект уже полностью готов. Кроме того если в потомке такой метод будет переопределен, то сам потомок может быть не готов к тому, что его вызовут раньше (до того как сам потомок начнет инициализацию). Как раз последнее и хотел показать Yan169, если я правильно понял.
И, как я уже писвл выше, на момент init'а объект уже является полноценным, нет никакого «подвешенного» состояния.
Думаю, неправильно говорить, что на момент вызова init объект является полноценным, поскольку его поля не инициализированы и в этом кроется проблема. Скажем, если в некотором сеттере или другом вызываемом методе идет обращение к другому ivar или property, которое еще не инициализировано, это может привести к неожиданному поведению. (более сложный случай, когда есть переопределение сеттера в потомке с обращением к другому неинициализированному полю) Без примеров, поскольку у меня нет цели вас переубедить :)
О том, что догрузка прекратится, если убить приложение самостоятельно, несколько раз упоминали в докладе «What’s New with Multitasking» на WWDC 2013 (5 минута 10 секунда и 50 минута 10 секунда):
Also, users will be able to swipe up to remove applications, and so just as before in iOS 6, that will stop the application from running but now in iOS 7, it will also stop that application from running in the background.
And we've made this consistent across a number of APIs, but you guys should be aware that that is what's that will be what's happening when the application is removed.
If the user removes your application from app switcher, your application will no longer run until it's then relaunched by the user.
So if your you know, you get feedback from users of saying, «Hey, I removed it and then I was expecting update.» This why.
Скоро выходит книга Remote, от 37signals, посвещенной данной теме. Уверен, она будет полезна всем, у кого есть фобия удаленной работы (т.е. как сотрудникам, так и руководителям).
Аналогично, столкнулся с этим пунктом в своем приложении.
Тоже подумал, что не повезло с ревьювером, поэтому подавал апелляцию через эту форму. В итоге сказали, что реджект справедлив, но предложили просто добавить новый функционал, которого нет в книгах.
Сделал отправку стихотворений из приложения и шаринг в социальные сети (в частности в vk) и отправил новую версию — пропустили (правда дня два рассматривали). Следующий релиз был в состоянии «In Review» совсем недолго.
Для Apple ID не получится использовать совсем слабый пароль, т.к. там ограничения весьма жесткие support.apple.com/kb/HT4232 (8 символов, буквы в двух регистрах, цифры и другие правила). А вот на включение в телефон либо не используют пароль (вроде половина пользователей), либо используют тривиальные.
Подскажите, пожалуйста, понятно ли из описания тут и/или на сайте отличия Glazum от Apptentive? Или пока создается ощущение, что это клон? Спрашиваю для того, чтобы разобраться, на что нужно делать упор в описании.
Вы пользовались опросами Apptentive?
Удалось ли вам посмотреть Glazum? Видите ли вы пользу от его использования для себя?
Простите, что задаю там много вопросов, ваши ответы них были бы крайней полезны для нас. Заранее спасибо!
Кстати, по моему мнению, Glazum легко можно использовать и с Apptentive, его вообще можно с чем угодно использовать, если есть простая необходимость задавать вопросы пользователям.
Apptentive — это эволюция кнопки сбора фидбэка. Glazum предлагает совершенной другой user experience и соответственно позволяет решать другие проблемы.
Вы используете Apptentive или подобный сервис?
Со строками языка в качестве ключей есть проблема: одна строка на английском может по-разному переводиться на другой язык в зависимости от контекста.
Справедливости ради, сейчас 100 девайсов одного типа (Apple TV, Apple Watch, iPhone, iPad, iPod Touch). Т.е., например, можно зарегистрировать 100 iPhone и 100 iPad.
IBInspectable или задавать через user defined runtime attributes (как собственно IBInspectable и работает)
Тема, конечно, холиварная, но раскрыта поверхностно. Вот немного еще по теме www.raywenderlich.com/51992/storyboards-vs-nibs-vs-code-the-great-debate
Хорошо бы рассмотреть варианты в контексте использования size class'ов.
Ну и не забыть про такой важный момент как наглядность верстки.
Считаю, что нужно отталкиваться от задачи. Начинать однозначно со storyboard/xib. Autolayout'ы использовать в коде, когда есть необходимость (а такое, конечно, бывает). На фреймы переходить только в крайнем случае, исключительно для повышения производительности.
Разве это не означает, что будет использована любая версия >= 1.7.5 и < 1.8?
В CocoaPods так:
В RubyGems тоже:
Думаю, неправильно говорить, что на момент вызова init объект является полноценным, поскольку его поля не инициализированы и в этом кроется проблема. Скажем, если в некотором сеттере или другом вызываемом методе идет обращение к другому ivar или property, которое еще не инициализировано, это может привести к неожиданному поведению. (более сложный случай, когда есть переопределение сеттера в потомке с обращением к другому неинициализированному полю) Без примеров, поскольку у меня нет цели вас переубедить :)
Ссылка по теме на старую статью в блоге Майка Эша.
Тоже подумал, что не повезло с ревьювером, поэтому подавал апелляцию через эту форму. В итоге сказали, что реджект справедлив, но предложили просто добавить новый функционал, которого нет в книгах.
Сделал отправку стихотворений из приложения и шаринг в социальные сети (в частности в vk) и отправил новую версию — пропустили (правда дня два рассматривали). Следующий релиз был в состоянии «In Review» совсем недолго.
Вы пользовались опросами Apptentive?
Удалось ли вам посмотреть Glazum? Видите ли вы пользу от его использования для себя?
Простите, что задаю там много вопросов, ваши ответы них были бы крайней полезны для нас. Заранее спасибо!
Кстати, по моему мнению, Glazum легко можно использовать и с Apptentive, его вообще можно с чем угодно использовать, если есть простая необходимость задавать вопросы пользователям.
Вы используете Apptentive или подобный сервис?