Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Image

Book Review: Android User Interface Development 111

Posted by samzenpus from the read-all-about-it dept.
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.

*

This discussion has been archived. No new comments can be posted.

Book Review: Android User Interface Development More

Book Review: Android User Interface Development

Comments Filter:

  • No e-book? (Score:3)

    by wvmarle ( 1070040 ) on Wednesday March 23, 2011 @01:36PM (#35589990)

    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.

    • Re: (Score:2)

      by stg ( 43177 )

      It is available as an e-book here [packtpub.com] . US$30.59

      Another e-book on the subject (I've started reading it and liked it, but didn't get around to finishing it yet) is Hello Android [pragprog.com].

      One thing I like about The Pragmatic Bookshelf is that they deliver directly to your Kindle. They are also DRM-free (Packt says they are too).

      • Thanks for the links.

        Pactpub link I almost closed as the price that I saw first was over USD 45; only upon looking again I realised they automatically put me to the bundle offer! Great marketing. One would expect them to promote e-books more these days. I'm considering now. USD 30.59 is not that bad; that's about the same cost as lunch for a whole week (7 days).

        • 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.

    • Check your local library.

      The one I use (aclib.us) has a Safari subscription available via your card number. Plenty of subjects to choose from.

    • Re: (Score:2)

      by wdef ( 1050680 )

      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.

      Possibly a sad reflection on programmer salaries? US$45 is not a lot of money and it would be tax deductible in most countries I suppose. Or perhaps you are a student.

      • I'm a hobbyist. And indeed not exactly rich.

        I program for fun; have an app out on the market that's free, and not even ad supported. Even if it's tax deductible (I could of course book it on my company) that doesn't help much as on my income my tax liability just a few % of my income.

  • Your first paragraph killed my interest (Score:1)

    by Anonymous Coward

    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.

    • Re: (Score:2)

      by sribe ( 304414 )

      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.

      My first thought exactly. In fact I stopped reading at that point and jumped straight to the comments, figuring there might at least be some entertainment value down here. But nooo, just reasonable criticism so far. Wishing I had mod points...

    • Re: (Score:2)

      by moberry ( 756963 )

      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.

      The concepts are virtually the same -- ok, exactly the same -- but the syntax of Objective-C, namely "message passing", took me some getting used to.

      • Re: (Score:2)

        by Altus ( 1034 )

        Really I think of message passing as more of a concept than just a syntax. Sure you can treat it as a regular old method call, but its so much more than that.

      • Re: (Score:2)

        by atrus ( 73476 )
        Since you decided to quote message passing, you don't actually understand the power that message passing brings to the table.

      • objective-c is not the same as java

        Objective C is the result of small-talk and C having unprotected sex . But small-talk expressive power is much greater than the expressive power of java and in C you can code anything that is possible on your system as you have a raw acces to that system. So I must concede that objective-c must be a really powerful language. But it syntax is so awful that I always get sick before I really take the time to get use to it.

      • You'll find the radically different syntax a blessing rather than a curse if you plan on flitting between languages on a regular basis. If you work with two almost identical but subtly different languages, the small differences with catch you out more often than you'd like. When you work with Objective-C and Java at the same time, the differences are substantial, so you end up putting more effort into learning them.

        That's my experience, anyway.

    • 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.

      • Re: (Score:1)

        by tk77 ( 1774336 )

        Agreed. Admittedly there are significant changes from Xcode 3 that can easily turn one off to it, but if you actually read the Xcode 4 transition guide and put in a bit of time with it, its actually far better then Xcode 3 was.

  • Objective-C is easy - frameworks take time (Score:5, Insightful)

    by EMB Numbers ( 934125 ) on Wednesday March 23, 2011 @01:45PM (#35590098)

    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.

    • Java is immensely easier to develop with than any flavor of C because of garbage collection and lack of pointers. If you do not understand why then please do not come anywhere near my C code.

      That said, I personally prefer to put in the extra work and develop in C++ because the result usually starts faster and performs better. And I absolutely detest JNI.

      • Java is immensely easier to develop with than any flavor of C because of garbage collection and lack of pointers. If you do not understand why then please do not come anywhere near my C code.

        1) Objective-C has garbage collection (though admitedly not on iOS at the moment)
        2) Even without GC, cocoa's reference counting system is about the best there ever has been and makes life *almost* as easy as GC –just gotta watch out for retain cycles.
        3) Java very much has pointers – that's why you can get Null pointer exceptions ;)

        • Re: (Score:2)

          by nkh ( 750837 )
          Don't forget that with the new Objective-C 2.0, reference counting is a thing of the past thanks to auto-released objects, and properties which are automagically created for you. Objective-C may not be the easiest OO language, but it sure is easier than ever (and I am an Android fan BTW).

          • Don't forget that with the new Objective-C 2.0, reference counting is a thing of the past thanks to auto-released objects

            autorelease is a method in cocoa and has nothing to do with ObjectiveC 2.0. Notably, it has nothing to do with making reference counting a thing of the past –it is in fact part of the ref counting system – it adds the object to a set of objects to have their reference counts decremented when the current stack unwinds back to the next autorelease pool drain.

        • Java is immensely easier to develop with than any flavor of C because of garbage collection and lack of pointers. If you do not understand why then please do not come anywhere near my C code.

          1) Objective-C has garbage collection (though admitedly not on iOS at the moment)

          Sort of an important distinction don't you think given that it's not available on iOS and this thread is about mobile development?

          2) Even without GC, cocoa's reference counting system is about the best there ever has been and makes life *almost* as easy as GC –just gotta watch out for retain cycles.

          Not a little biased are we?

          3) Java very much has pointers – that's why you can get Null pointer exceptions ;)

          Now here you go just spreading FUD. Java does NOT have pointers. None. Absolutely none. Despite the inappropriately named NullPointerException, pointers do NOT exist in Java. Java has references. References are != Pointers. Pointers "point" to a memory location. References "reference" an object. These are very different concepts and I don't care to writ

          • Re: (Score:1)

            by Anonymous Coward

            Now here you go just spreading FUD. Java does NOT have pointers. None. Absolutely none. Despite the inappropriately named NullPointerException, pointers do NOT exist in Java. Java has references. References are != Pointers.

            References are pointers without an explicit need to dereference them. Every reference is internally a pointer.

            Pointers "point" to a memory location. References "reference" an object.

            Internally they are identical. Both contain a natural word-sized number that references a memory location.

            These are very different concepts and I don't care to write a tutorial on the subject here on /.

            I'll take the time to write a tutorial. Pointers and references are internally identical. References as a language construct do not permit address arithmetic, while C pointers do. References are not immutable, they can be reassigned.

            Suffice it to say that pointers provide a mechanism for code to corrupt (whether intentionality or not) memory while references (being immutable) preclude this.

            I don't think immutable means what you think it does.

            • You are soooo wrong on nearly every point.

              References are NOT internally pointers. Just run a java app in a debugger and step through the code. Look at each reference created. The first reference created will have a reference id of something like 16, the second will be 17, and so on. These are simply "references" used to lookup the object, not address locations in memory. In C you can take a pointer and add 1 to it to address the next byte in memory, but you cannot do this with a reference. That's a VERY bi

      • Re:Objective-C is easy - frameworks take time (Score:4, Interesting)

        by pslam ( 97660 ) on Wednesday March 23, 2011 @02:16PM (#35590474) Homepage Journal

        Java is immensely easier to develop with than any flavor of C because of garbage collection and lack of pointers. If you do not understand why then please do not come anywhere near my C code.

        Funny, I find any flavor of C immensely easier to develop responsive applications due to pointers and the lack of garbage collection. I get the impression I don't want to see your C code.

        • Comment removed based on user account deletion
          • Bullshit - it's the same order of magnitude, if not faster. And doesn't attempt to load and JIT a metric shitload of libs on runtime initalization.

        • You would have a hard time making the difference between my java apps and a native one. The secret is to use the native platform look, release resource early (some java programmer are totally ignorant about this since the jvm close everything for you on exit), lazy load your ressource, use expiring ressources cache and optionally to gain 5 to 10 % (startup or running but not both) performance attends to one oracle formation on the JVM garbage collector tuning.

          The sad thing about java is that it enable a

          • The sad thing about java is that it enable a lots of morons to write applications

            It's even sadder when you realize the next generation of programmers think Objective-C is the best language around because Apple says so.

            • I don't know anyone who says Objective-C is the best language around. But I know plenty who consider Cocoa to be the best app API around. Different languages are not a big deal. They are quick to pick up. Becoming proficient in a platform's APIs is a much more significant consideration.

        • Java is immensely easier to develop with than any flavor of C because of garbage collection and lack of pointers. If you do not understand why then please do not come anywhere near my C code.

          Funny, I find any flavor of C immensely easier to develop responsive applications due to pointers and the lack of garbage collection. I get the impression I don't want to see your C code.

          Maybe you should consider getting into the habit of reading past the first sentence of a post. For your convenience and reading pleasure, here it is:

          That said, I personally prefer to put in the extra work and develop in C++ because the result usually starts faster and performs better.

          And you are not welcome to come near my C code either because an effective developer must not only possess the requisite skills and understanding, but be socially functional as well.

      • Re: (Score:1)

        by Desler ( 1608317 )

        Java is immensely easier to develop with than any flavor of C because of garbage collection and lack of pointers.

        What exactly is so hard about pointers? Unless you're a mouth breather pointers are quite easy to learn. Also Java DOES have pointers that's why there is even an exception [oracle.com] for when they are NULL.

        • Also Java DOES have pointers that's why there is even an exception [oracle.com] for when they are NULL.

          Actually, to be precise, Java does NOT have pointers (despite the mis-named NPE). It has references. References are NOT the same thing as pointers. While they serve a somewhat similar purpose, they are very different in implementation. I won't go into a long discussion of this on /., but the fact that you are equating the two is misleading and needs to be flagged.

          Also, statements like "What exactly is so hard about pointers?" is just geek bravado. I'm a long time hired gun and I can't count the number of t

          • Re: (Score:1)

            by Desler ( 1608317 )

            Also, statements like "What exactly is so hard about pointers?" is just geek bravado. I'm a long time hired gun and I can't count the number of times I've had to come into a C or C++ project because the team of programmers working on it could not resolve the reliability issues which were primarily due to pointer problems or memory leaks. While there are definitely performance considerations in Java (and a wise man knows that nothing in life is free), Java offers productivity gains over C (and even Obj-C IMHO) while still maintaining reasonable performance. This combination is unmatched by other language platforms at the current time (although I'd say C# runs a close second - again IMHO).

            Yeah, how dare someone actually learn about how the internals of hardware works and how their code actually runs!! Such bravado!! Oh wait, that's just common knowledge that pretty much EVERY programmer should know. Secondly, I can quite trivially point you to a famous Java program, Minecraft, that has dozens up dozens of posts on the Minecraft forums about nullpointerexceptions [google.com] and memory leaks [google.com]. Yeah, Java may have been "more productive" (a completely subjective term because I know numerous people who ar

            • It's not about "about how the internals of hardware works and how their code actually runs!!". Most of my customers don't give a damn whether I can look at a hex dump of some machine code and recite the mnemonic instructions they represent from memory, they just want the code to work, and work reliably.

              Just because I can write assembly code that would kick your C-code's ass in terms of performance (and believe me, I can) doesn't mean my customers who are paying me by the hour want me to take the time to wri

              • Re: (Score:1)

                by Desler ( 1608317 )

                Your references to Minecraft mean nothing.

                Actually it means quite a bit in counter to your:

                I can't count the number of times I've had to come into a C or C++ project because the team of programmers working on it could not resolve the reliability issues which were primarily due to pointer problems or memory leaks.

                because you were attempting to try to paint a picture where Java programs don't have those problems yet it's trivially easy to find Java programs with memory leaks and throwing nullpointerexceptions. And it all has to do with shitty mouth breathers who learn Java but know jack and shit about how to write software because all those things like pointers are "too hard".

                • No, I was pointing out that having to manage memory manually can easily lead to less reliable software. Having the runtime manage memory allocation/deallocation, while not completely eliminating the need to worry about memory over consumption entirely, leads to more reliable software and increases productivity. You can disagree all you want, but almost all modern languages today incorporate automatic memory management. Objective-C is now incorporating it, .Net languages have always had it. Even most C/C++ c

              • Re: (Score:1)

                by Desler ( 1608317 )

                I can point out plenty of C/C++ programs that have plenty of problems as well.

                Great, but neither I nor anyone else tries to claim that C and C++ programs are immune to those problems. Java weenies on the other hand are constantly telling us how Java eliminates memory management issues, null pointers, etc and yet numerous high profile Java programs suffer from all those issues.

                Bad programmers are a bad programmers regardless of the language they are using.

                Yes, which is why we shouldn't be ENCOURAGING more bad programmers by allowing them to get away with not actually learning enough to do their craft correctly.

                You're references to Java programmers as "mouth breathers" is pure ignorance.

                Nope.

      • Java is immensely easier to develop with than any flavor of C because of garbage collection and lack of pointers. If you do not understand why then please do not come anywhere near my C code.

        That said, I personally prefer to put in the extra work and develop in C++ because the result usually starts faster and performs better. And I absolutely detest JNI.

        Since you seem to think that garbage collection is magical and never causes problems, I assume that you have never worked with file handles or network sockets.

        You should NEVER rely on garbage collection to deal with resources such as files and network sockets. Both should always be closed explicitly when they are no longer needed. I would hate to see your code.

        • I assume that you have never worked with file handles or network sockets.

          Heh, good one.

      • Well, Android's framework makes leaks trivially easy. Read the developer blogs and the various other tidbits they provide. They are full of donts to prevent leaks left and right. Hmmm...was suppose to be a feature of Java and a major one-up over C++ and other languages. Not with Android...

        As an android developer who didn't originally have much background in Java (years ago), I can tell you I pine for C++ or python. Java tries to be a better C++ but fails. Its like the libraries were created by purists who h

        • I actually wonder why someone doesn't wrap Android Java-only APIs via JNI and exposes them as well-written, idiomatic C++ (like you said - exceptions, templates where convenient, etc).

          • I guess I didn't communicate it clearly. Android now exposes its API via C++. With the latest release of the NDK, you can now create applications completely in C++. Even better it includes template support, exceptions, and RTTI and they even include a port of STLport.

            If you are comfortable with C++ development, I encourage developers to move directly to C++ rather than bother with Java/Dalvik. The result is frequently smaller and considerably faster. The major down side to doing this is its not multiplatfor

    • 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.

      • Re: (Score:2)

        by s73v3r ( 963317 )

        I like the mulit-part method names in Objective-C. They tell me what I'm passing in, as opposed to just knowing the type that I'm passing in. And I don't have to declare infinity billion structs to do it your way.

      • Re: (Score:2)

        by torako ( 532270 )
        You don't have to use names for your parameters if you're writing your own classes. [myClassObject method:foo :bar :baz :foobarbaz] can be used if you declare the method that way. Also, runMethod:foo in your example is a bit misleading, because it doesn't mean "run a method called foo", but actually "run a method called runMethod:withParam:andHeresAnotherParm:ohWaitOneMore with parameters foo,bar,baz,foobarbaz]".

        Of course, you can't get around the long names if you want to use any pre-existing frameworks.

      • Seriously, what's the point of:

        foobar = [myClassObject runMethod:foo withParam:bar andHeresAnotherParam:baz ohWaitOneMore:foobarbaz];

        It's simple (hell, the IDE will autocomplete it for you) and makes your code easier to maintain.

        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.

        That doesn't help you at all when you have to call a method (that you didn't write)

  • Money saver (Score:2, Interesting)

    by Anonymous Coward

    If you don't think you'll need this book for over 2 months, you may want to get a subscription [packtpub.com] to access *all* books Packt has published. As a side benefit, there's a couple hundred other books you get access to too.

  • 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.

    • No, I skimmed and saw Packt and didn't read anything else. They've been using their shills to advertise their books here for a long time now.

      • Re: (Score:2)

        by gknoy ( 899301 )

        How can I, as an average reader, distinguish between a shill and a legitemate reviewer? I see that the author of this review has a blog on which he's reviewed two (maybe more?) of the Packt books, but it's possible that that's because he is active in the field and found genuine value in the book.

        I'm still more likely to buy the Pragmatic one, but this I felt was a good review: it focused on what was in the book: cookbook style, mainly focused on UI (rather than the SDK), etc. These are all very valuable thi

        • The review is a shill if there's a great deal of info on the contents of the book, but nothing on the quality of those contents. Did the reviewer actually follow any of the instructions? Do the programs work or have bugs? Does the book make the issues clearer or more confusing? And when it comes time to build a real solution to a complex problem, how well did the book prepare you?

        • If it gets the salient points that you're interested in across, then it sounds like it doesn't matter (for you) whether it was a shill posting or not. When I read these, the basic facts are definitely useful - but I'm also looking for an honest evaluation of the book's content. In this case (and in the case of all Packt reviews I've seen here in the last 1-2 years) we are given details about the content of the book; but told very little about the quality of that content.

  • 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?

    • You can (Score:5, Informative)

      by SuperKendall ( 25149 ) on Wednesday March 23, 2011 @03:04PM (#35591164)

      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#.

    • Re: (Score:1)

      by Desler ( 1608317 )

      Why can't I use native C or C++ on either of them?

      You can use native C for iPhone development. Objective-C is a strict superset of C.

    • Re: (Score:2)

      by s73v3r ( 963317 )

      You can use native C/C++ for both of them, except in certain places. The UI layer, for instance, has to be done using the native language on either platform (objc or java).

    • Or Python or Perl on Android

      There's a nice 20% project called Android-Scripting that lets you use scripting languages through an interpreter. Not exactly fast and lacks some features, but it makes it easy to get started with basic Android development in a language you're more familiar with.

      https://code.google.com/p/android-scripting/ [google.com]

    • 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?

      You can on some phones, like Nokia's N900, Symbian phones. And Windows Mobile smartphones, I think.

      On the N900, you even get a standard *nix environment, with libc and shell and X and a package manager that lets you install pretty much whatever you want.

    • Jython runs on the Andriod. This means you can use that to run python code. Cool hack.

      I wonder if you could use the Andriod apis? I can't see why not.

  • who noticed that table column values are messed up
  • The author's blog [wordpress.com] is a good chance to check out his writing, coverage of the kinds of development he's done, and depth of technical expertise. It's also worth mentioning that he is the designer of the EodSQL [java.net] open-source (LGPL) O/R bridge for Java.

    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...

  • 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.

Slashdot Top Deals

"Your stupidity, Allen, is simply not up to par." -- Dave Mack (mack@inco.UUCP) "Yours is." -- Allen Gwinn (allen@sulaco.sigma.com), in alt.flame

Close