Хотя вопрос был задан довольно давно, и автор, вероятно, двинулся дальше, я хочу дать свой ответ, потому что может быть кто-то вроде меня, ударяющий головой, пытаясь найти решение.
Кажется, я читал каждый ответ на эту тему, и все, что у меня было, было частью решения. Большую часть времени я потратил на реализацию метода KVO, как описано в @davew, который иногда работал, но большую часть времени оставил пустое пространство под содержимым контейнера WKWebView. Я также внедрил предложение @David Beck и сделал высоту контейнера равным 0, тем самым избегая возможности возникновения проблемы, если высота контейнера больше, чем высота содержимого контейнера. Несмотря на то, что у меня было это пустое место. Итак, для меня наблюдатель «contentSize» имел много недостатков. У меня нет большого опыта работы с веб-технологиями, поэтому я не могу ответить на вопрос, в чем проблема с этим решением, но я видел, что если бы я только печатал высоту в консоли, но ничего не делал с ней (например, изменяя размеры ограничений) он перескакивает на некоторое число (например, 5000), а затем переходит к числу до того самого высокого (например, 2500, что оказывается правильным). Если я устанавливаю ограничение высоты на высоту, которую я получаю от «contentSize», он устанавливает себя на наибольшее число, которое он получает, и никогда не будет изменен до правильного значения, что опять упоминается комментарием @David Beck.
После множества экспериментов мне удалось найти решение, которое работает для меня:
func webView(_ webView: WKWebView, didFinish navigation: WKNavigation!) {
self.webView.evaluateJavaScript("document.readyState", completionHandler: { (complete, error) in
if complete != nil {
self.webView.evaluateJavaScript("document.body.offsetHeight", completionHandler: { (height, error) in
self.containerHeight.constant = height as! CGFloat
})
}
})
}
Конечно, важно правильно установить ограничения, чтобы scrollView изменял размер в соответствии с содержимым containerHeight ограничение.
Как выясняется, метод наложения didFinish никогда не вызывается, когда я захотел, но, установив шаг document.readyState, следующий вызов (document.body.offsetHeight) будет вызван в нужный момент, вернув мне правильное число для высоты.
Надеюсь, что это сработает и для вас!
Да, можно. Пространство имен контактов будет содержать все классы, определенные в файлах, которые определяют это пространство имен.
Вы также можете определять типы, принадлежащие разным пространствам имен в одном файле. Файлы и пространства имен - полностью ортогональные концепции.
Вы также можете разделить определение класса на несколько файлов, начиная с C # 2.0. См. здесь .
пространство имен - это просто префикс к имени класса, способ разделения классов. они составляются отдельно.
Из документации MSDN :
Ключевое слово пространства имен используется для объявить область действия. Область этого пространства имен позволяет организовать код и дает способ создания глобально уникальных типов.
Да, пространства имен могут (и обычно разделяются) на несколько файлов кода. Классы в этих пространствах имен компилируются отдельно, но (как правило, пока не используются внешние ресурсы) в один выходной файл (например, exe или dll).
В очень широком смысле это похоже на сортировку белья. Каждая «стопка» (стопка цветов, стопка белого и т. Д.) Будет пространством имен. Каждый предмет одежды в стопке будет классом или интерфейсом.
Надеюсь, что это немного поможет ...
Да, вы можете использовать одно и то же пространство имен в нескольких файлах.
Самый доступный пример: в Visual Studio, после создания проекта, вы можете создавать больше файлов в этом проекте. В проекте есть настройка, какое пространство имен по умолчанию назначать новым файлам. Ваш проект будет скомпилирован как единый dll/exe.
Вы также можете использовать существующие пространства имен, например System
. Ваш класс System будет находиться в вашей сборке. Основные сборки .NET, содержащие System, не будут перекомпилированы, чтобы включить ваше дополнение. Тем не менее, для использования нового класса System.x вам по-прежнему потребуется только 1 утверждение using System
в верхней части классов.
Примечание: Я НЕ выступаю за то, чтобы поместить весь ваш код в System, чтобы потом избежать использования операторов. Есть очень веские причины не делать этого, но для ответа на исходный вопрос это излишне.
Оба компилируются в одно пространство имен, Contacts
. Это вполне нормально, что у вас несколько файлов и одно пространство имен.
Пространство имен - это просто некая обертка вокруг ваших классов. Например, сейчас вы можете иметь несколько классов с именем Sentence
.
Вы можете создать Sentence в пространстве имен Jail
и один в пространстве имен Linguistics
.
Таким образом, у вас будет два представления одного имени класса, Jail.Sentence
и Linguistics.Sentence
. Оба также имеют разное тело.
Я использую свои пространства имен, чтобы немного "организовать" код. Все мои интерфейсы существуют в Projectname.Contracts
, а мой обычный код в Projectname
Эта страница Википедии также полезна: Wiki
Да, вы можете разделять файлы и даже сборки с помощью пространства имен. Вот еще один трюк:
В Visual Studio, если вы перейдете в Solution Explorer и создадите папку под вашим проектом csharp, имя этой папки будет добавлено по умолчанию в пространство имен для любого файла, который вы создадите в этой папке.
Пример:
Нет никаких проблем с разделением пространства имен на несколько файлов, и в большинстве программ вы будете делать именно это.
Обычно все файлы .cs компилируются вместе с помощью компилятора C# (csc).
Вы можете увидеть, как компилируется ваш код, изменив эту настройку:
Tools | Options | Projects and Solutions | Build and Run
Измените выпадающий список: "MSBuild project build output verbosity" на одно из более высоких значений. По умолчанию он установлен на минимальное значение.
Короткий ответ - да, вы можете разделить их по отдельным файлам.
Если вы не разделяете его по разным файлам, вы, вероятно, слишком хорошо разбираетесь в макете пространства имен.