Data sharing android studio

SharedPreferences

Чтобы получить экземпляр класса SharedPreferences для получения доступа к настройкам в коде приложения используются три метода:

• getPreferences() — внутри активности, чтобы обратиться к определённому для активности предпочтению;
• getSharedPreferences() — внутри активности, чтобы обратиться к предпочтению на уровне приложения;
• getDefaultSharedPreferences() — из объекта PreferencesManager, чтобы получить общедоступную настройку, предоставляемую Android.

Все эти методы возвращают экземпляр класса SharedPreferences, из которого можно получить соответствующую настройку с помощью ряда методов:

• getBoolean(String key, boolean defValue)
• getFloat(String key, float defValue)
• getInt(String key, int defValue)
• getLong(String key, long defValue)
• getString(String key, String defValue)

Обратите внимание, что тип double не поддерживается.

Чтобы создать или изменить Общие настройки, нужно вызвать метод getSharedPreferences в контексте приложения, передав имя общих настроек (имя файла):

По умолчанию используется MODE_PRIVATE — только приложение имеет доступ к настройкам. Также существуют другие режимы, с которыми практически не встречался.

• MODE_APPEND — присоединяет новые настройки к существующим
• MODE_ENABLE_WRITE_AHEAD_LOGGING
• MODE_MULTI_PROCESS
• MODE_WORLD_READABLE — позволяет другим приложениям читать настройки
• MODE_WORLD_WRITEABLE — позволяет другим приложениям записывать новые настройки

Для любознательных могу добавить, что файлы настроек хранятся в каталоге /data/data/имя_пакета/shared_prefs/имя_файла_настроек.xml. Поэтому в отладочных целях, если вам нужно сбросить настройки в эмуляторе, то при помощи перспективы DDMS, используя файловый менеджер, зайдите в нужную папку, удалите файл настроек и перезапустите эмулятор, так как эмулятор хранит данные в памяти, которые он сбрасывает в файл. На устройстве вы можете удалить программу и поставить ее заново, то же самое можно сделать и на эмуляторе, что бывает проще, чем удалять файл настроек вручную и перезапускать эмулятор.

Если открыть файл настроек текстовым редактором, то можно увидеть приблизительно такое:

В данном случае в настройках хранятся только строковые значения.

Сохранение значений параметров

Для удобства создадим константу для имени файла настроек, например:

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

Когда вы определили названия параметров, то можете сохранять любые значения этих параметров. Для этого создаём переменную, представляющую экземпляр класса SharedPreferences:

Внутри метода onCreate() вы инициализируете эту переменную:

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

Чтобы внести изменения в настройки (редактировать), нужно использовать класс SharedPreferences.Editor. Получить объект Editor можно через вызов метода edit объекта SharedPreferences, который вы хотите изменить. После того, как вы внесли все необходимые изменения, вызовите метод commit() или apply() объекта Editor, чтобы изменения вступили в силу. Метод apply() появился в API 9 и работает в асинхронном режиме, что является более предпочтительным вариантом. Метод commit() приходится использовать для старых версий и кроме того, он возвращает значение true в успешном случае и false в случае ошибки. Если вам надо отслеживать ошибки, то используйте его.

Предположим, что у нас есть два текстовых поля, где пользователь должен ввести имя кота и его и возраст. Чтобы сохранить параметр, нужно получить текст, который ввел пользователь, через метод getText().toString():

Получив нужный текст, сохраняем его через метод putString() (есть также putLong(), putBoolean() и т.п.):

Как правило, параметры сохраняют в методах активности onPause() или onStop() в тех случаях, когда данные требуются сохранить между запусками приложения. Но могут быть и другие сценарии.

Чтение значений параметров

Для считывания данных при загрузке приложения обычно используют методы onCreate() или onResume(). Нам нужно получить доступ к настройкам программы и проверить, есть ли среди них нужный нам параметр. Нас интересует ключ Nickname. Если мы его найдём, то загрузим его значение в текстовое поле.

В этих строчках кода мы проверили существование параметра APP_PREFERENCES_NAME и получили его значение через getString(), передавая ключ и значение по умолчанию (используется в том случае, если для данного ключа пока что не сохранено никакое значение). Осталось только загрузить полученный результат в текстовое поле.

