Андроид студио проверить наличие файла

Java: Проверьте, существует ли файл или каталог

Проверка наличия файла или каталога-простая и важная операция во многих задачах. В этой статье мы рассмотрим множество различных способов, которые вы можете использовать, чтобы проверить, существует ли файл или каталог, если это символическая ссылка, и недостатки этих подходов.

Автор: David Landup
Дата записи

Вступление

Проверка наличия файла или каталога-простая и важная операция во многих задачах. Перед доступом к файлу мы должны проверить, существует ли он, чтобы избежать исключения NullPointerException . То же самое касается каталогов.

Хотя некоторые функции могут создавать новый файл/каталог, если запрошенный не существует, это может быть противоположностью тому, что мы хотим. Если мы хотим добавить дополнительную информацию в существующий файл, а метод выполняется без предупреждения, так как он создает необходимый ему новый файл, мы, возможно, потеряли некоторую информацию, не осознавая этого.

Здесь у нас простая структура:

Там есть file.txt файл и symlink.txt файл. В symlink.txt файл представляет собой символическую ссылку на file.txt .

Аналогично, у нас есть каталог и символическая ссылка на него – directory_link .

Проверьте, существует ли файл

Для работы с классом Files вам необходимо ознакомиться с классом Path . Файлы принимает только Путь , а не Файл объекты.

Для целей этого урока мы определим Файл и Путь экземпляр для file.txt в нашем каталоге:

Файлы.существует()

Тем не менее, первый способ, которым мы можем проверить, существует ли файл, – это класс Files :

Запуск этого кода даст нам:

Файлы.Не существует()

Возможно, вам будет интересно, почему метод не существует() вообще существует:

Если существует() возвращает истину , это означает, что не существует() должно возвращать ложь . Они логически дополняют друг друга и A = !B , верно?

Ну, вот тут-то многие и ошибаются. Если Files.exists() возвращает false , это не должно означать, что файл не существует.

Это также может означать, что существование файла не может быть проверено . В этом случае оба Files.exists() и Files.notExists() вернут false , поскольку Java не может определить, существует файл или нет.

Обычно это происходит, если у вас есть файл, заблокированный таким образом, что Java не может получить к нему доступ. Представьте, что у нас есть файл, который заблокирован в нашем каталоге – lockedFile.txt :

И если бы мы попытались проверить его существование с помощью:

Нас встретили бы с:

Очевидно, что он существует, но Java не имеет разрешения на подтверждение этого в нашей системе, что приводит к противоречивым результатам.

Файлы.isRegularFile()

Кроме того, мы можем проверить, является ли файл обычным файлом ( false если это каталог) с помощью метода isRegularFile() :

На выходе получается:

Файл.isFile()

Вместо использования класса Files мы также можем выполнять методы для самих файловых объектов:

Файл.существует()

Аналогично предыдущему варианту, мы можем запустить метод exists() :

И это также возвращает:

Git Essentials

Ознакомьтесь с этим практическим руководством по изучению Git, содержащим лучшие практики и принятые в отрасли стандарты. Прекратите гуглить команды Git и на самом деле изучите это!

Разница между этими двумя заключается в том, что первый проверяет, является ли это файлом, а другой проверяет, существует ли он. В разных обстоятельствах они дали бы разные результаты.

Заблокированные Файлы

Забавно отметить, что если вы используете Файл для проверки существования, Java может определить, существует ли заблокированный ранее файл или нет:

Запуск этого фрагмента кода приведет к:

При этом очевидно, что заблокированный файл может быть прочитан с помощью класса File вместо вспомогательного класса Files .

Проверьте, существует ли Каталог

Каталоги-это, по сути, файлы, которые могут содержать другие файлы. Вот почему проверка того, является ли каталог файлом, вернет true . Хотя, если вы проверяете, является ли каталог каталогом (файл особого типа), вы получите более точный результат.

На этот раз мы меняем наше местоположение на:

Файлы.существует()

Опять же, как и в первом примере, мы можем проверить, существует ли он с помощью:

На выходе получается:

Files.isDirectory()

Если бы мы хотели проверить, является ли это конкретным каталогом, мы бы использовали:

И результат таков:

Примечание: Если каталог не существует , метод isDirectory() вернет false . Это связано с тем, как называется метод. Что он делает – он проверяет, существует ли файл и , если это каталог, а не только последний. Файл не может быть каталогом, если он не существует – следовательно, возвращается false .

