Подождите, все проблемы из-за того, что вы не хотите с сервера делать запрос в Apple?
Механизм проверки же такой официальный: покупаем, от apple приходит response, мы его отправляем на свой сервер и со своего сервера его опять отправляем в apple и проверяем, корректно или нет. После этого сервер отвечает клиенту — ОК или нет.
Я не понимаю, как можно выпустить общую ломалку, которая ломает такую проверку :-/
Не, у вас же лочится только для получения статической переменной, а дальнейшая работа идет без лока.
Ок, подписался на твиттер проекта, пишите, если додумаете. Попробую один из следующих проектов запустить на iActiveRecord :)
Самый простой use case: приложение с новостями, синхронизация происходит в фоне — из интернета скачиваем новости в sqlite и уже из sqlite их отображаем.
Sqlite вообще штука однопоточная, нельзя с одним соединением работать из нескольких потоков, если у нас ActiveRecord, значит в сущности хранится ссылка на соединение с БД, так? Получается если мы создали сущность в одном потоке — передать ее в главный и сделать update уже нельзя. Я долго мучился, чтобы это исключить с CoreData, но до сих пор иногда приложение крешится в непонятных местах.
В Яндексе рассказывали, что они в контроллерах сохраняют только id-шники, сущности не хранят, и у них есть специальный менеджер контекстов, который смотрит в каком мы потоке и выдает соответствующий контекст. Еще встает вопрос с изоляцией соединений (если сделали update в одном, когда это увидим во втором).
А вообще у вас как — каждой сущности в БД соответствует только один объект или может быть два объекта, ссылающихся на одну и ту же строку в БД? И у них может быть два разных состояния.
Еще проблема — если мы сохранили сущность в каком-то контроллере, а в фоне (или даже в том же потоке) у нас вообще все сущности из базы удалили. Что будет в вашем ORM? В CoreData креш, и это часто напрягает.
Выглядит удобно! Ставлю +1 за индексы. И теперь главный вопрос: что с основной болью core data — многопоточностью? Если хочу обновлять базу в фоне — как это обрабатывается? Можно ли передавать сущности между потоками?
В нормальном государстве такими случаями должна заниматься полиция, а не служба поддержки опсоса. И уже полиция сможет узнать, скольких именно кинули, какое отношение к этому имеет билайн и т.п. Но это все к сожалению не в России.
Боюсь бабушка-наблюдатель от КПРФ не справится с приложением для андроида. Имхо надо разделить на две независимые части. Камеры работают постоянно без человеческого фактора и пытаются заснять очевидные вбросы. И выпустить отдельно приложения для андроида/айфона, которым будут пользоваться наблюдатели.
Судя по всему будет большое общественное движение по участию в качестве наблюдателей участников митингов, а там практически у всех смартфоны. Нужно что-то придумать, чтобы было удобно скидывать результаты подсчетов (фотографии итоговых протоколов с подписями) и все нарушения в твиттер и в единую базу сразу после фиксации.
Смартфон видимо реально удобнее, чем веб-камера с wifi.
Ага, как раз для этого нужно свойство hidesBottomBarWhenPushed. Просто логически в каждом табе должен быть свой навбар, так корректнее, можно писать [self.navigationController pushViewController...]
Что-то я сомневаюсь, что ВКонтакте таббар лежит внутри navigationController-а. Достаточно выставить hidesBottomBarWhenPushed = YES, когда пушишь в навбар, тогда нижний таббар уедет.
Насколько я понял, ИП без сотрудников в статистику отчитываться не обязан, так что туда идти и не надо. Или у кого-то есть опыт, что справка оттуда понадобилась?
Попробовал нымвыходных пописать приложение с ARC и Storyboard — очень круто. Кода становится гораздо меньше. За два дня и приложение с 10 экранами только один раз написал pushViewController. Да и то, только потому что они не доделали отдельный segue для нажатия на detail accessory в ячейке и пришлось это обрабатывать вручную.
Механизм проверки же такой официальный: покупаем, от apple приходит response, мы его отправляем на свой сервер и со своего сервера его опять отправляем в apple и проверяем, корректно или нет. После этого сервер отвечает клиенту — ОК или нет.
Я не понимаю, как можно выпустить общую ломалку, которая ломает такую проверку :-/
Ок, подписался на твиттер проекта, пишите, если додумаете. Попробую один из следующих проектов запустить на iActiveRecord :)
Sqlite вообще штука однопоточная, нельзя с одним соединением работать из нескольких потоков, если у нас ActiveRecord, значит в сущности хранится ссылка на соединение с БД, так? Получается если мы создали сущность в одном потоке — передать ее в главный и сделать update уже нельзя. Я долго мучился, чтобы это исключить с CoreData, но до сих пор иногда приложение крешится в непонятных местах.
В Яндексе рассказывали, что они в контроллерах сохраняют только id-шники, сущности не хранят, и у них есть специальный менеджер контекстов, который смотрит в каком мы потоке и выдает соответствующий контекст. Еще встает вопрос с изоляцией соединений (если сделали update в одном, когда это увидим во втором).
А вообще у вас как — каждой сущности в БД соответствует только один объект или может быть два объекта, ссылающихся на одну и ту же строку в БД? И у них может быть два разных состояния.
Еще проблема — если мы сохранили сущность в каком-то контроллере, а в фоне (или даже в том же потоке) у нас вообще все сущности из базы удалили. Что будет в вашем ORM? В CoreData креш, и это часто напрягает.
Судя по всему будет большое общественное движение по участию в качестве наблюдателей участников митингов, а там практически у всех смартфоны. Нужно что-то придумать, чтобы было удобно скидывать результаты подсчетов (фотографии итоговых протоколов с подписями) и все нарушения в твиттер и в единую базу сразу после фиксации.
Смартфон видимо реально удобнее, чем веб-камера с wifi.
И в ту и в другую сторону? А edge хватает для работы?