Это субъективное мнение, или возможно вы были в офисе на Чапыгина( я никогда там не был). На Пархоменко — очень удобный и комфортный бизнес центр, а насчет атмосферы — все в полном порядке — компания как одна семья.
Это не просто перевод, а выборочный и агрегированный, цель которого — привлечение внимания к вопросу. Насчет продолжения темы, повторять не буду, постараюсь сделать более интересной.
Тема действительно обширная, в статье показаны базовые сведения, уверен Ваш цикл не останется без внимания. Я думаю продолжить тему но с более практической стороны.
The Home, Menu and Back functions are essential to the Android navigation paradigm. Device implementations MUST make these functions available to the user at all times, regardless of application state. These functions SHOULD be implemented via dedicated buttons. They MAY be implemented using software, gestures, touch panel, etc., but if so they MUST be always accessible and not obscure or interfere with the available application display area. Device implementers SHOULD also provide a dedicated search key. Device implementers MAY also provide send and end keys for phone calls.
Т.о. производителю следует добавлять эту кнопку на корпус, но она все же не essential. На практике не видел девайсов без кнопки поиска, думаю довольно редкое явление.
Ага, понял. Я думаю надо все же исходить из функционала приложения, т.е. где и что логично использовать. Разумеется, эти паттерны не панацея и всегда возможны варианты.
Насчет табов(если я про те табы), то с т. зрения фукнионала они не заменяют action bar(хотя если речь о месте на экране, соглашусь — могут заменять). Dashboard vs табы думаю тоже возможно. Исходим из приложения, в общем :)
Еще разок — в статье описываются паттерны UI, т.е. то как можно представить определенные функции приложения, сделать приложение более целостным с точки зрения его структуры. Речь идет о проектировании интерфейса, не о реализации(в том числе названия естественно не имеют отношения к реализации). Паттерны вполне реализуемы с помощью стандартных нативных классов(т.е. конечно придется поработать, например — создать кастомную вьюшку)
>Забавно, что картинки от старого Твиттера, в то время как рефреш в новом можно вполне выделить в отдельный раздел. И кстати новые Quick Actions как раз перекрывают цель.
Не видел новый твиттер, по поводу перекрывают — возможно они могут себе это позволить.)
>Вообще я бы добавил больше примеров, потому что twitter вообще нехарактерно удачное приложение.
Согласен, нехарактерно. Только здесь цель была — демонстрация паттерна (дабы проиллюстрировать о чем речь).
Это действительно стандарт именования или Ваше видение вопроса?
Если стандарт, линк хотелось бы посмотреть.
Фраза ввела в ступор и заставила погуглить.
Со stackoverflow (со ссылкой на официальный источник):
The Home, Menu and Back functions are essential to the Android navigation paradigm. Device implementations MUST make these functions available to the user at all times, regardless of application state. These functions SHOULD be implemented via dedicated buttons. They MAY be implemented using software, gestures, touch panel, etc., but if so they MUST be always accessible and not obscure or interfere with the available application display area. Device implementers SHOULD also provide a dedicated search key. Device implementers MAY also provide send and end keys for phone calls.
Т.о. производителю следует добавлять эту кнопку на корпус, но она все же не essential. На практике не видел девайсов без кнопки поиска, думаю довольно редкое явление.
Насчет табов(если я про те табы), то с т. зрения фукнионала они не заменяют action bar(хотя если речь о месте на экране, соглашусь — могут заменять). Dashboard vs табы думаю тоже возможно. Исходим из приложения, в общем :)
Не видел новый твиттер, по поводу перекрывают — возможно они могут себе это позволить.)
>Вообще я бы добавил больше примеров, потому что twitter вообще нехарактерно удачное приложение.
Согласен, нехарактерно. Только здесь цель была — демонстрация паттерна (дабы проиллюстрировать о чем речь).