Archive

Archive for the ‘Android’ Category

Android SoundPool Bug – still no fix

March 2nd, 2012 1 comment

I had to remove certain devices from the availability list in the Android Market to prevent “bad reviews”. The SoundPool Bug from June 2012 is still not fixed and has now around 100 Comments in the Bug Tracker from other Developers. So feel free to push this Bug for getting more Attention.

Meanwhile I’m thinking of rewriting the SoundPool myself and distribute a free SoundPool Library. I keep you posted.

Software Patent claims – Seriously ?

October 3rd, 2011 2 comments

I had to remove the “Buy Full Version” Button from my “The Defense” Demo because it may infringe some Patents from intellectual Property Company in the US. So the first thing that came to my mind was “WTF – seriously ?” as I received a Fedex letter with the infringement claim. I thought this has to be a joke – but it wasn’t. In the US it’s still possible that you can have patents that are so trivial and widely interpretable that everybody can be sued. Good times for patent attorneys that are making a crap-load of money these days.

The same thing with Apple vs Everybody because other tablets might look nearly the same….so who cares. Table size and colorization is no rocket science. It’s common sense that tablet all over the world have to be somewhere near the size of a book and kind of thin. It’s so sad to see that this “Cold war of Patent Claims” costs billions and billions that could better be invested to do something useful

It’s a common pattern these days to buy patents from tiny companies and build up a whole intellectual  Property Company around it to sue everybody that may have money. This goes on and on and it’s getting worse. Starting with Oracle that may have currently more attorneys than developers for earning money these days , I’m kind of frustrated when I realize  that the world and the companies are getting more greedy every day. I’m not quite sure who can end this mayhem of patent madness, but hopefully soon.

Tags:

Resolution Breakdown on Android Displays

March 29th, 2011 1 comment

You’ll find a couple of “not that official” Numbers on Phone Specs across the Market. Following Diagram is a rough statistic snapshot over ~35.000 Devices End of 2010.

For my game this is a very valuable information, because to support 800×480 and 854×480 is not a big problem, but i should think of the time i have to invest to support 480×320.

EDIT:

Google itself now has a official Site where you can check overall statistics of the android market: see http://d.android.com/resources/dashboard/screens.html

Persisting Game Data / A Game State

September 12th, 2010 No comments

I was thinking about some possibilities storing a more or less “big” GameState. As you may know the InstanceState is transient. If you google the topic you will find the Android Developer Documents about “Saving Persistent State“.

In my opinion the SharedPreferences are “ok” for simple data like Music on / off, or some yes / no / age / gender stuff. But when it comes to more complex data structures you will run into problems.

So let’s see what else we got. There is another solution called Parcelable This works with objects too, but it’s a pain in the *** to implement it for every Object you have in your Pocket.

Another possibility would be to store your data in a SQLite Database. But when you only want to store “one big” Object with lots of sub objects it’s a not to underestimate effort to implement everything you need to get tings stored at the right place.

I came to the conclusion to “keep it simple stupid”. I have a large “GameData” Object with a lot of Object Lists and primitive values and so on ….so i wrote a Singleton Save Service that read/write the Object to a File on the device. Nothing to be proud of, but sometimes in the Android World you loose the sense for the simple Java Stuff that just – works !

package com.androidfactory.service;

public class SaveService {

	private static final String SAVE_FILENAME = "TheSaveFile.ser";

	private GameData saveData;

	private static SaveService saveService;
	private Activity context;

	private FileOutputStream fOut = null;
	private ObjectOutputStream  osw = null;
	
	private FileInputStream fin = null;
	private ObjectInputStream sin = null;

	public SaveService(Context context){
		this.context = (Activity)context;
	}

	public static SaveService getInstance(Context context){
		if(saveService == null){
			saveService = new SaveService(context);

		}
		return saveService;
	}

	public  void save(GameData object){
		try {
			fOut = context.openFileOutput(SAVE_FILENAME, Activity.MODE_PRIVATE);
			osw = new ObjectOutputStream(fOut);
			osw.writeObject(object);
			osw.close();
		} catch (FileNotFoundException e) {
			e.printStackTrace();
		} catch (IOException e) {
			e.printStackTrace();
		}

	}

	public GameData readLastState(){
			try {
				fin = context.openFileInput(SAVE_FILENAME);
				sin = new ObjectInputStream(fin);
				saveData = (GameData) sin.readObject();
				sin.close();
			} catch (StreamCorruptedException e) {
				e.printStackTrace();
			} catch (IOException e) {
				e.printStackTrace();
			} catch (ClassNotFoundException e) {
				e.printStackTrace();
			}

			return saveData;
	}
}

Bitmap processing in Android

September 8th, 2010 No comments

I recently got somehow curious about some Sample Code I found in the web. The Problem is Simple. Let’s say we have a GameThread that want’s to draw a background image that fits the complete Screen. Before you draw the Bitmap to the Canvas you normally want to import the picture like this (maybe):

Bitmap mBackgroundImage = BitmapFactory.decodeResource(res, R.drawable.hase);
// this is curious
Log.i("DEBUG", "Imported Image width = " +
mBackgroundImage.getWidth() + " Heigth ="+
mBackgroundImage.getHeight());
// maybe expensive
mBackgroundImage = Bitmap.createScaledBitmap(mBackgroundImage, 480, 800, true);

The open Question: Why scaling the picture if the source-image is already in 480×800 ? The picture will suffer from scaling besides the expensive scaling process. In this scenario the we have a fixed TargetDisplay-Size of 480×800. The Picture we are importing is already 480×800 Pixel. So far so good, but the LOG output says:

09-08 10:10:16.859: INFO/DEBUG(19137): Imported Image width = 720 Heigth =1200

Strange ? ! This comes from the default density settings which seem to be kind of unreliable. In my case it’s 240dpi but the BitmapFactory works with 160 dpi. If you want to skip the re-scaling part and want to import a Bitmap the “short” way you can do that with Options.

The first thing you should do is get the density of your Display:

final DisplayMetrics metrics = context.getResources().getDisplayMetrics();

Now we can wire some options for the decoding:

Options myOptions = new Options();
		myOptions .inScaled = false;
		myOptions .inScreenDensity = metrics.densityDpi;
		myOptions .inTargetDensity = metrics.densityDpi;

So now we are ready to load the Bitmap in the right scale & size:

Bitmap newPic =	BitmapFactory.decodeResource(_resources, R.drawable.hase, myOptions )

Let the music play…

September 3rd, 2010 1 comment

While a game consists usually of more pieces than simple code, from my point of view music and sound effects are a big part of the fun.  By testing a lot of “successful” games, i noticed that the have mostly pretty poor sound effects or music.

The reason for this could be the more or less poor implementation of MediaPlayer Capabilities in Games. As Developer you will struggle in playing multiple sounds at once, or loops that run smooth. There are several things that currently look more like a “workaround” implementation-wise, like the SoundPool.

Whatever…here are some samples of background loops it created recently, enjoy:

Loop Choir
Loop Piano
Loop E-Bass

Tags: , , ,