Да единицу я не там просто разглядел. Рано утром смотрел, показалось, что в начале long единица, а в конце литерала L, а там на самом деле наоброт.
Что касается автоупаковки, я имел в виду случай вроде этого (случай, разумеется, надуманный, чтобы было нагляднее):
Long year = 201L;
for (int offset = 0; offset < 100; offset++) {
year += offset;
}
В первой строчке запакуется только один раз, что ни на что особенно не повлияет, но потом каждый раз будет распаковываться, когда нужно что-то сделать со значением.
Значит, я даже с масштабом не там единичку разглядел. Ещё удивился насчёт типов.
Константа тут, мне кажется, не очень поможет. Если прописать в названии число, то тогда потом, когда оно поменяется, придётся её переименовывать, что не очень хорошо. А если не прописать, то тогда и разницы между константой и переменной особенно нет. Неоднозначность тут убирает именно заглавная L. Я сам обычно в литералах чисел строчные вообще не пишу, чтобы такая проблема не возникала.
Я не очень понял насчёт заглавной L (пока что не прорешал задачи, надо сделать это обстоятельно, а не наспех), но если имеется в виду Long вместо long, то это совершенно не одно и то же, и так без нужды делать не стоит. Первое — объект, а второе — примитивный тип. В вычислениях объект придётся превращать в примитивный тип, и это вызовет ненужные проблемы с эффективностью кода. А если результат нужно будет записать обратно в переменную, то ещё и создастся новый объект в процессе автоупаковки.
Насчёт неоднозначности поведения всё, к сожалению, очень непросто. Если разработчик не написал документацию, то это лишь отчасти восполняется визитом в исходники. Да, как библиотека ведёт себя сейчас, ты узнаешь. Но можно ли полагаться, что это поведение останется таким и дальше? Автор возьмёт и поменяет что-то в следующей версии, и у меня код начнёт работать неправильно. Без документации не угадаешь, какое поведение библиотеки остаётся неизменным, а какое нет, потому что это знают только авторы. Именно поэтому, например, StackOverflow никогда не будет являться полноценной заменой документации, а всегда будет лишь дополнять (если только разработчики библиотек не начнут там оставлять официальные ответы).
Вот практический пример: работаю в Android с AlertDialog, при нажатии на кнопку меня уведомляют, что кнопка была нажата, и ещё отдельно о том, что диалог был убран с экрана. Мне важен порядок, в котором эти вызовы происходят. В документации ничего не написано. Я посмотрел исходники и проверил опытным путём, допустим, для Android 4.4, какой порядок у этих обратных вызовов. ОК. А он такой же в каждой остальной версии? Не знаю. А в новых версиях он тоже останется таким же? Тоже не знаю, и если с предыдущими версиями ещё можно разобраться, потратив тучу времени, то о новых версиях никто, кроме разработчиков, мне не расскажет.
Одним словом, если документации нет, то чтение исходников как-то помогает, но проблему полностью не решает. Документация всё равно нужна, вне зависимости от наличия исходников и времени на их изучение.
Могу перечислить проблемы с дроплетами и действиями:
Нет работы с относительными путями;
Нет работы с префиксами ("_normal", "_focused", "_disabled" и т.п.);
Невозможна обработка nine-patch;
Нельзя автоматически генерировать XML.
Самые важные — это первые два пункта: нет поддержки относительных путей, и в каждом отдельном дроплете один постфикс на все про все. В итоге даже в самом простом случае это означает, что на каждую пиксельную плотность и для каждого проекта нужно писать по дроплету, потому что финальная папка должна быть прописана заранее, абсолютным путем. Можно, конечно, и так делать, но что это за автоматизация?
А если в ресурсе несколько состояний, то нужно писать по дроплету еще и на состояние кнопки в определенной пиксельной плотности. Если у нас 5 плотностей и 6 состояний кнопки, это 5 × 6 = 30 дроплетов, что уже вообще никуда не годится.
У меня дело не только в векторе, мне еще нужно применять стили и обрабатывать nine-patch. Изначально-то, конечно, все и у меня примерно так же было: есть изображение, надо сохранить в разных размерах. Но каждую кнопку рисовать в нескольких состояниях — это довольно утомительно. Значит, нужно создавать применение стилей. Еще нужно сделать кнопки растягиваемые — делаю обработку nine-patch. Потом надоело XML прописывать вручную — пишу код, чтобы он генерировался сам. Вот так и получилось то, что есть в итоге.
Раньше, кстати, еще была необходимость в том, чтобы иконки рисовались под разные версии Android. Например, на версии 2.3 и ранее были меню, где использовались те же иконки, которые сейчас сидят в панели действий. Но требования к их стилю были другие, поэтому надо было еще сохранять по два варианта иконки на каждый. Сейчас Google наконец-то сделали официальную библиотеку, в которой есть поддержка панели действий на Android 2.1 и выше, так что теперь нужда в этом точно отпала. А кроме меню были еще те же самые проблемы и у других элементов, таких как иконки для уведомлений и вкладок. К счастью, это тоже уже перестало быть нужным, и довольно давно, особенно в случае вкладок.
Интересный инструмент, кстати. Когда я смотрел на то, что вообще доступно на эту тему, мне он не попадался. Но там автоматизация, насколько я понял, несколько другого рода, да и стили он сам не применяет. У меня-то как бывает: я нарисую несколько иконок, просто один слой в каждом файле. Потом в скрипте описываю, какие стили слоя я хочу видеть для каждого состояния, применяю сразу ко всем иконкам, и у меня на выходе из каждого однослойного документа сразу штук 30 автоматически сгенерированных ресурсов. А там, судя по описанию, стили надо вручную рисовать для каждой иконки и ставить по отдельному слою на состояние. Это все равно прилично работы.
longединица, а в конце литерала L, а там на самом деле наоброт.Что касается автоупаковки, я имел в виду случай вроде этого (случай, разумеется, надуманный, чтобы было нагляднее):
В первой строчке запакуется только один раз, что ни на что особенно не повлияет, но потом каждый раз будет распаковываться, когда нужно что-то сделать со значением.
Константа тут, мне кажется, не очень поможет. Если прописать в названии число, то тогда потом, когда оно поменяется, придётся её переименовывать, что не очень хорошо. А если не прописать, то тогда и разницы между константой и переменной особенно нет. Неоднозначность тут убирает именно заглавная L. Я сам обычно в литералах чисел строчные вообще не пишу, чтобы такая проблема не возникала.
Longвместоlong, то это совершенно не одно и то же, и так без нужды делать не стоит. Первое — объект, а второе — примитивный тип. В вычислениях объект придётся превращать в примитивный тип, и это вызовет ненужные проблемы с эффективностью кода. А если результат нужно будет записать обратно в переменную, то ещё и создастся новый объект в процессе автоупаковки.Вот практический пример: работаю в Android с AlertDialog, при нажатии на кнопку меня уведомляют, что кнопка была нажата, и ещё отдельно о том, что диалог был убран с экрана. Мне важен порядок, в котором эти вызовы происходят. В документации ничего не написано. Я посмотрел исходники и проверил опытным путём, допустим, для Android 4.4, какой порядок у этих обратных вызовов. ОК. А он такой же в каждой остальной версии? Не знаю. А в новых версиях он тоже останется таким же? Тоже не знаю, и если с предыдущими версиями ещё можно разобраться, потратив тучу времени, то о новых версиях никто, кроме разработчиков, мне не расскажет.
Одним словом, если документации нет, то чтение исходников как-то помогает, но проблему полностью не решает. Документация всё равно нужна, вне зависимости от наличия исходников и времени на их изучение.
Самые важные — это первые два пункта: нет поддержки относительных путей, и в каждом отдельном дроплете один постфикс на все про все. В итоге даже в самом простом случае это означает, что на каждую пиксельную плотность и для каждого проекта нужно писать по дроплету, потому что финальная папка должна быть прописана заранее, абсолютным путем. Можно, конечно, и так делать, но что это за автоматизация?
А если в ресурсе несколько состояний, то нужно писать по дроплету еще и на состояние кнопки в определенной пиксельной плотности. Если у нас 5 плотностей и 6 состояний кнопки, это 5 × 6 = 30 дроплетов, что уже вообще никуда не годится.
Раньше, кстати, еще была необходимость в том, чтобы иконки рисовались под разные версии Android. Например, на версии 2.3 и ранее были меню, где использовались те же иконки, которые сейчас сидят в панели действий. Но требования к их стилю были другие, поэтому надо было еще сохранять по два варианта иконки на каждый. Сейчас Google наконец-то сделали официальную библиотеку, в которой есть поддержка панели действий на Android 2.1 и выше, так что теперь нужда в этом точно отпала. А кроме меню были еще те же самые проблемы и у других элементов, таких как иконки для уведомлений и вкладок. К счастью, это тоже уже перестало быть нужным, и довольно давно, особенно в случае вкладок.
createFile, которую я не приводил.