Я думаю что реалтайм и постоянная передача данных — разные вещи. В нашем приложении мы используем вебсокет, как раз для реалтайма. А передача данных происходит всего несколько раз в минуту. То есть по расходу батареи мы в этом случае выигрываем, так как не дергаем сервер каждые 5-10 секунд для синхронизации.
Простите, а на чем основано ваше предположение, что вебсокет дорог для батареи? Насколько я знаю, то батарею ест не поддержка постоянного соединения, а количество данных передаваемых через сеть.
Я конечно может что-то не понимаю, но пример реалзиации вебсокета есть прямо в на гитхабе в самой socketroket. И просто показать то, что может одна либа недостойно статьи на хабре. Есть еще куча реализаций этого протокола. Есть Socket-IO. Можно попытаться сделать energy-diagnostic, чтобы показать как классно юзать вебсокеты. А это по сути капитанская статья. То есть надо показать преимущества и недостатки данного подхода к организации работы с сетью. А это тупо пересказ того, что я и так могу найти в интеренете в два клика. Извините, накипело.
Предложеный Вами подход также имеет право на существование. Все зависит от целей, для которых нужен UDID. Вот ссылка на статью, в которой описываются плюсы и минусы разных подходов для получения идентификатора девайса.
Вопросы типа «что такое мьютекс?» нужны, чтобы понять в каких областях человек работал и как глубоко он в них разобрался. А ответ на этот конкретный вопрос надо знать, потому что он из общего программирования.
можно и на objective-c. Cуть — выяснить как человек понимает работу NSAutoreleasePoll. Большинство вопросов провокационных. И цель их — услышать рассуждения. 100% правильного ответа может и не существовать. На своем опыте могу сказать, что после того, как объяснил интервьюверу, как реализовать NSAutoreleasePoll на плюсах, то лучше понял его(NSAutoreleasePoll) работу.
Хабр — для спокойных людей. Всегда будет кто-то, кто, по вашему мнению, ни разу не прав. Однако просим оставить хамство, грубость, переходы на личности и прочие проявления агрессии и неадекватности для других ресурсов — на Хабре это не в почёте.
Об активной/пассивной модели можно почитать тут и тут. Если верить MSDN, то Application Programming in Smalltalk-80: How to use Model-View-Controller (MVC) [Burbeck92], Steve Burbeck — это первоисточник.
В данном примере использован POSIX для отвлечения внимания. Можно с тем же успехом использовать и другие технологии. Мне не приходилось использовать POSIX в проектах, где я учавствовал.
Вот что можно найти в документации по поводу использования POSIX:
Use POSIX calls if cross-platform portability is required. If you are writing networking code that runs exclusively in OS X and iOS, you should generally avoid POSIX networking calls, because they are harder to work with than higher-level APIs. However, if you are writing networking code that must be shared with other platforms, you can use the POSIX networking APIs so that you can use the same code everywhere.
На мой взгляд, чем больше подходов к решению проблемы кандидат может придумать, тем лучше.
Может есть ещё какие, которые необходимо знать?
Я может не смог донести суть статьи до читателей, но я не хотел сказать, что если ты не можешь ответить на все вопросы, то ты не senior. Или что если ты ответил, то ты мегакрут. Суть статьи в том, чтобы показать моменты, на которые стоит обратить внимание перед собеседованием.
Имелась в виду такая ситуация. Есть mutable массив объектов, есть айди объекта, который надо удалить из массива. Как удалить объект с данным айди из массива?
А как еще проверить умение работать? Можно с помощью тестового задания, но я лично, если это не гиганты рынка, отказался бы от его выполнения, дав ссылку на гитхаб, где лежит мой опенсорсный код. Потому что тратить день-два на его выполнение мне не хочется. А задание на 1-2 часа нет смысла давать, потому что оно ничего не покажет. Так что как ни крути, а без технических вопросов на собеседовании никак не обойтись.
Вот что можно найти в документации по поводу использования POSIX:
Я может не смог донести суть статьи до читателей, но я не хотел сказать, что если ты не можешь ответить на все вопросы, то ты не senior. Или что если ты ответил, то ты мегакрут. Суть статьи в том, чтобы показать моменты, на которые стоит обратить внимание перед собеседованием.
Мы же говорим о позиции middle/senior.
Если кандидат умеет это делать в не ARC коде, то под ARC ему это не составить труда.
Изменил на Networking & Multithreading
На полноту обзора всех тем на собеседовании этот топик не претендует. В статье упомянуты вопросы, которые автор получал/задавал на собеседованиях.