Комментарии 8
Вы только, что убили мое делание встроить автообновление в свое приложение…
p.s.
все же было не пролохо куски кодв пост вставить. большие посты есть годные посты.
p.s.
все же было не пролохо куски кодв пост вставить. большие посты есть годные посты.
0
Андрей, а как лучше сделать синхронизацию данных, которые могут изменяться в онлайне и в оффлайне параллельно друг другу. Например, есть документ в онлайне, который мы скачиваем для редактирования в метро. Редактируем в метро, но за это время происходит изменение онлайн версии. Как на ваш взгляд лучше производить синхронизацию в данном случае?
0
Не согласен с реализацией.
1) У вас UpdateManager САМ создает экземпляры updater'ов, т.е. он осведомлен об их реализации, и в тоже время пользуется ими через интерфейс, получается двояко — вроде бы и пользуемся через интерфейс и быть там может все что угодно, но в тоже время сами создаем экземпляры и знаем что там внутри, т.е. зависимость то есть, уместнее было бы настраивать Manager, передавая ему его worker'ов через интерфейс, тогда не было бы никакой связи между реализациями.
2 ) При реализации updater'ов, вы заставляете того кто их пишет заботиться о том чтобы вызвать самостоятельно у manager'а метод «next», и если этого не произойдет — случится коллапс, паровоз не поедет, все застрянет… «Нужно писать так, чтобы легко было пользоваться правильно, и сложно было пользоваться неправильно» (с) не помню кто писал, так вот тут этот принцип явно не в силе получается.
3) Нет никакой индикации о том что процесс завершился и в тоже время если вызвать метод «runUpdateProcess» повторно — то старый Instance просто потеряется(утечет), будет конкурентное обращение к очереди да и вобщем-то скорее всего будет очередной коллапс в тот момент, когда обе задачи попробуют зарелизить instance…
Надеюсь на правильное отношение к критике…
1) У вас UpdateManager САМ создает экземпляры updater'ов, т.е. он осведомлен об их реализации, и в тоже время пользуется ими через интерфейс, получается двояко — вроде бы и пользуемся через интерфейс и быть там может все что угодно, но в тоже время сами создаем экземпляры и знаем что там внутри, т.е. зависимость то есть, уместнее было бы настраивать Manager, передавая ему его worker'ов через интерфейс, тогда не было бы никакой связи между реализациями.
2 ) При реализации updater'ов, вы заставляете того кто их пишет заботиться о том чтобы вызвать самостоятельно у manager'а метод «next», и если этого не произойдет — случится коллапс, паровоз не поедет, все застрянет… «Нужно писать так, чтобы легко было пользоваться правильно, и сложно было пользоваться неправильно» (с) не помню кто писал, так вот тут этот принцип явно не в силе получается.
3) Нет никакой индикации о том что процесс завершился и в тоже время если вызвать метод «runUpdateProcess» повторно — то старый Instance просто потеряется(утечет), будет конкурентное обращение к очереди да и вобщем-то скорее всего будет очередной коллапс в тот момент, когда обе задачи попробуют зарелизить instance…
Надеюсь на правильное отношение к критике…
+5
И как вы эти regexp'ы читаете?)
-2
Можно вообще не заморачиваться с thread-ами и aturorelease pool-ом.
Совсем недавно открыл для себя NSOperationQueue. Доступно с версии 2.0
Эта очередь сама создает тред и выполняет в нем полученную операцию, плюс дает возможность гибкого управления всеми операциями в очереди и уведомления о статусе операций.
Реально удобная вещь.
А начиная с 4.0 еще и Grand Central Dispatch появился, еще больше возможностей для многопоточности, плюс «блоки» они же lambda или enclosure, которые можно напрямую скармливать NSOperationQueue.
Правда написанный с ним софт не будет на старых прошивках работать.
Совсем недавно открыл для себя NSOperationQueue. Доступно с версии 2.0
Эта очередь сама создает тред и выполняет в нем полученную операцию, плюс дает возможность гибкого управления всеми операциями в очереди и уведомления о статусе операций.
Реально удобная вещь.
А начиная с 4.0 еще и Grand Central Dispatch появился, еще больше возможностей для многопоточности, плюс «блоки» они же lambda или enclosure, которые можно напрямую скармливать NSOperationQueue.
Правда написанный с ним софт не будет на старых прошивках работать.
0
dojob — это хорошо звучит, если представить себе что это транслит.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Изменить настройки темы
Обновление контента IPhone приложения