Basic About Mobile Phone Screens and resolutions

It’s sleek and stylish, but it’s complicated! That’s how normal buyers describe smartphones in the market today. Is this description accurate? Not necessarily!

They may look complicated, but most mobile phones now are actually user friendly. What is missing then? Why is it that some users feel a little alienated and apprehensive about the new technology in mobile phones?

Somehow, there’s a technological gap brought about by the use of technological lingo to describe functions and applications in these state-of-the-art communication gadgets. Many would-be users simply do not understand the terms used to describe most of the product’s functions, applications, and processes.

So in order to cope, most users who are not really well versed when it comes to the technical terms used to describe products and product specifications go with what can be seen with the naked eye: the phone’s physical attributes. This means the screen, the keypads, the camera, and the games. Users use the most basic functions of the phone as a basis for their purchasing decisions, which is good, but which does not truly give the whole picture of what the mobile phone unit is and what it can do for the user.

So to help users know a little bit more about mobile phone deals, most especially the latest smartphones, here’s a list of terms commonly used in mobile phone conversations and product descriptions and specifications.

Screen Size and Resolution

When screens are considered, two factors are taken into account when it comes to measurements: 1) the size, and 2) the resolution. The size is generally measured diagonally in inches, and the resolution is on the number of pixels displayed on the screen.

Screen resolution is frequently referred to as a modification of the classic VGA resolution, which is 640x480 pixels. Years before, the size of mobile screens used to be 128 x 128. Today, the biggest screen size for mobile phones is 800 x 480 (WVGA). The smaller screens have a portrait orientation, while the large screens have landscape orientation. Today, a lot of mobile phones can change orientation. Most of these mobile phones have a dominant overall screen size of 240 x 320 or QVGA.

Today, however, a lot of companies are beginning to refer to resolution as a fraction of 1920x1080 pixels, or full high definition.

Here’s an example of how companies today refer to resolution, from an article in cnet.com.au:

o        QVGA       :        quarter VGA (240x320 pixels)

o        HVGA       :        half VGA (320x480 pixels)

o        WVGA      :        wide VGA (480x800 pixels)

o        FWVGA:   full wide VGA (480x854 pixels)

o        nHD         :        one-ninth high definition (360x640 pixels)

o        qHD         :        one-quarter high definition (540x960 pixels)

Read More

How to Install APK Files on Android Device Emulator

