Linked by Thom Holwerda on Fri 16th Nov 2007 19:38 UTC, submitted by anonymous
Google "This in-depth, hands-on article introduces Android, Google's Linux/Java mobile phone SDK. After a tour of Android's tools, documentation, and code samples, it suggests a path for further exploration and concludes with a simple applet showing the power and simplicity of the Android environment."
Order by: Score:
Simple?
by FunkyELF on Fri 16th Nov 2007 20:33 UTC
FunkyELF
Member since:
2006-07-26

power and simplicity of the Android environment
I watched a video of some guy creating a hello world application.
Maybe its because I have never created an Enterprise Java application but it seems to overcomplicate things.

For every java file you have 5 xml files and the Java code is full of words with at least 3 of the following words...default, factory, abstract, delegate, manager, provider.

I can't watch youtube at work so my memory may be off but I remember being really turned off by the amount of work needed to get something running on there.

Aren't phones turning into little computers now? Why can't it be as easy to create a java phone application as it is to create the same application on a computer?

Reply Score: 10

RE: Simple?
by Sodki on Fri 16th Nov 2007 20:50 UTC in reply to "Simple?"
Sodki Member since:
2005-11-10

For every java file you have 5 xml files and the Java code is full of words with at least 3 of the following words...default, factory, abstract, delegate, manager, provider.
[...]
Aren't phones turning into little computers now? Why can't it be as easy to create a java phone application as it is to create the same application on a computer?


It's just as easy. The problem lies with the ideologies surrounding Java and Java clones, like C#. Anyone who has ever programmed in Java and dwelled in current programming practices knows that there is a tendency to overcomplicate things in this overengineered language.

Java was the worst thing that happened in computer programming in the last two decades. Apart from C++. :-)

Reply Score: 4

RE[2]: Simple?
by HangLoose on Sat 17th Nov 2007 13:19 UTC in reply to "RE: Simple?"
HangLoose Member since:
2007-09-03

Do I sense a VB programmer around here ?

Reply Score: 4

RE: Simple?
by Beta on Fri 16th Nov 2007 21:25 UTC in reply to "Simple?"
Beta Member since:
2005-07-06

Not quite 5 XML filesÖ

He edited one file for GUI layout. Another would be the app manifest, thatís autogenerated by Eclipse, he only needed to edit it to request app permissions.

Java isnít the most terse language, but itís not that mad :^)

Reply Score: 3

RE: Simple?
by butters on Fri 16th Nov 2007 21:25 UTC in reply to "Simple?"
butters Member since:
2005-07-08

I think I saw the same video. He wrote an application that displays the user's contacts as a list and calls the selected contact. It was maybe 15 lines of Java and 3 modified lines of XML starting from the default project skeleton. As application development goes, that's pretty concise.

You seem like a systems programmer or sysadmin, and you probably have no perspective on what it's like to be an application developer. I'm the same way. But that doesn't mean I want to develop applications in C instead of Java, it just means I don't want to do application development, period.

Reply Score: 6

RE: Simple?
by ahmetaa on Sat 17th Nov 2007 00:12 UTC in reply to "Simple?"
ahmetaa Member since:
2005-07-06

those xml files, were android specific, not java related. they use one for declarative GUI , othr for manifest (for security settings etc.). if you ever seen telephone software, you would understand doing that example in that amount of time and code is actually pretty damn good.

Reply Score: 3

java
by serlex on Fri 16th Nov 2007 22:08 UTC
serlex
Member since:
2007-01-09

oh thats why we been learning java for last 2 years at university, now i get it... </sarcasm>

Edited 2007-11-16 22:08

Reply Score: 0

On screen keyboard.
by Timmmm on Fri 16th Nov 2007 22:53 UTC
Timmmm
Member since:
2006-07-25

I've played around with Android a bit, and have noticed a few things:

Firstly there's no on screen keyboard. Anyone who's used an iPhone or iPod Touch will agree that this approach is superior to the Blackberry's tiny tiny keyboard. As this is the internet, and some people will no doubt disagree with my awesome opinion, I'd better say: 1) The screen and keyboard no longer compete for space, but share it. 2) It looks much better. 3) It really does work well. 4) It can be context-sensitive (e.g. the '.com' button). 5) It can rotate with the device to give a landscape mode.

