Satya Komatineni

Aruna,

Keep an eye on the following link

Android Study Guide for Pro Android 3: How can I learn Android Quckly?


I will post an article and resources that aim to answer the following in an actionable form

3 years ago we were beginers too. How did we learn Android?

I am a beginer will this book help me to learn Android?

I am a beginer how can I use this book to learn Android?

what are my strategies to learn Android the quickest?

what are my prerequisites to learn Android?

what do I need to know first and what can I learn next on a real project?

what do I need to know to get a job in Android space?

Where can I get help and advice?

Thanks again
Satya

Terence,

One can certainly include externally build jar files by other java compilers in to android.

Here is a research link for this topic

Externally built jar files and Android

However you must see what other java jar files those may further depend on. Also the android java sdk is a smaller subset of the full java sdk. So if the external jar is using some classes that don't exist in android jar then they will fail.

Hope this is of some help

Satya

Thank you very much for participating in Pro Android 3 promotion. The questions have been thought provoking and inspired by the need I will post an essaty/article/writeup with a goal to answer the following Very Useful Set of questions

3 years ago we were beginers too. How did we learn Android?

I am a beginer will this book help me to learn Android?

I am a beginer how can I use this book to learn Android?

what are my strategies to learn Android the quickest?

what are my prerequisites to learn Android?

what do I need to know first and what can I learn next on a real project?

what do I need to know to get a job in Android space?

Where can I get help and advice?

here is a link where I will post the answers

Android Study Guide for Pro Android 3: How can I learn Android Quckly?

Thanks again
Satya

Roban,
thank you for looking into the book.

the key is to reach out to us through email and we will make sure you get the ideas that are in the book

Satya

I think you will find Android a good company then.

I am quite jealous of the EXTENSIVE graphics API in Android. Probably the most extensive of the Android APIs. You can see this from the sample programs that come with the android sdk.

However having spoiled by the web for so many years I haven't had a chance to cover the graphics API much as I will need to refresh the basic drawing principles on a canvas and using the drawable views etc. Not sure at all when I will get a chance to do that at this moment.

This is one area that needs a good short book

Satya

To add to Dave's comments, this book is still useful to some extent for the experienced OpenGL programmer as well because it deals with the Android Speciific interfaces that are required for you to start calling the OpenGL APIs.

Satya

Leroy,

the OpenGL chapter is about 70 pages long. I would like to think that it is a great OpenGL resource that can get you up and running with OpenGL with out knowing anything about OpenGL ES 1.x.

However android is now moving on to OpenGL ES 2.x which is an entirely different animal.

However one needs to understand all of the concepts that we covered in the book.

There are samples in the book that is really good for an experienced java programmer but a beginer opengl programmer. This should be a good place to start integrating with the rest of your controls.

However that application integration is not covered in the book. You will be venturing into that space on your own.

Satya

Augusto,

I see the dilemma. I don't know the answer.

All I know is OpenGL drawing occurs on a special view called GLSurfaceView which itself is derived from a View. Here is what the doc says about this view

Manages a surface, which is a special piece of memory that can be composited into the Android view system
Provides a dedicated drawing surface embedded inside of a view hierarchy. You can control the format of this surface and, if you like, its size; the SurfaceView takes care of placing the surface at the correct location on the screen

The surface is Z ordered so that it is behind the window holding its SurfaceView; the SurfaceView punches a hole in its window to allow its surface to be displayed. The view hierarchy will take care of correctly compositing with the Surface any siblings of the SurfaceView that would normally appear on top of it. This can be used to place overlays such as buttons on top of the Surface, though note however that it can have an impact on performance since a full alpha-blended composite will be performed each time the Surface changes.

It may be obliquely pointing to what you are refering to.

Marco,

For good or bad these are "teachable" simple examples that demonstrate the concepts of that particular chapter. They are stand alone and simple.

Here is a list of these samples: Pro Android 3 Downloadable Projects

Satya

It is an excellent approach.

