I'd like to know with Pro Android 3 does it touch on designing and optimizing for Tablets? The book is really big, but on Amazon's site I didn't see this specific topic mentioned in the product description. At 1200 pages, I assume unlike a lot of the Android books available you don't gloss over the topics and spend a little time, not just showing an example of how to do things, but explaining what is done and why. This is something I've been looking for and hope that your book delivers on that.
Thank you for providing the community with another valueable resource!
We have asked tough questions in the book especially "why?".
As far as optimizing for tablets, the 3.0 API has introduced a couple of new concepts just for tablets. Fragments, fragmetn dialogs, action bar etc. We cover the details of these a lot.
when you use fragments extensively you are essentially programming for tablets. we cover fragments really well. Trust us there are a ton of surprizes with fragments.
However we do not cover the styling aspects of what you should do differently for tablets. Such as what shoudl icons look like or how you should layout your screens etc. we cover the technology but not the asthetics.
You mentioned that there are a lot of "surprises" with using fragments. Do you discuss things to be aware of and watch out for when using them? As developers begin to create tablet versions of their software are there many new facets to developing for a tablet that they will need to be aware of aside from the aesthetics of their apps that are vastly different from developing for the phone? Basically do the same items such as memory management, power consumption of apps, storage, permissions, etc apply to developing for tablets like they do for developing for phones?
I'm wanting to get a good idea of how similiar/different it is developing for both phones and tablets when creating a version of your application for both.
posted 9 years ago
we clearly don't have coverage for
memory management, power consumption of apps, storage, permissions
However programming for tablets mean programming using
and more facilities revolving around fragments.
Currently tablet programming is all about programming with fragments. we cover this well.
The fragments are designed in such a way that you can place one or more fragments based on orientation or device size. Fragments also manage state. They manage back button well. Along with actionbar they emulate a browser like usage pattern for your application. These aspects are covered in the book.
Fragments are expected to become available on phone API as well. But until that happens you are developing in two different worlds. You can have the same service API but you end up with two UIs.
Once the fragments are available uniformly for both APIs (phone and tablet) then you probably have more options. Even then it will be continuing challenge with signficant differences in screen sizes.
The resources mechanism in android (we cover resources well) allows for different layout configurations.
However we don't have a chapter that specifically says how to write one application that works on both tablets and phones.
If you write a phone application it will run on tablets but not the otherway around as those apis are not available in phone right now.
Thank you Satya for the excellent information and again for providing this book. I'm not sure, but at present this may be the only book available or at least one of the very few to address creating applications for tablets in addition to covering development for phones.
Here's an example of something that was surprising with fragments: because fragments exist within an activity, handling the back button requires a different mechanism. Normally the back button would pop the activity, but when you're working with fragments, you will probably keep the current activity in place and just swap around fragments. To do this, Android introduces the fragment transaction and the back stack. In effect, you are swapping out the state of some fragments with other fragments to make the UI change to your liking. For example, if you have a list of emails on the left, and the text of the current email on the right, clicking the back button could take the user back to the email they were looking at previously. This is in effect rolling back the fragment transaction. So you might think that you're rolling back the state of the activity, but you're not. You're only swapping out certain fragments with certain other fragments while the activity itself will only be changed if you make it change. It's hard to explain in just a short space as a forum post, but it was something that we felt needed to be explained in the book, because it could get really weird if your users start hitting the back key, you start popping fragment transactions off the back stack, but other elements of your activity aren't adjusted to match. This is also why you should probably encapsulate as much as you can within fragments, so your activity becomes a very simple container for fragments, and not as much an integral part of your application.
Thank you for the additional information. I'm still new to Android development, but I will have to look further into this. It really sounds like your book is an excellent addition to any Android developer's bookshelf.