In its current form it can't really compete with the iPhone interface as it depends on physical buttons too much. For example there is no way to scroll the favourites bar just using the touch screen.

Finally, you can't code with C++! :-( Java's ok I guess, but I must start a language war. :-)

1. Java *is* slow. Get over it.
2. I recently read a book ('Java for C/C++ Programmers') about Java written in 1996. They were praising its simplicity and the fact that it left out complex unneccessary features from C++ like templates, enums, and assertions. Guess what's been added to Java since then?
3. Who want's to write 'if ("this".equals(that)) {...'? When it comes down to it, no one really abuses operator overloading.
4. Maybe it's just me that encapsulates memory operations, but I never had any problems with memory leaks or segfaults (which Java doesn't avoid - it still has null pointers).
5. It's lack of type safety means you have to use exceptions everywhere. *And* they even say in the Java docs that it is better to be able to do type checking at compilation.

Personally I think D is the best approach to modernising C++. Java does have portability (probably the reason Android uses it) and libraries in its favour though.

Reply Score: 2

RE: On screen keyboard.
by thavith_osn on Sat 17th Nov 2007 00:00 UTC in reply to "On screen keyboard."
thavith_osn Member since:
2005-07-11

Onscreen keyboards rock, I agree. I bought an iJam a few years ago and loved it (until I lost it). I can't go back to a "real" keyboard, but that is just me, I know a lot of people who hate the onscreen keyboards. I guess one of the clear advantages onscreen has it that it can change depending on your language settings, current application etc... One of the disadvantages is tactile response...

Java *is not* slow. I thought it was too, but have since discovered that in a lot of areas, Java is as fast as compiled languages, or if not as fast, pretty close. The thing is, you should never get a book from 1996 to learn Java with (don't worry, I know you didn't, but others do), it's has changed just a tad since then. Check out NIO for instance. You can get legacy filesystem/network code running many many times faster with very little effort too. Regex stuff is very very fast.

I think some of your arguments are really just your opinion (and fair enough). For instance, the lack of type checking can be seen in as a good thing, especially in respect to late binding. Exceptions are sweet as I can make sure my fellow work mates write code to handle events that could otherwise bring an app down.

Java, like every other language is really good at some things and not so good at others, we don't need a language war, we just need to be professional enough to know what tools we have and when to use them... I use C for driver dev, Java for scalable servers...

Personally on Android SDK, I think Java will be just fine for most things.

I hope the SDK officially supports Netbeans, maybe it does, I should check again...

Reply Score: 3

RE: On screen keyboard.
by ahmetaa on Sat 17th Nov 2007 00:06 UTC in reply to "On screen keyboard."
ahmetaa Member since:
2005-07-06

For your list,

1- Java can be slow. Possibly initial versions of android, it will be slow. Because the underlying virtual machine is interpreted. But i doubt users will feel it, most intensive operations (video-sound) are native. For desktop-server, current virtual machines (sun HotSpot, BEA JRockit) can easily compete with C++.

2- Java does not use templates. Generics is a different concept. Java's enums are very different then C++ enums, they are strongly typed and real classes. Java is still simple comparing with C or C# on that aspect. (no operator overloading, pointers, In/out params etc.)

3- equals is just fine. == is used for reference comparison, equals()compares semantic equality. another sybol could be used, but i don't think it makes a big difference.

4- first, i have never seen a medium-large C-C++ project without a memory leak. And real problem is not the leak itself, it is the complexity and overhead memory management brings during development. After working in C++, i am so glad Java does not allow any explicit memory management. Java's null pointer exception is actually a null reference exception.

5- You are so wrong on this. Java is a strongly typed language. there is type safety. it was an issue for collections, but After Java5, thanks to generics collections had compile time type safety. it uses type erasure, but it is not a big deal IMHO. it alows crating a much simpler virtual machine.

When was the last time you used java seriously anyway? All said, java has it's issues. Because it was pioneer in many things, in the API they did not get some things right (such as f*ed up Date/Calendar api or incorrect use of checked exceptions ). But You should understand the choice of Java for Google makes sense. it has the best IDES available in all platforms (Eclipse, Intellij IDEA, Netbeans) , excellent tool and library support and there are literally millions of developers around.

