Slashdot Mirror
Book Review: Android User Interface Development
RickJWagner writes "So you want to be an Android developer? If you're like me, you've probably been wanting to learn how to program a mobile device, but just haven't found the time to master Objective-C. So now that Android is here, all of us garden-variety Java coders can jump on the bandwagon and start slinging apps out, right? Well, it turns out there's a little more to it than that. This book can make the trail from everyday Java code slinger to best-selling Android app writer a little more plausible." Read below for the rest of Rick's review.
Android User Interface Development
author
Jason Morris
pages
Packt Publishing
publisher
304
rating
RickJWagner
reviewer
1849514488
ISBN
A good resource for Android developers who aren't already UI experts.
summary
7/10
The book does not teach Android development. For that, there are other books and the Android SDK documentation, which I found adequate for my uses so far. This book emphasizes teaching Android User Interface development, which is something I would not have had much of a clue about without the book. (The Java and XML-based configuration of Android is easy enough for a back-end Java coder like myself, but I've never been a web-design and layout guy. Or fat-client layout and design guy for that matter, either.) That's the sweet spot for this book.
Android newbies do get an introductory chapter that guides the reader through setting up the SDK and writing a quick first app. After that, the book starts to take a serious UI bent, and that's o.k. because that's where the book's intended to go. The earliest chapters cover UI-centric matters like asking the user a question and processing the answer that is returned. List selections are explained (i.e. single-select button choices versus multi-select). Functional features like adding a header or a footer are explained.
The middle chapters cover pragmatic issues like producing an image gallery, handling date/time inputs, and validating user inputs. Layouts in Android are explained, which will be somewhat familiar to Java Swing developers. I had an interest in learning how animation works (don't we all dream of writing the next viral-selling game?), this is explained as well.
The final chapters deal with styling (i.e. how to change the way a button looks) and themes. It's very important that your application 'feels' like it should, and this is given adequate coverage in the book. I'm sure a back-end coder like myself would botch this part horribly without guidance, so I can appreciate the reason the book emphasizes these things.
The book is written in Packt's 'Cookbook' style. If you haven't seen one of these before, the book is largely cut up into sections covering some general idea. Within the section you'll find headings for the topics "Time for Action", "What Just Happened" and "Have a Go, Hero". "Time for Action" is a series of instructions that spell out exactly what to do for a sample scenario. "What Just Happened" follows up with an explanation of why the reader was asked to execute the instructions. "Have a Go, Hero" is a section challenging the reader to extend the spoon-fed instructions by implementing a next-step challenge. This style of writing emphasizes hands-on knowledge transfer without a lot of verbose theory, so it'll be good for readers who like to learn as they code. Contrast this to books that have a lengthy section of text explaining all the details of some topic, followed by a monolithic code blob towards the end of the chapter-- this book is not written that way.
The sample code that's available on Packt's site is clean and easy to understand. It follows the same structure as the sample code you'd find in the SDK, so if you're brand new to Android development you might start with the SDK teachings and then extend it with the book as soon as you're ready. I thought the examples the book presented were almost all reasonably relevant. The author did a good job of keeping the exercises presented throughout the book well contained, so you're never asked to code too much stuff at one time. I like that, as it lets you read the book without having to set aside a huge block of time at once to see the results of your coding efforts.
So who is this book good for? I'd say it's a good resource for Android developers who aren't already UI experts. I'm not saying it's good for Android newbies who need to learn the basics of Android programming, because there's just too little introductory material for that. But if you can already hack something together, and want it to be appealing to someone besides yourself, this book can help.
You can purchase Android User Interface Development from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Android newbies do get an introductory chapter that guides the reader through setting up the SDK and writing a quick first app. After that, the book starts to take a serious UI bent, and that's o.k. because that's where the book's intended to go. The earliest chapters cover UI-centric matters like asking the user a question and processing the answer that is returned. List selections are explained (i.e. single-select button choices versus multi-select). Functional features like adding a header or a footer are explained.
The middle chapters cover pragmatic issues like producing an image gallery, handling date/time inputs, and validating user inputs. Layouts in Android are explained, which will be somewhat familiar to Java Swing developers. I had an interest in learning how animation works (don't we all dream of writing the next viral-selling game?), this is explained as well.
The final chapters deal with styling (i.e. how to change the way a button looks) and themes. It's very important that your application 'feels' like it should, and this is given adequate coverage in the book. I'm sure a back-end coder like myself would botch this part horribly without guidance, so I can appreciate the reason the book emphasizes these things.
The book is written in Packt's 'Cookbook' style. If you haven't seen one of these before, the book is largely cut up into sections covering some general idea. Within the section you'll find headings for the topics "Time for Action", "What Just Happened" and "Have a Go, Hero". "Time for Action" is a series of instructions that spell out exactly what to do for a sample scenario. "What Just Happened" follows up with an explanation of why the reader was asked to execute the instructions. "Have a Go, Hero" is a section challenging the reader to extend the spoon-fed instructions by implementing a next-step challenge. This style of writing emphasizes hands-on knowledge transfer without a lot of verbose theory, so it'll be good for readers who like to learn as they code. Contrast this to books that have a lengthy section of text explaining all the details of some topic, followed by a monolithic code blob towards the end of the chapter-- this book is not written that way.
The sample code that's available on Packt's site is clean and easy to understand. It follows the same structure as the sample code you'd find in the SDK, so if you're brand new to Android development you might start with the SDK teachings and then extend it with the book as soon as you're ready. I thought the examples the book presented were almost all reasonably relevant. The author did a good job of keeping the exercises presented throughout the book well contained, so you're never asked to code too much stuff at one time. I like that, as it lets you read the book without having to set aside a huge block of time at once to see the results of your coding efforts.
So who is this book good for? I'd say it's a good resource for Android developers who aren't already UI experts. I'm not saying it's good for Android newbies who need to learn the basics of Android programming, because there's just too little introductory material for that. But if you can already hack something together, and want it to be appealing to someone besides yourself, this book can help.
You can purchase Android User Interface Development from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
yet another packt publishing review.
Just reading this story when finishing some Android programming work... and it sounds very interesting to me. Especially as UI design is not my strongest point.
Unfortunately USD 45 is quite steep, will have to add international shipping costs to it even, for a book that I can't check out first.
Now if they were selling this for a few bucks as e-book, I'd be digging up my credit card instead of writing this comment. Besides, it's a bit strange these days that a book about computers and programming does not come in e-book format.
I'm getting more and more interested in Android -- especially as the newly redesigned XCode 4 is the worst IDE I've ever used -- but I am not going to read a review by someone who finds Obj-C a significant effort to learn from Java. That's a sign that you're a code monkey and not someone who has anything close to a deep understanding of programming; moving in either direction between Java and Obj-C is one of the dead-simplest transitions amongst distinct programming languages.
Saying you don't have time to learn Objective-C is ridiculous. If you know Java, It takes half a day to learn Objective-C. The time consuming part of learning any new technology/platform is learning the frameworks. Cocoa and Cocoa Touch are huge and use design patterns that many coders do not already know. Fortunately, the design patterns are used everywhere, and they are used consistently. Once you understand and recognize the patterns, there is no more productive and flexible framework on the planet.
Frankly, learning the design patterns will make you a better programmer no matter what platform you choose. It's worth it just to advance your computer science knowledge.
If you don't think you'll need this book for over 2 months, you may want to get a subscription to access *all* books Packt has published. As a side benefit, there's a couple hundred other books you get access to too.
It's the ADT Plugin for Eclipse, jackass. If you'd taken a glance at the Dev Guide you wouldn't have had to type out that dumb comment.
Android's GUI system actually has pretty much fuck-all to do with Java Swing; the patent infringement allegations mostly have to do with techniques used in Dalvik's JIT system, if I remember correctly.
http://www.amazon.com/Cocoa-Design-Patterns-Erik-Buck/dp/0321535022/
Think you could say fragmented a few more times there?
Yes, there is an interface builder for Android in the eclipse ADT plugin. You probably already know this, but "haters got to hate", I suppose.
To answer your question, there are a few GUI Builders like this one, but they aren't great [yet].
Carrier/handset device fragmentation does mean the developer needs to account for different sizes/resolutions of screens. Using flow-based layouts, this allows the developer to create one UI and apply it to many devices (phones, tablets, laptops, TVs, etc.)
Do you have to create two exact UIs, one for iphone/ipod and the other for the ipad using the XCode Interface Builder (assuming you don't just "scale" the smaller UI to the larger screen)? And what if you were able to run your app on AppleTV someday.. would you then need to create a third exact layout?
Why respond to an obvious troll?
Objective C should take anybody who knows C and understands Java about a day to master. Its extensions are really quite simple and elegant.
The hypothetical apple TV app isn't touch based, so re-using the exact same iPhone/iPad UI doesn't make much sense.
Do you even lift?
These aren't the 'roids you're looking for.
Has anyone else notice that the field are in the wrong place?
pages = Packt Publishing?
publisher = 304 ?
Someone messed up on the ordering of the fields.
Coming from a rudimentary background of C/C++/Java/C#/Perl/Pascal/Modula-2/BASIC, I find Objective-C's named parameters infuriating.
Seriously, what's the point of:
foobar = [myClassObject runMethod:foo withParam:bar andHeresAnotherParam:baz ohWaitOneMore:foobarbaz];
Sure, if there's a lot of parameters, then naming them is a bit helpful. But I can do that in C by placing the parameters in a struct with named fields and then passing the struct in as a parameter.
Not sure what you dislike about XCode 4, once you get used to it it's much better than XCode 3. The project structures make more sense as did integrating Interface Builder, and the git integration is fantastic.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
So my only choices for smartphone development are Objective C or Java? Seems like a lose-lose situation to me. Why can't I use native C or C++ on either of them?
Morphing Software
Do you have to create two exact UIs, one for iphone/ipod and the other for the ipad using the XCode Interface Builder (assuming you don't just "scale" the smaller UI to the larger screen)?
You don't have to but in practice you do. Where the fingers are positioned when holding, the way the keyboard comes up, even the styles of navigation that make the most sense all differ from large to small devices.
Interface Builder in XCode provides very nice tools to build scalable interfaces, and they work well to support rotation. But if all you are doing to support a tablet is allowing a small screen to scale up... the in the immortal words of technical users the world over, you are Doing It Wrong.
The correct way to think about the move from a smartphone sized to display to a tablet sized display is the concept of Responsive Design.
That's a lot of text, but what is it really? It's realizing that with more space you can present more information, very well illustrated by this site that collects examples of responsive design:
http://mediaqueri.es
Now those are talking about the context of web design, but the idea applies equally well to application UI design.
What you should be doing in a design tool is building a scalable component that can be placed as a node into a responsive design.
But it does mean the container may be different depending on the device, where you select the best container at runtime - especially in terms of arranging navigation.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
On Android you can use the NDK.
On the iPhone you are perfectly free to use Objective-C++, or C, and mix in calls to the Objective-C framework.
Between the two life is probably easier for the C/C++ programmer on the ObjC side.
Oh and there's also mono for the iPhone if you prefer C#.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
So you want to be an android develeper? No. I'm a Motherfucking programmer motherfucker. And garden variety Java programmers? Is Objective C that friggin obtuse?
I hate to agree with the troll, but he's right on that point: UI Layout on Android is sorely lacking compared to the offerings from Apple and Microsoft.
Given the introduction of Android Tablets and Honeycomb, Android devs are going to have to start making two different UI layouts for phone and tablet apps. Mainly because consumers of tablet apps are going to expect you to do something with the extra space a tablet affords other than just making everything bigger. Also, because the tablet versions of the OSes come with new UI controls specifically for tablets.
I have no idea why you're at 0: Troll. ADT is nothing close to IB, or even Microsoft's WPF tools. If you haven't tried them all, don't rush to make judgement.
Well, *coding* the user interface is one of those things that seem daunting when you set out, but turns out to be no big deal after you've learned your way around a platform. The real challenge is *designing* a mobile user interface, which is especially hard for developers coming from a desktop app background. It's important not to transfer your keyboard/mouse/big ole display ways of doing things to a palmtop device. There aren't just disadvantages your app has to work around (e.g. the screen is really tiny) but there are advantages you need to exploit (less modality than a keyboard and mouse interface).
That's not to say that having a great interface builder isn't a convenience, or that the developers of such a thing don't deserve a hearty pat on the back. It's just that I would never choose a development platform, much less a *target* platform, based on how much I liked an interface builder. I'll do without a GUI for building the interface, so long as it's possible to get good looking results and the platform has other features that make my overall job easier.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
who noticed that table column values are messed up
Unless, of course, you install Qt for Android...
Hey! I drive a Camry. How does it not compare to a Porsche? It's comfy, gets good mileage, decent speakers and takes me where I want to go.
The comparison you are looking for is "comparing a Porsche to a stick up your..."
(guy who dabbles in android but really envies his iOS dev buddy)
A proper flow-based layout could work for both a small screen and a large one. Think more scrolling for the small screen, while text and other elements flow into the available space for the large screen. Just like good HTML + CSS; content can look great on a wide variety of screen sizes.
Wow, slashdot really needs a -1, Astroturfing moderation option. Does Apple pay you or do you just worship The Steve?
I've had Xoom since release date, and GP is right. While it's true that dynamic flexible layouts that are the hallmark of (most) Android apps scale to tablet screen size more often than not - most of my phone apps still look okay - they're not perfect in that respect. In particular, on small screens, developers tend to stuff a lot of secondary functions away in the context menu, some of which on tablet are better placed in an always-visible toolbar or suchlike. Also, because the screen is wider (even in portrait), sometimes it makes sense to do two-column layout instead of single-column with everything stretched to width.
Disclosure: The author is my son, so yeah - proud Dad talking, but seriously check his work out for yourself if you (like me) think the review leaves something to be desired. Personally I'm still reading the book, so can't evaluate yet...
New mod option wanted: -1 DrunkenRambling
I've written some basic software on Apple iOS and also the fragmented Android. Apple's XCode has a wonderful Interface Builder GUI component that lets you lay out your interface's widgets exactly (and in XCode 4, the Interface Builder is now part of the XCode IDE rather than a separate program). Now, I know that Android (and the Java GUI system from which Android illegally stole most of its functionality) is based on layout flows, so having an Interface Builder to place elements exactly on the screen isn't the correct approach for Android's fragmented system. Nonetheless, the XCode Interface Builder lets me set widget properties and connect source code to the widgets. Similarly, in Microsoft's Visual Studio, there is a nice interface construction GUI-based builder system as well. Is there an equivalent Interface Builder for Android, particularly one that isn't affected by Android's pervasive fragmentation?
I don't think you used the word "fragmented" enough.
To have a right to do a thing is not at all the same as to be right in doing it
Apple's Interface Builder is very much a double-edged sword though. Because it's designed as the way to create interfaces on iOS, the .xib XML files that it creates are inscrutable. They're a step up from the old .nib files, which were binary, but they're still not made for human consumption.
This means that you can't fall back to the text editor to make changes when Interface Builder refuses to do what you want it to do. Thankfully, IB is good enough that this is a fairly rare occurrence (other graphical editors might not be so good). Worse, it makes diagnosing and fixing bugs that crop up during regression testing much more difficult, because it's hard to tell exactly what's changed when viewing a diff between versions.
The graphical environment that comes with the ADT plugin is crap by comparison (hey, when your dev environment is built on Eclipse, my expectations are low). But the fundamental idea behind it is different. Android layout XML files are meant to be written and read by humans, and the graphical editor is just an optional extra that can help you learn how to write the XML. And a diff between two different versions of an Android layout XML file will be illuminating, not baffling.
I've only had the briefest introduction to Visual Studio, so I won't comment on it. It reminded me of using Visual Basic 6 in high school though.
One month cost less than this book, and then you get access to all the books you could possibly digest. Sure, it is a monthly fee, but I would normally purchase more books than this... the fact that they are all online all the time also makes it great.
I'm not debating that the flow based layouts of Android won't properly scale; quite the opposite, I believe the layout manager I wrote for my phone will scale up (aside from some of the image assets) and fit the tablet view just fine. The thing is, with a tablet, there's a lot more that I could do than just scale everything up. Taking some iPad apps as an example (as I haven't really looked at many Android tablet apps), the sketching apps use the extra space not just for more canvas, but also to introduce persistent color pickers and toolbox panes that stay on the display, instead of having to be launched from a menu. That's an example of better using the extra space.
I heard about that, but haven't had much time to actually look at it. Is it any good? Is it currently ready for prime time?
Ah....the old Java sucks, no it doesn't, C is better, no C++ is, garbage collection is for newbies, I can write some trivial program in that beats your program written in , blah blah blah blah blah. I've seen enough of these threads on /. to know that nothing useful will come of them. Including, especially, this comment. Pro-tip. Does your code meet required specifications? If yes, whodafuckcares.
CodeMeh Programming Forums is your place for Java, PHP, C++, C#, and SQL discussions, snippets, and challenges! With our Programming Challenges you can test your programming skills against other others and gain points that you can spend on various thing's!
http://www.codemeh.com