In this tutorial you are to run any APK (Android application) file to your Android emulator. Assuming you already have the Emulator running  (if not sure how run the Android device emulator, refer to this (http://kalyankumar-testing.blogspot.in/2013/02/android-emulator-to-run-your-apps.html) .

  Figure 1

Locate your adb.exe file in your Android SDK folder. In Windows environment normally your adb.exe is inside [Android-SDK-folder]/platform-tools/ . In my case, the adb.exe is in C:\android-juno\android-sdk\platform-tools (this is an example path to the adb.exe, may varies depending on your system). Find any APK file (for the purpose of this tutorial, I’ve prepare an APK file – download herehttp://bit.ly/peribahasa-apk ). After you’ve successfully downloaded the APK, put it inside your [Android-SDK-folder]/platform-tools/ as in Figure 2.

 

Figure 2

Now run the adb.exe through the command prompt, go to Start, and find cmd.

 Figure 3

In the command line, go inside the platform-tools folder, as in the Figure 4. Execute command;

adb install Peribahasa.apk

C:\Users\kerul>cd\

C:\>cd android-juno

C:\android-juno>cd android-sdk

C:\android-juno\android-sdk>cd platform-tools

C:\android-juno\android-sdk\platform-tools>adb install Peribahasa.apk

 Figure 4

Later, the apps you just install will be in the emulator.

Read More

Android Emulator to run your apps

What is Android Emulator - a virtual mobile device that runs on your computer. The emulator lets you develop and test Android applications without using a physical device.

When the emulator is running, you can interact with the emulated mobile device just as you would an actual mobile device, except that you use your mouse pointer to "touch" the touchscreen and can use some keyboard keys to invoke certain keys on the device.

This Android Virtual Device (AVD) or emulator is packaged in the Android SDK. It 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 Android applications running.

This article provides the steps to start the emulator and to run your Android app in the emulator.

STEP 1: Starting-Up your Emulator (Virtual Device)

This article assumes that you have the IDE installed in your machine (if not read the following articlehttp://blog.kerul.net/2011/06/eclipse-helios-android-development.html) and already have the knowledge to create a new Android project(click here if you have not). Press the button as in Figure 1 to open the Android SDK and AVD Manager window. AVD is Android Virtual Device.

Figure 1

You will see this window, click on the Virtual Devices. Then click New… to set a new emulator (Figure 2).

Figure 2

Key in the emulator name, the target API, and the Skin. Then click Create AVD (as in Figure 3).

Figure 3

Click on the new AVD that you have already created, and Start the AVD (Figure 4).

Figure 4

If you need to resize the virtual device (emulator) screen size, click the “Scale display to real size”. Then click Launch  (Figure 5).

Figure 5

Picture in Figure 6 is an emulator booting process. If you have lower spec of processor and memory, you will notice that it boot-up really slow.

Figure 6

Wait until the left screen displays a nice picture with icons as in Figure 7. The left component is you device (smartphone) screen and the right component is, shall we say, the physical smartphone keypad.

Figure 7

STEP 2: Compiling and Running your app in the Emulator

Figure 8

You will see this window if you’re running several emulator. So choose the emulator that match your API level (higher).

Figure 9

GO back to the emulator, and you will notice that the app screen is appearing on your left.

Figure 10

More on the emulator –> http://developer.android.com/guide/developing/devices/emulator.html

Read More

Memory Analysis for Android Applications

Let's use DDMS to examine the heap usage of this app. You can start up DDMS in one of two ways:

• from Eclipse: click Window > Open Perspective > Other... > DDMS
• or from the command line: run ddms (or ./ddms on Mac/Linux) in the tools/ directory

Select the process com.example.android.hcgallery in the left pane, and then click the Show heap updates button in the toolbar. Then, switch to the VM Heap tab in DDMS. It shows some basic stats about our heap memory usage, updated after every GC. To see the first update, click the Cause GC button.

We can see that our live set (the Allocated column) is a little over 8MB. Now flip through the photos, and watch that number go up. Since there are only 13 photos in this app, the amount of memory we leak is bounded. In some ways, this is the worst kind of leak to have, because we never get an OutOfMemoryError indicating that we are leaking.

Creating a heap dump

Let's use a heap dump to track down the problem. Click the Dump HPROF file button in the DDMS toolbar, choose where you want to save the file, and then run hprof-conv on it. In this example, I'll be using the standalone version of MAT (version 1.0.1), available from the MAT download site.

If you're running ADT (which includes a plug-in version of DDMS) and have MAT installed in Eclipse as well, clicking the “dump HPROF” button will automatically do the conversion (using hprof-conv) and open the converted hprof file into Eclipse (which will be opened by MAT).

Analyzing heap dumps using MAT

Start up MAT and load the converted HPROF file we just created. MAT is a powerful tool, and it's beyond the scope of this article to explain all it's features, so I'm just going to show you one way you can use it to detect a leak: the Histogram view. The Histogram view shows a list of classes sortable by the number of instances, the shallow heap (total amount of memory used by all instances), or the retained heap (total amount of memory kept alive by all instances, including other objects that they have references to).

If we sort by shallow heap, we can see that instances of byte[] are at the top. As of Android 3.0 (Honeycomb), the pixel data for Bitmap objects is stored in byte arrays (previously it was not stored in the Dalvik heap), and based on the size of these objects, it's a safe bet that they are the backing memory for our leaked bitmaps.

Right-click on the byte[] class and select List Objects > with incoming references. This produces a list of all byte arrays in the heap, which we can sort based on Shallow Heap usage.

Pick one of the big objects, and drill down on it. This will show you the path from the root set to the object -- the chain of references that keeps this object alive. Lo and behold, there's our bitmap cache!

MAT can't tell us for sure that this is a leak, because it doesn't know whether these objects are needed or not -- only the programmer can do that. In this case, the cache is using a large amount of memory relative to the rest of the application, so we might consider limiting the size of the cache.

Comparing heap dumps with MAT

When debugging memory leaks, sometimes it's useful to compare the heap state at two different points in time. To do this, you'll need to create two separate HPROF files (don't forget to convert them using hprof-conv).

Here's how you can compare two heap dumps in MAT (it's a little complicated):

1. Open the first HPROF file (using File > Open Heap Dump).
2. Open the Histogram view.
3. In the Navigation History view (use Window > Navigation History if it's not visible), right click on histogram and selectAdd to Compare Basket.
4. Open the second HPROF file and repeat steps 2 and 3.
5. Switch to the Compare Basket view, and click Compare the Results (the red "!" icon in the top right corner of the view).

Read More

Avoiding Memory Leaks in Android

Avoiding memory leaks

Android applications are, at least on the T-Mobile G1, limited to 16 MB of heap. It's both a lot of memory for a phone and yet very little for what some developers want to achieve. Even if you do not plan on using all of this memory, you should use as little as possible to let other applications run without getting them killed. The more applications Android can keep in memory, the faster it will be for the user to switch between his apps. As part of my job, I ran into memory leaks issues in Android applications and they are most of the time due to the same mistake: keeping a long-lived reference to a Context.
On Android, a Context is used for many operations but mostly to load and access resources. This is why all the widgets receive a Context parameter in their constructor. In a regular Android application, you usually have two kinds of Context,Activity and Application. It's usually the first one that the developer passes to classes and methods that need a Context:

@Override
protected void onCreate(Bundle state) {
  super.onCreate(state);
  
  TextView label = new TextView(this);
  label.setText("Leaks are bad");
  
  setContentView(label);
}

This means that views have a reference to the entire activity and therefore to anything your activity is holding onto; usually the entire View hierarchy and all its resources. Therefore, if you leak the Context ("leak" meaning you keep a reference to it thus preventing the GC from collecting it), you leak a lot of memory. Leaking an entire activity can be really easy if you're not careful.
When the screen orientation changes the system will, by default, destroy the current activity and create a new one while preserving its state. In doing so, Android will reload the application's UI from the resources. Now imagine you wrote an application with a large bitmap that you don't want to load on every rotation. The easiest way to keep it around and not having to reload it on every rotation is to keep in a static field:

private static Drawable sBackground;
@Override
protected void onCreate(Bundle state) {
  super.onCreate(state);
  
  TextView label = new TextView(this);
  label.setText("Leaks are bad");
  
  if (sBackground == null) {
    sBackground = getDrawable(R.drawable.large_bitmap);
  }
  label.setBackgroundDrawable(sBackground);
  
  setContentView(label);
}

This code is very fast and also very wrong; it leaks the first activity created upon the first screen orientation change. When aDrawable is attached to a view, the view is set as a callback on the drawable. In the code snippet above, this means the drawable has a reference to the TextView which itself has a reference to the activity (the Context) which in turns has references to pretty much anything (depending on your code.)
This example is one of the simplest cases of leaking the Context and you can see how we worked around it in the Home screen's source code (look for the unbindDrawables() method) by setting the stored drawables' callbacks to null when the activity is destroyed. Interestingly enough, there are cases where you can create a chain of leaked contexts, and they are bad. They make you run out of memory rather quickly.
There are two easy ways to avoid context-related memory leaks. The most obvious one is to avoid escaping the context outside of its own scope. The example above showed the case of a static reference but inner classes and their implicit reference to the outer class can be equally dangerous. The second solution is to use the Application context. This context will live as long as your application is alive and does not depend on the activities life cycle. If you plan on keeping long-lived objects that need a context, remember the application object. You can obtain it easily by callingContext.getApplicationContext() or Activity.getApplication().
In summary, to avoid context-related memory leaks, remember the following:

• Do not keep long-lived references to a context-activity (a reference to an activity should have the same life cycle as the activity itself)
• Try using the context-application instead of a context-activity
• Avoid non-static inner classes in an activity if you don't control their life cycle, use a static inner class and make a weak reference to the activity inside. The solution to this issue is to use a static inner class with a WeakReference to the outer class, as done in ViewRoot and its W inner class for instance
• A garbage collector is not an insurance against memory leaks

Read More