Scogun, на мой взгляд, Вы зря отказываетесь от Activity — так вы получите больше свободного места на устройствах с маленьким экраном, если захотите отображать не только название папки/файла, но и дополнительную информацию о файле.
Под спойлерами пример того, что было у меня и как я это улучшил. Код во многом соответствует коду, который Вы привели.
Было (PNG, 40КБ)
Стало (PNG, 42КБ)
Прошу прощения за сторонний хостинг картинок, что-то странное творится с HabraStorage
Пару недель назад пытался прикрутить Support Action Bar в свой проект. Возможно такая ошибка была только у меня, но тем не менее на 2.3.3 вываливался exception, если я пытался использовать в ActionBar навигацию списком (NAVIGATION_MODE_LIST). После этого и других мелких недочётов (например, мне не нравится, как панель выглядит на API ниже 11 — с голубой полосой снизу, как в ActionMode, а стилизовать не хотелось) решил вернуться на ActionBarSherlock.
Для приведённого Вами кода переход на Sherlock потребует только добавление к проекту зависимость от библиотеки и немного изменений в import-ах.
Скажите, пожалуйста, почему Вы не использовали единицы измерения напрямую? В пункте 7.1 (http://www.w3.org/TR/SVG/coords.html) сказано, что очень желательно использовать единицы реального мира.
Прошёл по ссылке, просмотрел первые три страницы результатов. Про метод учёта числа пересечений написано почти на каждой странице. Про метод учёта числа оборотов написано не больше, чем есть на википедии.
Пожалуй я останусь при мнении, что фраза
Давайте будет считать, что я не совсем точно выразился. В русскоязычной литературе из двух вышеназванных методов я встречал только метод учёта числа пересечений, либо оба со скудным описанием.
Я буду только рад, если в комментариях будут появляться ссылки на различные источники. Думаю, что это будет многим интересно.
А пока подредактирую пост для устранения своей неточности. Всем спасибо за комментарии.
Я попробовал ваш вариант и должен отметить, что он работает замечательно.
Но с другой стороны он мне не подходит по ряду причин:
— почти всегда я получаю вещественные значения координат точки, т.к. конвертирую координаты точки касания в другую единицу измерения. Поэтому int сразу отпадает — каст к нему ведёт к большим погрешностям в работе приложения.
— краткое тестирование времени выполнения методов:
long time = System.currentTimeMillis();
// Do something...
Log.i("Time:", String.valueOf(System.currentTimeMillis() - time));
для многоугольника с N примерно равным 10 — 15 возвращает одинаковое время работы двух методов — 0...1 мс. Ни в коем случае не утверждаю, что какой-то из способов хуже или лучше, но для моих задач такой производительности вполне хватает.
Думаю, что если найду время, то попробую протестировать нативный и самописный методы на производительность более тщательно.
Вы правы, это хороший способ для уменьшения числа вычислений, именно поэтому в своей программе я проверяю точку на принадлежность прямоугольнику, в который вписан объект, перед тем, как выпускать «тяжёлую артиллерию».
Под спойлерами пример того, что было у меня и как я это улучшил. Код во многом соответствует коду, который Вы привели.
Прошу прощения за сторонний хостинг картинок, что-то странное творится с HabraStorage
Для приведённого Вами кода переход на Sherlock потребует только добавление к проекту зависимость от библиотеки и немного изменений в import-ах.
Смещение должно быть на ширину линии. Так, например, для первой линии x1 = 1 и y2 = 1 означает, что ширина линии штриховки равна 1.
Скажите, пожалуйста, почему Вы не использовали единицы измерения напрямую? В пункте 7.1 (http://www.w3.org/TR/SVG/coords.html) сказано, что очень желательно использовать единицы реального мира.
А вообще, жду продолжения — очень интересно узнать про Ваши правила стилизации и использования текста на чертежах
Пожалуй я останусь при мнении, что фраза больше подходит для данного топика.
Я буду только рад, если в комментариях будут появляться ссылки на различные источники. Думаю, что это будет многим интересно.
А пока подредактирую пост для устранения своей неточности. Всем спасибо за комментарии.
Но с другой стороны он мне не подходит по ряду причин:
— почти всегда я получаю вещественные значения координат точки, т.к. конвертирую координаты точки касания в другую единицу измерения. Поэтому int сразу отпадает — каст к нему ведёт к большим погрешностям в работе приложения.
— краткое тестирование времени выполнения методов:
для многоугольника с N примерно равным 10 — 15 возвращает одинаковое время работы двух методов — 0...1 мс. Ни в коем случае не утверждаю, что какой-то из способов хуже или лучше, но для моих задач такой производительности вполне хватает.
Думаю, что если найду время, то попробую протестировать нативный и самописный методы на производительность более тщательно.