Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Topic
SrNo.
1
Date
Page
2
Introduction
5
2
General Concepts
Activity
Manifest
6
7
13
27
39
Debugging In Eclipse
42
45
8
Diagrammatic Overview
Using the Android Emulator
54
61
62
9
10
11
Sign
Introduction
Background:
Walky (as named) is an android based Research Project. It is an simple sleek application
compatible with most of the Android Phones running Operating System version2.3.6 or
above. Walky enables two Android based Phones to communicate each other with in
Local Area Network.
It Simulates Legacy Walky Talky(half duplex) but one which is IP based. This
research application is been optimized and incorporated with a Chat functionality along
with it.
Statement Of Problem:
Objective Of Thesis:
Aim was to learn an Android System to deep extent. Create a Deployable App using
Network and Other Hardware (mic & speakers). Also working with numerous Threads as
Android Applications are Thread Sensitive.
Limitations:
Basic Requirements:
Android SDK.
Eclipse IDE (My Choice). +Android ADT plug in.
Java and XML knowledge.
Hardware Requirements:
Android Powered Phone
Min CPU 500MHz
SD card : min 10 Mb
Internal Memory : 3 MB when installed
Min Android API Version: 2.3 (Ginger Bread)
Max Android API Version: 4.0 (Ice Cream Sandwich)
General Concepts
What Is Android?
You might have seen windows, Linux and Mac operating systems which are made for
computers. Windows is the most popular operating system on computers. So if you know
about it then it is easy for you to get an answer for what is android.
Android is also an operating system developed by Google. Basically it was started by
some other company which was taken by Google. Google improved the operating system
and made it a open source platform. It was widely adapted over the world. As it is open
source it is so popular amongst the Smartphone. Android OS can also be used on tablet
PCs.
Android Versions:
Android beta.
1.5 Android Cupcake.
1.6 Android Donut.
2.0/2.1 clair.
2.2.x Froyo.
2.3.x Gingerbread.
3.x Honeycomb (used mainly for tablets.)
4.0.x Ice Cream Sandwich (both for phones and table)
4.1/4.2-JellyBeans.
As day by day there is a drastic development in hardware need for software support also
arise and later version are getting better and better with Multi-processor Devices.
Android Architecture:
Android consists of a kernel based on Linux kernel version 2.6 and, from Android 4.0 Ice
Cream Sandwich onwards, version 3.x, with middleware, libraries and APIs written in C,
and application software running on an application framework which includes Javacompatible libraries based on Apache Harmony. Android uses the Dalvik virtual
machine with just-in-time compilation to run Dalvik 'dex-code' (Dalvik Executable),
which is usually translated from Java byte code. The main hardware platform for Android
is the ARM architecture. There is support for x86 from the Android x86 project, and
Google uses a special x86 version of Android.
Android's Linux kernel has further architecture changes by Google outside the typical
Linux kernel development cycle. Android does not have a nativeX Window System by
default nor does it support the full set of standard GNU libraries, and this makes it
difficult to port existing Linux applications or libraries to Android. Support for simple C
and SDL applications is possible by injection of a small Java shim and usage of
the JNI like, for example, in the Jagged Alliance 2 port for Android.
Android App Concepts:
Android apps make life easier and are easy to understand. When people use your app for
the first time, they should intuitively grasp the most important features. The design work doesn't
stop at the first use, though. Android apps remove ongoing chores like file management and
syncing. Simple tasks never require complex procedures, and complex tasks are tailored to the
human hand and mind.
Design Principles
Android's system UI provides the framework on top of which you build your app.
important aspects include the Home screen experience, global device navigation, and
notifications.
Build visually compelling apps that look great on any device.
Use color and illumination to respond to touches, reinforce the resulting behaviors
of gestures, and indicate what actions are enabled and disabled.
Whenever a user touches an actionable area in your app, provide a visual
response. This lets the user know which object was touched and that your app is
"listening".
States
Most of Android's UI elements have touch-feedback built in, including states that
indicate whether touching the element will have any effect.
10
Patterns:
Design apps that behave in a consistent, predictable fashion.
UI (User Interface)
Android UI is an XML frame work and behavior is Java platform.
The graphical user interface for an Android app is built using a hierarchy
of View and View Group objects. View objects are usually UI widgets such
as buttons or text fields and View Group objects are invisible view containers that define
how the child views are laid out, such as in a grid or a vertical list.
Android provides an XML vocabulary that corresponds to the subclasses
of View and View Group so you can define your UI in XML using a hierarchy of UI
elements.
Ever thing is a view, a button is a view, a textview is a view or even a radio button is a
view.
Example of XML File
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="horizontal" >
</LinearLayout>
11
Layouts: Just like we use Flow Layout/ Border Layout in Java Swing applications, here
same goes for Linear Layout /Relative Layout to place any component or view in some
fashion.
LinearLayout
extends ViewGroup
A Layout that arranges its children in a single column or a single row. The direction of
the row can be set by calling setOrientation(). You can also specify gravity, which
specifies the alignment of all the child elements by calling setGravity() or specify that
specific children grow to fill up any remaining space in the layout by setting
the weight member of LinearLayout.LayoutParams. The default orientation is horizontal.
View
extends Object
implements Drawable.Callback KeyEvent.Callback AccessibilityEventSource
This class represents the basic building block for user interface components. A View
occupies a rectangular area on the screen and is responsible for drawing and event
handling. View is the base class for widgets, which are used to create interactive UI
components (buttons, text fields, etc.). The ViewGroupsubclass is the base class
for layouts, which are invisible containers that hold other Views (or other ViewGroups)
and define their layout properties.
For Example:
EditText
extends TextView
<EditText android:id="@+id/edit_message"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:hint="@string/edit_message" />
12
INTERNATIONALISATION (I10Nationalization)
Android Application Strictly Follow I10Nationalization Concept.
Internationalization is the process by which one can make my web application to
use all languages. Main objectives are to develop a Web Application for Translation. I.e. to
add Multilingual Support to app.
13
14
Activity
extends ContextThemeWrapper
An activity is a single, focused thing that the user can do. Almost all activities interact
with the user, so the Activity class takes care of creating a window for you in which you
can place your UI withsetContentView(View). While activities are often presented to the
user as full-screen windows, they can also be used in other ways: as floating windows
(via a theme with windowIsFloating set) or embedded inside of another activity
(using ActivityGroup). There are two methods almost all subclasses of Activity will
implement:
onCreate(Bundle) is where you initialize your activity. Most importantly, here you
will usually callsetContentView(int) with a layout resource defining your UI, and
using findViewById(int) to retrieve the widgets in that UI that you need to
interact with programmatically.
onPause() is where you deal with the user leaving your activity. Most importantly,
any changes made by the user should at this point be committed (usually to
the ContentProvider holding the data).
To be of use with Context.startActivity(), all activity classes must have a
corresponding <activity>declaration in their package's AndroidManifest.xml.
Build an Intent
An Intent is an object that provides runtime binding between separate components (such
as two activities). The Intent represents an apps "intent to do something." You can use
intents for a wide variety of tasks, but most often theyre used to start another activity.
An intent not only allows you to start another activity, but it can carry a bundle of data to
the activity as well. Inside thesendMessage() method, use findViewById() to get
theEditText element and add its text value to the intent:
15
Resumed
In this state, the activity is in the foreground and the user can interact with it. (Also
sometimes referred to as the "running" state.)
Paused
In this state, the activity is partially obscured by another activitythe other activity that's
in the foreground is semi-transparent or doesn't cover the entire screen. The paused
activity does not receive user input and cannot execute any code.
Stopped
In this state, the activity is completely hidden and not visible to the user; it is considered
to be in the background. While stopped, the activity instance and all its state information
such as member variables is retained, but it cannot execute any code.
The other states (Created and Started) are transient and the system quickly moves from
them to the next state by calling the next lifecycle callback method. That is, after the
system calls onCreate(), it quickly calls onStart(), which is quickly followed
by onResume().
The main activity for your app must be declared in the manifest with an <intentfilter> that includes the MAIN action and LAUNCHER category. For example:
<activity android:name=".MainActivity" android:label="@string/app_name">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
17
Activity
extends ContextThemeWrapper
implements ComponentCallbacks2 KeyEvent.Callback LayoutInflater.Factory2 View.OnCreateCo
ntextMenuListenerWindow.Callback
java.lang.Object
android.content.Context
android.content.ContextWrapper
android.view.ContextThemeWrapper
android.app.Activity
Known Direct Subclasses
AccountAuthenticatorActivity, ActivityGroup, AliasActivity, ExpandableListActivity, FragmentActivity,
ListActivity,NativeActivity
Known Indirect Subclasses
LauncherActivity, PreferenceActivity, TabActivity
Fragments
Starting with HONEYCOMB, Activity implementations can make use of
the Fragment class to better modularize their code, build more sophisticated user
interfaces for larger screens, and help scale their application between small and large
screens.
Activity Lifecycle
Activities in the system are managed as an activity stack. When a new activity is started,
it is placed on the top of the stack and becomes the running activity -- the previous
activity always remains below it in the stack, and will not come to the foreground again
until the new activity exits.
An activity has essentially four states:
18
If an activity in the foreground of the screen (at the top of the stack), it
is active or running.
If an activity has lost focus but is still visible (that is, a new non-full-sized or
transparent activity has focus on top of your activity), it is paused. A paused activity is
completely alive (it maintains all state and member information and remains attached
to the window manager), but can be killed by the system in extreme low memory
situations.
If an activity is paused or stopped, the system can drop the activity from memory
by either asking it to finish, or simply killing its process. When it is displayed again to
the user, it must be completely restarted and restored to its previous state.
The following diagram shows the important state paths of an Activity. The square
rectangles represent callback methods you can implement to perform operations when the
Activity moves between states. The colored ovals are major states the Activity can be in.
19
There are three key loops you may be interested in monitoring within your activity:
sees what you are displaying. The onStart() and onStop() methods can be called
multiple times, as the activity becomes visible and hidden to the user.
The entire lifecycle of an activity is defined by the following Activity methods. All of
these are hooks that you can override to do appropriate work when the activity changes
state. All activities will implementonCreate(Bundle) to do their initial setup; many will
also implement onPause() to commit changes to data and otherwise prepare to stop
interacting with the user. You should always call up to your superclass when
implementing these methods.
public class Activity extends ApplicationContext {
protected void onCreate(Bundle savedInstanceState);
protected void onStart();
protected void onRestart();
protected void onResume();
protected void onPause();
protected void onStop();
protected void onDestroy();
}
21
Configuration Changes
If the configuration of the device (as defined by the Resources.Configuration class)
changes, then anything displaying a user interface will need to update to match that
configuration. Because Activity is the primary mechanism for interacting with the user, it
includes special support for handling configuration changes.
Unless you specify otherwise, a configuration change (such as a change in screen
orientation, language, input devices, etc) will cause your current activity to be destroyed,
going through the normal activity lifecycle process of onPause(), onStop(),
and onDestroy() as appropriate. If the activity had been in the foreground or visible to the
user, once onDestroy() is called in that instance then a new instance of the activity will be
created, with whatever savedInstanceState the previous instance had generated
fromonSaveInstanceState(Bundle).
This is done because any application resource, including layout files, can change based
on any configuration value. Thus the only safe way to handle a configuration change is to
re-retrieve all resources, including layouts, drawables, and strings. Because activities
must already know how to save their state and re-create themselves from that state, this is
a convenient way to have an activity restart itself with a new configuration.
In some special cases, you may want to bypass restarting of your activity based on one or
more types of configuration changes. This is done with
the android:configChanges attribute in its manifest. For any types of configuration
changes you say that you handle there, you will receive a call to your current
activity's onConfigurationChanged(Configuration) method instead of being restarted. If a
configuration change involves any that you do not handle, however, the activity will still
be restarted andonConfigurationChanged(Configuration) will not be called.
Starting Activities and Getting Results
The startActivity(Intent) method is used to start a new activity, which will be placed at
the top of the activity stack. It takes a single argument, an Intent, which describes the
activity to be executed.
Sometimes you want to get a result back from an activity when it ends. For example, you
may start an activity that lets the user pick a person in a list of contacts; when it ends, it
returns the person that was selected. To do this, you call the startActivityForResult(Intent,
int) version with a second integer parameter identifying the call. The result will come
back through your onActivityResult(int, int, Intent) method.
When an activity exits, it can call setResult(int) to return data back to its parent. It must
always supply a result code, which can be the standard results RESULT_CANCELED,
RESULT_OK, or any custom values starting at RESULT_FIRST_USER. In addition, it
22
can optionally return back an Intent containing any additional data it wants. All of this
information appears back on the parent'sActivity.onActivityResult(), along with the
integer identifier it originally supplied.
If a child activity fails for any reason (such as crashing), the parent activity will receive a
result with the code RESULT_CANCELED.
public class MyActivity extends Activity {
...
static final int PICK_CONTACT_REQUEST = 0;
protected boolean onKeyDown(int keyCode, KeyEvent event) {
if (keyCode == KeyEvent.KEYCODE_DPAD_CENTER) {
// When the user center presses, let them pick a contact.
startActivityForResult(
new Intent(Intent.ACTION_PICK,
new Uri("content://contacts")),
PICK_CONTACT_REQUEST);
return true;
}
return false;
}
23
Process Lifecycle
The Android system attempts to keep application process around for as long as possible,
but eventually will need to remove old processes when memory runs low. As described
in Activity Lifecycle, the decision about which process to remove is intimately tied to the
state of the user's interaction with it. In general, there are four states a process can be in
based on the activities running in it, listed here in order of importance. The system will
kill less important processes (the last ones) before it resorts to killing more important
processes (the first ones).
1.
The foreground activity (the activity at the top of the screen that the user is
currently interacting with) is considered the most important. Its process will only be
killed as a last resort, if it uses more memory than is available on the device. Generally
at this point the device has reached a memory paging state, so this is required in order
to keep the user interface responsive.
2.
A visible activity (an activity that is visible to the user but not in the foreground,
such as one sitting behind a foreground dialog) is considered extremely important and
will not be killed unless that is required to keep the foreground activity running.
3.
A background activity (an activity that is not visible to the user and has been
paused) is no longer critical, so the system may safely kill its process to reclaim
memory for other foreground or visible processes. If its process needs to be killed,
when the user navigates back to the activity (making it visible on the screen again),
its onCreate(Bundle) method will be called with the savedInstanceState it had
previously supplied in onSaveInstanceState(Bundle) so that it can restart itself in the
same state as the user last left it.
4.
24
[Expand]
Inherited Constants
From class android.content.Context
From interface android.content.ComponentCallbacks2
Public Constructors
Activity()
Public Methods
void
void
closeContextMenu()
Programmatically closes the most recently opened context menu, if showing.
void
closeOptionsMenu()
Progammatically closes the options menu.
PendingIntent
final void
dismissDialog(int id)
This method was deprecated in API level 13. Use the new DialogFragment class
with FragmentManager instead; this is also available on older platforms through the
Android compatibility package.
boolean
dispatchGenericMotionEvent(MotionEvent ev)
Called to process generic motion events.
boolean
dispatchKeyEvent(KeyEvent event)
Called to process key events.
boolean
dispatchKeyShortcutEvent(KeyEvent event)
Called to process a key shortcut event.
boolean
dispatchPopulateAccessibilityEvent(AccessibilityEvent event)
Called to process population of AccessibilityEvents.
boolean
dispatchTouchEvent(MotionEvent ev)
Called to process touch screen events.
boolean
dispatchTrackballEvent(MotionEvent ev)
Called to process trackball events.
void
View
findViewById(int id)
Finds a view that was identified by the id attribute from the XML that was processed
in onCreate(Bundle).
void
finish()
Call this when your activity is done and should be closed.
void
finishActivity(int requestCode)
Force finish another activity that you had previously started
with startActivityForResult(Intent, int).
25
void
void
finishAffinity()
Finish this activity as well as all activities immediately below it in the current task that
have the same affinity.
void
finishFromChild(Activity child)
This is called when a child activity of this one calls its finish() method.
ActionBar
getActionBar()
Retrieve a reference to this activity's ActionBar.
final Applicatio
n
getApplication()
Return the application that owns this activity.
ComponentNam
e
getCallingActivity()
Return the name of the activity that invoked this activity.
String
getCallingPackage()
Return the name of the package that invoked this activity.
int
getChangingConfigurations()
If this activity is being destroyed because it can not handle a configuration parameter
being changed (and thus itsonConfigurationChanged(Configuration) method
is not being called), then you can use this method to discover the set of changes that
have occurred while in the process of being destroyed.
ComponentNam
e
getComponentName()
Returns complete component name of this activity.
View
getCurrentFocus()
Calls getCurrentFocus() on the Window of this Activity to return the currently focused
view.
FragmentManag
er
getFragmentManager()
Return the FragmentManager for interacting with fragments associated with this
activity.
Intent
getIntent()
Return the intent that started this activity.
Object
getLastNonConfigurationInstance()
This method was deprecated in API level 13. Use the
new Fragment API setRetainInstance(boolean) instead; this is also available on older
platforms through the Android compatibility package.
LayoutInflater
getLayoutInflater()
Convenience for calling getLayoutInflater().
LoaderManager
getLoaderManager()
Return the LoaderManager for this fragment, creating it if needed.
String
getLocalClassName()
Returns class name for this activity with the package prefix removed.
MenuInflater
getMenuInflater()
Returns a MenuInflater with this context.
final Activity
getParent()
Return the parent activity if this view is an embedded child.
Intent
getParentActivityIntent()
Obtain an Intent that will launch an explicit target activity specified by this activity's
logical parent.
SharedPreferenc
es
getPreferences(int mode)
Retrieve a SharedPreferences object for accessing preferences that are private to this
26
activity.
void
onBackPressed()
Called when the activity has detected the user's press of the back key.
void
onConfigurationChanged(Configuration newConfig)
Called by the system when the device configuration changes while your activity is
running.
void
onContentChanged()
This hook is called whenever the content view of the screen changes (due to a call
to Window.setContentView or Window.addContentView).
boolean
onContextItemSelected(MenuItem item)
This hook is called whenever an item in a context menu is selected.
void
onContextMenuClosed(Menu menu)
This hook is called whenever the context menu is being closed (either by the user
canceling the menu with the back/menu button, or when an item is selected).
void
CharSequence
onCreateDescription()
Generate a new description for this activity.
void
onCreateNavigateUpTaskStack(TaskStackBuilder builder)
Define the synthetic task stack that will be generated during Up navigation from a
different task.
boolean
onCreateOptionsMenu(Menu menu)
Initialize the contents of the Activity's standard options menu.
boolean
View
onCreatePanelView(int featureId)
Default implementation of onCreatePanelView(int) for activities.
boolean
View
View
void
onDetachedFromWindow()
Called when the main window associated with the activity has been detached from the
window manager.
boolean
onGenericMotionEvent(MotionEvent event)
Called when a generic motion event was not handled by any of the views inside of the
activity.
boolean
boolean
boolean
27
boolean
void
onLowMemory()
This is called when the overall system is running low on memory, and would like
actively running process to try to tighten their belt.
boolean
boolean
boolean
onNavigateUp()
This method is called whenever the user chooses to navigate Up within your
application's activity hierarchy from the action bar.
boolean
onNavigateUpFromChild(Activity child)
This is called when a child activity of this one attempts to navigate up.
boolean
onOptionsItemSelected(MenuItem item)
This hook is called whenever an item in your options menu is selected.
void
onOptionsMenuClosed(Menu menu)
This hook is called whenever the options menu is being closed (either by the user
canceling the menu with the back/menu button, or when an item is selected).
void
void
onPrepareNavigateUpTaskStack(TaskStackBuilder builder)
Prepare the synthetic task stack that will be generated during Up navigation from a
different task.
boolean
onPrepareOptionsMenu(Menu menu)
Prepare the Screen's standard options menu to be displayed.
boolean
Object
onRetainNonConfigurationInstance()
This method was deprecated in API level 13. Use the
new Fragment API setRetainInstance(boolean) instead; this is also available on older
platforms through the Android compatibility package.
boolean
onSearchRequested()
This hook is called when the user signals the desire to start a search.
boolean
onTouchEvent(MotionEvent event)
Called when a touch screen event was not handled by any of the views under it.
boolean
onTrackballEvent(MotionEvent event)
Called when the trackball was moved and not handled by any of the views inside of the
activity.
void
onTrimMemory(int level)
Called when the operating system has determined that it is a good time for a process to
trim unneeded memory from its process.
void
onUserInteraction()
Called whenever a key, touch, or trackball event is dispatched to the activity.
28
void
onWindowAttributesChanged(WindowManager.LayoutParams params)
This is called whenever the current window attributes change.
void
onWindowFocusChanged(boolean hasFocus)
Called when the current Window of the activity gains or loses focus.
ActionMode
onWindowStartingActionMode(ActionMode.Callback callback)
Give the Activity a chance to control the UI for an action mode requested by the system.
void
openOptionsMenu()
Programmatically opens the options menu.
void
void
recreate()
Cause this Activity to be recreated with a new instance.
void
registerForContextMenu(View view)
Registers a context menu to be shown for the given view (multiple views can show the
context menu).
final void
removeDialog(int id)
This method was deprecated in API level 13. Use the new DialogFragment class
with FragmentManager instead; this is also available on older platforms through the
Android compatibility package.
final boolean
requestWindowFeature(int featureId)
Enable extended window features.
final void
runOnUiThread(Runnable action)
Runs the specified action on the UI thread.
void
setContentView(int layoutResID)
Set the activity content from a layout resource.
void
setContentView(View view)
Set the activity content to an explicit view.
void
final void
setDefaultKeyMode(int mode)
Select the default key handling for this activity.
final void
final void
final void
final void
void
setFinishOnTouchOutside(boolean finish)
Sets whether this activity is finished when touched outside its window's bounds.
void
setIntent(Intent newIntent)
Change the intent returned by getIntent().
final void
setProgress(int progress)
Sets the progress for the progress bars in the title.
final void
setProgressBarIndeterminate(boolean indeterminate)
29
Sets whether the horizontal progress bar in the title should be indeterminate (the circular
is always indeterminate).
final void
setProgressBarIndeterminateVisibility(boolean visible)
Sets the visibility of the indeterminate progress bar in the title.
final void
setProgressBarVisibility(boolean visible)
Sets the visibility of the progress bar in the title.
void
setRequestedOrientation(int requestedOrientation)
Change the desired orientation of this activity.
Manifest
AndroidManifest.xml
Every application must have an AndroidManifest.xml file (with precisely that name) in
its root directory. The manifest presents essential information about the application to the
Android system, information the system must have before it can run any of the
application's code. Among other things, the manifest does the following:
It names the Java package for the application. The package name serves as a
unique identifier for the application.
It also declares the permissions that others are required to have in order to interact
with the application's components.
It lists the Instrumentation classes that provide profiling and other information as
the application is running. These declarations are present in the manifest only while
the application is being developed and tested; they're removed before the application is
published.
It declares the minimum level of the Android API that the application requires.
30
31
32
All the elements that can appear in the manifest file are listed below in alphabetical
order. These are the only legal elements; you cannot add your own elements or
attributes.
<action>
<activity>
<activity-alias>
<application>
<category>
<data>
<grant-uri-permission>
<instrumentation>
<intent-filter>
<manifest>
<meta-data>
<permission>
<permission-group>
<permission-tree>
<provider>
<receiver>
<service>
<supports-screens>
<uses-configuration>
<uses-feature>
<uses-library>
<uses-permission>
<uses-sdk>
File Features
The following sections describe how some Android features are reflected in the manifest
file.
Intent Filters
The core components of an application (its activities, services, and broadcast receivers)
are activated byintents. An intent is a bundle of information (an Intent object) describing
a desired action including the data to be acted upon, the category of component that
should perform the action, and other pertinent instructions. Android locates an
appropriate component to respond to the intent, launches a new instance of the
component if one is needed, and passes it the Intent object.
Components advertise their capabilities the kinds of intents they can respond to
through intent filters. Since the Android system must learn which intents a component
33
can handle before it launches the component, intent filters are specified in the manifest
as <intent-filter> elements. A component may have any number of filters, each one
describing a different capability.
An intent that explicitly names a target component will activate that component; the filter
doesn't play a role. But an intent that doesn't specify a target by name can activate a
component only if it can pass through one of the component's filters.
For information on how Intent objects are tested against intent filters, see a separate
document, Intents and Intent Filters.
Icons and Labels
A number of elements have icon and label attributes for a small icon and a text label that
can be displayed to users. Some also have a description attribute for longer explanatory
text that can also be shown on-screen. For example, the <permission> element has all
three of these attributes, so that when the user is asked whether to grant the permission to
an application that has requested it, an icon representing the permission, the name of the
permission, and a description of what it entails can all be presented to the user.
In every case, the icon and label set in a containing element become the
default icon and label settings for all of the container's subelements. Thus, the icon and
label set in the <application> element are the default icon and label for each of the
application's components. Similarly, the icon and label set for a component for
example, an <activity> element are the default settings for each of the
component's<intent-filter> elements. If an <application> element sets a label, but an
activity and its intent filter do not, the application label is treated as the label for both the
activity and the intent filter.
The icon and label set for an intent filter are used to represent a component whenever the
component is presented to the user as fulfilling the function advertised by the filter. For
example, a filter with "android.intent.action.MAIN" and
"android.intent.category.LAUNCHER" settings advertises an activity as one that initiates
an application that is, as one that should be displayed in the application launcher. The
icon and label set in the filter are therefore the ones displayed in the launcher.
Permissions
A permission is a restriction limiting access to a part of the code or to data on the device.
The limitation is imposed to protect critical data and code that could be misused to distort
or damage the user experience.
Each permission is identified by a unique label. Often the label indicates the action that's
restricted. For example, here are some permissions defined by Android:
34
android.permission.CALL_EMERGENCY_NUMBERS
android.permission.READ_OWNER_DATA
android.permission.SET_WALLPAPER
android.permission.DEVICE_POWER
A feature can be protected by at most one permission.
If an application needs access to a feature protected by a permission, it must declare that
it requires that permission with a <uses-permission> element in the manifest. Then, when
the application is installed on the device, the installer determines whether or not to grant
the requested permission by checking the authorities that signed the application's
certificates and, in some cases, asking the user. If the permission is granted, the
application is able to use the protected features. If not, its attempts to access those
features will simply fail without any notification to the user.
An application can also protect its own components (activities, services, broadcast
receivers, and content providers) with permissions. It can employ any of the permissions
defined by Android (listed inandroid.Manifest.permission) or declared by other
applications. Or it can define its own. A new permission is declared with
the <permission> element. For example, an activity could be protected as follows:
<manifest . . . >
<permission android:name="com.example.project.DEBIT_ACCT" . . . />
<uses-permission android:name="com.example.project.DEBIT_ACCT" />
...
<application . . .>
<activity android:name="com.example.project.FreneticActivity"
android:permission="com.example.project.DEBIT_ACCT"
...>
...
</activity>
</application>
</manifest>
Note that, in this example, the DEBIT_ACCT permission is not only declared with
the <permission> element, its use is also requested with the <uses-permission> element.
Its use must be requested in order for other components of the application to launch the
protected activity, even though the protection is imposed by the application itself.
If, in the same example, the permission attribute was set to a permission declared
elsewhere (such asandroid.permission.CALL_EMERGENCY_NUMBERS, it would not
have been necessary to declare it again with a <permission> element. However, it would
still have been necessary to request its use with <uses-permission>.
35
The <permission-tree> element declares a namespace for a group of permissions that will be defined in
code. And <permission-group> defines a label for a set of permissions (both those declared in the manifest
with <permission> elements and those declared elsewhere). It affects only how the permissions are grouped
when presented to the user. The <permission-group> element does not specify which permissions belong to
the group; it just gives the group a name. A permission is placed in the group by assigning the group name
to the <permission> element's permissionGroup attribute
36
ConnectivityManager
extends Object
java.lang.Object
android.net.ConnectivityManager
Class Overview
Class that answers queries about the state of network connectivity. It also notifies
applications when network connectivity changes. Get an instance of this class by
callingContext.getSystemService(Context.CONNECTIVITY_SERVICE).
The primary responsibilities of this class are to:
1.
2.
3.
4.
getActiveNetworkInfo()
Returns details about the currently active data network.
NetworkInfo[
]
getAllNetworkInfo()
boolean
getBackgroundDataSetting()
This method was deprecated in API level 14. As
of ICE_CREAM_SANDWICH, availability of background data
depends on several combined factors, and this method will
always return true. Instead, when background data is
unavailable,getActiveNetworkInfo() will now appear
disconnected.
NetworkInfo
getNetworkInfo(int networkType)
int
getNetworkPreference()
37
boolean
isActiveNetworkMetered()
Returns if the currently active data network is metered.
static boolean
isNetworkTypeValid(int networkType)
boolean
void
setNetworkPreference(int preference)
int
int
[Expand]
Inherited Methods
From class java.lang.Object
38
Dialogs
A dialog is a small window that prompts the user to make a decision or enter additional
information. A dialog does not fill the screen and is normally used for modal events that
require users to take an action before they can proceed.
Dialog Design
For information about how to design your dialogs, including recommendations for
language, read the Dialogs design guide.
The Dialog class is the base class for dialogs, but you should avoid
instantiating Dialog directly. Instead, use one of the following subclasses:
AlertDialog
A dialog that can show a title, up to three buttons, a list of selectable items, or a
custom layout.
DatePickerDialog or TimePickerDialog
A dialog with a pre-defined UI that allows the user to select a date or time.
39
Toasts
A toast provides simple feedback about an operation in a small popup. It only fills the
amount of space required for the message and the current activity remains visible and
interactive. For example, navigating away from an email before you send it triggers a
"Draft saved" toast to let you know that you can continue editing later. Toasts
automatically disappear after a timeout.
WifiManager.WifiLock
extends Object
java.lang.Object
android.net.wifi.WifiManager.WifiLock
Class Overview
Allows an application to keep the Wi-Fi radio awake. Normally the Wi-Fi radio may turn
off when the user has not used the device in a while. Acquiring a WifiLock will keep the
radio on until the lock is released. Multiple applications may hold WifiLocks, and the
radio will only be allowed to turn off when no WifiLocks are held in any application.
40
Before using a WifiLock, consider carefully if your application requires Wi-Fi access, or
could function over a mobile network, if available. A program that needs to download
large files should hold a WifiLock to ensure that the download will complete, but a
program whose network usage is occasional or low-bandwidth should not hold a
WifiLock to avoid adversely affecting battery life.
Note that WifiLocks cannot override the user-level "Wi-Fi Enabled" setting, nor Airplane
Mode. They simply keep the radio from turning off when Wi-Fi is already on but the
device is idle.
Any application using a WifiLock must request
the android.permission.WAKE_LOCK permission in an<uses-permission> element of the
application's manifest.
Summary
Public Methods
void
acquire()
Locks the Wi-Fi radio on until release() is called.
boole
an
isHeld()
Checks whether this WifiLock is currently held.
void
release()
Unlocks the Wi-Fi radio, allowing it to turn off when the device
is idle.
void
setReferenceCounted(boolean refCounted)
Controls whether this is a reference-counted or nonreference-counted WifiLock.
void
setWorkSource(WorkSource ws)
String
toString()
Returns a string containing a concise, human-readable
description of this object.
41
public class
WifiInfo
extends Object
implements Parcelable
java.lang.Object
android.net.wifi.WifiInfo
Class Overview
Describes the state of any Wifi connection that is active or is in the process of being set
up.
Summary
Constants
Stri
ng
LINK_SPEED_U
NITS
[Expand]
Inherited Constants
From interface android.os.Parcelable
Public Methods
String
getBSSID()
Return the basic service set identifier (BSSID)
of the current access point.
static NetworkInfo.DetailedSta
te
getDetailedStateOf(SupplicantState suppState)
Map a supplicant state into a fine-grained
network connectivity state.
boolean
getHiddenSSID()
int
getIpAddress()
int
getLinkSpeed()
Returns the current link speed
in LINK_SPEED_UNITS.
String
getMacAddress()
42
int
getNetworkId()
Each configured network has a unique small
integer ID, used to identify the network when
performing operations on the supplicant.
int
getRssi()
Returns the received signal strength indicator
of the current 802.11 network.
String
getSSID()
Returns the service set identifier (SSID) of the
current 802.11 network.
SupplicantState
getSupplicantState()
Return the detailed state of the supplicant's
negotiation with an access point, in the form of
a SupplicantState object.
43
Debugging In Eclipse
44
45
After you have started the application once via the context menu, you can use the created
launch configuration again via the Debug button in the the Eclipse toolbar.
If you have not defined any breakpoints, this will run your program as normal. To debug
the program you need to define breakpoints.
46
Walky is still an Android APP and hence to get your it work you need to follow normal
Android navigations i.e. HomeApp DrawerWalky
Walky works healthy on LAN Your Phone Must be connected to an Access Point or
Wifi-Hot Spot.
47
Way To Be Connected:
What is an Access Point?
In computer networking, a wireless access point (AP) is a device that allows wireless
devices to connect to a wired network using Wi-Fi, or related standards. The AP usually
connects to a router (via a wired network) if it's a standalone device, or is part of a router
itself.
Connection to Access Point :Ensure that you have your wifi On on your device and your
handset must support that of course. Once you have connected to your Access point you r
ready to use Walky. Walky doesnt need any Internet connection as the basic need to
work is in LAN
What a Walky want is a common access point where all Walky clients are connected.
Onces connected Device are assigned an IP address which needs to exchanged when
communicating.
Note: Walky Helps In Establishing Communication Channel. It does not Communicate on
behalf of User. User must be smart enough to use it optimum & intelligently convey Half
duplex communication.
48
How to Tether?
One device can can take atmost 5 connection. And also the device which will act as an
access point will not be used for communication by user.
The reason for this is that an Android Device cannot act wifi client and server at same
time.
TO Configure : Select Setup Wifi Edit name and password and type of Security
To Enable Tether Just check on Portable Wi-fi hotspot.
49
Diagrammatic Overview
System Overview:
Walky
Receiver
Service
Sender Activity
Class Name:
Con_Activity.java
Class Name:
Wservice.java
Two main threads are running in Walky which take care of both way communication.
One of which is an activity which is visible on the screen and take care of Out Bound
messages.
Second is a Service which is responsible for Inbound or Incoming messages. Reason for
the receiver to be a Service class has its own importance. An Activity remains running on
a system even if it is not Visible until demand for resources rise. Once demands rises
need for memory increases and in such case Activities in background are stoped.
But a Service remains in system running even if that application is closed. Hence Service
was a reasonable choice in selecting a receiver class.
50
Activity: Con_Activity
As Form is for Dotnet; JFrame is for Java, similarly an Activity is for Android.
Activity =Activity.java + activity.xml
This Activity take care of outbound messages of Walky. It tries to establish connection
with Reciver Services (wservice) for Walky.
Soon we will see some more diagrammatic representation of this class. Also what are
those multi-threads running in background all together toward same goal.
Let us see Top View of this Activity called Con_Activity.
51
Con_Activity Representation
Start
ON
52
Listening
Incoming network connection
YES
NO
Receive File
Access Sdcard and Store File
Play
The above diagram constitutes the State Transition Diagrams of Service named
wservice. Here we can see that initially receiver is continuously in a listening state.
This continue to be same until and external socket connection is interrupt on the system
at same port on which Walkys wservice is running. Once connection is established but
obvious audio message is received and stored at some predefined location. Now after
receiving current thread again returns to listening state. A new thread is initiated which
access received file location and play for the user to listen. Hence again Service is ready
to receive new message.
Now lets move to Building Blocks to Walky.
53
Building Blocks:
One way of Solving Problem Statement is to break the problem in smaller
problems and then individually solving them might solve the bigger gaint problem.
Same problem solving scheme has been use in Walky. Apart from learning Android
System and Java Platform four basic ideas have inspired development of Walky.
SR
te o c r e
F i l e
o
IIPo nn r dtd e i rr en ca t l l yo
r
SSl
ee
t u
p
uC
ESR
xsodeur eetccd eak i rte ne t a a l
nA
aeo pie v er va ek re S r os
sSM
.c
k
e
m
o
r
y
a
Ty
C
P
/ I P
A
eaeFF ii tbc ll ae cl u e e s sti nos g
c
o
n
n
e
n
t i
Fja a i c l ev ec da e .i san s e
M
t
ve
i t y .
PLm il bae ryd a e i ra r y
o
f
U
s
e
J a
v
a
A
Sr e tn co d or re r o d iF ed i l r e o
f
. n
e
t
sLA yo n sc d ta re lo lm yi d. .
L
i b
r a
r y
s
y
s
t e
m
.
I n
d
i r e
c
t l y
u
s
e
m
i c
.
Assembly of these building blocks have resulted in Walky. But off course there are
various methods to assemble these Blocks which we will discuss in next segment of this
book.
Note: I have tried many more methods to make a working model of Walky but
unfortunately each method had some loop hole or inefficiency. Current version is
acceptably balanced but it still lack Full Duplex Communication. All we need is
continuous steaming of message as and when said. But currently Recording and Sending
at same time is a Thorn in a Neck issue.
All the different approaches tried to made APP will be discussed later.
54
55
</activity>
<activity
android:name="col.project.walky.CallActivity"
android:label="@string/title_activity_call" >
<meta-data
android:name="android.support.PARENT_ACTIVITY"
android:value="col.project.Con_Activity" />
</activity>
<service
android:name="col.project.walky.WService"
android:enabled="true"
android:process=":wreciver" >
</service>
<service
android:name="col.project.walky.WalkySevice"
android:enabled="true"
android:process=":wsender" />
<service android:name="col.project.walky.RecorderService"
android:enabled="true"
android:process=":wrecorder"/>
<activity
android:name="col.project.walky.ConversationActivity"
android:label="@string/app_name" >
</activity>
</application>
</manifest>
56
Class HandsOn.java:
This class is a helper class of project. As Need for some commonly used Functions and
variable increased need for some generalize space and scope rised. And hence this helper
class came into exsistence
Following are some snippets from Class HandOn.java
//Check online status of device
public static boolean isOnline(Context context ) {
WifiManager wifi;
Ip="";
Mac="";
RemoteIp="192.168.1.4";
Port =12345;
RemotePort=12345;
Status="";
try{
ConnectivityManager connMgr =
(ConnectivityManager)context.getSystemService(Context.CONNECTIVITY
_SERVICE);
NetworkInfo networkInfo = connMgr.getActiveNetworkInfo();
Log.d("Network Status:::",networkInfo.getDetailedState().toString());
//toastit(networkInfo.getDetailedState().toString());
wifi = (WifiManager) context.getSystemService(Context.WIFI_SERVICE);
WifiInfo wi= wifi.getConnectionInfo();
String ip=Formatter.formatIpAddress(wi.getIpAddress());
Ip=ip;
Mac=wi.getMacAddress().toString();
// Just to Create Folder n file
//toastit("IP"+ip);
//toastit("Mac"+wi.getMacAddress().toString());
return (networkInfo != null && networkInfo.isConnected());
}catch(Exception e)
{
Log.e(handsOn.Tag,"HandsONException:"+e);
Ip="NO Connectivity";
return false;
}
57
58
The Android SDK includes a virtual mobile device emulator that runs on your computer.
The emulator lets you prototype, develop and test Android applications without using a
physical device.
The Android emulator mimics all of the hardware and software features of a typical
mobile device, except that it cannot place actual phone calls. It provides a variety of
navigation and control keys, which you can "press" using your mouse or keyboard to
generate events for your application. It also provides a screen in which your application is
displayed, together with any other active Android applications.
To let you model and test your application more easily, the emulator utilizes Android
Virtual Device (AVD) configurations. AVDs let you define certain hardware aspects of
your emulated phone and allow you to create many configurations to test many Android
platforms and hardware permutations. Once your application is running on the emulator,
it can use the services of the Android platform to invoke other applications, access the
network, play audio and video, store and retrieve data, notify the user, and render
graphical transitions and themes.
59
The emulator also includes a variety of debug capabilities, such as a console from which
you can log kernel output, simulate application interrupts (such as arriving SMS
messages or phone calls), and simulate latency effects and dropouts on the data network.
Overview
The Android emulator is an application that provides a virtual mobile device on which
you can run your Android applications. It runs a full Android system stack, down to the
kernel level, that includes a set of preinstalled applications (such as the dialer) that you
can access from your applications. You can choose what version of the Android system
you want to run in the emulator by configuring AVDs, and you can also customize the
mobile device skin and key mappings. When launching the emulator and at runtime, you
can use a variety of commands and options to control its behavior.
The Android system images available through the Android SDK Manager contain code
for the Android Linux kernel, the native libraries, the Dalvik VM, and the various
Android packages (such as the Android framework and preinstalled applications). The
emulator provides dynamic binary translation of device machine code to the OS and
processor architecture of your development machine.
The Android emulator supports many hardware features likely to be found on mobile
devices, including:
The following sections describe the emulator and its use for development of Android
applications in more detail.
Android Virtual Devices and the Emulator
60
To use the emulator, you first must create one or more AVD configurations. In each
configuration, you specify an Android platform to run in the emulator and the set of
hardware options and emulator skin you want to use. Then, when you launch the
emulator, you specify the AVD configuration that you want to load.
Each AVD functions as an independent device, with its own private storage for user data,
SD card, and so on. When you launch the emulator with an AVD configuration, it
automatically loads the user data and SD card data from the AVD directory. By default,
the emulator stores the user data, SD card data, and cache in the AVD directory.
To create and manage AVDs you use the AVD Manager UI or the android tool that is
included in the SDK. For complete information about how to set up AVDs, see Managing
Virtual Devices.
Starting and Stopping the Emulator
During development and testing of your application, you install and run your application
in the Android emulator. You can launch the emulator as a standalone application from a
command line, or you can run it from within your Eclipse development environment. In
either case, you specify the AVD configuration to load and any startup options you want
to use, as described in this document.
You can run your application on a single instance of the emulator or, depending on your
needs, you can start multiple emulator instances and run your application in more than
one emulated device. You can use the emulator's built-in commands to simulate GSM
phone calling or SMS between emulator instances, and you can set up network
redirection that allows emulators to send data to one another. For more information,
see Telephony Emulation, SMS Emulation, and Emulator Networking
To start an instance of the emulator from the command line, navigate to the tools/ folder
of the SDK. Enter emulatorcommand like this:
emulator -avd <avd_name> [<options>]
This initializes the emulator, loads an AVD configuration and displays the emulator
window. For more information about command line options for the emulator, see
the Android Emulator tool reference.
61
Note: You can run multiple instances of the emulator concurrently, each with its own
AVD configuration and storage area for user data, SD card, and so on.
If you are working in Eclipse, the ADT plugin for Eclipse installs your application and
starts the emulator automatically, when you run or debug the application. You can specify
emulator startup options in the Run/Debug dialog, in the Target tab. When the emulator is
running, you can issue console commands as described later in this document.
If you are not working in Eclipse, see Installing Applications on the Emulator for
information about how to install your application.
To stop an emulator instance, just close the emulator's window.
Emulator Networking
The emulator provides versatile networking capabilities that you can use to set up
complex modeling and testing environments for your application. The sections below
introduce the emulator's network architecture and capabilities.
Network Address Space
Each instance of the emulator runs behind a virtual router/firewall service that isolates it
from your development machine's network interfaces and settings and from the internet.
An emulated device can not see your development machine or other emulator instances
on the network. Instead, it sees only that it is connected through Ethernet to a
router/firewall.
The virtual router for each instance manages the 10.0.2/24 network address space all
addresses managed by the router are in the form of 10.0.2.<xx>, where <xx> is a number.
Addresses within this space are pre-allocated by the emulator/router as follows:
Network Address
Description
10.0.2.1
Router/gateway address
10.0.2.2
10.0.2.3
10.0.2.4 /
10.0.2.5 / 10.0.2.6
10.0.2.15
127.0.0.1
Note that the same address assignments are used by all running emulator instances. That
means that if you have two instances running concurrently on your machine, each will
have its own router and, behind that, each will have an IP address of 10.0.2.15. The
instances are isolated by a router and can not see each other on the same network. For
information about how to let emulator instances communicate over TCP/UDP,
see Connecting Emulator Instances.
Also note that the address 127.0.0.1 on your development machine corresponds to the
emulator's own loopback interface. If you want to access services running on your
development machine's loopback interface (a.k.a. 127.0.0.1 on your machine), you should
use the special address 10.0.2.2 instead.
Finally, note that each emulated device's pre-allocated addresses are specific to the
Android emulator and will probably be very different on real devices (which are also very
likely to be NAT-ed, i.e., behind a router/firewall)
Local Networking Limitations
Android applications running in an emulator can connect to the network available on
your workstation. However, they connect through the emulator, not directly to hardware,
and the emulator acts like a normal application on your workstation. This means that the
emulator, and thus your Android applications, are subject to some limitations:
The emulator's virtual router should be able to handle all outbound TCP and UDP
connections/messages on behalf of the emulated device, provided your development
machine's network environment allows it to do so. There are no built-in limitations on
port numbers or ranges except the one imposed by your host operating system and
network.
Depending on the environment, the emulator may not be able to support other protocols
(such as ICMP, used for "ping") might not be supported. Currently, the emulator does not
support IGMP or multicast.
Using Network Redirection
To communicate with an emulator instance behind its virtual router, you need to set up
network redirection on the virtual router. Clients can then connect to a specified guest
63
port on the router, while the router directs traffic to/from that port to the emulated
device's host port.
To set up the network redirection, you create a mapping of host and guest ports/addresses
on the the emulator instance. There are two ways to set up network redirection: using
emulator console commands and using the ADB tool, as described below.
Setting up Redirection through the Emulator Console
Each emulator instance provides a control console the you can connect to, to issue
commands that are specific to that instance. You can use the redir console command to
set up redirection as needed for an emulator instance.
First, determine the console port number for the target emulator instance. For example,
the console port number for the first emulator instance launched is 5554. Next, connect to
the console of the target emulator instance, specifying its console port number, as
follows:
telnet localhost 5554
Once connected, use the redir command to work with redirection. To add a redirection,
use:
add <protocol>:<host-port>:<guest-port>
where <protocol> is either tcp or udp, and <host-port> and <guest-port> sets the mapping
between your own machine and the emulated system, respectively.
For example, the following command sets up a redirection that handles all incoming TCP
connections to your host (development) machine on 127.0.0.1:5000 and will pass them
through to the emulated system's 10.0.2.15:6000.:
redir add tcp:5000:6000
To delete a redirection, you can use the redir del command. To list all redirection for a
specific instance, you can use redir list. For more information about these and other
console commands, see Using the Emulator Console.
Note that port numbers are restricted by your local environment. this typically means that
you cannot use host port numbers under 1024 without special administrator privileges.
64
Also, you won't be able to set up a redirection for a host port that is already in use by
another process on your machine. In that case, redir generates an error message to that
effect.
Setting Up Redirection through ADB
The Android Debug Bridge (ADB) tool provides port forwarding, an alternate way for
you to set up network redirection. For more information, see Forwarding Ports in the
ADB documentation.
Note that ADB does not currently offer any way to remove a redirection, except by
killing the ADB server.
Configuring the Emulator's DNS Settings
At startup, the emulator reads the list of DNS servers that your system is currently using.
It then stores the IP addresses of up to four servers on this list and sets up aliases to them
on the emulated addresses 10.0.2.3, 10.0.2.4, 10.0.2.5 and 10.0.2.6 as needed.
On Linux and OS X, the emulator obtains the DNS server addresses by parsing the
file /etc/resolv.conf. On Windows, the emulator obtains the addresses by calling
the GetNetworkParams() API. Note that this usually means that the emulator ignores the
content of your "hosts" file (/etc/hosts on Linux/OS X, %WINDOWS
%/system32/HOSTS on Windows).
When starting the emulator at the command line, you can also use the -dns-server
<serverList> option to manually specify the addresses of DNS servers to use, where
<serverList> is a comma-separated list of server names or IP addresses. You might find
this option useful if you encounter DNS resolution problems in the emulated network (for
example, an "Unknown Host error" message that appears when using the web browser).
65
2.Exchange IPs
66
Walky though is able to transport message well but due to some lack of Research is has
some bad standards of validation.
In some cases typing the wrong IP and then trying to connect may may not notifiy you
what mistake you have made. Hence there is need for more user friendliness along with
simple and optimized behavior.
Along with this there is a need for Full Duplex communication need which this APP
currently does not satisfy. A very importance is been given to this feature and will be
available in near future.
Hence Walky will fully Function as IP Phone
Extend right from LAN to WAN
Walky works on IP address or we can say sockets with fixed port numbers. Hence
if given a proper IP and receiver running on required port number one can establish a
connection.
According to MyPublic
Research
and Development (Made a Dummy Receiver running on my
IP
pc).with some proper NATing efforts I was able to communicate via Public Ip Address
though it was not two way proper communication at all but gave a sign of connectivity
clear enough.
NAT
To NATing into android again some deep research has to be carried out.
Public IP
NAT
WAN
67
Chat Integration
Though Walky solely works on Speech concept but something extra like chat will
support the user out of his way. More than one channel or mode for communitation will
not only make to communicate in a robust way but also gracefully make APP robust in
turn.
Currently Walkys Chat Integration is in Development mode. As it was Voice same is the
case with Chat. Just to an extension is a chat LOG file which keep track of data
exchanged between user.
As Walky is LAN based and people are not foolish to use chat application when sitting
around. But in Offices or any event management occation their might come a condition to
convey message quietly. So for that, user might use any other message alternative to do
so. Walky will do this for them as well.
68
Walky-Chat
Receiver
Service
Sender Activity
Class Name:
Converstional_Activity.java
Class Name:
WalkyService.java
Two main threads are running in Walky which take care of both way communication.
One of which is an activity which is visible on the screen and take care of Out Bound
messages.
Second is a Service which is responsible for Inbound or Incoming messages. Reason for
the receiver to be a Service class has its own importance. An Activity remains running on
a system even if it is not Visible until demand for resources rise. Once demands rises
need for memory increases and in such case Activities in background are stoped.
But a Service remains in system running even if that application is closed. Hence Service
was a reasonable choice in selecting a receiver class.
69
Sender:
Call Live
Yes
NO
IDLE
Call
Thread:
Recording for so
Sent to remote site
Repeat
As you can see here same procedure is been carried out here. But except whole file pieces
of files are sent in Real Time.
Difficulty with this approach is that recording thread must be timed and synchronized so
that there is minimum jitter in the pieces of audio. Say 10 micro seconds between two
file.
Receiver:
Listening
From Sender
Play
Storage
Receive the file in some order.
70
Threa
Sm
if(socket.isConnected())
{
Log.d(handsOn.Tag, "Walky Service connected to :"+socket.getInetAddress());
int i=0;
while(i<15)
{
File f=new File(Environment.getExternalStorageDirectory() + "/walky
Folder/file"+i+".wav");
Thread.sleep(50);
new RecordThread(f).start();
Thread.sleep(1000);//3000
//Send file
i++;
}//while ends
int j=0;
while(j<15)
{
File fp1=new File(Environment.getExternalStorageDirectory() + "/walky
Folder/file"+j+".wav");
for (i=j;i<j+5;i++)
{
File sample=new File(Environment.getExternalStorageDirectory() +
"/walky Folder/file"+i+".wav");
fp1=ConcatAudio.confile(fp1, sample);
}
Thread.sleep(10);
new PlayRecieved(fp1).start();
Thread.sleep(5000);//2900;100;
j=j+5;
}//while ends
Log.d(handsOn.Tag, "WalkySevice Finished playing:");
}//if ends
}catch(Exception e){Log.d(handsOn.Tag, "WalkySevice Error:"+e);}//trycatch
}//run
}).start();
71
Another approach:
Use Parcel File Descriptor:
In this approach we directly write out recorded bit stream on Socket. And
Read is Directly from socket .
This Concept might be very easy to Imagine but is most difficult to
Implement.
Sender:
Record and write on socket
Send
Call Live
Receiver:
Call Live
72
Conclusion
Hence the problem statement of a need of an APP for Android user communicate
within LAN.
Development of and APP simulating Legacy Walky Talky.
Uses of minimum hardware requirement and also low end device support.
Support from Android Version 2.3 till 4.0 and above.
Apart from all these research gave many byproduct knowledge associated by
Android.
Rooted and UnRooted Phones
Locked and Unlock Bootloader
Flashing ROMs
Flashing Apps
Backup and Restore Systems
Etc
Reference
http://www.vogella.com/articles/Android/article.html
developer.android.com/
http://stackoverflow.com/questions/
http://prasanta-paul.blogspot.in/2010/06/android-parcelable-example.html
http://dev.fyicenter.com/Interview-Questions/Socket2/What_s_File_Descriptors_and_Sockets_.html
http://www.mastertheboss.com/jboss-configuration/solving-javanetbindexceptionaddress-already-in-use-jvm_bind
http://android-er.blogspot.in/2011/01/simple-communication-using.html
and other Internet Videos Tutorial
www.youtube.com
Book
Java 2 Complete Reference
73