Аналогично поступаем и с другими параметрами через методы get () (getLong, getBoolean() и т.д.).

Если вам ещё не понятно, то ниже исходный код:

Показать код (щелкните мышкой)

Можно получить ассоциативный массив со всеми ключами и значениями через метод getAll(). После этого можно проверить наличие конкретного ключа с помощью метода contains().

Очистка значений

Для очистки значений используйте методы SharedPreferences.Editor.remove(String key) и SharedPreferences.Editor.clear().

Методы getStringSet() и putStringSet()

Начиная с API 11, у класса SharedPreferences появился новый метод getStringSet(), а у класса SharedPreferences.Editor родственный ему метод putStringSet(). Данные методы позволяют работать с наборами строк, что бывает удобно при большом количестве настроек, которые нужно сразу записать или считать.

Удаление файла

Как я уже сказал, файл настроек хранится в /data/data/имя_пакета/shared_prefs/имя_файла_настроек.xml. Вы можете удалить его программно, например так:

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

Метод getPreferences() — Сохранение состояния активности

Если вы хотите сохранить информацию, которая принадлежит активности и не должна быть доступна другим компонентам (например, переменным экземпляра класса), вы можете вызвать метод Activity.getPreferences() без указания названия Общих настроек. Доступ к возвращённому ассоциативному массиву Общих настроек ограничен активностью, из которой он был вызван. Каждая активность поддерживает только один безымянный объект Общих настроек.

Сохранение настроек на SD-карту

Сам файл с настройками хранится в системе и обычному пользователю он не виден. Если вам понадобится получить все значения, хранимые в настройках, то вы можете считать все данные при помощи метода getAll() и записать их в файл, который можно сохранить на SD-карте:

Я у тебя первый?

Предположим, вы хотите выводить пользователю какую-то информацию при первом запуске приложения (краткую инструкцию, заставку и т.п.).

Запомнить пользователя

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

Запомнить состояние переключателей

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

Код, который отслеживает выбор переключателя и записывает состояние в настройки.

getDefaultSharedPreferences()

В используемых примерах я использовал getSharedPreferences() с придумыванием имени файла для хранения настроек. Этот способ придаёт гибкости в том случае, когда вам нужно создать несколько отдельных файлов. Но если вам нужен один файл, то можно ничего не придумывать, а использовать метод getDefaultSharedPreferences() из объекта PreferencesManager. Система сама сгенерирует имя файла из имени вашего пакета с добавлением слова _preferences. Вот как выглядит связка из трёх методов в исходниках Android (обратите внимание на выделенный текст).

Поэтому примеры можно переделать следующим образом.

Удаляем файл настроек

В API 24 появился новый метод, позволяющий удалить сам файл настроек. До этого можно было удалить своими силами, зная его местоположение. Поэтому универсальный код будет приблизительно следующим.

Источник

Sharing Content between Android apps

Sharing is caring, as they say, but sharing on Android means something perhaps slightly different. ‘Sharing’ is really shorthand for sending content such as text, formatted text, files, or images between apps.

So if ‘sharing’ == sending content, it makes slightly more sense that it is implemented using ACTION_SEND (or ACTION_SEND_MULTIPLE) Intents and its dozen extras.

While that approach is perfectly valid, I prefer to use ShareCompat, a set of classes in the v4 Support Library designed to make it easy to build intents for sharing content.

Sharing text

Sharing plain text is, as you might imagine, a good place to start. In fact, there’s not a whole lot to it:

ShareCompat.IntentBuilder uses a fluent API where you can chain together multiple method calls, using only the ones you need. For sharing, one of the most important parts is picking the right mime type — this is how apps filter what type of content they can receive. By using text/plain, we signify that our Intent will only contain plain text. Then, of course, setText() is how we actually add the CharSequence to the Intent to send. And while you can certainly send styled text using setText(), there’s no guarantee that the receiving app will honor that styling, so you should ensure that the text is legible with or without styling.

You’ll note we then use resolveActivity() before calling startActivity(). As mentioned in Protecting Implicit Intents with Runtime Checks, this is critical to prevent an ActivityNotFoundException when there is no Activity available to handle the mime type you have selected. While probably not as much of a concern with text/plain, it may be much more common with other types.

