Ну например, к нам приходит json, у которого по ключику «data» — массив обьектов, которые нужно замапить в наш обьект (назовем его MyClass). Тогда нужно лишь описать схему:
Mетод -jsonSchema сам создаст схему для нашего класса (все проперти)
После этого, каждый объект в массиве будет провалидирован в соответствии с этой схемой, и если нужно уже провалидированный json будет инстанциирован в обьекты нашего MyClass. Каждый ключик будет соотнесен со свойством инстанса и присвоен ему.
Не нужные нам объекты так и остаются NSDictionary и NSArray
Я тут недавно писал про JSON Schema validator. Если пройтись по озвученный минусам, то эта реализация поддерживает mapping; не нужно создавать класс для каждого ключа json'а; полная проверка входных данных, в том числе и типа класса в массивах; небольшой объем исходного кода.
Но меня на написание своего велосипеда толкнуло полное отсутствие уже готовых решений. Mapping получился в итоге сам собой + все плюшки валидатора
Если я правильно понял, то речь о JFFJsonValidator? Но ведь он просто валидирует на то, что все объекты являются объектами, представимыми в JSON.
Основное предназначение валидатора схем — составление схемы (как ни странно) (структуры) JSON'а, что позволяет проверить, например, что по ключу «key_1» к нам прийдет именно массив, он будет содержать не больше 20 чисел со значением в диапазоне от 5 до 255(или 100500). А а по ключику «key_2» — строка, значение которой может быть только «A», «B» и «C» и т.д.
Если я правильно из понял исходников, то JFFJsonValidator для такой задачи не предназначен.
Да все тоже самое, что и без валидации. Но когда после демо вы пойдете дебажить, чтобы узнать «какого черта», то тут появляется переменная error, которая содержит информацию о том, какие именно ключи json не соответствуют ожиданиям и почему. Это чуть проще, чем проверять вручную большой json.
валидатор — это инструмент, и как каждый инструмент он имеет свою область применимости.
А можно подробнее о «стирании целых классов»? Это стандартное поведение при локализации ресурсов — они копируются хкодом по тем самым папочкам *.lproj. Или вы файлы с исходным кодом пытались локализовать?
Я надеюсь вы это не серьезно? Вот эта простыня из if-else и switch-ей уж никак не является примером хорошего кода.
Да и ваше «скопировать в новую папочку» — в xCode в File Inspector (первая вкладочка в правой колонке) есть специально обученный раздел для локализации любых ресурсов в приложении:
Насколько я понял -performSeletor: вызывался для метода, который возвращает CGFloat без прививания переменной. В этом случае XCode не выдает даже warning'а. Что то вроде:
По опыту большинство багов — это именно неправильное использование фреймворков (тот-же UIKit), именно в UI части. И вот если вы покажите как использовать Unit-тесты для тестирования не модели, а контроллера, или вью под ios — это будет горазд гораздо ценнее.
Бегло просмотрев топик так и не понял о каком языке идет речь. Пришлось уже внимательнее перечитать, чтобы ближе к концу понять что речь о руби. Можно хоть в заголовок вынести, или в начало статьи?
Это отлично, что вы открыли для себя сложные проценты, финансовая грамотность — это то, что обязаны преподавать в школах ИМХО, но вы забыли, что инфляция тоже считается по сложным процентам.
Наоборот, лучше уж ширина изменяется динамически. Во многих стандартных программах и их настройках высота меняется динамически, в зависимости от контента и никого это не смущает
Спасибо, поставил на попробовать
Из первого, что бросилось в глаза — отсутствие пункта меню «настройки» на привычном месте (в меню самого приложения). Нашел только через пункт меню сервис -> параметры. Само окно настроек какое-то поплывшее
В общем довольно приятное первое впечатление. Но шрифт monaco по умолчанию для кода — это конечно очень по-дельфийски, но глаз не радует
Mетод -jsonSchema сам создаст схему для нашего класса (все проперти)
После этого, каждый объект в массиве будет провалидирован в соответствии с этой схемой, и если нужно уже провалидированный json будет инстанциирован в обьекты нашего MyClass. Каждый ключик будет соотнесен со свойством инстанса и присвоен ему.
Не нужные нам объекты так и остаются NSDictionary и NSArray
Но меня на написание своего велосипеда толкнуло полное отсутствие уже готовых решений. Mapping получился в итоге сам собой + все плюшки валидатора
Основное предназначение валидатора схем — составление схемы (как ни странно) (структуры) JSON'а, что позволяет проверить, например, что по ключу «key_1» к нам прийдет именно массив, он будет содержать не больше 20 чисел со значением в диапазоне от 5 до 255(или 100500). А а по ключику «key_2» — строка, значение которой может быть только «A», «B» и «C» и т.д.
Если я правильно из понял исходников, то JFFJsonValidator для такой задачи не предназначен.
валидатор — это инструмент, и как каждый инструмент он имеет свою область применимости.
Да и ваше «скопировать в новую папочку» — в xCode в File Inspector (первая вкладочка в правой колонке) есть специально обученный раздел для локализации любых ресурсов в приложении:
Статья более вредна чем полезна ИМХО
ну и они-же для объявления свойств
Из первого, что бросилось в глаза — отсутствие пункта меню «настройки» на привычном месте (в меню самого приложения). Нашел только через пункт меню сервис -> параметры. Само окно настроек какое-то поплывшее
В общем довольно приятное первое впечатление. Но шрифт monaco по умолчанию для кода — это конечно очень по-дельфийски, но глаз не радует