При необходимости оповестить слушателей (targets) мы сначала проверяем существование этого target, затем либо удаляем его из списка, либо дергаем callback.
Вы не можете проверить существование target либо другого объекта, так как при обращении к объекту, который освобожден из памяти, мы получим крэш. Это, если я правильно понял смысл слова «проверяем существование target».
Я предлагал, чтобы target сам добавлялся и удалялся из подписки, когда ему нужно. Обычно это выполняется в методах init и deinit.
Чтобы с несколькими потоками все было гладко, нужно обеспечить потокобезопасный доступ к списку, который хранит слушателей.
Судя по всему аналога atomic в swift нет.
Видел такой вариант реализации потокобезопасности:
Чего у Вас не хватает в классе Dynamic, так это методов: unBind и removeListener.
Иногда ведь нужно отменять подписку не дожидаясь своей смерти (освобождения памяти).
Наличие этих методов также решает проблему weak, unowned в замыканиях (closures), которые используются в качестве коллбэков. Используете unowned, а в методе deinit вызываете removeListener или unBind.
Изначально паттерн Observer подразумевает симметричность вызовов add/remove.
Появляется дополнительная строчка кода, это да, но как по мне, гонясь за локоничностью, Вы можете потерять логичность.
В целом статья хорошая, расширяет понимание возможностей swift.
Не уверен, что понимаю Вас.
Что мы имеем: на девайсе храниться незашифрованная база сообщений (если не ставить пароль на приложение), на сервере храниться зашифрованная база, ключи для дешифровки храниться локально на девайсе. Теперь предположим, что кто-то удаляет приложение у вас с телефона, или ваше устройство умирает и вы покупаете новое. В результате теряем незашифрованную базу и приватные ключи.
Что и как здесь конвертировать?
проблема в том, что как только ты делаешь end-to-end шифрование во всех чатах, то при переустановке приложения, сразу теряешь историю переписки, так как ключ шифрования должен храниться локально на девайсе.
Кто-нибудь может объяснить почему в офисах потолки не декорируют, а выставляют все внутренности наружу?
Раньше работал в Минском в офисе, все было красивенько, уютненько. Сейчас переехал в Штаты, офис оказался примерно как на картинке выше. Находится в таком месте не очень уютно.
Я похожим образом жене предложение делал на Новый год: написал Android приложение в виде ребуса с видео обращением, стихотворением, азбукой Морзе и другими этапами, которые требуют некоторое время на разгадку. Последняя загадка приводила к месту, где было спрятано кольцо. Приложение самому ставить не пришлось — я просто, в качестве подарка, вручил открытку, в которой был qr код, содержащий ссылку на приложение. Жена (QA по профессии) была в восторге.
Первое ограничение, которое у себя ввели Android-коллеги — это неспособность передавать сложные объекты между контроллерами (activity) — для этого дополнительно необходимо обеспечить сериализацию этих объектов.
каждый контроллер должен быть максимально обособленным
Вы здесь связали два несвязанных принципа. То, что нельзя передавать сложные объекты предварительно не реализовав сериализацию, не является посылом к максимальной обособленности контроллеров.
Данные простых типов (String, Integer и т.д) тоже сериализуются при передаче между Activity. Просто о серилизации простых типов подумали разработчики Android, а о кастомных (сложных) типах должен позаботиться разработчик.
Правильным посылом к максимальной обособленности контроллеров, как мне кажется, является принцип вызова Activity через Intent.
Да, предлагают шифровать базу, если указать длинный пароль.
А чем шифруют видимо никто пока не узнает, так последней версии кода, видимо, нет в открытом доступе. Последнюю версию, которую нашел — 2.8. Текущая 2.9.x.
Чем шифрует?
Или теперь пользователю нужно будет вводить какой-то пароль?
Или имеется ввиду стандартное шифрование средствами iOS SDK, когда устройство залочено?
Если внутри замыкания НЕ используется вызов self, то такого подвоха НЕ возникает.
На самом деле отсутствие self не гарантирует отсутствия циклических ссылок.
Например, если вместо self передать другую переменную ссылающуюся на self, то это породит циклические ссылки:
var me: ViewController = self
whatToDo = { println(me.theString) }
Все-таки нужно логически понимать, что происходит в коде.
Вы не можете проверить существование target либо другого объекта, так как при обращении к объекту, который освобожден из памяти, мы получим крэш. Это, если я правильно понял смысл слова «проверяем существование target».
Я предлагал, чтобы target сам добавлялся и удалялся из подписки, когда ему нужно. Обычно это выполняется в методах init и deinit.
Чтобы с несколькими потоками все было гладко, нужно обеспечить потокобезопасный доступ к списку, который хранит слушателей.
Судя по всему аналога atomic в swift нет.
Видел такой вариант реализации потокобезопасности:
Иногда ведь нужно отменять подписку не дожидаясь своей смерти (освобождения памяти).
Наличие этих методов также решает проблему weak, unowned в замыканиях (closures), которые используются в качестве коллбэков. Используете unowned, а в методе deinit вызываете removeListener или unBind.
Изначально паттерн Observer подразумевает симметричность вызовов add/remove.
Появляется дополнительная строчка кода, это да, но как по мне, гонясь за локоничностью, Вы можете потерять логичность.
В целом статья хорошая, расширяет понимание возможностей swift.
Что мы имеем: на девайсе храниться незашифрованная база сообщений (если не ставить пароль на приложение), на сервере храниться зашифрованная база, ключи для дешифровки храниться локально на девайсе. Теперь предположим, что кто-то удаляет приложение у вас с телефона, или ваше устройство умирает и вы покупаете новое. В результате теряем незашифрованную базу и приватные ключи.
Что и как здесь конвертировать?
Как Вы себе это представляете?
Никто ведь не говорит, что Apple рассчитывает на массовый спрос золотой модели, но и пройти мимо они не могли.
Раньше работал в Минском в офисе, все было красивенько, уютненько. Сейчас переехал в Штаты, офис оказался примерно как на картинке выше. Находится в таком месте не очень уютно.
Если они наняли почти столько же людей, сколько там работало, то рост должен все-таки стремится к 100%
Сам уехал в штаты по H1B визе имея диплом БГУ (далеко не топ в мировом рейтинге).
Вы здесь связали два несвязанных принципа. То, что нельзя передавать сложные объекты предварительно не реализовав сериализацию, не является посылом к максимальной обособленности контроллеров.
Данные простых типов (String, Integer и т.д) тоже сериализуются при передаче между Activity. Просто о серилизации простых типов подумали разработчики Android, а о кастомных (сложных) типах должен позаботиться разработчик.
Правильным посылом к максимальной обособленности контроллеров, как мне кажется, является принцип вызова Activity через Intent.
А чем шифруют видимо никто пока не узнает, так последней версии кода, видимо, нет в открытом доступе. Последнюю версию, которую нашел — 2.8. Текущая 2.9.x.
Или теперь пользователю нужно будет вводить какой-то пароль?
Или имеется ввиду стандартное шифрование средствами iOS SDK, когда устройство залочено?
На самом деле отсутствие self не гарантирует отсутствия циклических ссылок.
Например, если вместо self передать другую переменную ссылающуюся на self, то это породит циклические ссылки:
Все-таки нужно логически понимать, что происходит в коде.