Tag Archive: tips


Native dialogs in Android are boring! Open-mouthed smile if you are developing an app having some cool and customized theme then doing something about those dull dialogs is a must. They wouldn’t just compliment the overall look of your application. I faced this kinda scenario recently and while experimenting and trying different suggestions on forums, I finally got around it and made it to work!

First things first, as far as my experience went, AlertDialog is not going to help you here. It just don’t get rid of that black background that is there by default (talking about gingerbread dialogs here). No matter what you do, it’ll always show the black background from behind your image (if you have any). Anyways, to create a custom dialog, we need to create a layout first in a separate xml file. Here’s an example:

Capture

This is just a simple layout having a background image that has irregular borders. Now we just need to write a few lines of code in order to make it work:

Capture

Here, we are setting the background color to transparent in order to get rid of the default dialog background color. After that, we just need to assign the layout resource to the dialog and that gets the job done.

Notice the resultDlg.getWindow().clearFlags(WindowManager.LayoutParams.FLAG_DIM_BEHIND); This will remove the dim effect that makes your parent layout a bit darker. You can also set some additional flags like adding a blurred effect to the background/host activity from which this dialog is invoked. To do this, simply use the addFlags function with FLAG_BLUR_BEHIND flag. Here’s the exact statement:

resultDlg.getWindow().addFlags(WindowManager.LayoutParams.FLAG_BLUR_BEHIND);

This will create a very nice blur effect which I find more neat than the original dim effect. And that ends this post here. Feel free to comment and ask questions, I’ll try to answer them as swiftly as I can.

Quite a long title, isn’t it? Smile

On-screen keyboard usually takes around half of the screen space while it’s shown. Most of the times it hides important controls/views that you want to be shown to the user all the times. Consider a layout having a EditText widget at the top, a list or some other control in the middle and some Buttons right at the bottom. While the user is writing text in the EditText view through on-screen keyboard, the buttons would be hiding behind it. Luckily, Android has an option to handle this scenario automatically without writing much code.

To enable a layout to adjust itself while the keyboard is shown, you need to configure an attribute for its host activity through AndroidManifest.xml file. Here’s how to do it:

<activity android:name="TestActivity" android:windowSoftInputMode="adjustResize" android:screenOrientation="portrait">

By setting android:windowSoftinputMode of this activity to adjustResize you are telling it to resize itself while the on-screen keyboard is shown. This will let the activity to shorten it’s layout in order to show everything that’s present over it. For example, if you have some buttons at the bottom of the screen, this setting will show them just above the keyboard helping the user to interact with them without closing the keyboard.

There’s one important catch in this however, this configuration DOES NOT work if the application is bound to run in full-screen. This is normally done by setting it’s android:theme attribute to @android:style/Theme.NoTitleBar.FullScreen in AndroidManifest.xml file.

This is one simple and neat technique to make your layout more flexible and user-friendly.

Recently, we at excelarz Interactive made a series of Sports Apps that enables user to follow their choice of sports in an intuitive and flexible manner. The set of applications offers its user to view news, live scores, blogs, players, schedule, draws, twitter feeds according to his choice. What we needed was to build the apps in a way as to enhance the usabilty by letting the user customize the application in a way that he choses.

For implementing the switching between selected information types (news, blogs, scores, players, twitter, schedule etc), we first looked into the native tab control of Android. After digging enough, we concluded that the tab control would not help us accomplish this variable nature that we required from it due to its rigid set of options and properties.

We then came up with the idea of using the Gallery view for achieving this functionality. What we do is we make some images for each of the tab that we require to have in our application. Then a simple adapter is created (which is required to populate the gallery dynamically) and pass on the list of selected tabs to the adapter. The adapter then creates the view as per the selection made by the user. This way we managed to acheive a sliding choice bar for selection of different info type.

See the tab bar in action the the following video.

