Pull to refresh
4
0
Ян Казлаускас@NayZaK

User

Send message
Учитывая, что Swift все еще претерпевает изменения, книга такого рода, еще и на русском, еще и в переплете… Лично для меня сомнительно. Думаю кто хотел, тот уже обмазался и доками и The Swift Programming Language и еще кучей материала. Лучше бы написали книгу, в которой покажут неподготовленным умам как можно и нужно писать на Swift. Имею ввиду функциональный подход со всеми вытекающими.
Согласен. Видимо я выразился некорректно.
Но от того, что работа с данными, сетью и т.д. и т.п. остается в моделях, контроллеры от этого не становятся менее уродливыми. Скорее всего этому способствует масса материала, где показывается решение задачи в лоб, и начинающий разработчик её воспринимает как должное, не пытаясь как-то раскидать все по своим местам. Со временем у него накапливается такой опыт проект оказывается неподдерживаемым. Видимо я сам попал в такую ситуацию, но решение нашлось уже на другой стороне :)
Рекомендую к ознакомлению вторую главу (Анализ) из книги Problem Solving with Algorithms and Data Structures, перевод которой мелькал на Хабре. В ней доходчиво объясняется понятие сложности алгоритмов. Соответственно перед тем, как сделать для себя открытие о том, что в конкретном языке, конкретная операция над конкретной структурой данных работает не так быстро\медленно как того ожидает разработчик, не мешало бы разузнать как именно реализованы данные операции в конкретном случае.
Понимаю, что запись чисто физически должна работать медленней, однако разброс 3 секунды и доля секунды всё-же не укладывается в голову.
Удивляет меня скорость записи. Загрузить и распарсить json получается заметно быстрее, чем записать результат в Core Data. Чем это обусловлено?
Вместо того, чтобы упростить описание интерфейса путем переноса этого самого описания в декларативный код (xaml в качестве примера), Apple накрутила еще одну неочевидную сущность :( И так «верстать» iOS UI было тяжко, а стало еще запутанней. И не понять, толи это наследие, которое навсегда останется с разработчиком, толи оптимизация (тобиш потребуем от разработчика как можно больше данных, зато железке будет проще из переваривать), толи я чего-то не понимаю/не осилил. Но вот честно, мне проще ручками описать xml с версткой, чем работать с эпловским UI дизайнером. Может порекомендуете чего толкового почитать на эту тему? Или там дзен достигается лишь путем проб и ошибок?

Автору за статью огромное спасибо. Познавательно и полезно.
Автокомплит есть, но в Xamarin Studio 5.2 он отвалился. В 5.1.4 все работает. И кстати я не понимаю, в чем проблема кастомизации контролов. Их так и так приходится кастомизировать, другое дело в том, что действительно накладывается новый слой потенциальных багов. Xamarin-Forms-Labs — хороший проект, но только для примера, пользоваться им не советую. А еще есть проблема с неотзывчивым форумом. Ни на один мой вопрос там не дали ответа. Приходится тратить кучу времени на ковыряние в ксамариновской либе, ибо документация скудноватая. Вот к примеру спросил у них почему процесс перехода к новой вьюхе настолько тормознутый (http://forums.xamarin.com/discussion/21671/pushasync-and-delay). Приложил даже видео. В ответ тишина.
Всю жизнь думал, что там Java всех задавила.
Это да, но все равно неочевидность этих автолэйаутов зашкаливает. Да и посмотрите, как constraints описываются ручками. И еще момент. В сториборде рисовать — это, конечно, здорово но ради элементарной кастомизации внешнего вида кнопки нужно лезть в императивный код. При этом с завистью смотришь на веб-разработчиков, на WP и андроид (именно в плане описания UI).
Верстать на iOS — боль. Посему Xamarin Forms оказался находкой. Еще сыро, местами приходится долго и мучительно обходить стандартное поведение компонентов. Особенно когда у разработчиков Xamarin Forms ООП головного мозга, и огромная часть реализации компонентов скрыта от пользователя с помощью private, internal, в следствии чего просто взять переопределить метод неполучится, но бывает спасает шарповская магия. Но ради XAML можно и помучаться на старте.
Автор вел речь об объектно-ориентированных языках, так что С++.
Сдается мне, что для людей, не имеющих никакого представления о разработке ПО, данная статья еще больше их запутает. А в целом с посылом согласен. Но к Java и C# я бы еще C++ добавил. Все-так у начинающего программиста должно быть сформировано представление о работе с памятью.
2

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity

Specialization

Разработчик мобильных приложений