Note: when you use startActivity(shareIntent), that respects any default apps the user has set (i.e., if they’ve previously selected sharing all “text/plain” items to a certain app). If you’d like to instead always show a disambiguation chooser, use the intent generated from IntentBuilder.createChooserIntent() as explained in the ACTION_CHOOSER documentation.

Sharing HTML text

Some apps, most notably email clients, also support formatting with HTML. The changes, compared to plain text, are fairly minor:

The differences here are that we use of setHtmlText() in place of setText() and a mime type of text/html replacing text/plain. Here ShareCompat actually does a little bit extra: setHtmlText() also uses Html.fromHtml() to create a fallback formatted text to pass along to the receiving app if you haven’t previously called setText() yourself.

Given that many of the apps that can receive HTML text are email clients, there’s a number of helper methods to set the subject, to:, cc:, and bcc: email addresses as well — consider adding at least a subject to any share intent for best compatibility with email apps.

Of course, you’ll still want to call resolveActivity() just as before — nothing changes there.

Receiving text

While the focus so far has been on the sending side, it is helpful to know exactly what is happening on the other side (if not just to build a simple receiving app to install on your emulator for testing purposes). Receiving Activities add an intent filter to the Activity:

The action is obviously the more critical part — without that there’s nothing that would denote this as an ACTION_SEND (the action behind sharing). The mime type, same as with our sending code, is also present here. What isn’t as obvious are the two categories. From the element documentation:

Note: In order to receive implicit intents, you must include the CATEGORY_DEFAULT category in the intent filter. The methods startActivity() and startActivityForResult() treat all intents as if they declared the CATEGORY_DEFAULT category. If you do not declare it in your intent filter, no implicit intents will resolve to your activity.

So CATEGORY_DEFAULT is required for our use case. Then, CATEGORY_BROWSABLE allows web pages to natively share into apps without any extra effort required on the receiving side.

And to actually extract the information from the Intent, the useful ShareCompat.IntentReader can be used:

Similar to IntentBuilder, IntentReader is just a simple wrapper that make it easy to extract information.

Sharing files and images

While sending and receiving text is straightforward enough (create text, include it in Intent), sending files (and particularly images — the most common type by far) has an additional wrinkle: file permissions.

The simplest code you might try might look like

And that almost works — the tricky part is in getting a Uri to the File that other apps can actually read, particularly when it comes to Android 6.0 Marshmallow devices and runtime permissions (which include the now dangerous READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE permissions).

My plea: don’t use Uri.fromFile(). It forces receiving apps to have the READ_EXTERNAL_STORAGE permission, won’t work at all if you are trying to share across users, and prior to KitKat, would require your app to have WRITE_EXTERNAL_STORAGE. And really important share targets, like Gmail, won’t have the READ_EXTERNAL_STORAGE permission — so it’ll just fail.

Instead, you can use URI permissions to grant other apps access to specific Uris. While URI permissions don’t work on file:// URIs as is generated by Uri.fromFile(), they do work on Uris associated with Content Providers. Rather than implement your own just for this, you can and should use FileProvider as explained in the File Sharing Training.

Once you have it set up, our code becomes:

Using FileProvider.getUriForFile(), you’ll get a Uri actually suitable for sending to another app — they’ll be able to read it without any storage permissions — instead, you are specifically granting them read permission with FLAG_GRANT_READ_URI_PERMISSION.

Note: we don’t call setType() anywhere when building our ShareCompat (even though in the video I did set it). As explained in the setDataAndType() Javadoc, the type is automatically inferred from the data URI using getContentResolver().getType(uriToImage). Since FileProvider returns the correct mime type automatically, we don’t need to manually specify a mime type at all.

If you’re interested in learning more about avoiding the storage permission, consider watching my Forget the Storage Permission talk or at least go through the slides, which covers this topic in depth at 14:55 (slide 11).

Receiving files

Receiving files isn’t too different from text because you’re still going to use ShareCompat.IntentReader. For example, to make a Bitmap out of an incoming file, it would look like:

Of course, you’re free to do whatever you want with the InputStream — watch out for images that are so large you hit an OutOfMemoryException. All of the things you know about loading Bitmaps still apply.

The Support Library is your friend

With both ShareCompat (and its IntentBuilder and IntentReader) and FileProvider in the v4 Support Library, you’ll be able to include sharing text, HTML text, and files in your app with the best practices by default.

Источник