Сделать свойства потокобезопасными будет очень накладно: для каждого свойства придется писать какой-то код, который будет выполнять INotifyPropertyChanged на нужном потоке. Производительность тоже надо мерить при таком подходе.
Мутабильные они "by design". Объясню почему. В любой момент с сервера Телеграма может прилететь апдейт — например, пользователь сменил имя или аватарку. Этот апдейт в конечном счете тоже дойдет до контекста, где нужно выполнить смену значения для этого свойства.
Как лучше реализовать все эти кейсы, я не придумал. Если подскажете, буду только рад.
Это правда спорное место. ContactLoader мог бы сам выполнить код на планировщике Avalonia. Преследуется несколько целей: 1) работу с UI-потоком выполнять только из классов Context для простоты и однообразности 2) Дать свободу контексту выполнять обновления в бэкграунде, если сущность не привязана к UI в данный момент.
Люди, вы видимо не читаете англоязычных постов. На английском пишут все: от индусов с китайцами до самих англичан. Даже с моим лимитированным знанием языка, можно постоянно находить ошибки в тексте. Но никто не стесняется, все пишут и общаются.
Не нужен уровень языка, который удовлетворит саму королеву. К грамотности стремиться нужно, но комплексовать не стоит. Если у ребят из ТМ всё получится, то уровень владения языком у русскоязычной аудитории со временем даже подрастет. Удачи ребятам!
Бред. Цивилизованный мир уходит от аутсорса. В современных условиях информационые технологии это ядро бизнеса. Даже американские компании начинают понимать что к чему, и потихоньку перетаскивают разработку в инхаус, несмотря на бОльшие затраты по ЗП.
Со стороны работника продуктовая компания тоже обычно лучше аутсорса.
предоставление доменных имен, оказание услуг хостинга
Означает ли это то, что Amazon, Azure и Google Cloud Platform теперь должны платить налог за размещение приложений, которые ориентированы на российских пользователей или на приложения, которые сделаны в России?
Rider. Возможно, VS for Mac не выполняет инструкцию копирования библиотек в итоговую сборку. Можно попробовать руками скопировать в output: https://github.com/x2bool/egram.tel/blob/master/Egram/libtdjson.dylib
И правда, так намного лучше. Спасибо.
https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet?tabs=netcore2x — всё что нужно там
DNS не прописан. Пока выкладывать туда особо нечего :)
Отлично, спасибо. Писать руками геттеры и сеттеры действительно мало удовольствия. Обязательно попробую.
Сделать свойства потокобезопасными будет очень накладно: для каждого свойства придется писать какой-то код, который будет выполнять INotifyPropertyChanged на нужном потоке. Производительность тоже надо мерить при таком подходе.
Мутабильные они "by design". Объясню почему. В любой момент с сервера Телеграма может прилететь апдейт — например, пользователь сменил имя или аватарку. Этот апдейт в конечном счете тоже дойдет до контекста, где нужно выполнить смену значения для этого свойства.
Как лучше реализовать все эти кейсы, я не придумал. Если подскажете, буду только рад.
Это правда спорное место. ContactLoader мог бы сам выполнить код на планировщике Avalonia. Преследуется несколько целей: 1) работу с UI-потоком выполнять только из классов Context для простоты и однообразности 2) Дать свободу контексту выполнять обновления в бэкграунде, если сущность не привязана к UI в данный момент.
Ну от этого ни куда не деться. Хотя в технических статьях разрыв между родным и неродным языком должен быть минимальным.
Люди, вы видимо не читаете англоязычных постов. На английском пишут все: от индусов с китайцами до самих англичан. Даже с моим лимитированным знанием языка, можно постоянно находить ошибки в тексте. Но никто не стесняется, все пишут и общаются.
Не нужен уровень языка, который удовлетворит саму королеву. К грамотности стремиться нужно, но комплексовать не стоит. Если у ребят из ТМ всё получится, то уровень владения языком у русскоязычной аудитории со временем даже подрастет. Удачи ребятам!
Надеюсь что и хостить контент будете не в России?
Если добавить к названию "Blockchain", то всё становится лучше. Вы не знали?
Бред. Цивилизованный мир уходит от аутсорса. В современных условиях информационые технологии это ядро бизнеса. Даже американские компании начинают понимать что к чему, и потихоньку перетаскивают разработку в инхаус, несмотря на бОльшие затраты по ЗП.
Со стороны работника продуктовая компания тоже обычно лучше аутсорса.
Почему вы утиную типизацию интерфейсов записали в плюсы? Спорный ведь вопрос.
Почему отсутствие выбора это хорошо? На C# можно и наследование и композицию.
Это не магия. Канонический формат доменного имени имеет точку на конце. Для удобства точку практически нигде не используют.
http://www.dns-sd.org/trailingdotsindomainnames.html
А как оно должно знать о жизненном цикле, если это фича языка, а не интеграции с Android?
Реализация не завязана на конкретный тип, такой, как Task. Ну, и то, что async/await это не специальные ключевые слова, а всего лишь функции.
В Kotlin очень чистая реализация async/await, смотрится намного приятнее чем тот же TPL в C#. И для платформы Android это еще одна киллер-фича.
Означает ли это то, что Amazon, Azure и Google Cloud Platform теперь должны платить налог за размещение приложений, которые ориентированы на российских пользователей или на приложения, которые сделаны в России?
Нет, я предлагаю оставить эту шутку в покое.