Я не защищаю паркующихся не по правилам. Я сам не встаю под знаками и не говорю, что это хорошо. Я лишь утверждаю, что по закону не любая парковка под знаком влечет эвакуация, а на практике так и происходит.
Про конкретный кейс, который я писал:
1. Там пройдет и грузовик и пожарная (проезжали на моих глазах), даже если припаркуется грузовик.
2. вы не можете повернуть в правый ряд, а потом перестроиться, потому что по ПДД там 1 ряд, в который вы сразу и поворачиваете.
Еще разок, я не говорю про машины которые мешают (не дают совершить маневр по ПДД, ограничивают обзор и т.д.). Я говорю о местах, где припаркованные машины не мешают, а знак стоит. Если дорога позволяет ехать в 2 полосы, но разметка для одной — то ехать в 2 полосы — нарушение ПДД. В этом случае пинать надо не тех кто припарковался, а тех кто рисует разметку.
Задержание автомобиля регламентируется ст.27.13 Кодекса РФ об административных нарушениях (КоАП РФ). Согласно этой статье транспортное средство задерживается до устранения причины задержания при нарушениях, предусмотренных следующими статьями КоАП РФ:
а) ч.1 ст. 12.3 — если у водителя, отсутствуют документы на право управления транспортным средством, регистрационные документы на транспортное средство, а также документы, подтверждающие право владения, пользования или распоряжения управляемым им транспортным средством в отсутствие его владельца;
б) ч. 2 ст.12.5 — при управлении автомобилем с заведомо неисправными тормозами, рулевым управлением, либо сцепным устройством согласно Перечню по допуску транспортных средств;
в) ч. 1 и 2 ст.12.7 — если водитель не имеет прав (за исключением учебной езды), либо лишен их;
г) ч.1 ст.12.8 — когда водитель находится в состоянии опьянения (алкогольного или наркотического;
д) ч. 4 ст.12.19 — за нарушение правил остановки и стоянки, повлекшее создание препятствий для движения других автомобилей;
е) ст.12.26 — за отказ от прохождения медицинского освидетельствования на состояния опьянения.
(http://www.pravorf.ru/analytics/57.php)
Вот то что регламентирует эвакуацию авто по закону. Если на односторонней улице разметкой не предусмотрено больше одного ряда для движение, а при парковке автомашин остается достаточно места для движения, то такая машина создает препятствие для движения других автомашин? Знак запрещающий остановку при этом висит.
На сколько я понимаю закон в этом случае машина эвакуации не подлежит. По скольку в 2 ряда ехать все равно нельзя (разметка указывает что ряд один).
Согласен, про не оплату парковки — это из другой оперы. Давайте разберемся со знаком остановка запрещена и эвакуацией в этом случае.
Это необязательно не очень хороший район. Это может быть около офиса (у нас часто задерживаются до поздна) или около дома (можно выйти покурить на балкон и увидеть).
Я не готов утверждать, что «в основном ночью», по моим наблюдениям это часто происходит ночью. Точной статистики у меня нету.
Дело в том, что машина припаркованная под знаком стоянка запрещена не подлежит эвакуации по закону. По закону эвакуируются те машины, которые мешают дорожному движению/пешеходам.
Т.е. припаркованный на тротуаре подлежит эвакуации, а не оплативший праковку — нет (если не мешает движению). Тем не менее, в Москве эвакуируют всех, кто нарушает правила парковке и часто это происходит ночью, когда они вообще никому не мешают.
А я больше люблю сам класс View. Еще ни разу до конца не дочитал )
А вообще, качество кода местами удручает и читается плохо. Но он по крайне мере есть и можно в него залезть и увидеть, что там происходит и как это обойти.
А вот этот момент очень интересен. Может после редизайна напишете статью с цифрами, влияет ли «нативный» дизайн на комфорт пользователей. Сколько пользователей проводят времени в приложении и т.д. в iOSном дизайне и в андроидном.
Мне кажется, было бы очень интересно такое сравнение.
Хорошо, скажем по-другому. В андроиде есть гайды с описанием типовых элементов и их поведением. Есть описанные правила навигации и размещения некоторых стандартных элементов на экране. Если говорить про графическую часть дизайна, то она мне очень нравится, но использование контроллов из ios мне доставляет неудобство, причем не только эстетическое.
Жаль, что опять тотальное игнорирования Android дизайна. Дизайн с iOS опять натянули на другую платформу, наплевав, что пользоваться не привычны и банально не удобно.
Но никто, кроме мото Х не включится от Ok google. это работает только на домашнем экране и при открытом Google Now. Поэтому это проблема не очень актуальна.
Мне кажется, будь это ListView, это был бы тоже законченный элемент. В него можно было бы передавать любой свой адаптер со своими View и это было бы очевиднее. Разработчик знает что такое AdapterView и как с ним работать, а вот то что нельзя поставить иконки — может оказаться фатальным недостатком.
Вы такой замкнутостью компонента ломаете модель, на которой android построен. Компонент должен отвечать за отображение данных, но не ограничивать их тип.
Что бы избежать добавления элементов и избавиться от запаха приспособления для инвалидов, можно добавлять paddingTop у listView при скролле дальше первого элемента.
Правильным архитектурным решением было бы расширить ListView, который снаружи вел себя так же как обычные. Т.е. ему можно было бы передать любой адаптер, наследуемый от BaseAdapter. Вся реализация внутри одного класса, наследуемого от ListView.
Не портить адаптер фиктивными элементами, а делать нужные отступы внутри listView, в крайнем случае делать wrapper над адаптером.
Работать исключительно с View, что бы не зависеть от того, что возвращает адаптер (картинки, кнопки или текст).
Параметризировать количество элементов, скорость уменьшения элементов и т.д. что бы можно задать из xml и из кода.
Увеличивать и уменьшать элементы в onDraw, что бы при скроле не пересчитывать весь layout. В крайнем случае, если необходимо смещать элементы — то еще onLayout переписать.
Я позволю себе немного покритиковать.
Вы решили очень частную задачу и код совсем не универсален, мне кажется для статьи это не очень хорошо. Хорошо бы дать возможность отдавать свой адаптер и тогда при использовании можно было бы выводить не только одно текстовое поле, но и картинки например. Размер менять с помощью view.setScaleX(). Это было бы куда более гибко и интересно для остальных.
Кроме того, задание setTextSize при скролле — долго. setScale было бы немного быстрее. setTextSize требует измерения текста каждый раз, потом измерения view и т.д. Делать это на каждый пиксель скролла не очень производительно.
Из статьи так и не понял, зачем наследоваться от LinearLayout, а не сразу от ListView (ну или в крайнем случае FrameLayout). Лишний элемент в иерархии не очень хорошо.
Хранить все view в массиве — не нужно. listView.getViewAt(int) — вернет те же самые View.
Для того, чтобы можно было сдвинуть первый элемент списка в середину добавим в начало и конец массива пустые строки.
Как-то попахивает костылем.
В целом как решение узкой задачи хорошо, но выкладывать я бы не стал, очень уж тяжело переиспользовать и много не оптимальных путей.
Итак, про первый и второй пункт ни слова не увидел.
Про третий пункт — проблема надуманна.
Пользователю тяжело тянуться к вкладкам — ок. Стандартный свайп — чем не устраивает. Горизонтальный свайп решает проблему с правилом большого пальца.
Да, action bar предполагает использование фрагментов, но сохранение состояния фрагмента — это не так много кода, зато более рациональная работа памяти.
Поведение с отдельным стеком на вкладке — это ужас. Кнопка назад — возвращает назад, а не непонятно куда, как у вас. На детальном экране вообще не должно быть табов.
Я боюсь представить как реализовано это внутри, если это без фрагментов еще сделано.
Про пункт 4:
Я имел в виду Don't use right-pointing carets on line items из гайдов. У вас это в разделе «прочее».
Стрелки назад в адроиде нету, есть кнопка вверх (Up). Ее поведение у вас в Прочее -> о проекте -> Свяжитесь с нами -> назад — неправильно.
У меня стойкое впечатление, что вы гайды первый раз открыли сегодня. А андроидом пользовались 2 дня тестовым, перед тем как заняться разработкой.
Такие вопросы я чаще всего слышу от дизайнера, который сам ходит с iPhone. Каждый раз я слышу одни и те же слова. Почему ни у кого не возникает сделать таббар сверху на iOS?
Это вопрос к гайдам, который есть под платформу и создают некое единообразие и ожидаемое поведение для пользователя. Попробую их позащищать немного:
1. А почему не слева или внизу например? ActionBar — стандартный элемент интерфейса android. Если вы его не хотите использовать — не используйте. Делать элемент, похожий на стандартный, но не стандартный — зачем? Что бы потом использовать кнопки где-то еще, вместо того что бы расположить их в ActionBar (как в этом приложении)?
2. Это место для отображение действий по android гайдам. Т.е. не навигации, а действий. Поэтому наличие навигации внизу — это плохо. Конечно, можно сделать и внизу и слева, пользователь даже разберется с этим. Но такие приложение ломают вырабатываемую привычку у пользователя.
3. Это вопрос исключительно стиля системы (она и расположена в разделе PureAndroid). Просто наличие этого в гайдах гугла — повод не использовать этот элемент из iOS. А вот ни одно «за» за то что бы его использовать я не вижу.
Про конкретный кейс, который я писал:
1. Там пройдет и грузовик и пожарная (проезжали на моих глазах), даже если припаркуется грузовик.
2. вы не можете повернуть в правый ряд, а потом перестроиться, потому что по ПДД там 1 ряд, в который вы сразу и поворачиваете.
Еще разок, я не говорю про машины которые мешают (не дают совершить маневр по ПДД, ограничивают обзор и т.д.). Я говорю о местах, где припаркованные машины не мешают, а знак стоит. Если дорога позволяет ехать в 2 полосы, но разметка для одной — то ехать в 2 полосы — нарушение ПДД. В этом случае пинать надо не тех кто припарковался, а тех кто рисует разметку.
а) ч.1 ст. 12.3 — если у водителя, отсутствуют документы на право управления транспортным средством, регистрационные документы на транспортное средство, а также документы, подтверждающие право владения, пользования или распоряжения управляемым им транспортным средством в отсутствие его владельца;
б) ч. 2 ст.12.5 — при управлении автомобилем с заведомо неисправными тормозами, рулевым управлением, либо сцепным устройством согласно Перечню по допуску транспортных средств;
в) ч. 1 и 2 ст.12.7 — если водитель не имеет прав (за исключением учебной езды), либо лишен их;
г) ч.1 ст.12.8 — когда водитель находится в состоянии опьянения (алкогольного или наркотического;
д) ч. 4 ст.12.19 — за нарушение правил остановки и стоянки, повлекшее создание препятствий для движения других автомобилей;
е) ст.12.26 — за отказ от прохождения медицинского освидетельствования на состояния опьянения.
(http://www.pravorf.ru/analytics/57.php)
Вот то что регламентирует эвакуацию авто по закону. Если на односторонней улице разметкой не предусмотрено больше одного ряда для движение, а при парковке автомашин остается достаточно места для движения, то такая машина создает препятствие для движения других автомашин? Знак запрещающий остановку при этом висит.
На сколько я понимаю закон в этом случае машина эвакуации не подлежит. По скольку в 2 ряда ехать все равно нельзя (разметка указывает что ряд один).
Согласен, про не оплату парковки — это из другой оперы. Давайте разберемся со знаком остановка запрещена и эвакуацией в этом случае.
Я не готов утверждать, что «в основном ночью», по моим наблюдениям это часто происходит ночью. Точной статистики у меня нету.
Т.е. припаркованный на тротуаре подлежит эвакуации, а не оплативший праковку — нет (если не мешает движению). Тем не менее, в Москве эвакуируют всех, кто нарушает правила парковке и часто это происходит ночью, когда они вообще никому не мешают.
А вообще, качество кода местами удручает и читается плохо. Но он по крайне мере есть и можно в него залезть и увидеть, что там происходит и как это обойти.
Мне кажется, было бы очень интересно такое сравнение.
Вы такой замкнутостью компонента ломаете модель, на которой android построен. Компонент должен отвечать за отображение данных, но не ограничивать их тип.
Что бы избежать добавления элементов и избавиться от запаха приспособления для инвалидов, можно добавлять paddingTop у listView при скролле дальше первого элемента.
Не портить адаптер фиктивными элементами, а делать нужные отступы внутри listView, в крайнем случае делать wrapper над адаптером.
Работать исключительно с View, что бы не зависеть от того, что возвращает адаптер (картинки, кнопки или текст).
Параметризировать количество элементов, скорость уменьшения элементов и т.д. что бы можно задать из xml и из кода.
Увеличивать и уменьшать элементы в onDraw, что бы при скроле не пересчитывать весь layout. В крайнем случае, если необходимо смещать элементы — то еще onLayout переписать.
Вы решили очень частную задачу и код совсем не универсален, мне кажется для статьи это не очень хорошо. Хорошо бы дать возможность отдавать свой адаптер и тогда при использовании можно было бы выводить не только одно текстовое поле, но и картинки например. Размер менять с помощью view.setScaleX(). Это было бы куда более гибко и интересно для остальных.
Кроме того, задание setTextSize при скролле — долго. setScale было бы немного быстрее. setTextSize требует измерения текста каждый раз, потом измерения view и т.д. Делать это на каждый пиксель скролла не очень производительно.
Из статьи так и не понял, зачем наследоваться от LinearLayout, а не сразу от ListView (ну или в крайнем случае FrameLayout). Лишний элемент в иерархии не очень хорошо.
Хранить все view в массиве — не нужно. listView.getViewAt(int) — вернет те же самые View.
Как-то попахивает костылем.
В целом как решение узкой задачи хорошо, но выкладывать я бы не стал, очень уж тяжело переиспользовать и много не оптимальных путей.
Про третий пункт — проблема надуманна.
Пользователю тяжело тянуться к вкладкам — ок. Стандартный свайп — чем не устраивает. Горизонтальный свайп решает проблему с правилом большого пальца.
Да, action bar предполагает использование фрагментов, но сохранение состояния фрагмента — это не так много кода, зато более рациональная работа памяти.
Поведение с отдельным стеком на вкладке — это ужас. Кнопка назад — возвращает назад, а не непонятно куда, как у вас. На детальном экране вообще не должно быть табов.
Я боюсь представить как реализовано это внутри, если это без фрагментов еще сделано.
Про пункт 4:
Я имел в виду Don't use right-pointing carets on line items из гайдов. У вас это в разделе «прочее».
Стрелки назад в адроиде нету, есть кнопка вверх (Up). Ее поведение у вас в Прочее -> о проекте -> Свяжитесь с нами -> назад — неправильно.
У меня стойкое впечатление, что вы гайды первый раз открыли сегодня. А андроидом пользовались 2 дня тестовым, перед тем как заняться разработкой.
1. А почему не слева или внизу например? ActionBar — стандартный элемент интерфейса android. Если вы его не хотите использовать — не используйте. Делать элемент, похожий на стандартный, но не стандартный — зачем? Что бы потом использовать кнопки где-то еще, вместо того что бы расположить их в ActionBar (как в этом приложении)?
2. Это место для отображение действий по android гайдам. Т.е. не навигации, а действий. Поэтому наличие навигации внизу — это плохо. Конечно, можно сделать и внизу и слева, пользователь даже разберется с этим. Но такие приложение ломают вырабатываемую привычку у пользователя.
3. Это вопрос исключительно стиля системы (она и расположена в разделе PureAndroid). Просто наличие этого в гайдах гугла — повод не использовать этот элемент из iOS. А вот ни одно «за» за то что бы его использовать я не вижу.