43 of 51 people found the following review helpful
Does not use Android API,
This review is from: Beginning Android Games (Paperback)The words on the book "Get started with game apps development for the Android platform" is misleading because the book does not cover the Android API. I checked the forum on the author's site and found out that the reason for not covering the Android API is that this API is not platform independent. So why the words "Android platform" on the book? Shouldn't the cover simply state "Creating a Java framework for beginning Android Games" because that's what the book is about.
Later, in the book, I read that he wanted to make things easier by not covering the Android API. But it is truly easier to learn how to do things the correct way than to learn the "easier" way and have to relearn everything. Plus, this book is listed second in Apress's Android book series, right after the beginning Android book; so one should already have some knowledge of the Android API before ready this book.
In reality, the book is a precursor to the open source Java-based game development framework libgdx, which the author developed. This framework works on Windows, Linux, Mac OS X, as well as Android. Thus, the reason for the code not being platform dependent and, therefore, not using the Android API. The book should not be sold as an Android book. It is a Java framework that just happens to work on the Android. This does not mean it is the best way to write code if you are creating your games solely for Android devices. Otherwise, why even bother to develop the Android API?
As a book that provides a Java framework for creating games for Android mobile phones, the book is excellent. The author's framework provides a very organized structure for creating games.
However, there will be issues that will crop up if you use his framework without the Android API. For this reason, I am now in the process of modifying the code to use the Android API, at first I subtracted one star, giving the book four stars instead of five, for that. But after reading Chapter 6 and realizing just how uncompilable his code is to the Android way of doing things, I've subtracted two stars.
Sort: Oldest first | Newest first
Showing 1-5 of 5 posts in this discussion
Initial post: Apr 12, 2012 1:35:42 AM PDT
Mario Zechner says:
The abstraction is similar to libgdx, but it's pure Android. I'm not exactly sure what hinders you from using Android specifics in combination with the books framework?
In reply to an earlier post on Apr 12, 2012 12:51:58 PM PDT
Nothing hinders me from using the Android API, which is exactly what I did. I used activities, intents, views, drawables, and listeners as well as taking into consideration pixels in addition to density. I did not use canvas and surface view. I'll write something up about what I did on my site (apps.joyellen.net). In the meantime, my first app is now up on Google Play (Lucky Cat by Joy Ellen).
Posted on Aug 17, 2012 5:34:50 PM PDT
I don't see how this book is incompatible with the Android API? I've used it as a basis for writing a lot of things, strictly for Android, and have never had problems. The book covers Activities, drawables, Canvas, OpenGL ES, lifecycle, pretty much everything you need to know to get started. It may not be as in-depth on those topics as a pure Android book, but that's because it's not supposed to be/marketed as a pure Android book, but rather a game development book aimed at Android, and it succeeds as such.
In reply to an earlier post on Aug 18, 2012 3:16:14 AM PDT
Last edited by the author on Aug 18, 2012 3:17:19 AM PDT
It's been a long time; so you are really taxing my memory here, but I do remember that I stopped reading the book after Chapter six.
Yes. I did give the book three stars due to the author's knowledge of Java and game programming. However, I was disappointed in the book as a book for teaching game programming to Android developers.
I might have a different viewpoint or different expectations because I'm coming from a web development background. I have found that programming for Android devices is very similar to developing websites. For one, you can not depend on one screen size. Handling layouts, images, and text is of prime importance.
Surprisingly though, I have found the most difficult issue with developing Andriod apps is not accommodating screen sizes. It is handling the loading of images. Android still has a long way to go in providing sufficient memory for loading large images. In the meantime, it is very important to minimize image file size.
To do so, I:
* Use one copy of each image for all screen sizes. I then scale the images on-the-fly to accommodate different screen sizes.
* Reuse images whenever possible.
* Garbage collect images instead of relying on Java's garbage collection feature. (The GC doesn't always clear memory when it should.)
* Make images as small as possible.
* Compare resolution and image file types for all images. I do not assume that one type will always lead to a smaller file size.
* Avoid text images. If there is text, I put it in the XML or my Constants static class file.
In comparison, the author:
* Used large image sprites (which he calls atlasing) instead of small images. Sprites are typically used in web development to reduce the number of http requests. In addition, sometimes the file size of one large image will be smaller than that of multiple small images. And I have seen Android developers using sprites. However, I'm not so sure they are going about it the right way because I'm finding that Android has huge issues loading large images as opposed to loading multiple images.
* Used text images when designing the Mr Nom game.
* Used all PNGs for Mr Nom, which could end up being larger than GIFs due to indexing.
I also adhere to the following practices when writing for the Android:
* Use XML files and static constants for all content.
* Do not use the private modifier.
* Access variables directly instead of through getters/setters.
* Use static classes whenever possible.
* Do not make unnecessary classes.
* Avoid looping.
* Use int over float.
* Minimize object creation.
* Use local variables over member variables.
Many of these practices differ from writing typical Java apps. The author does mention many of these, but his code doesn't always follow his advice. For example, his AndroidSound class seems like a lot of unnecessary overhead. One of my apps has 12 sounds. I create one SoundPool and 12 ints for them. If I did it his way, I would need to create 12 AndroidSound objects in addition to the SoundPool object and 12 ints. Another example is his AccelerometerHandler class. It has getter methods getAccelX(), getAccelY(), and getAccelZ(), which do nothing more than return the variable values.
And then, I prefer to take advantage of the Android API whenever possible, I am:
* Making extensive use of XML for layout, animation, styles, strings, arrays, colors, and dimensions. It makes a huge difference in how I write my code.
* Using AsynTask, not the Java interface Runnable as used by the author. This also makes a huge difference in how I write my code.
* Using the drawable folder for my images, not the assets folder as recommended by the author.
I then had concerns about the following:
The author mentions optimizing animations for performance by minimizing the frame rate. He suggests a frame rate of between 30 to 60, with 60 being the maximum. These numbers seem awfully high. A frame rate of 24 should be good enough. This is the default for Flash.
The author recommends using a wake lock to keep the screen from going dim. Wake locks are known to drain the battery.
After reading through Chapter 6, I lost confidence in the book, but I'm not a Java programmer. I used to be a web developer. So I decided to check out the author's games. If his games worked well on my Android devices, then perhaps there is something to his Libgdx framework after all. I found only one of his games on the Android. It's called Newton. I installed the lite version on my Android tablet. The game has potential. However, as it stands, it is excruciatingly slow. And then the game design, as an Android game, needs work. The game consists of a rocket, an object, and a line to fire the object. Like the old arcade games (and being 50, I remember them very well), you have to use buttons to turn the object and fire it. Only strangely, you need two buttons to turn the object. In the old days, we only needed one. Anyway, mobile devices don't have these button restrictions. Mobile device screens are touchable, which means that as a very basic requirement you should be able to touch the rocket to move and fire it. Clearly, the game is not making use of Android's capabilities. It's as if the author wrote his code to make a game for another platform and then adapted the game code to work on Android mobile devices. This is what the author's Libgdx framework is all about--creating games for multiple platforms. So you will need to adapt his code if you want to create games for Android. I would rather consult a book that is geared to writing games for Android devices and not one trying to market the author's framework.
In reply to an earlier post on Aug 18, 2012 7:04:05 PM PDT
Last edited by the author on Aug 18, 2012 7:04:31 PM PDT
Maybe that's why. Up through chapter 6 he only deals with Canvas, but most of the techniques he uses are geared toward the introduction of OpenGl after ch. 6, which, if you're writing real time games, OpenGl is a million times better than Canvas. In that regard, things like texture/font atlasing, assets vs. drawable, and float-based math are all good and relevant techniques to use.
Some of your practices are more efficient, for sure, but that's why it's a beginners book. It's also important to remember that games are an exceptional medium, and there are a lot of Android best practices that don't apply to games. Personally, I find games that don't use wake-lock to be incredibly irritating.
Ultimately, you've clearly explained some good improvements to the book's methods, but I just think it's a little unfair to say it doesn't use the Android API.
‹ Previous 1 Next ›