0% found this document useful (0 votes)
14 views13 pages

Unit 5

mobile application development

Uploaded by

Sindhu Raji
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
14 views13 pages

Unit 5

mobile application development

Uploaded by

Sindhu Raji
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 13

Storage System to Store Data in Android

Internal storage, external storage, shared preferences, database, and shared


storage are some of the storage options offered by Android.
Let’s begin with the internal storage system. We create several variables for
storing various data that are used in an Android application when developing
it. For example, we can utilize a variable to save data from a remote database
and then use that variable throughout the application. These variables,
however, are in-app storage, which means they will be visible to you while the
app is operating. When the application is ended, all of the data in the variable
is wiped, and you are left with nothing. Those variables will be created again
when you start the application, and new values can be saved in those variables.

1. Storage on the Inside

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.

2. External Hard Drives

Most Android devices have relatively low internal storage. As a result, we


keep our data on an external storage device. These storage units are accessible
to everyone, which means they can be accessed by all of your device’s
applications. You can also access the storage by connecting your mobile
device to a computer. You must obtain the READ EXTERNAL
STORAGE permission from the user in order to gain access to the external
storage. As a result, any application with this permission has access to your
app’s data.
When is it appropriate to use external storage?
You can use external storage if the data that your application stores can be
used by other applications. Additionally, if the file stored by your application
is huge, such as a video, you can save it to external storage. You can use
external storage to keep the data even after uninstalling the application.

3. Using the Shared Preferences

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.

4. Using Android Database

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.

There is some standard methods – insert(), query(), update(), delete(), to access


application data. So it is easy to implement a content provider.

We need to assign a URI to each Content Provider, starting with


“content://” and that will be recognized by applications.ps to writing a Content
Provider:

1. Create a class for ContentProvider.


2. Define content URI
3. Implement all the unimplemented methods. insert(), update(), query(),
delete(), getType().
4. Declare the content provider in AndroidManifest.xml
Content provider URI – content://authority/path/id

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>

What is Networking in Android Apps?


Networking in Android apps refers to the process of communicating with remote
servers or APIs to fetch or send data. This data can be in the form of text, images,
videos, or any other type of digital content. Android provides several APIs and
classes to facilitate networking, including HttpURLConnection, OkHttp,
and Retrofit.
Types of Networking in Android Apps
There are two primary types of networking in Android apps:
1. Synchronous Networking
Synchronous networking involves blocking the main thread until the network
operation is complete. This approach is not recommended, as it can lead to ANRs
(Application Not Responding) and poor user experience.
2. Asynchronous Networking
Asynchronous networking, on the other hand, involves performing network
operations in the background, allowing the main thread to remain responsive and
interactive. This approach is recommended, as it provides a better user experience
and prevents ANRs.
What is API Integration in Android Apps?
API integration in Android apps involves integrating third-party APIs or services into
the app to fetch or send data. APIs provide a structured way of accessing data or
services, and Android apps can integrate with APIs using various protocols, such as
HTTP, HTTPS, or WebSockets.
Types of API Integration in Android Apps
There are two primary types of API integration in Android apps:
1. RESTful APIs
RESTful APIs (Representational State of Resource) use HTTP methods (GET,
POST, PUT, DELETE) to interact with resources. They are widely used and provide
a flexible way of integrating with APIs.
2. SOAP-based APIs
SOAP-based APIs (Simple Object Access Protocol) use XML to define the format of
the data and rely on other protocols, such as HTTP or SMTP, for message
negotiation. They are less commonly used than RESTful APIs.
Benefits of Networking and API Integration in Android Apps
Networking and API integration in Android apps provide several benefits, including:
1. Access to Remote Data
Networking and API integration enable Android apps to access remote data, such as
weather updates, news feeds, or social media content.
2. Improved User Experience
By integrating with APIs, Android apps can provide a more comprehensive and
engaging user experience, such as fetching user data from social media platforms or
accessing online storage services.
3. Real-time Updates
Networking and API integration enable Android apps to receive real-time updates,
such as push notifications or live scores.
4. Increased Functionality
API integration can extend the functionality of Android apps, such as integrating
with payment gateways or location-based services.
Best Practices for Networking and API Integration in Android Apps
To ensure efficient and secure networking and API integration in Android apps,
follow these best practices:
1. Use Asynchronous Networking
Use asynchronous networking to prevent ANRs and ensure a responsive user
interface.
2. Implement Error Handling
Implement robust error handling to handle network errors, API errors, and other
exceptions.
3. Use HTTPS
Use HTTPS (Hypertext Transfer Protocol Secure) to ensure secure data transmission
and prevent man-in-the-middle attacks.
4. Cache Data
Cache data to reduce the number of network requests and improve app performance.
5. Use API Keys and Tokens
Use API keys and tokens to authenticate and authorize API requests.
6. Monitor API Usage
Monitor API usage to prevent abuse and ensure compliance with API terms of
service.
Conclusion
Networking and API integration are essential components of Android app
development, enabling apps to access remote data, provide a better user experience,
and extend their functionality. By following best practices and understanding the
concepts and benefits of networking and API integration, Android developers can
create efficient, secure, and engaging apps that meet the evolving needs of users.

 GET: Fetch data from API.


 POST: Adding new data to API.
 PUT: Updating existing data.
 DELETE: Deleting data on the server.

