Pro Android with Kotlin

58
CHAPTER 5: Broadcasts
// do s.th. when receiving...
}
}
val ifi: IntentFilter =
IntentFilter("de.pspaeth.myapp.DO_STH")
registerReceiver(bcReceiver, ifi,
"com.xyz.theapp.PERMISSION1", null)
}
override fun onDestroy() {
super.onDestroy()
unregisterReceiver(bcReceiver)
}
In addition, you must both define the permission and declare using it in the receiver’s 
manifest file.
...
"com.xyz.theapp.PERMISSION1" />
"com.xyz.theapp.PERMISSION1" />
...
Again, for noncustom permissions, you don’t need to use the 
 element. For 
more about permissions, see Chapter 
7
.
Sending Broadcasts from the Command Line
For devices you can connect to via the Android Debug Bridge (ADB), you can use a shell 
command on your development PC to send a broadcast message (see Chapter 
18
). Here’s 
an example of sending an action de.pspaeth.myapp.DO_STH to the dedicated receiver 
MyReceiver of the package de.pspaeth.simplebroadcast (this is an explicit broadcast 
message):
./adb shell am broadcast -a de.pspaeth.myapp.DO_STH \
de.pspaeth.simplebroadcast MyReceiver
To get a complete synopsis of sending broadcasts in this way, you can use the shell as follows:
./adb shell am
This command will show you all the possibilities to create broadcast messages and do other 
things using that am command.
Note As an additional means to improve security, in applicable cases you can use
Intent.setPackage() to restrict possible receivers.

---

59
CHAPTER 5: Broadcasts
Random Notes on Broadcasts
Here is some additional information about broadcasts:

You can register and unregister programmatically managed receivers 
also in the callback methods onPause() and onResume(). Obviously, 
registering and unregistering will then happen more often compared to 
using the onCreate() / onDestroy() pair.

A currently executing onReceive() method will upgrade the process 
priority to “foreground” level, preventing the Android OS from killing the 
receiving process. It would then happen only under extreme resource 
shortage conditions.

If you have long-running processes inside onReceive(), you might think 
of running them on a background thread, finishing onReceive() early. 
However, since the process priority will be reverted to the normal level 
after finishing onReceive(), your background process is more likely to 
be killed, breaking your app. You can prevent this by using Context.
goAsync() and then starting an AsyncTask (inside at the end you must 
call finish() on the PendingResult object you got from goAsync() to 
eventually free resources), or you can use a JobScheduler.

Custom permissions, like we used in the “Securing Implicit Broadcasts” 
section, get registered when the app gets installed. Because of that, the 
app defining the custom permissions must be installed prior to the apps 
using them.

Be cautious with sending sensitive information through implicit 
broadcasts. Potentially malicious apps may try to receive them as well. 
At the least, you can secure the broadcast by specifying permissions on 
the sender side.

For clarity and to not mess up with other apps, always use namespaces 
for broadcast action and permission names.

Avoid starting activities from broadcasts. This contradicts Android 
usability principles.

---

61
© Peter Späth 2018 
P. Späth, Pro Android with Kotlin, 
https://doi.org/10.1007/978-1-4842-3820-2_6
Chapter
6
Content Providers
This chapter will cover content providers.
The Content Provider Framework
The content provider framework allows for the following:

Using (structured) data provided by other apps

Providing (structured) data for use by other apps

Copying data from one app to another

Providing data to the search framework

Providing data to special data-related UI widgets

Doing all that by virtue of a well-defined standardized interface
The data communicated can have a strictly defined structure, such as the rows from a 
database with defined column names and types, but it can also be files or byte arrays 
without any semantics associated.
If the requirements of your app concerning data storage do not fit in any of the previous 
cases, you don’t need to implement content provider components. Use the normal data 
storage options instead.
Note It is not strictly forbidden for an app to provide data to its own components or use its own 
data provider for accessing content; however, when looking at content providers, you usually think 
of inter-app data exchange. But if you need it, you always can consider intra-app data exchange 
patterns as a straightforward special case of inter-app communication.

---