This approach may definity not the ideal one in this scenario but we did achieve what we wanted to do. Any suggestion on improvements and alternative is more than welcome.

The starting point of any game project is writing a game loop. This is one of the most integral and crucial part of any game, whether small or large. So it must be given due attention and one should choose the most appropriate and optimized way of doing it.

The Android game programming is no exception and there are several ways of managing and writing this game loop. Here I’ll discuss some approaches that I found in SDK samples and other resources (excluding OpenGL part). There are some basic steps to follow before writing these game loops.

The first step is to create your own View or Layout by extending an existing Layout or View (like LinearLayout or SurfaceView). Then override its onDraw method to control the rendering over this surface. The general concept is, that you call some update function that calculates the dynamics of the new frame and then post an invalidate command that ultimately forces the View to draw itself, hence creating a simple basis for drawing and refreshing the objects on this surface.

1. Using TimerTask and Timer

One way of creating this loop is to extend the LinearLayout class and override its onDraw function. Then add a Timer object in the child class. Look at the code chunk below:

image

You then need to write some functions to start/stop this timer. They should look something like below:

image

The schedule function of the timer object takes a TimerTask object and the time after which the Timer task is run. Here the UpdateTask is a custom class that extends the TimerTask and overrides its run function.

image 

The postInvalidate function forces the View to redraw itself and the update function is a local function that you have to write yourself (you can name it anything) to calculate game’s next frame.

2. Creating a Custom Handler

This scheme is used in the Snake game that comes with the SDK’s samples. In this approach, you create a custom class by extending the Handler class and overriding its handleMessage function. The custom handle should be written inside you game view so that it can access the update and invalidate functions of your view. The child handler class should look like this:

image

Now you need to create an instance of this class in your game view class and then call its sleep function from your method that you will use to update your game’s frame. In the code snippet above, the sleep method calls some internal message handlers to make sure that the message is sent and handled appropriately. To find out more details about this approach, refer to the Snake game that comes with SDK samples.

3. Using SurfaceView, SurfaceHolder and a Custom Thread

This approach is considered more appropriate if one wants to write a game that is more real-time. Some SDK samples like LunarLander and JetBoy also implement this technique.

This method use the SurfaceView class to create its main game view class. The game view class in turn needs to handle the SurfaceHolder call back and then use it to get the underlying canvas which can be used to carryout the required drawing routines.

All the core game logic is written in the custom thread that uses it’s overridden ‘run’ method to update the game objects and redraw the view. This method contains a while(true) type of loop that repeatedly calls the drawing and updating routines. To draw the game objects, the method uses the SurfaceHolder’s lockCanvas method to get the underlying canvas object and then uses that object to do the drawings.

This approach doesn’t use the view or layout’s onDraw method and hence doesn’t require calling the invalidate method as the other two approaches do. Instead it clears the screen itself by calling the Canvas object’s drawBackground or drawColor routines.

Since there’s no delay or wait time mechanism in this approach, therefore, it allows the system to do the update and draw processing as fast as it possible increasing the refresh time of the game’s frames.

This wraps up the post here. I hope it is helpful for those seeking out to develop games on the Android platform.

Here’s a quick post that will guide you through a few very simple ways through which you can make you application run in a full screen i.e. without title and the notification bar of the Android OS.

1. You can add the following piece of code to your OnCreate function of your activity to make it run in full screen mode:

requestWindowFeature(Window.FEATURE_NO_TITLE);

getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN); 

Note that the first call to requestWindowFeature function might be optional for you in case you want to run the application in full screen but you also need to show the title.

2. The second method, which is more preferred in my opinion, is to use the AndroidManifest.xml file and add following attribute to your activity (in your <activity> tag, of-course):

android:theme="@android:style/Theme.NoTitleBar.Fullscreen"

The main difference between these two methods is that the first one will be called a bit late and you will see the notification bar appearing and then going in the background. The second method however avoids this behavior and make your application run in full screen straight away.