Reply Score: 4

No C++, Java....
by luzr on Sat 17th Nov 2007 09:27 UTC in reply to "RE: On screen keyboard."
luzr Member since:
2005-11-20

You should understand the choice of Java for Google makes sense. it has the best IDES available in all platforms (Eclipse, Intellij IDEA, Netbeans)

Yes, having Java is perhaps a good idea.

Anyway, I am not so convinced that having ONLY Java is as good idea. Abstracting from language flamewars, this will reduce Android usability quite seriously.

E.g. what if I do not like SQLite and would like to port some other DB (e.g. PGSQL, MySQL)? Do you supose rewrite in Java? Same goes for a lot of stuff, written in C/C++...

With Linux behind (written in C ;) , I would expect open environment...

Reply Score: 2

RE: No C++, Java....
by sanctus on Sat 17th Nov 2007 16:49 UTC in reply to "No C++, Java...."
sanctus Member since:
2005-08-31

Is it possible to use jython with this?

It could be a nice thing to have.

Reply Score: 1

RE[2]: No C++, Java....
by ahmetaa on Sat 17th Nov 2007 18:44 UTC in reply to "RE: No C++, Java...."
ahmetaa Member since:
2005-07-06

performance overhead would be too much imho. generated byte code is prety lame for JRuby and Jython. also the call of the api would be awkward.

Reply Score: 1

RE[3]: No C++, Java....
by Kokopelli on Sat 17th Nov 2007 20:42 UTC in reply to "RE[2]: No C++, Java...."
Kokopelli Member since:
2005-07-06

performance overhead would be too much imho. generated byte code is prety lame for JRuby and Jython. also the call of the api would be awkward.


I am not sure I follow what you are saying here. I do not use Jython but the current release of JRuby has performance parity with MRI by and large. It is better in some things worse in others (especially start up time) but for long running apps it is quite good in my experience.

The question in my mind becomes whether the Dalvik VM can handle the JIT compilation needed for a scripting language to work and if it does what is the performance like. I honestly would not expect it to work too well (if at all) but it is still early.

Reply Score: 1

RE[4]: No C++, Java....
by ahmetaa on Sat 17th Nov 2007 21:24 UTC in reply to "RE[3]: No C++, Java...."
ahmetaa Member since:
2005-07-06

i am not comparing JRuby versus Ruby. i am comparing Jruby versus Java. Difference may be 100 folds.

Reply Score: 1

RE[5]: No C++, Java....
by Kokopelli on Sat 17th Nov 2007 23:21 UTC in reply to "RE[4]: No C++, Java...."
Kokopelli Member since:
2005-07-06

Ah, I misunderstood you, fair enough. Though I do not think you would find a 100 folds difference except in poorly coded apps.

Cheers

Reply Score: 1

RE: On screen keyboard.
by bsharitt on Sat 17th Nov 2007 03:31 UTC in reply to "On screen keyboard."
bsharitt Member since:
2005-07-07

I have a Treo, and have used an iPod touch, and I'd take the Treo keyboard any day.

Reply Score: 1

RE: On screen keyboard.
by John Nilsson on Sun 18th Nov 2007 01:51 UTC in reply to "On screen keyboard."
John Nilsson Member since:
2005-07-06

Just skip Java and go directly for Scala it blends perfectly.

Reply Score: 2

RE: On screen keyboard.
by renox on Sun 18th Nov 2007 16:55 UTC in reply to "On screen keyboard."
renox Member since:
2005-07-06

[[Firstly there's no on screen keyboard. Anyone who's used an iPhone or iPod Touch will agree that this approach is superior to the Blackberry's tiny tiny keyboard.]]

I've not used an iPhone, and sure on screen keyboard look better but this doesn't mean that they truly are better: a study found that iPhone users makes more typo, than users with a real keyboard:
http://hardware.slashdot.org/article.pl?sid=07/11/14/157202

As for D vs Java: while I prefer D, I think that one of the reason they chose Java is because of the sandboxing feature which gives additionnal security, D has no such feature..
Of course it can be done in other ways, with virtualisation for example as the OLPC guys did.

Edited 2007-11-18 16:58

Reply Score: 2