There are documentation issues a couple of years ago when I wrote the chapter. But is a very active set of deveopers and I know Jeff (one of their founders) reall well. He is awsome.

I have high hopes for Titanium.

Satya

Andrzej,

Thank you very much for pointing this out.

I encourage you to contact us for anything like this.

Let me see if I can solve your chapter 7 problem first and then I will address why Pro Android 2 has a problem compiling.

You can access zip files chapter by chapter that you can directly import into eclipse.

Here is the link

Pro Android 2 Downloadable Projects

From this link download the zip file for chapter 7 and you should be able to import into your eclipse ADT. Just to be cautious make sure you are at a higher API level such as 2.3 or so.

if you can't you email me or Dave directly and we will help you out. (Infact I encourage it)

Now coming to why stuff may not compile in ProAndroid2 book:

1. For space saving in many places I haven't included the imports, leaving the eclipse ADT to fill them in. This leaves some discrepancy with package names in the android manifest file that needs to be fixed by hand.

2. With so many chapters and so many examples we have missed to include some XML files. Even with two editors checking things got missed. [Note: It is exteremely hard to present code that can compile right out of the book]. So in book 3 we have provided downloadable zip files so that we may be excused for our follies in the text of the book.

we worked hard to correct this in Pro Android 3

1. We have made a practice to include the list of files where we present examples. This acted as a cross check for us to make sure we dont miss any thing
2. Our technical editor Dylan has put extra emphasis to compile them
3. We have given the zip files on the website for downloads
4. All samples/examples in Pro Android 3 can be found here Pro Android 3 Downloadable Projects

If I can say one final thing, contact us if you can't compile. It is the easiest and the least difficult thing for us to help you on those.

Appreciate again your support

Satya

Sai,

I suspected Spring will show up on Android at some point.

No we don't cover it at all.

we stick to the basic SDK. (I have deviated from this to cover Titanium. But again removed it from 3rd edition due to space)

But clearly I see the advantage of having a small Spring as part of your toolkit

Goodluck
Satya

This is certainly a thought provoking question.

An application is a nice abstraction to have. I hope they keep it.

I like the idea that from anywhere in my code irrespective of its place I can ask for an application object and I get the same single application object. then i can discover where the app is installed, where are the log files, how I can read configuration etc.

However the right way to use an application is to use it as a conduit to get access to various services including the discovery of single instance objects (not necessarily implemented using singletons).

Again this is theory.

Until now in Android the application object if fairly simple. Given that if one needs to use its context then one can call the

Context.getApplicationContext()

static method from anywhere in the code.

If you were to use the inheritance approach the application interface will get crowded with many many methods which could have been broken down into their own abstractions.

I wish Android has a unified factory/configuration service that would have completely eliminated the need for singletons. For example the framework I developed and regularly use for web work called AspireWeb has this abstraction (much like spring) and I found it extremely useful. In that world any application instance will have the following methods

IApplication
{
IFactory getFactoryService();
ILog getLoggingService();
IConfig getConfigurationService()
}

Then each application be it desktop or web will implement its own idea of what these services are. Once you get hold of an application object it is guaranteed to have these services. Out of these the IFactory works much like Spring.

Anyways coming back to your question

Implmenting the DAOs as singletons will give you better scoping because you can use multiple singletons and not corrupt the application name space.

I will still say find a way to implement or borrow a "spring" like abstraction to eliminate singletons but still get the same affect.

No. I haven't done this on Android.

I am hoping I will get time in about 10 years to port the AspireWeb framework to Android.

Nidhi,

I follow the android developers group. Although it is the last place one would here rumors I haven't seen any one talking about certifications yet.

I am sure they have a place.

Just to humor, I don't take any certifications because I am quie afraid I will fail in most of them.

Satya

I have collected a few kudos from readers of the previous editions of this book and posted at the link below.

This is to convince myself once in a while that the book is not entirely lame and it is being used

http://www.satyakomatineni.com/proandroid3/kudos

Thanks
Satya