Unit 5
Unit 5
When you install an app on your phone, the Android operating system will
give you some form of secret internal storage where the app can store its
private data. No other application has access to this information. When you
uninstall an application, all of the data associated with it is also removed.
To save a file to the internal storage, you must first obtain it from the internal
directory. You can do this by calling the getFilesDir() or getCacheDir()
methods. The getFilesDir() method returns the absolute path to the directory
where files are created on the filesystem. getCacheDir() returns the absolute
path to the filesystem’s application-specific cache directory.
When Should Internal Storage Be Used?
The internal storage can be used when you need some confidential data for
your application. Another thing to keep in mind is that if your app is storing
data that may be utilized by other apps, you should avoid using internal
storage since when you remove the app, all of your data will be gone, and
other apps will never have access to that data. For instance, if your app is
downloading a pdf or storing an image or video that might be used by other
apps, you shouldn’t use internal storage.
You can use the shared preferences if you only have a little amount of data to
keep and don’t want to use the internal storage. Shared Preferences are used to
store data in a key-value format, which means you’ll have one key and the
associated data or value will be stored depending on that key. The data saved
in the shared preferences will remain with the application until you delete it
from your phone. All shared preferences will be deleted from the device if you
uninstall the application.
When Should Shared Preferences Be Used?
You can utilize the shared preference in your application when the data you
want to store is relatively little. It’s not a good idea to save more than 100
kilobytes of data in shared preferences. In addition, if you wish to keep tiny
and private data, you can use Android’s shared preferences.
Databases are collections of data that are organized and saved for future use.
Using a Database Management System, you can store any type of data in your
database. All you have to do is establish the database and use one query to
perform all of the operations, such as insertion, deletion, and searching. The
query will be passed to the database, which will return the desired output. In
Android, an SQLite database is an example of a database.
When should you utilize a database?
A database is useful when you need to keep track of structured data. A
database can hold any type of information. So, if your data is large and you
want to retrieve it quickly, you can use a database and store it in a structured
style.
Share data between applications using Content Providers
By using the content provider, data can be shared across applications. The
content provider is a set of data wrapped up in a custom API to read and write.
Applications/Processes have to register themselves as a provider of data. Other
applications can request Android to read/write that data through a fixed API.
Content provider API has methods to perform operations(CRUD) on data.
Contacts are the best example – that exposes user information to other
applications, Media store-Allows other applications to access, store media files.
1. content:// – The content provider URIs should start with this value.
2. ‘authority’ – This is Java namespace of the content provider implementation
passes the Java package name.
3. ‘path’ – This is a virtual directory within the provider that identifies, what
kind of data being requested.
4. ‘id’ – This is an optional part that specifies the primary key of a record being
requested. This part can be ignored to access all data.
Applying CRUD operations:
Add data:
We need to override insert() method. If data inserted successful, it will return
the URI value with the associated with ID.
For example: If we passed – content://packageName/sample
Method will return content://packageName/sample/1
Updating data:
update() method of the ContentProvider is used to update records.
This method will return the number of rows updated.
Deleting data:
delete() method of the ContentProvider will return the number of records
deleted.Restering the provider in AndroidManifest.xml:
We need to register the content providers in the AndroidManifest.xml.
<provider
android:name=".MyProvider"
android:authorities="packageName.MyProvider">
</provider>
1
1. a = 4 // It is Idempotence, as final value(a = 4)
2
// would not change after executing it multiple
3
// times.
4
5
2. a++ // It is not Idempotence because the final value
6
// will depend upon the number of times the
7
// statement is executed.
Request and Response
Now we will see how request and response work for
different HTTP methods. Let’s assume we have
an API( https://www.geeksforgeeks.org/api/students ) for all students data
of gfg.
GET: Request for all Students.
Request
GET:/api/students
POST:/api/students
{“name”:”Raj”}
PUT or PATCH:/api/students/1
{“name”:”Raj”}
DELETE:/api/students/1
RESTful web services are very popular because they are light weight,
highly scalable and maintainable and are very commonly used to create
APIs for web-based applications.
What is Telephony?
Telephony Applications:
Dialer
Contacts
Messaging — SMS/MMS(BasicSmsReceiver)
Settings app — a) Airplane mode b) APN settings C)Network selection
(auto/manual) d) Call settings, such as, call waiting, call forwarding/diverting e)
CLIR f)FDN
SIM Application Toolkit (SAT)
Browser
CellBroadcastReceiver
CarrierConfig
PhoneCommon
as per Android P. The responsibility of the framework is to expose API’s for the
upper mentioned telephony applications and communicate with below layers.
/frameworks/base/telephony/java/com/android/internal/telephony/
/frameworks/base/telephony/java/android/telephony/
Your Android app is deployed when you run it on an Android target device.
You can also use the Deployment Manager to manage the deployed files. After
your Android application is ready for final deployment, you can proceed to
build and sign your application. See Deploying Your Signed Android
Application.
Configuring the Options for Deploying Your Android App
You must configure several options for your Android app before you build the
application for distribution. The properties that you configure are bundled with
your application, in the AndroidManifest.xml file. You cannot modify these
properties after you build and sign your application. Because these properties
provide key information about your application, you should ensure that they
contain the correct values before you deploy your application, or you might
have to rebuild your application in order to change the configured values.
Before each release of your Android application, you should check that every
setting is properly configured.
To configure your Android app:
On the Project > Options > Application page, provide the icons and
images to represent your application.
On the Project > Options > Version Info page, increase the version code of
your application. Application stores such as Google Play may require that
newer versions of your application always have a higher version code than
previous versions.
On the Project > Options > Uses Permissions page, define the permissions
that your application requires to work.
On the Project > Options > Provisioning page, select in Target the build
configuration that you want to use to deploy your application (for
example, Release) and provide a KeyStore file if you have not already
created one. This step is necessary in order to install your application in a
device that has USB debugging disabled and to distribute your application to
others. For more information about keystore files,
see: http://docs.oracle.com/javase/1.5.0/docs/api/java/security/KeyStore.htm
l.
Customizing Your AndroidManifest.xml File
RAD Studio writes the options of your Android application to a special
Android file, AndroidManifest.xml, which is included in your final Android
package when you deploy your application for Android. This file defines things
such as the version code or display name of your application, the list of
permissions that your application requires, and so on.
Usually, you do not need to touch this file, and you can let RAD Studio take
care of everything for you. However, RAD Studio allows you to customize the
content of the AndroidManifest.xml file if you need to include custom data in
this file that you can not define visually in your project options.
When you build an application for the Android target platform for the first time,
RAD Studio adds a file to your project folder: AndroidManifest.template.xml.
Whenever you build your application for Android, RAD Studio reads this file,
replaces some placeholders in the file with actual values from your project
options, and writes the resulting content into an output file: Android\<build
configuration>\AndroidManifest.xml. This output file is the
AndroidManifest.xml file that is included in the Android package that RAD
Studio generates when you deploy your application for the Android target
platform.
To customize the output AndroidManifest.xml file of a single project, edit the
content of AndroidManifest.template.xml.
The AndroidManifest.template.xml file that RAD Studio adds to a project when
you build that project for the Android target platform for the first time comes
from %AppData%\Embarcadero\BDS\<n.n>\AndroidManifest.xml. If you want
your new projects to have a different starting AndroidManifest.template.xml
file, edit this file.