Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Book Review: Android User Interface Development

samzenpus posted more than 3 years ago | from the read-all-about-it dept.

Android 111

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

cancel ×

111 comments

yappr (0)

Anonymous Coward | more than 3 years ago | (#35589966)

yet another packt publishing review.

No e-book? (2)

wvmarle (1070040) | more than 3 years ago | (#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.

red bull hats wholesale (-1)

Anonymous Coward | more than 3 years ago | (#35590614)

Dear Sir/Madam
Welcome to http://www.jerseys-caps.net, which is a Global Wholesale and Distribution Center for caps/hats.
www.jerseys-caps.net is a wholesale supplier caps/hat,such as New era,DC shoes,NBA,MLB Monster energy caps,Red bull,tapout etc, Whether you want to renew your store, sell goods on eBay or just looking for a bargain for yourself, we will give you best choice. With jerseys-caps.net you can be sure that you will find the best products, Freeshippment, Dropshipping for wholesalers, retailers, ebay sellers, combined order for big lots order, jerseys-caps.net make the effective, safe, professional cooperation with all company and private.
In order to guarantee the safe order, we work with the Five powerful shippment company :EMS, UPS, DHL, FEDEX, CSS. We make the safe payment method for every customers : Paypal,western union,money gram and bank transfer for reliable order. We just want to save your money when you order from china.
E-mail: myyu333@hotmail.com
MsN: myyu333@hotmail.com
website:www.jerseys-caps.net

Re:No e-book? (1)

stg (43177) | more than 3 years ago | (#35590890)

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

Re:No e-book? (1)

wvmarle (1070040) | more than 3 years ago | (#35594750)

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

Safari Books Onlne (1)

terjeber (856226) | more than 2 years ago | (#35596936)

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.

Re:No e-book? (0)

Anonymous Coward | more than 3 years ago | (#35593474)

enter promo code "bawdanu" for 40% off the ebook!

Re:No e-book? (1)

i.r.id10t (595143) | more than 3 years ago | (#35594514)

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:No e-book? (1)

wdef (1050680) | more than 2 years ago | (#35595918)

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.

Re:No e-book? (1)

wvmarle (1070040) | more than 2 years ago | (#35596074)

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.

Does Android have an 'Interface Builder' yet? (-1, Flamebait)

jmcbain (1233044) | more than 3 years ago | (#35589992)

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?

Re:Does Android have an 'Interface Builder' yet? (4, Informative)

Jello B. (950817) | more than 3 years ago | (#35590110)

It's the ADT Plugin for Eclipse [android.com] , jackass. If you'd taken a glance at the Dev Guide [android.com] you wouldn't have had to type out that dumb comment.

Re:Does Android have an 'Interface Builder' yet? (-1)

Anonymous Coward | more than 3 years ago | (#35590220)

Have you tried using the builder compared to IB? Its basically unusable from my experience, and is nowhere near the usability of IB (or even Microsoft's WPF builder).

Re:Does Android have an 'Interface Builder' yet? (1)

$1uck (710826) | more than 3 years ago | (#35590232)

Why respond to an obvious troll?

You've obviously never used iOS Interface Builder (-1, Troll)

jmcbain (1233044) | more than 3 years ago | (#35590586)

The fact that you saying that the ADT Plugin has a tool even remotely close to Apple's Cocoa Interface Builder is shameful. Android has nothing like Interface Builder or Visual Studio's GUI builder. It's like comparing a Camry to Porsche, or Android to iPhone.

Re:You've obviously never used iOS Interface Build (0)

atrus (73476) | more than 3 years ago | (#35591388)

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.

Re:You've obviously never used iOS Interface Build (3, Insightful)

hey! (33014) | more than 3 years ago | (#35591754)

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.

Re:You've obviously never used iOS Interface Build (1)

ustolemyname (1301665) | more than 3 years ago | (#35592286)

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)

Re:You've obviously never used iOS Interface Build (1)

teh kurisu (701097) | more than 2 years ago | (#35596408)

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.

Re:Does Android have an 'Interface Builder' yet? (0)

s73v3r (963317) | more than 3 years ago | (#35591306)

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.

Re:Does Android have an 'Interface Builder' yet? (0)

Anonymous Coward | more than 3 years ago | (#35590118)

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.

Re:Does Android have an 'Interface Builder' yet? (1)

Anonymous Coward | more than 3 years ago | (#35590136)

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.

Re:Does Android have an 'Interface Builder' yet? (2)

psyclone (187154) | more than 3 years ago | (#35590172)

To answer your question, there are a few GUI Builders like this one [droiddraw.org] , 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?

Re:Does Android have an 'Interface Builder' yet? (1)

larry bagina (561269) | more than 3 years ago | (#35590550)

You can use a single nib for iphone and ipad (both horizontal and vertical orientations) if it's the exact same UI. Of course, some people want to take advantage of the larger screen size and iPad-specific UI functionality.

The hypothetical apple TV app isn't touch based, so re-using the exact same iPhone/iPad UI doesn't make much sense.

Re:Does Android have an 'Interface Builder' yet? (3, Informative)

SuperKendall (25149) | more than 3 years ago | (#35591046)

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 [needmoredesigns.com] .

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

Re:Does Android have an 'Interface Builder' yet? (1)

s73v3r (963317) | more than 3 years ago | (#35591342)

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.

Re:Does Android have an 'Interface Builder' yet? (1)

psyclone (187154) | more than 3 years ago | (#35592666)

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.

Re:Does Android have an 'Interface Builder' yet? (1)

shutdown -p now (807394) | more than 3 years ago | (#35595078)

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.

Re:Does Android have an 'Interface Builder' yet? (0)

Anonymous Coward | more than 3 years ago | (#35594156)

Wow, slashdot really needs a -1, Astroturfing moderation option. Does Apple pay you or do you just worship The Steve?

Re:Does Android have an 'Interface Builder' yet? (2)

tehcyder (746570) | more than 2 years ago | (#35596390)

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.

Your first paragraph killed my interest (1)

Anonymous Coward | more than 3 years ago | (#35590046)

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:Your first paragraph killed my interest (1)

sribe (304414) | more than 3 years ago | (#35590142)

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:Your first paragraph killed my interest (1)

moberry (756963) | more than 3 years ago | (#35590436)

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:Your first paragraph killed my interest (1)

Altus (1034) | more than 3 years ago | (#35590528)

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:Your first paragraph killed my interest (1)

atrus (73476) | more than 3 years ago | (#35591418)

Since you decided to quote message passing, you don't actually understand the power that message passing brings to the table.

Re:Your first paragraph killed my interest (2)

JonySuede (1908576) | more than 3 years ago | (#35592422)

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.

Re:Your first paragraph killed my interest (2)

teh kurisu (701097) | more than 2 years ago | (#35596446)

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.

What's wrong with XCode 4? (1)

SuperKendall (25149) | more than 3 years ago | (#35590762)

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:What's wrong with XCode 4? (1)

tk77 (1774336) | more than 3 years ago | (#35591738)

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.

Re:What's wrong with XCode 4? (0)

Anonymous Coward | more than 3 years ago | (#35593582)

It makes many things more complicated, it introduces many bugs, and the single-window GUI makes things much less convenient for how I use it.
This guy [tigsource.com] addresses many points about the GUI, although I disagree on a minor nitpick or two or he missed many of the things that bother me.
 
As to making things more complicated, one example is running a profiler. In XCode 3, running a different profiler than the current one required:

  1. Select sub-menu item for the type of profiling you want.

In XCode4:

  • Select menu item (Edit Scheme)
  • Wait for window to pop up.
  • Select left-hand list item.
  • Select drop-down list item.
  • Click Okay
  • Click or type "run profile" command.

The other option I found is to duplicate the current "scheme" and edit it, which creates two new menu items for each scheme, meaning that just to have a separate scheme for each profiling type you now have a nice long list of 24 items. If you have more than one basic scheme, the list length multiplies; it wouldn't take much to get the menu list to be too tall for the screen. Better still, selecting that scheme doesn't run it -- even after you bothered to create a new scheme, it still takes two clicks versus one in XCode 3. Enabling guard malloc, as an another example, similarly went from one click to three (including waiting for a new window to pop up), or having to create another version of your basic scheme(s).

Now, I'm more focused on working past XCode 4 because the app I've been working on as my main job for two years is finally feature complete and I want to get it out the door, so maybe I'm missing another way for that particular example. Please do correct me. But there are just so many things that now take more time or more clicks or more GUI transitions than they use to. Why doesn't the console stayed scrolled to the bottom so it displays the latest output anymore? Why, when you have "midnight" color selected, does the time profiler now show percentages in black with dark tint around it, so as to be illegible on the black background? (I need a black background to reduce eye fatigue and symptoms of dry eye.)
 
I realize, even without studying it in too much detail, that they're trying to make XCode more powerful, but being more powerful doesn't mean that simple things have to be more complicated, time-consuming, and different both from previous versions of XCode and other IDEs. Much of what I see is simply change for the sake of change, and has nothing to do with improving it. Why, as the link mentions, would you possibly remove "Get Info" completely and replace that system-standard cmd-I functionality with having it be a shortcut to "run profiler"?

Re:What's wrong with XCode 4? (1)

teh kurisu (701097) | more than 2 years ago | (#35596486)

I haven't done a huge amount of work in Xcode 4 yet (just minor changes to a project that started life in Xcode 3), but my initial impression is that this is Apple's way of trying to goad me into buying one of their cinema displays. Or at the very least, a new laptop with a higher-res screen.

Objective-C is easy - frameworks take time (4, Insightful)

EMB Numbers (934125) | more than 3 years ago | (#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.

Re:Objective-C is easy - frameworks take time (1)

Daniel Phillips (238627) | more than 3 years ago | (#35590326)

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.

Re:Objective-C is easy - frameworks take time (1)

beelsebob (529313) | more than 3 years ago | (#35590440)

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:Objective-C is easy - frameworks take time (1)

nkh (750837) | more than 3 years ago | (#35591674)

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

Re:Objective-C is easy - frameworks take time (1)

beelsebob (529313) | more than 3 years ago | (#35591970)

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.

Re:Objective-C is easy - frameworks take time (0)

mswhippingboy (754599) | more than 3 years ago | (#35593614)

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 write a tutorial on the subject here on /. Suffice it to say that pointers provide a mechanism for code to corrupt (whether intentionality or not) memory while references (being immutable) preclude this.

Re:Objective-C is easy - frameworks take time (1)

Anonymous Coward | more than 3 years ago | (#35595378)

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.

Re:Objective-C is easy - frameworks take time (1)

mswhippingboy (754599) | more than 2 years ago | (#35599040)

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 big difference. If there was a way to increment the reference id (which there is not - and this is not a language construct issue, it is not possible due to the architecture of the JVM), you would be simply referencing a completely different object, or referencing an object that does not exist which the JVM does not allow. In C, a pointer with an address value of 0 is a null pointer, but in Java a variable set to a null reference does not point to an address of zero, but rather references a special object in the JVM called the null object. Again, a big difference.

References ARE absolutely immutable. You can reassign a variable to a different reference (thereby referencing a different object), but you cannot change the reference itself.

I suggest you learn a little about what you are speaking of before making a fool of yourself.

Re:Objective-C is easy - frameworks take time (3, Interesting)

pslam (97660) | more than 3 years ago | (#35590474)

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.

Re:Objective-C is easy - frameworks take time (1)

Yosho (135835) | more than 3 years ago | (#35590732)

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.

Why do you think pointers and garbage collection have anything to do with how responsive an application is? People have developed perfectly responsive applications in Javascript, of all things, and aside from lacking pointers or garbage collection, it's at least an order of magnitude slower than Java.

Re:Objective-C is easy - frameworks take time (1)

JonySuede (1908576) | more than 3 years ago | (#35592526)

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 lots of morons to write applications but if you know it well this language shines.

Re:Objective-C is easy - frameworks take time (2)

mswhippingboy (754599) | more than 3 years ago | (#35593432)

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.

Re:Objective-C is easy - frameworks take time (1)

BasilBrush (643681) | more than 3 years ago | (#35593904)

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.

Re:Objective-C is easy - frameworks take time (0)

Anonymous Coward | more than 3 years ago | (#35593296)

Funny, I find that CPUs with 4 cores doing over 2 billion operations a second make it immensely easy to develop responsive applications.

I get the feeling I don't want to see either of your code.

Re:Objective-C is easy - frameworks take time (1)

Daniel Phillips (238627) | more than 3 years ago | (#35594710)

You're running my code every day most probably.

Re:Objective-C is easy - frameworks take time (0)

Daniel Phillips (238627) | more than 3 years ago | (#35594670)

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:Objective-C is easy - frameworks take time (1)

Desler (1608317) | more than 3 years ago | (#35591350)

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.

Re:Objective-C is easy - frameworks take time (1)

mswhippingboy (754599) | more than 3 years ago | (#35593414)

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

Programming languages are many, and the way I look at it, they are all part of a continuum from the bare bones assembly languages all the way through to the highest level languages. Each (well, most) have things I like and things I don't and every developer has their own taste. There is no "best" language, but for a particular application, there is usually a best choice (and it doesn't always have to be based on technical merit).

Re:Objective-C is easy - frameworks take time (1)

aristotle-dude (626586) | more than 3 years ago | (#35591604)

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.

Re:Objective-C is easy - frameworks take time (0)

Anonymous Coward | more than 3 years ago | (#35591750)

Or in C# if you deal with anything relating to GDI handles such as Bitmaps, Fonts, Rectangles, etc. It's hard to count how many times I've come across bugs due to people forgetting to release these resources just assuming that the garbage collector takes care of everything. Now in some cases this is due to the fact that some documentation won't explicitly tell you this, but today's "programmers" (really just scripters) seem to overly reliant on some other mechanism cleaning up their shit. Can even a good or great programmer still have issues with null pointers, memory leaks, etc? Sure, but since they actually bothered to LEARN such things as manual memory management and pointers (which really are not THAT hard of subjects despite protestations to the contrary) they have fewer and fewer issues with such. Throw a Java scripter into C or C++ and the amount of bugs related to pointers, memory management, etc are usually astronomically because they never bother to think about such things because the JVM or the .NET runtime has been doing all that for them for so long.

Re:Objective-C is easy - frameworks take time (1)

Daniel Phillips (238627) | more than 3 years ago | (#35594754)

...since they actually bothered to LEARN such things as manual memory management and pointers (which really are not THAT hard of subjects despite protestations to the contrary) they have fewer and fewer issues with such.

But never zero, and the few issues that slip through tend to be doozies. BTW, if you think that memory management is an easy subject then you have not yet scratched the surface of it.

Re:Objective-C is easy - frameworks take time (0)

Anonymous Coward | more than 2 years ago | (#35599358)

But never zero, and the few issues that slip through tend to be doozies.

Because Java programs never have null exceptions or memory leaks? Oh wait...

BTW, if you think that memory management is an easy subject then you have not yet scratched the surface of it.

What is really so hard about it?

Re:Objective-C is easy - frameworks take time (1)

wdef (1050680) | more than 2 years ago | (#35595964)

... today's "programmers" (really just scripters) seem to overly reliant on some other mechanism cleaning up their shit. Can even a good or great programmer still have issues with null pointers, memory leaks, etc? Sure, but since they actually bothered to LEARN such things as manual memory management and pointers (which really are not THAT hard of subjects despite protestations to the contrary) they have fewer and fewer issues with such.

Reasons that everyone should learn C even though the latter always takes thought. I guess unless you'te programming in C all the time you just can't be asleep at the wheel, ever. I taught myself C and Perl and still dabble. I have this sneaking suspicion that these mobile platform thingies just can't be all that hard.

Re:Objective-C is easy - frameworks take time (1)

Daniel Phillips (238627) | more than 3 years ago | (#35594724)

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

Heh, good one.

Re:Objective-C is easy - frameworks take time (1)

GooberToo (74388) | more than 3 years ago | (#35592126)

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 had never actually done anything OO. Everything is painful to use because its never been normalized for how people actually do things. As such, its frequently far more verbose and tedious or on par with C++. Which always raises the question; why am I not doing this in C++ already. And then on the other side, there is something like Python. I've literally written several pages of Java code to do what a half dozen lines of python code is able to do. So Java isn't really as high level as everyone would have us to believe. And the size is largely driven by the fact it was designed by purest who seemingly, didn't have the experience to be writing something like Java. Which means it doesn't really challenge C++ and its far from challenging the likes of Python.

So in a nut shell, there absolutely are very strong reasons why many people were in a hurry to rush to the NDK once it actually supported C++ (exceptions, templates, RTTI; contrary to Google's assertions, they didn't actually support C++ for a long, long time ) and the ability to develop full blown android applications. The lack of Dalvik performance was only part of the rush developers had for the NDK. Of course it didn't help that literally, Google thinks C++ is C with a couple of extra features; which is why C++ on Android was originally so screwed up and crippled.

Long story short, I absolutely agree with you. If you're interested in Android development and do not absolutely love, love, love Java, and feel even moderately comfortable with C++, skip Java/Dalvik completely.

Re:Objective-C is easy - frameworks take time (1)

shutdown -p now (807394) | more than 3 years ago | (#35595146)

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

Re:Objective-C is easy - frameworks take time (1)

GooberToo (74388) | more than 2 years ago | (#35598156)

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 multiplatform and can create the need for large apks and multiple compiles per target down the road. But, for now, its really a no brainer.

Objective-C named parameters are dumb (1)

jmcbain (1233044) | more than 3 years ago | (#35590698)

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:Objective-C named parameters are dumb (0)

Anonymous Coward | more than 3 years ago | (#35590952)

Well, then you are in luck - Objective-C does not have named parameters.

It has infixed multi-part method names, just like Smalltalk.

Re:Objective-C named parameters are dumb (1)

s73v3r (963317) | more than 3 years ago | (#35591412)

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:Objective-C named parameters are dumb (0)

Anonymous Coward | more than 3 years ago | (#35592000)

I agree to a certain point. Objective-C is a kludge designed by a C programmer who wished he could be writing in Smalltalk. It was initially just a simple preprocessor for C, but as sometimes happens, the kludge gets picked up and gains enough popularity that it sticks around.

Having said that, there are certain attributes it brings to the table (the dynamic typing and message passing of Smalltalk combined with the speed of C) that can be advantageous for certain applications.

Where I take issue with Apple is the idea that Obj-C is the only language you should be using which only an idiot (or Apple fanboy) would buy into.

Re:Objective-C named parameters are dumb (1)

torako (532270) | more than 2 years ago | (#35596362)

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

Re:Objective-C named parameters are dumb (1)

teh kurisu (701097) | more than 2 years ago | (#35596568)

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) with the signature doSomething(int, int, double) and the documentation is poor.

Re:Objective-C is easy - frameworks take time (0)

Anonymous Coward | more than 3 years ago | (#35595110)

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.

Possibly your programming or design skills but I doubt it has much bearing on anyone's computer science knowledge.

Money saver (2, Interesting)

Anonymous Coward | more than 3 years ago | (#35590108)

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.

Re:Money saver (0)

Anonymous Coward | more than 3 years ago | (#35590450)

to too

Never do that.

Re:Money saver (1)

tcr (39109) | more than 3 years ago | (#35592354)

FWIW, the title is also available on O'Reilly Safari.

Objective C (0)

Anonymous Coward | more than 3 years ago | (#35590486)

Objective C should take anybody who knows C and understands Java about a day to master. Its extensions are really quite simple and elegant.

Book review summary table screwed up (1)

EMR (13768) | more than 3 years ago | (#35590556)

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.

Re:Book review summary table screwed up (1)

thePowerOfGrayskull (905905) | more than 3 years ago | (#35590602)

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:Book review summary table screwed up (1)

gknoy (899301) | more than 3 years ago | (#35592036)

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 things to know about a book if I'm looking to buy one (I am), because it helps me choose a book based on content, not merely on a 7/10 (or 4/10) review score. I dont' care as much about the review score when I read one here, and more on what sorts of topics it covers and any weaknesses that are identified.

Re:Book review summary table screwed up (1)

Bitmanhome (254112) | more than 3 years ago | (#35592694)

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?

red bull hats (-1)

Anonymous Coward | more than 3 years ago | (#35590706)

http://www.jerseys-caps.net wholesale red bull hats
http://www.jerseys-caps.net wholesale new era hats
http://www.jerseys-caps.net wholesale monster energy hats
http://www.jerseys-caps.net wholesale dc hats
http://www.jerseys-caps.net wholesale nfl jerseys
http://www.jerseys-caps.net wholesale nba jerseys
http://www.jerseys-caps.net wholesale sunglasses

Choices are ObjC and Java? (2)

Ark42 (522144) | more than 3 years ago | (#35590886)

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 (4, Informative)

SuperKendall (25149) | more than 3 years ago | (#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:Choices are ObjC and Java? (1)

Desler (1608317) | more than 3 years ago | (#35591322)

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:Choices are ObjC and Java? (1)

s73v3r (963317) | more than 3 years ago | (#35591432)

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

Re: (0)

Anonymous Coward | more than 3 years ago | (#35592114)

Unless, of course, you install Qt for Android...

Re:Choices are ObjC and Java? (1)

ecliptik (160746) | more than 3 years ago | (#35592150)

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]

Re:Choices are ObjC and Java? (0)

Anonymous Coward | more than 3 years ago | (#35594732)

Java is "not exactly fast" either. And from my experience, Python is far more stable and definitely faster than Java. JIT or no JIT involved.

Re:Choices are ObjC and Java? (1)

inglorion_on_the_net (1965514) | more than 3 years ago | (#35592922)

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.

Re:Choices are ObjC and Java? (1)

Billly Gates (198444) | more than 3 years ago | (#35595190)

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.

not really (0, Flamebait)

toxonix (1793960) | more than 3 years ago | (#35591276)

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?

Am I the only one (1)

ideaz (1981092) | more than 3 years ago | (#35591758)

who noticed that table column values are messed up

Author's Blog (1)

mdm42 (244204) | more than 2 years ago | (#35595996)

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

Re:Author's Blog (0)

Anonymous Coward | more than 2 years ago | (#35596474)

Could you ask your son why he always posts such glowing reviews for Packt publishing books?

Sorry, but his reviews always read like he's trying to convince us to buy rather than giving an honest assessment.

Re:Author's Blog (0)

Anonymous Coward | more than 2 years ago | (#35596894)

His son being the author of the book, not the reviewer I think.

Re:Author's Blog (1)

mdm42 (244204) | more than 2 years ago | (#35597128)

AFAIK Jason's never reviewed any Pakt books (nor any other publishers') so I don't understand your comment. Perhaps you're referring to the author of the review? I was referring to the author of the book.

Honestly, the review does, indeed, smell like astroturf, hence my suggestion... I would far rather have seen an honest, genuine review. So far I'm quite enjoying the book (since I'm also in the process of learning my way around Android), but any review I might write here is going to be suspect, yes?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...