Проверьте, является ли Файл символической ссылкой

Возможно, вы также захотите проверить, является ли файл просто символической ссылкой. В этом случае вы бы использовали класс Files .

Давайте переключим наше местоположение на:

Файлы.isSymbolicLink()

Как обычно, класс Files принимает Путь к файлу:

Запуск этого приведет к:

Файл.getCanonicalPath() против файла.getAbsolutePath()

Другой способ проверить наличие символической ссылки-сравнить результаты канонического пути к файлу и абсолютного пути. Если они разные, то, скорее всего, это символическая ссылка:

Поскольку мы проверяем наличие символической ссылки, и мы знаем, что это так, они должны возвращать другой результат – a symlink.txt и file.txt путь:

Однако здесь это не так. Это связано с тем, что символическая ссылка была создана в Windows с использованием NTFS (Файловая система новой технологии). Символическая ссылка была создана с помощью команды mklink в CMD.

Проверьте, Существует Ли Какой-Либо Из Них

Из предыдущих примеров очевидно, что метод Files.exists() вернет true как для существующих файлов, так и для каталогов. Хотя, это не работает лучше всего, когда дело доходит до заблокированных файлов.

С другой стороны, метод exists() из класса File также вернет true как для файлов, так и для каталогов и сможет прочитать заблокированный файл, который класс Files не может.

Вывод

Проверка наличия файлов и каталогов-это первая линия защиты от пропавших файлов и каталогов. Разные подходы имеют разные недостатки, и вы можете предположить, что метод вернет точный результат, но это не произойдет из-за того, как он работает в фоновом режиме.

Знание того, какие методы возвращают какие результаты и при каких обстоятельствах, позволит вам избежать неприятных исключений при обработке файлов.

После проверки того, существует ли ваш файл или нет, вы, скорее всего, захотите прочитать и записать файлы на Java .

Источник

Работа с файловой системой

Чтение и сохранение файлов

Работа с настройками уровня activity и приложения позволяет сохранить небольшие данные отдельных типов (string, int), но для работы с большими массивами данных, такими как графически файлы, файлы мультимедиа и т.д., нам придется обращаться к файловой системе.

ОС Android построена на основе Linux. Этот факт находит свое отражение в работе с файлами. Так, в путях к файлам в качестве разграничителя в Linux использует слеш «/», а не обратный слеш «\» (как в Windows). А все названия файлов и каталогов являются регистрозависимыми, то есть «data» это не то же самое, что и «Data».

Приложение Android сохраняет свои данные в каталоге /data/data/ / и, как правило, относительно этого каталога будет идти работа.

Для работы с файлами абстрактный класс android.content.Context определяет ряд методов:

boolean deleteFile (String name) : удаляет определенный файл

String[] fileList () : получает все файлы, которые содержатся в подкаталоге /files в каталоге приложения

File getCacheDir() : получает ссылку на подкаталог cache в каталоге приложения

File getDir(String dirName, int mode) : получает ссылку на подкаталог в каталоге приложения, если такого подкаталога нет, то он создается

File getExternalCacheDir() : получает ссылку на папку /cache внешней файловой системы устройства

File getExternalFilesDir(String type) : получает ссылку на каталог /files внешней файловой системы устройства

File getFileStreamPath(String filename) : возвращает абсолютный путь к файлу в файловой системе

FileInputStream openFileInput(String filename) : открывает файл для чтения

FileOutputStream openFileOutput (String name, int mode) : открывает файл для записи

Все файлы, которые создаются и редактируются в приложении, как правило, хранятся в подкаталоге /files в каталоге приложения.

Для непосредственного чтения и записи файлов применяются также стандартные классы Java из пакета java.io.

Итак, применим функционал чтения-записи файлов в приложении. Пусть у нас будет следующая примитивная разметка layout:

Поле EditText предназначено для ввода текста, а TextView — для вывода ранее сохраненного текста. Для сохранения и восстановления текста добавлены две кнопки.

Теперь в коде Activity пропишем обработчики кнопок с сохранением и чтением файла:

При нажатии на кнопку сохранения будет создаваться поток вывода FileOutputStream fos = openFileOutput(FILE_NAME, MODE_PRIVATE)

В данном случае введенный текст будет сохраняться в файл «content.txt». При этом будет использоваться режим MODE_PRIVATE

Система позволяет создавать файлы с двумя разными режимами:

MODE_PRIVATE : файлы могут быть доступны только владельцу приложения (режим по умолчанию)

