Как пользоваться документацией?


#1

Вот вроде понимаю ООП, понимаю, что такое объект, его свойства и методы, но все равно не могу разобраться в чертовой документации. Можете показать на примере как это делается? С подобного рода языками не работал, поэтому сложно… гуглить постоянно каждую фигню - это бред, и задавать кучу глупых вопросов, когда все это можно найти в док-ции. Я один такой тупой или многие не понимают эту документацию?))


#2

слишком абстрактно, можно немного конкретнее?


#3

ну вот к примеру, я хочу сделать бордер-радиус к TextField. Я сколько искал, ничего так и не нашел в документации, что я делаю не так? (вы ответили мне в прошлой теме, спс) Но можете показать на примере, как бы вы искали это в док-ии?


#4

В документации я ничего не ищу.
Все что мне нужно google или StackOverflow.

В документации такое сложно искать. Нужно просматривать тонны свойств и классов, которые ведут еще глубже. Документация как по мне, служит для описания какого-то класса/свойства, посмотреть что возращает или требует для установки/передачи.


#5

вот этого я и боялся) У меня такое же представление об этом все) Но искать по гуглу порою тоже очень долго… и не всегда понятно, особенно когда ты новичок в этом деле. Вырежут кусок кода, а хвосты откуда взялись, нужно долго разбираться. Ну ладно спасибо за ответ, думаю этот ответ будет исчерпывающим)


#6

самое главное правильно делать поисковый запрос


#7

я понял свою ошибку, я просто не там искал) я пытался найти свойство cornerRadius в UIKit, а надо было в SwiftUI искать. Ведь UIKit это фремворк, а так есть далеко не все.


#8

вас не туда понесло.
UIKit может все тоже что и SwiftUI, в плане кастомизации. По сути SwiftUI и построен на UIKit, как обертка.
И теперь стоит определиться, вы на чем пишете UIKit или SwiftUI?


#9

но почему этого нет в документации UIKit? Мне кажется это базовый метод, а UIKit как фремворк реализует то, чего нету… разве не так должно быть? И поэтому в UIKit нет этого метода, ибо зачем создавать велосипед. Или я чего-то не понимаю))


#10

UIKit, хорошо тогда как это сделать на ките?


#11

Все там есть
https://developer.apple.com/documentation/uikit/uiview
https://developer.apple.com/documentation/quartzcore/calayer/1410818-cornerradius


#12

Я вам давал пример как раз для UIKit


#13

ну все я запутался… это же вобще ведет к CoreAnimation


#14

cornerRadius это свойство класса CALayer, который наследуется от класса NSObject, а Core Animation это раздел документации, в котором собраны все классы для Render, compose, and animate visual elements.


#15

Вот именно этим и нужно заниматься новичку!!!


#16

Гуглить конечно классно, но все таки этот способ уступает официальной документации по методам и свойствам, которые там уже заложены и расписаны. Ну на PHP в фреймворке Ларавел, точно так, гуру смотрят именно описание классов, свойств и методов в оф.доке, а потом уже лезут на стековерфлоу.

По логике тут должно быть так же.

Поднимаю вопрос официальной документации, повторно.

Не могу понять, вот есть свойство, которое говорит, есть такая штука, что я могу получить ближайший хоп от моего устройства в моем случае мобильника, который подсоединен по Wi-Fi к роутеру, ну и роутер является ближайшим хопом, тоесть по сути это должно вернуть IP адрес роутера:
https://developer.apple.com/documentation/networkextension/neipv4route/1406519-gatewayaddress

Или я что-то не понимаю?
Вроде написано * iOS 9.0+

Как предположим этим свойством воспользоваться внутри класса UIViewController, который создается по умолчанию в самом популярном дефоултном шаблоне?

В общем страницу нагуглил и что дальше с ней делать не понятно, как воткнуть это свойство?

Не менее интересный вопрос, как это все находить эффективно по навигации(или только дело практики)? Вроде пытаюсь пройти назад, чтобы снова вернуться по навигации, но не так то просто это сделать… Предположим, до корня и обратно.


P.S. Ну типа схема пользования докой на примере этого или другого свойства и метода

  1. находим родительский класс свойства в доке таким образом(если на свойство вышли через Гугл)
  2. подключаем его так(импортируем) …
  3. Вызываем данное свойство или метод так… проверяем работоспособность

обратная задача, предположим стоит цель конвертации картинок в формат webp или pdf ну или сжатие сгенерированных файлов в архив, ищем прям из доки

  1. Находим подходящие ветки
  2. исследуем разные классы в этих ветках
  3. доходим до свойств и методом максимально эффективным способом.

Ну или может какие-то другие схемы и я что-то не верно понимаю, возможно работает тут как-то по другому.


#17

Попробую объяснить по другому.
Предположим на примере PHP в фреймворке Laravel, есть два типа документации, для новичков, где словами объяснено, как решать ту или иную задачу, какие паттерны применены в официальном коде ядра этого фреймворка и т.д.
https://laravel.ru/docs/v5 (привел в пример русскоязычную документацию для ясности понимания)

ну, а для совсем новичков лучше начинать с видео и подключать потом документацию.

Для тех кто уже понял смысл ООП, есть второй тип документации, где, можно развернуть каждый класс и заглянуть в него, какие методы и свойства там вообще существуют, в человекподобной документации такого конечно нету иначе она будет просто огромна.
https://laravel.com/api/8.x/index.html

Это конечно круто, когда в Xcode можно запрашивать информацию наведя мышкой чуть ли не на каждый элемент, но это помогает только в просмотре чужого кода.
А вот для разработки, как разу нужно делать в следующей последовательности на мой взгляд

  1. смотреть официальную документацию под задачу
    а) человеко подобную
    б) краткую в дереве классов
    Тут нужно решить каким способом нужно писать код
  2. Только потом смотреть примеры на сетковерфлоу, как решили другие, для поиска более оптимальных путей или оптимизированного кода и уже потом совмещать со своим решением
  3. Написание кода.

Вопрос по
а) и по б)
Как правильно решать эти задачи.


#18

Я думаю вы сильно драматизируете )))
Во-первых: ничего плохо в сетеке не вижу.
Во-вторых: как и любом обучении, вы сначала копируете, не понимая, а уже потом через время начинаете понимать что к чему.

С документацией то же самое: как только вам достаточно будет одной документации, то вы сами это поймёте и начнёте смотреть только её. Но пока вы не понимаете что искать, то и стек вполне себе решение. Всему своё время.

Это как новичков пичкают архитектурами и паттернами - да они не понимают как данные передать между вью )) А потом, как только приходит понимание зачем это, то и вопросы отпадают. С документацией то же самое.

ПС
Единственная ремарка - это качество документации. Если Эппл не хватает звёзд с неба, то, например, у гугла для фейрбейза просто идеальная документация, при которой стек вы даже не вспомните.