REpresentational State Transfer (REST) is an architectural style that


defines a set of constraints to be used for creating web services. REST
API is a way of accessing web services in a simple and flexible way
without having any processing.

REST technology is generally preferred to the more robust Simple Object


Access Protocol (SOAP) technology because REST uses less
bandwidth, simple and flexible making it more suitable for internet usage.
It’s used to fetch or give some information from a web service. All
communication done via REST API uses only HTTP request.
Working: A request is sent from client to server in the form of a web URL
as HTTP GET or POST or PUT or DELETE request. After that, a
response comes back from the server in the form of a resource which can
be anything like HTML, XML, Image, or JSON. But now JSON is the most
popular format being used in Web Services.
In HTTP there are five methods that are commonly used in a REST-based
Architecture i.e., POST, GET, PUT, PATCH, and DELETE. These
correspond to create, read, update, and delete (or CRUD) operations
respectively. There are other methods which are less frequently used like
OPTIONS and HEAD.
 GET: The HTTP GET method is used to read (or retrieve) a
representation of a resource. In the safe path, GET returns a
representation in XML or JSON and an HTTP response code of 200
(OK). In an error case, it most often returns a 404 (NOT FOUND) or
400 (BAD REQUEST).
 POST: The POST verb is most often utilized to create new resources.
In particular, it’s used to create subordinate resources. That is,
subordinate to some other (e.g. parent) resource. On successful
creation, return HTTP status 201, returning a Location header with a
link to the newly-created resource with the 201 HTTP status.
NOTE: POST is neither safe nor idempotent.
 PUT: It is used for updating the capabilities. However, PUT can also
be used to create a resource in the case where the resource ID is
chosen by the client instead of by the server. In other words, if the PUT
is to a URI that contains the value of a non-existent resource ID. On
successful update, return 200 (or 204 if not returning any content in the
body) from a PUT. If using PUT for create, return HTTP status 201 on
successful creation. PUT is not safe operation but it’s idempotent.
 PATCH: It is used to modify capabilities. The PATCH request only
needs to contain the changes to the resource, not the complete
resource. This resembles PUT, but the body contains a set of
instructions describing how a resource currently residing on the server
should be modified to produce a new version. This means that the
PATCH body should not just be a modified part of the resource, but in
some kind of patch language like JSON Patch or XML Patch. PATCH
is neither safe nor idempotent.
 DELETE: It is used to delete a resource identified by a URI. On
successful deletion, return HTTP status 200 (OK) along with a
response body.
Idempotence: An idempotent HTTP method is a HTTP method that can
be called many times without different outcomes. It would not matter if the
method is called only once, or ten times over. The result should be the
same. Again, this only applies to the result, not the resource itself.
Example:
1. a = 4 // It is Idempotence, as f
// w ould not change after e
// times.

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: Request for Posting/Creating/Inserting Data


Request

POST:/api/students
{“name”:”Raj”}

 PUT or PATCH: Request for Updating Data at id=1


Request

PUT or PATCH:/api/students/1
{“name”:”Raj”}

 DELETE: Request for Deleting Data of id=1


Request

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?

The telephony system is a software framework to provide mobile phones with


telephony functionalities, such as voice call, Video call, SMS,MMS ,data
service, network management and so on.

Architecture: Telephony framework for Android has four layered Architecture.

1. Communication processor(Wireless module drivers in Linux kernel)

2. RIL(Radio Interface Layer)

3. Android Telephony Services

4. High level telephony applications


Telephony Architecture

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

We can see the source code for these apps


in http://androidxref.com/9.0.0_r3/xref/packages/apps/

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.

Telephony framework consists of components like

Service State Tracker (SST),SIM IO subsystem,

GsmCdmaCallTracker,Data Connection Tracker (DCT),SIM toolkit,Support for


MMI codes.It also provides us certain services like Voice services ( MO, MT ,
Call forwarding, call hold, 3-way call, Call supplementary ),SMS , MMS, voice
mail,Network Acess Services (NAS-Voice, data and bearer registration ),SIM
Services ,Device Management Services(DMS),Phone book Manager(PBM —
Managing Contacts).

Additionally IMS service has also been added.

There are two catagories of packages in telephony framework-

 Internal telephony packages:

Used for default telephony app-Phone.apk

/frameworks/base/telephony/java/com/android/internal/telephony/

 Open technology packages:

Used by 3rd party apps.

/frameworks/base/telephony/java/android/telephony/

 Also we have The Android Telecom framework is responsible for


managing calls on an Android device.

Preparing an Android Application for Deployment

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.

You might also like