MODE_APPEND : данные могут быть добавлены в конец файла

Поэтому в данном случае если файл «content.txt» уже существует, то он будет перезаписан. Если же нам надо было дописать файл, тогда надо было бы использовать режим MODE_APPEND:

Для чтения файла применяется поток ввода FileInputStream :

Подробнее про использование потоков ввода-вывода можно прочитать в руководстве по Java: https://metanit.com/java/tutorial/6.3.php

В итоге после нажатия кнопки сохранения весь текст будет сохранен в файле /data/data/название_пакета/files/content.txt

Где физически находится созданный файл? Чтобы увидеть его на подключенном устройстве перейдем в Android Stud в меню к пункту View -> Tool Windows -> Device File Explorer

После этого откроектся окно Device File Explorer для просмотра файловой системы устройства. И в папке data/data/[название_пакета_приложения]/files мы сможем найти сохраненный файл.

Источник

Использование Lint в Android Studio для проверки своего кода

Содержание

На практике в коде очень часто можно встретить очевидные ошибки, спустя какое-то время. Это может происходить из-за невнимательности при написании кода. Что бы свести такие ошибки к минимуму могут помочь статические анализаторы кода. Одним из таких анализаторов является Lint.

Lint — это статический анализатор кода, который сообщает о подозрительных или критических выражениях в коде. По факту это слово стало нарицательным и им называют анализаторы, которые сканируют код на наличие ошибок.

В Android Studio уже есть встроенные анализаторы кода, который дают подсказки “налету”.

Однако подсказки подсвечивают ошибки достаточно ненавязчиво и поэтому их легко пропустить. Но можно запустить проверку несколькими способами.

Способы запуска Lint.

Запуск через меню в Android Studio

Самый простой и удобный способ запуска проверки — это через Android Studio. Для этого в меню необходимо выбрать пункты Analyze -> Inspect Code. В появившемся окне можно ограничить область сканирования кода. Можно проверить весь проект, определённый модуль или отдельный взятый класс. На мой взгляд самый полезных из пунктов — это проверка не закоммиченых файлов. Так же можно выбрать профиль с набором правил для проверки.

После выбора настроек можно начать проверку по нажатию на кнопку Ок. Когда проверка закончиться то появиться окно в котором все ошибки, и предупреждения будут выведены в специальном окне. Все замечания удобно собраны по типам с кратким описание причины и решением проблемы.

Запуск через командную строку

Так же проверку можно запустить через gradle выполнив в консоли команду:

После проверки сформируется отчёт в формате html, который можно посмотреть по следующему пути:

Этот способ менее удобный чем первый, так как отчёт формируется в отрыве от студии и для правки ошибок нужно постоянно переключаться между отчётом и IDE. Зато этот способ прекрасно подходит для случаев если проверку осуществляется на сервере, а в случае обнаружение ошибок, прикреплять файл с отчётом к письму.

Запуск при сборке проекта.

Можно автоматизировать запуск проверки lint, который будет осуществлять при каждой сборке проекта. Для этого необходимо зайти в настройки запуска проекта:

Добавить следующую строку:

Этот способ менее предпочтительный так как значительно замедлит скорость сборки и разработки.

Настройка gradle сборки

Так же lint проверку можно настроить в gradle файле.

• abortOnError: В случае обнаружение ошибки прекращается проверка.
• warningsAsErrors: определяет предупреждения как ошибки.
• lintConfig: путь к файлу проекта с настройками lint.

Если опция abortOnError включена, то при запуске сборки через gradle в случае обнаружении ошибки произойдёт исключение:

Настройка правил проверки lint

Отредактировать правила lint можно в настройках Android studio. Там же можно сделать отдельный конфигурационный профиль и использовать его.

Отключение проверки Lint с помощью анотаций в коде

Иногда бывают исключения, и может сложиться ситуация что необходимо отключить проверку какого-либо правила проверки для класса или метода. В Java коде это делается через аннотацию @SuppressLint(“NewApi”). В качестве параметра принимает строку названия проверки которую нужно исключить. Если нужно исключить все правила, то можно использовать следующую аннотацию:

Так же проверку можно обойти в xml файлах с помощью аттрибута tools:ignore=“NewApi,StringFormatInvalid”.

Выводы

В данной статье мы рассмотрели основные способы запуска проверки кода. Lint очень полезный инструмент для контроля за качеством кода, которым можно и нужно пользоваться.

Источник