archive-com.com » COM » T » TECHOTOPIA.COM

Total: 1018

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Creating an Example Android Application - Techotopia
    menu If at this point more than one AVD emulator has been configured on the system a window will appear providing the option to select which AVD environment the application will run in If multiple AVDs are listed select the Nexus7 emulator created in the earlier chapter In the event that only one AVD is available Eclipse will automatically launch that virtual device The AVD window typically appears immediately but a delay may be encountered as the emulator starts up and loads the Android operating system Once the operating system has loaded the example application will run and appear within the emulator as shown in Figure 4 8 Figure 4 8 In the event that the activity does not automatically launch check to see if the launch icon has appeared on the emulator screen If it has simply click on it to launch the application When the application has launched an additional window may appear asking whether or not LogCat messages should be monitored When an application is running a range of diagnostic messages is output by the system In addition the application developer may have included diagnostic messages into the application code It is generally recommended therefore that monitoring of these messages be enabled Assuming that the application loads into the emulator and runs as expected we have safely verified that the Android development environment is correctly installed and configured Stopping a Running Application When building and running an application for testing purposes each time a new revision of the application is compiled and run the previous instance of the application running on the device or emulator will be terminated automatically and replaced with the new version It is also possible to manually stop a running application from within the Eclipse environment To stop a running application begin by displaying the Eclipse DDMS perspective DDMS stands for Dalvik Debug Monitor Server The default configuration for Eclipse is to launch showing the Java perspective and for a button to be located in the top right hand corner of the main Eclipse screen Figure 4 9 that allows the DDMS perspective to be displayed Figure 4 9 In the event that this button is not present the perspective may be displayed using the Window Open Perspective DDMS menu option Once selected the DDMS perspective will appear as illustrated in Figure 4 10 Figure 4 10 The left hand panel entitled devices lists any devices or emulators to which the development environment is attached Under each device is a list of processes currently running on that device or emulator instance Figure 4 11 for example shows the Devices panel with the AndroidTest application running Figure 4 11 To terminate the AndroidTest application select the process from the list and click on the red Stop button located in the Devices panel toolbar To return to the main Java development perspective simply click on the Java button in the Eclipse toolbar eBookFrenzy com Purchase the fully updated Android 6 Edition of this Android Studio Development Essentials publication in eBook 9 99 or Print 38 99 format Android Studio Development Essentials Android 6 Edition Print and eBook ePub PDF Kindle editions contain 65 chapters Modifying the Example Application The next step in this tutorial is to modify the user interface of our application so that it displays a larger text view object with a different message to the one provided for us by Eclipse The user interface design for our activity is stored in a file named fragment android test xml which in turn is located under res layout in the project workspace Using the Package Explorer panel locate this file as illustrated in Figure 4 12 Figure 4 12 Once located double click on the file to load it into the user interface builder tool which will appear in the center panel of the Eclipse main window Figure 4 13 In the toolbar across the top of the layout editor panel is a menu that is currently set to Nexus One Since we are designing a layout for the screen of a Nexus 7 device click on the menu and select the Google Nexus 7 800 x 1280 tvhdpi menu option The visual representation of the device screen will subsequently change to reflect the dimensions of the Nexus 7 device If you have created a custom AVD for another device this may also be selected from the menu so that the design canvas matches that device To change the orientation between landscape and portrait simply use the drop down menu immediately to the right of the device selection menu In the center of the panel is the graphical representation of the user interface design now within the context of a Nexus 7 device As can be seen this includes the label that displays the Hello World message Running down the left hand side of the panel is a palette containing different categories of user interface components that may be used to construct a user interface such as buttons labels and text fields It should be noted however that not all user interface components are obviously visible to the user One such category consists of layouts Android supports a variety of different layouts that provide different levels of control over how visual user interface components are positioned and managed on the screen Though it is difficult to tell from looking at the visual representation of the user interface the current design has been created using a RelativeLayout This can be confirmed by reviewing the information in the Outline panel that by default is located on the upper right hand side of the Eclipse main window and is shown in Figure 4 14 Figure 4 14 As we can see from the outline the user interface consists of a RelativeLayout parent that has as a child the TextView object The first step in modifying the application is to delete the TextView component from the design Begin by clicking on the TextView object within the user interface

    Original URL path: http://www.techotopia.com/index.php/Creating_an_Example_Android_Application (2016-02-13)
    Open archived version from archive


  • Testing Android Applications on a Physical Android Device with ADB - Techotopia
    resulting dialog check for a category entitled Other Devices Unfold this category and check to see if the Android device is listed in the case of Figure 5 5 a Nexus 7 has been detected Figure 5 5 Right click on the device name and select Update Driver Software from the menu Select the option to Browse my computer for driver software and in the next dialog keep the Include subfolder option selected and click on the Browse button Navigate to the location into which the USB drivers were installed in the case of the Google USB driver this will be sdk path sdk extras google usb driver and click on OK to select the driver folder followed by Next to initiate the installation During the installation a Windows Security prompt will appear seeking permission to install the driver as illustrated in Figure 5 6 When this dialog appears click on the Install button to proceed Figure 5 6 Once the installation completes the Windows driver update screen will refresh to display a message indicating that the driver has been installed and that the device is now recognized as an Android Composite ADB Interface Figure 5 7 Return to the Device Manager and note that the device is no longer listed under Other Devices and is now categorized as an Android Composite ADB Interface Figure 5 8 for example shows the device entry for a Nexus 7 tablet using the Google USB driver Figure 5 8 With the drivers installed and the device now being recognized as the correct device type open a Command Prompt window and execute the following command adb devices This command should output information about the connected device similar to the following List of devices attached 015d41d4454bf80c offline If the device is listed as offline or unauthorized go to the device display and check for the dialog shown in Figure 5 9 seeking permission to Allow USB debugging Figure 5 9 Enable the checkbox next to the option that reads Always allow from this computer before clicking on OK Repeating the adb devices command should now list the device as being ready List of devices attached 015d41d4454bf80c device In the event that the device is not listed execute the following commands to restart the ADB server adb kill server adb start server In the event that the device is still not listed try executing the following command android update adb Note that it may also be necessary to reboot the system Linux adb Configuration For the purposes of this chapter we will once again use Ubuntu Linux as a reference example in terms of configuring adb on Linux to connect to a physical Android device for application testing Begin by attaching the Android device to a USB port on the Ubuntu Linux system Once connected open a Terminal window and execute the Linux lsusb command to list currently available USB devices lsusb Bus 001 Device 003 ID 18d1 4e44 asus Nexus 7 9999 Bus 001 Device

    Original URL path: http://www.techotopia.com/index.php/Testing_Android_Applications_on_a_Physical_Android_Device_with_ADB (2016-02-13)
    Open archived version from archive

  • An Overview of the Android Architecture - Techotopia
    smaller memory footprint than standard Java bytecode Standard Java class files can usually though not always be converted to Dex format using the dx tool included with the Android SDK Android Runtime Core Libraries The Android Core Libraries also referred to as the Dalvik Libraries fall into three main categories each of which merits an individual description Dalvik VM Specific Libraries This is a set of libraries used predominantly for interacting directly with an instance of the Dalvik VM and is unlikely to be used by most Android application developers eBookFrenzy com Purchase the fully updated Android 6 Edition of this Android Studio Development Essentials publication in eBook 9 99 or Print 38 99 format Android Studio Development Essentials Android 6 Edition Print and eBook ePub PDF Kindle editions contain 65 chapters Java Interoperability Libraries Android applications are predominantly developed using the Java programming language The Standard Java development environment includes a vast array of classes that are contained in the core Java runtime libraries These libraries provide support for tasks such as string handling networking and file manipulation to name but a few and are both familiar to and widely used by Java developers regardless of platform The Java Interoperability Libraries are an open source implementation based on the Apache Harmony project of a subset of the Standard Java core libraries that have been adapted and transformed for use by applications running within a Dalvik VM Android Libraries This category encompasses those Java based libraries that are specific to Android development Examples of libraries in this category include the application framework libraries in addition to those that facilitate user interface building graphics drawing and database access A summary of some key core Android libraries available to the Android developer is as follows android app Provides access to the application model and is the cornerstone of all Android applications android content Facilitates content access publishing and messaging between applications and application components android database Used to access data published by content providers and includes SQLite database management classes android graphics A low level 2D graphics drawing API including colors points filters rectangles and canvases android hardware Presents an API providing access to hardware such as the accelerometer and light sensor android opengl A Java interface to the OpenGL ES 3D graphics rendering API android os Provides applications with access to standard operating system services including messages system services and inter process communication android media Provides classes to enable playback of audio and video android net A set of APIs providing access to the network stack Includes android net wifi which provides access to the device s wireless stack android provider A set of convenience classes that provide access to standard Android content provider databases such as those maintained by the calendar and contact applications android text Used to render and manipulate text on a device display android util A set of utility classes for performing tasks such as string and number conversion XML handling and date and time manipulation android

    Original URL path: http://www.techotopia.com/index.php/An_Overview_of_the_Android_Architecture (2016-02-13)
    Open archived version from archive

  • The Anatomy of an Android Application - Techotopia
    data of a specific type on which the action is to be performed In the case of implicit intents the Android runtime will select the activity to launch that most closely matches the criteria specified by the Intent using a process referred to as Intent Resolution Broadcast Intents Another type of Intent the Broadcast Intent is a system wide intent that is sent out to all applications that have registered an interested Broadcast Receiver The Android system for example will typically send out Broadcast Intents to indicate changes in device status such as the completion of system start up connection of an external power source to the device or the screen being turned on or off A Broadcast Intent can be normal asynchronous in that it is sent to all interested Broadcast Receivers at more or less the same time or ordered in that it is sent to one receiver at a time where it can be processed and then either aborted or allowed to be passed to the next Broadcast Receiver Broadcast Receivers Broadcast Receivers are the mechanism by which applications are able to respond to Broadcast Intents A Broadcast Receiver must be registered by an application and configured with an Intent Filter to indicate the types of broadcast in which it is interested When a matching intent is broadcast the receiver will be invoked by the Android runtime regardless of whether the application that registered the receiver is currently running The receiver then has 5 seconds in which to complete any tasks required of it such as launching a Service making data updates or issuing a notification to the user before returning Broadcast Receivers operate in the background and do not have a user interface Android Services Android Services are processes that run in the background and do not have a user interface They can be started and subsequently managed from Activities Broadcast Receivers or other Services Android Services are ideal for situations where an application needs to continue performing tasks but does not necessarily need a user interface to be visible to the user Although Services lack a user interface they can still notify the user of events through the use of notifications and toasts small notification messages that appear on the screen without interrupting the currently visible Activity and are also able to issue Intents Services are given a higher priority by the Android runtime than many other processes and will only be terminated as a last resort by the system in order to free up resources In the event that the runtime does need to kill a Service however it will be automatically restarted as soon as adequate resources once again become available Example situations where a Service might be a practical solution include the streaming of audio that should continue when the application is no longer active or a stock market tracking application that needs to notify the user when a share hits a specified price Content Providers Content Providers implement a mechanism for

    Original URL path: http://www.techotopia.com/index.php/The_Anatomy_of_an_Android_Application (2016-02-13)
    Open archived version from archive

  • Understanding Android Application and Activity Lifecycles - Techotopia
    that processes that were the least recently in the foreground are killed first Empty Process Empty processes no longer contain any active applications and are held in memory ready to serve as hosts for newly launched applications somewhat analogous to keeping the doors open and the engine running on a bus in anticipation of passengers arriving Such processes are obviously considered to be the lowest priority and are the first to be killed to free up resources Inter Process Dependencies The situation with regard to determining the highest priority process is slightly more complex than outlined in the preceding section for the simple reason that processes can often be inter dependent As such when making a determination as to the priority of a process the Android system will also take into consideration whether the process is in some way serving another process of higher priority for example a service process acting as the content provider for a foreground process As a basic rule the Android documentation states that a process can never be ranked lower than another process that it is currently serving eBookFrenzy com Purchase the fully updated Android 6 Edition of this Android Studio Development Essentials publication in eBook 9 99 or Print 38 99 format Android Studio Development Essentials Android 6 Edition Print and eBook ePub PDF Kindle editions contain 65 chapters The Activity Lifecycle As we have previously determined the state of an Android process is determined to a large extent by the status of the activities and components that make up the application that it hosts It is important to understand therefore that these activities also transition through different states during the execution lifetime of an application The current state of an activity is determined in part by its position in something called the Activity Stack The Activity Stack For each application that is running on an Android device the runtime system maintains an Activity Stack When an application is launched the first of the application s activities to be started is placed onto the stack When a second activity is started it is placed on the top of the stack and the previous activity is pushed down The activity at the top of the stack is referred to as the active or running activity When the active activity exits it is popped off the stack by the runtime and the activity located immediately beneath it in the stack becomes the current active activity The activity at the top of the stack might for example simply exit because the task for which it is responsible has been completed Alternatively the user may have selected a Back button on the screen to return to the previous activity causing the current activity to be popped off the stack by the runtime system and therefore destroyed A visual representation of the Android Activity Stack is illustrated in Figure 8 2 Figure 8 2 As shown in the diagram new activities are pushed on to the top of the

    Original URL path: http://www.techotopia.com/index.php/Understanding_Android_Application_and_Activity_Lifecycles (2016-02-13)
    Open archived version from archive

  • Handling Android Activity State Changes - Techotopia
    killed by the runtime system while in the background The dynamic state on the other hand is saved and restored for slightly more complex reasons Consider for the sake of an example that an application contains an activity which we will refer to as Activity A containing a text field and some radio buttons During the course of using the application the user enters some text into the text field and makes a selection from the radio buttons Before performing an action to save these changes however the user then switches to another activity causing Activity A to be pushed down the Activity Stack and placed into the background After some time the runtime system ascertains that memory is low and consequently kills Activity A to free up resources As far as the user is concerned however Activity A was simply placed into the background and is ready to be moved to the foreground at any time On returning Activity A to the foreground the user would quite reasonably expect the entered text and radio button selections to have been retained In this scenario however a new instance of Activity A will have been created and if the dynamic state was not saved and restored the previous user inputs lost The main purpose of saving dynamic state therefore is to give the perception of seamless switching between foreground and background activities regardless of the fact that activities may actually have been killed and restarted without the user s knowledge The mechanisms for saving persistent and dynamic state will become clearer in the following sections of this chapter The Android Activity Lifecycle Methods As previously explained the Activity class contains a number of lifecycle methods which act as event handlers when the state of an Activity changes The primary methods supported by the Android Activity class are as follows onCreate Bundle savedInstanceState The method that is called when the activity is first created and the ideal location for most initialization tasks to be performed The method is passed an argument in the form of a Bundle object which may contain dynamic state information typically relating the state of the user interface from a prior invocation of the activity onRestart Called when the activity is about to restart after having previously been stopped by the runtime system onStart Always called immediately after the call to the onCreate or onRestart methods this method indicates to the activity that it is about to become visible to the user This call will be followed by a call to onResume if the activity moves to the top of the activity stack or onStop in the event that it is pushed down the stack by another activity onResume Indicates that the activity is now at the top of the activity stack and is the activity with which the user is currently interacting onPause Indicates that a previous activity is about to become the foreground activity This call will be followed by a call to either the onResume

    Original URL path: http://www.techotopia.com/index.php/Handling_Android_Activity_State_Changes (2016-02-13)
    Open archived version from archive

  • Android Activity State Changes - An Example Application - Techotopia
    interface for the activity We will now modify this method so that it outputs a diagnostic message in the Eclipse LogCat panel each time it executes For this we will use the Log class which requires that we import android util Log and declare a tag that will enable us to filter these messages in the log output package com example statechange import android app Activity import android app ActionBar import android app Fragment import android os Bundle import android view LayoutInflater import android view Menu import android view MenuItem import android view View import android view ViewGroup import android os Build import android util Log public class StateChangeActivity extends Activity private static final String TAG com example StateChange Override protected void onCreate Bundle savedInstanceState super onCreate savedInstanceState setContentView R layout activity state change if savedInstanceState null getFragmentManager beginTransaction add R id container new PlaceholderFragment commit Log i TAG onCreate The next task is to override some more methods with each one containing a corresponding log call protected void onStart super onStart Log i TAG onStart protected void onResume super onResume Log i TAG onResume protected void onPause super onPause Log i TAG onPause protected void onStop super onStop Log i TAG onStop protected void onRestart super onRestart Log i TAG onRestart protected void onDestroy super onDestroy Log i TAG onDestroy protected void onSaveInstanceState Bundle outState super onSaveInstanceState outState Log i TAG onSaveInstanceState protected void onRestoreInstanceState Bundle savedState Log i TAG onRestoreInstanceState Enabling and Filtering the LogCat Panel The purpose of the code added to the overridden methods in StateChangeActivity java is to output logging information to the LogCat panel within the main Eclipse window By default this panel is not displayed so it will be necessary to configure Eclipse to display it before running the application To enable LogCat select the Window Show View Other menu option In the Show View dialog select LogCat from the Android category and click on OK An additional tab labeled LogCat should now be present next to the Console tab in the bottom panel of the Eclipse window as shown in Figure 10 2 Figure 10 2 With no filters defined the log will list every logged event that takes place within the device or emulator thereby making it all but impossible to find the log messages for our overridden methods Before running the application therefore it is necessary to create a filter which when selected will ensure that only log messages that contain the tag declared in our activity are displayed With the LogCat panel displayed click on the green located to the right of the Saved Filters title to display the filter settings dialog Figure 10 3 Name the filter Lifecycle and in the by Log Tag field enter the Tag value declared in StateChangeActivity java in the above code example this was com example StateChange but you may have changed this to reflect your company s URL Figure 10 3 When the changes are complete click on the OK button

    Original URL path: http://www.techotopia.com/index.php/Android_Activity_State_Changes_-_An_Example_Application (2016-02-13)
    Open archived version from archive

  • Saving and Restoring the User Interface State of an Android Activity - Techotopia
    provides a container for storing data using a key value pair mechanism The keys take the form of string values whilst the values associated with those keys can be in the form of a primitive value or any object that implements the Android Parcelable interface A wide range of classes already implements the Parcelable interface Custom classes may be made parcelable by implementing the set of methods defined in the Parcelable interface details of which can be found in the Android documentation at http developer android com reference android os Parcelable html The Bundle class also contains a set of methods that can be used to get and set key value pairs for a variety of data types including both primitive types including Boolean char double and float values and objects such as Strings and CharSequences For the purposes of this example we need to make sure that the text entered into the EditText field by the user is saved into the Bundle object and subsequently restored This will be achieved by using the putCharSequence and getCharSequence methods of the Bundle class respectively Saving the State The first step in extending the StateChange application is to make sure that the text entered by the user is extracted from the EditText component within the onSaveInstanceState method of the StateChangeActivity activity and then saved as a key value pair into the Bundle object In order to extract the text from the EditText object we first need to identify that object in the user interface Clearly this involves bridging the gap between the Java code for the activity contained in the StateChangeActivity java source code file and the XML representation of the user interface contained within the activity state change xml resource file In order to extract the text entered into the EditText component we need to gain access to that user interface object Each component within a user interface has associated with it a unique identifier By default the Graphical Layout tool constructs the ID for a newly added component from the object type followed by a sequential number though this can and should be changed to something more meaningful by the developer As can be seen by checking the Outline panel within the main Eclipse window when the activity state change xml file is selected and the Graphical Layout tool displayed the EditText component has been assigned ID editText1 As outlined in the chapter entitled The Anatomy of an Android Application all of the resources that make up an application are compiled into a class named R Amongst those resources are those that define layouts including the layout for our current activity Within the R class is a subclass named layout which contains the layout resources and within that subclass is our activity state change layout With this knowledge we can make a call to the findViewById method of our activity object to get a reference to the EditText1 object as follows final EditText textBox EditText findViewById R id editText1 Having

    Original URL path: http://www.techotopia.com/index.php/Saving_and_Restoring_the_User_Interface_State_of_an_Android_Activity (2016-02-13)
    Open archived version from archive



  •