Pull to refresh
92
0
Сергей Зайцев @zserge

User

Send message
Material Design — для всех, потому у них в гайдлайнах и говорят что делать с пустым местом на больших экранах и т.д.
К тому же Material Design встречается и в Google Docs, и в Google Photos, и на developer.android.com? Это я все про настольные веб-версии.
Не-не, все верно, я про то что компилилось все jdk8, затем с помощью ретролямбды в байткод 7й джавы превращалось. Да, увы всех фич java8 не видать, разве только гугл свои jack/jill доведут до ума. А, ну правда еще стримы бэкпортировали — github.com/aNNiMON/Lightweight-Stream-API

(мимо, да что ж такое, это в ответ artemgapchenko )
Вот может быть интересно — www.docjar.com/html/api/java/lang/Thread.java.html
Вообщем, getStackTrace() как и dumpStack() в итоге все равно упираются в new Exception().
В принципе, это технически можно провернуть с помощью кастомного принтера (туда приходит уровень лога, тэг и сообщение). Но лично я все равно фильтрую logcat'ом (точнее, надстройкой над ним).
Можно сделать собственный принтер логов. Например,

Log.usePrinter(new Printer() {
  public void print(int level, String tag, String msg) {
    Crashlytics.log(level, tag, msg);
  }
}, true).usePrinter(System.ANDROID, false);
Log.d("Hello"); // выведется в крэшлитикс
Смысл в легкой миграции. Если люди используют android.util.Log, то зачастую в их классах есть атрибут TAG (или tag). Если они перейдут на trikita.log.Log — то ожидаемо что теги по прежнему будут браться из атрибута TAG.
Спасибо. Проверил. Увы, разницы по быстродействию никакой. Хотя обычно говорят что new Throwable() даже быстрее — stackoverflow.com/questions/2347828/how-expensive-is-thread-getstacktrace
У него API совсем далекое от android.util.Log (а значит сложнее мигрировать). Да и как всегда, отсутствует вывод объектов через запятую без форматной строки (как console.log в js или log.Println в Go). Логеров много, каджый чем-то хорош. На вкус и цвет. Когда я писал свой — не было логгера с совместимым API и не было логгера для varargs через запятую без форматной строки. Теперь есть.
Да, неплохой и весьма популярный логгер. Кстати, упомянут в статье.
Меня лично в нем не устроило: отсутствие логгирования через запятую (только форматные строки), странноватое API (я понимаю, что это игра слов на тему лесорубов, но глазу непривычно), нет поддержки просто JVM (без android.util.Log).

(мимо, это должно было быть в ответ Suvitruf)
Да я к критике нормально отношусь — чем больше потенциальных ошибок я узнаю сейчас, тем меньше времени потрачу если бы сам наступал на эти грабли в будушем.

Кстати, внизу привел замеры скорости моего логгера и стандартного. Рефлексия конечно медленнее, но вполне приемлемо для логгера. Мы же как правило пишем логи несколько раз в секудну, не чаще.

А к энамам у меня какая-то нелюбовь в джаве. Они там как-то сбоку-припеку прикручены и все время вызывают настороженность (ни отнаследовать, ни расширить). Хотя в том же C я энамы люблю и регулярно использую.
Да, я про конечное время работы, пользователю-то важно не тормозит ли его приложение из-за корявого логгера.

Вообщем, я померял. Moto G 1st gen, середнячок, но не флагман. android.util.Log в среднем занимает 7-10 микросекунд на сообщение, trikita.log.Log в среднем занимает 40-50 микросекунд.

Признаю, рефлексия (ожидаемо) медленнее, практически на порядок, но в целом можно успеть записать 300 логов пока сменится один кадр при 60 fps. Так что я бы не сказал что потеря скорости логгера здесь критична.
Отнюдь. Не всё и не всегда замечаешь сам и сразу, так что за замечания — спасибо.

4. А существует ли более быстрый способ узнать имя вызывающего класса?
5. Упс. И ведь хотел сделать «utility class», а конструктор потерял где-то.
6. Наверняка enum идеологичнее, но сейчас я могу написать Log.level(Log.D), а с энамом будет чуть длинее. Разве только сам Log попробовать сделать энамом. А кстати в android.util.Log уровни сделаны константами, а не энамом.
Спасибо что заглянули в исходник!

1. Рефлексия — это плата за удобство использования. Timber кстати делает так же, использует рефлексию для поиска тега. К тому же считается что компиляторы неплохо оптимизируют рефлексию в наши дни. Можно конечно проделать бенчмарки чтобы доказать обратное. Но логирование даже без рефлексии считается небыстрым — там JNI вызовы, затем syscall (запись в лог-устройство).

2/3. А вот по поводу тред-сейфности вы дело говорите. Это точно надо бы исправить. Если хотите — можете багу открыть на гитхабе, чтобы не забылось.
Для людей делающих все из консоли или для любителей автоматизировать (требуется root доступ):
Можно получить *.hprof дамп сделав «adb shell kill -10 » для вашего dalvikvm-процесса. Стянув дамп из /data/misc к себе на компьютер с помощью adb pull его можно поизучать даже с помощью стандарной jvisualvm (standalone-приложение, кажется идет вместе с JDK, не требудет установки эклипса).
А не про них ли в июне после Google I/O все говорили и писали? habrahabr.ru/post/227641/ или habrahabr.ru/company/mailru/blog/232489/
Хм… Впервые вижу чтобы в списке редакторов отсутствовал vim.
Боюсь что языки и технологии с названиями длиннее пары слогов просто обречены на сокращение: javascript -> js, ruby on rails -> rails, visual basic .net -> vb.net, assembly -> asm, gnu emacs lisp -> elisp и т. д.
Да это же практически Scaloid только круче и на Kotlin! Спасибо, добрый человек, отзывчивых вам пользователей и легких багфиксов!

И сразу каверзный вопрос, а что с ActionBar, support классами и т.д? Потому что тот же скалоид застрял в этохе андроида 2.х без фрагментов.
Отлично, то что надо! Спасибо.
Спасибо за статью, приятно видеть что хороший язык уверенно идет вперед. Когда-то пытался прикрутить его к андроиду, тогда еще с Ant, сейчас вижу все стало еще проще с Gradle (http://zserge.com/blog/kotlin.html).

Но честно скажу что тогда сильно не хватало документации.Вопрос может глупый, но скажите — а есть что-то типа JavaDocs по стандартным классам языка?

А еще очень надоедало что почти все Android-классы приходилось писать со знаком вопроса, т.к. в java любой объект может быть null. Вопрос — планируется ли какая-нибудь обертка над Android SDK чтобы разработчикам не приходилось постоянно сталкиваться с java interoperability?

Ну а в целом язык классный, молодцы!

Information

Rating
Does not participate
Location
Украина
Date of birth
Registered
Activity