HATEOAS и HAL это частные реализации HTTP протокола. Нет нужды подменять ими REST. REST/RESTful повсеместно используется мобильными разработчиками. Поскольку, как правило, мобильный API ограничивается GET и POST запросами, то в тексте упоминается именно REST, а не RESTful, хотя этот факт ни на что не влияет. Кроме того, Вы подменяете HTTP статусы кодами ошибок REST — последние нигде не определены стандартом, и могут меняться разработчиками в широких пределах.
Серверные разработчики могут изменить API таким образом, что его обработка приведет к крешу приложения. Если клиент пишется на готовом API — такая ситуация никогда не возникает. Но вот когда API пишется одновременно с клиентом — такая ситуация возникает сплошь и рядом (заменили поле id на ident). Но даже уже существующее API может вызвать проблему, если, вдруг, отправит вместо int тип double или string. Для языков с нестрогой типизацией это обычное явление.
> Просто попробуйте поработать с git таким способом, и вы увидите, как много времени можно сэкономить.
Вы не поверите сколько времени можно сэкономить если воспользоваться SourceTree или аналогичными инструментами.
Провел 3 недели в Великобритании, в основном, Brodstairs Language School. Ни разу не слышал чтоб кто-то обратился к кому-то по фамилии… Все преподаватели имели на шее бейдж с именами, но без фамилий.
Итого, 30 строчек XAML + 44 C# кода. Я нарочно не стал делать всякую асинхронщину, т.к. глупо жать кнопку и тут же что-то менять — нужно дождаться результата, но если кому чешется, можете для async/await прибавить ещё 4 строчки.
В любом случае, полученный код явно компактнее и проще Swift-оригинала, да и сам проект — всего одна форма:
К Вашему сведению, .net работает не только в Windows. И сравнивать языки программирования, в том числе и по объему написанного кода можно только в том случае, если Вы можете воспроизвести ОБА примера на одной и той же платформе. То что Вы называете ахинеей — это реальность, о которой Вы не знаете просто потому что кроме Windows никогда ничего не видели. Да, в винде Framework встроенный, но на любой другой ОС, его нужно копировать к полученному бинарнику. (ужа надоело это даже писать), и без него НИЧЕГО работать не будет. Swift с которым Вы сравниваете работает только на OSX и iOS. Так что, прежде чем называть меня школотой, потрудитесь отвечать за свои слова и запустите свою поделку на любой из этих платформ.
Каждый кто программирует на Objective-C и на C# знает, что первый отставал от последнего на два десятка лет. Но за пару лет Objective-C взял такой разгон, что были основания полагать, что скоро C# придется догонять… А поведение Балмерт и уход автора C# из Microsoft только усугубил кризис. Это вообще не предмет дискуссии. Но вот что значит стремится? Нужно ли Apple переходить к векторной графике? До тех пор пока я не начал программировать на IOS я был уверен, что за векторной графикой будущее. Но растр у Microsoft не делает десятой части того, что делает у Apple. В таком случае, в чем смысл? А именно это позволило обрести WPF/Siverlight такую популярность. Да, у Apple отсуствует декларативное программирование. Это очень не привычно, в современном мире. С другой стороны, пробовали Вы сделать сложную декларативную графику без Microsoft Blend? Вот и посудите, а оно надо? Все равно же будут использовать посроители интерфейса, как это делает Apple. Ну и в завершении, что делает WPF таковой, что резко сокращает количество кода — бандинги! А скажете ли Вы что MVVM легче для понимания и работы в очень сложной форме чем MVC? Думаю что нет. Так нужно ли идти по этой дороге?
Это не я складываю, а автор топика который пытается сравнивать десктопную векторную платформу, работающую на x86 архитектуре, с растровой ARM iOS платформой. Перечислением платформ я лишь пытался показать перечень того, где нет встроенного .NET.
Про размер файлов я знаю. Но в сумме они дают слишком высокий прирост.
Фреймворки не только предоставляют абстракции, но и обеспечивают большим количеством прикладного кода. Автор, к примеру, апеллирует к тому, насколько плохо в IOS обеспечена поддержка JSON. Так если выкинуть из .Net сборки по сериализации, там тоже ничего работать без костылей не будет. И именно это создает богатство платформы. В IOS SDK они не меньше, просто пример для Swift показан минимальными средствами.
Конечно WPF под iOS не существует, хотя бы потому, что повсеместно используется растровая графика, а не векторная как в WPF. Но в целом Monotouch и Mono существенно уступает в производительности нативному решению (а в винде, это предмет бесконечных споров). Так что все сравнение некорректно от начала до конца. Хотя начало статьи — действительно приковывает внимание.
Ну, для начала, сообщу Вам, что я программирую на C# c 2005 года. Сетевые приложение писал и c сокетами, и с REST, и с WCF / WF как для WinForm, так и для WPF и Silverlight. Так что кто еще не владеет темой — отдельный вопрос.
Для того чтоб у Вас все заработало, Вам необходим .Net framework, который делает за Вас все «из коробки». Последние годы он включен в винду, но чтоб это же приложения работали под Linux/FreeBSD/Solaris/OSX или Android / iOS вам необходим Mono/Monotoch который копируется в каталог приложения. И, в общей сложности увеличивает размер бинарника в сотни раз. А без него него — никак.
Из этого следует:
1) Ваше сравнение с ЛЮБЫМ iOS приложением по объему полученного бинарника это fail.
2) Говорить о том, что все «из коробки» — это тоже fail.
Ну это были так, азы, для тех кто в теме.
Далее, относительно объема кода:
Чтоб отобразить таблицу необходимо и достаточно реализовать всего три метода:
— получить количество секций
— получить количество строк в секции
— получить ячейку и сделать ей кастомизацию, вычитав данные из словаря.
Чтобы получить словарь — достаточно одного метода для GET запроса, и одного метода для превращения JSON в NSDictionary.
ВСЕ!
При всем при этом, XCode предоставляет шаблонный код, где вообще почти ничего не нужно менять.
Будете считать строки кода в переносами на другую строку и открывающей/закрывающей фигурной скобкой?
Только полный профан будет на столь элементарных примерах доказывать преимущество одного языка, над другим.
ИТОГО:
сравнение платформ: fail
сравнение языков: fail.
Поговорим о производительности WPF кода под iOS, или пойдете читать учебники?
Ну а на iOS работает CoreData из коробки. Тоже еще аргумент. Swift сырой язык — с этим может спорить только тот, кто не программирует на iOS. Он еще даже не вышел в первой версии — он был только презентован. При его создании использовали опыт в том числе и C#, так же как сам C# был создан при участии разработчиков Delphi и почерпнул оттуда многие свои идеи. Дискуссия здесь холиварна просто потому, что невозможно сравнивать что-то простое и неработающее, с чем-то менее интуитивным в вполне работоспособным. Вот когда автор топика запустит свое приложение под IOS, разработав его под WPF, тогда и будет смысл сравнивать ПРОСТОТУ программирования и объем кода. Пока что, автор показал одно, а в заголовке написал совсем другое.
Это было бы честным сравнением, если бы Автор свою поделку еще запустил на iOS девайсе. А так это сравнение ракетки и ракеты. Относительно количества кода — для минималистичного iOS приложения на Objective-C его не намного больше чем на C# WPF, а уж бинарный файл и того меньше на порядки (для C# нужно еще .Net framework установить в каталог с приложением). Это не говоря уж о том, что Swift короче Objective-C, а длинные примеры обусловлены тем, что авторы стараются показать особенности языка.
Если Вы программировали на C# до того как начали писать на Objective-C, то Вам будет невероятно сложно наступать себе на горло, сталкиваясь с идеологией 25-ти летней давности. В Swift всего этого нет. Ощущение от синтаксиса примерно такое же, как при переходе от C++ к С#. Конечно, было бы суперски если бы вместо Swift Apple перешел на C#, но, видимо, уж очень шарп заточен под .net.
Нет, конечно. Просто им окружающий мир представляют как мир полный насилия и голода (хотя чего уж там, россия ведет войну против Украины), и для них, кимчинырия кажется несокрушимым государством обеспечивающим нужны трудящихся. Но жители других стран, кто видел северокорейские новости, прекрасно знают как мир выглядит на самом деле. Они реально бояться того, что северокорейские взгляды могут где-нибудь преобладать, например, на 1/8 части суши.
Вы не поверите сколько времени можно сэкономить если воспользоваться SourceTree или аналогичными инструментами.
Итого, 30 строчек XAML + 44 C# кода. Я нарочно не стал делать всякую асинхронщину, т.к. глупо жать кнопку и тут же что-то менять — нужно дождаться результата, но если кому чешется, можете для async/await прибавить ещё 4 строчки.
В любом случае, полученный код явно компактнее и проще Swift-оригинала, да и сам проект — всего одна форма:
К Вашему сведению, .net работает не только в Windows. И сравнивать языки программирования, в том числе и по объему написанного кода можно только в том случае, если Вы можете воспроизвести ОБА примера на одной и той же платформе. То что Вы называете ахинеей — это реальность, о которой Вы не знаете просто потому что кроме Windows никогда ничего не видели. Да, в винде Framework встроенный, но на любой другой ОС, его нужно копировать к полученному бинарнику. (ужа надоело это даже писать), и без него НИЧЕГО работать не будет. Swift с которым Вы сравниваете работает только на OSX и iOS. Так что, прежде чем называть меня школотой, потрудитесь отвечать за свои слова и запустите свою поделку на любой из этих платформ.
Про размер файлов я знаю. Но в сумме они дают слишком высокий прирост.
Фреймворки не только предоставляют абстракции, но и обеспечивают большим количеством прикладного кода. Автор, к примеру, апеллирует к тому, насколько плохо в IOS обеспечена поддержка JSON. Так если выкинуть из .Net сборки по сериализации, там тоже ничего работать без костылей не будет. И именно это создает богатство платформы. В IOS SDK они не меньше, просто пример для Swift показан минимальными средствами.
Конечно WPF под iOS не существует, хотя бы потому, что повсеместно используется растровая графика, а не векторная как в WPF. Но в целом Monotouch и Mono существенно уступает в производительности нативному решению (а в винде, это предмет бесконечных споров). Так что все сравнение некорректно от начала до конца. Хотя начало статьи — действительно приковывает внимание.
Для того чтоб у Вас все заработало, Вам необходим .Net framework, который делает за Вас все «из коробки». Последние годы он включен в винду, но чтоб это же приложения работали под Linux/FreeBSD/Solaris/OSX или Android / iOS вам необходим Mono/Monotoch который копируется в каталог приложения. И, в общей сложности увеличивает размер бинарника в сотни раз. А без него него — никак.
Из этого следует:
1) Ваше сравнение с ЛЮБЫМ iOS приложением по объему полученного бинарника это fail.
2) Говорить о том, что все «из коробки» — это тоже fail.
Ну это были так, азы, для тех кто в теме.
Далее, относительно объема кода:
Чтоб отобразить таблицу необходимо и достаточно реализовать всего три метода:
— получить количество секций
— получить количество строк в секции
— получить ячейку и сделать ей кастомизацию, вычитав данные из словаря.
Чтобы получить словарь — достаточно одного метода для GET запроса, и одного метода для превращения JSON в NSDictionary.
ВСЕ!
При всем при этом, XCode предоставляет шаблонный код, где вообще почти ничего не нужно менять.
Будете считать строки кода в переносами на другую строку и открывающей/закрывающей фигурной скобкой?
Только полный профан будет на столь элементарных примерах доказывать преимущество одного языка, над другим.
ИТОГО:
сравнение платформ: fail
сравнение языков: fail.
Поговорим о производительности WPF кода под iOS, или пойдете читать учебники?
В Swift есть женерики. Посмотрите обучающие примеры.