Google's Android Cellphone SDK Released
AchiIIe writes "The android SDK has been released to the wild. As expected it features the Linux Kernel, low level libraries such as FreeType, OpenGL, SQL Lite, WebKit (as a web browser), a custom Java Bytecode interpreter that is highly specialized for the CPU. A common java API is provided. A video has been posted with an the overview of the API." SM: Several readers have also written to mention the Android Developer Challenge offering $10 million in prizes for cool mobile apps.
The most common question I've heard is "What hardware is the Android platform running on?" Nobody outside of Google and possibly the Open Handset Alliance members has run it on hardware yet. If you're interested in trying to hack it, there is a board of people trying to get it on some phones: http://www.ohadev.com/forum/viewtopic.php?t=15 ------------ Cheers, Brian Jordan http://ohadev.com/ - Android SDK code samples, tutorials, discussion
What would be needed would be a developer's model for these phones,
and the correct transfer hardware and developer's kit from a NON-OHA
phone.
Ironically, that makes this really hard, because the old-school (non-
Android) handsets make it very hard to independently develop with.
We have a forum thread discussing this possibility:
http://www.ohadev.com/forum/viewtopic.php?p=23
Cheers,
Brian Jordan
http://ohadev.com/ - Android SDK discussion, code samples, tutorials,
application submission
Shouldn't this point to the official repository at http://code.google.com/android/ instead of http://code.google.com/p/android, which just looks like some ad-hoc mirror?
Real slow phones.
No. Most of the phones on the market today use Java for graphics and applications, including pretty much all of the popular cell phones in Japan that make any phones in the Western world look childish by comparison. The problem is that there is an impression among standard Windows developers that Java is necessarily slow, which is absolutely not true. Sure, the early PC JVMs, the Swing toolkit and the applet model were resource-hungry abominations, but Java on cellphones is lean, mean, and it's already pretty much everywhere.
I just downloaded the SDK, so will hopefully have some time to play around with it. It looks potentially very interesting, but here are a few quick thoughts:
.. it's on the side so it doesn't get in the way, but it's there if you want it).
.. it will be interesting to see how it compares. I really like Cocoa. It's really a great language/libraries for developing windowed systems. Interface Builder is the only GUI builder I think makes sense. I hate code generation, and I hate the weird quirks that come with many others (QT, Visual Studios, WxWidgets, GLADE++). IB just works.
(1) It's Java. Sometimes Java is the right tool for the job. Unfortunately, I've never been a big fan of the Java libraries. They always seemed overly complex and verbose to do simple things. I say this comparing it to both the STL/Boost for C++ and Cocoa. Granted, both of those libraries have their issues.
(2) It's eclipse-centric. It looks like they want you to use Eclipse. I'm sure you can do fine without using Eclipse. I'm not sure how dependent it is on creating interfaces etc. So you might do best to ignore this point. Eclipse does some things really well -- taking advantage of being a Java-based editor, it can use RTTI to help in the code-writing process.
That said, I would be very happy if I never had to use Eclipse again. The interface itself is extremely non-intuitive, gets in the way, and caused a great deal of swearing to occur. Nowadays I use either Emacs, Textmate, or XCode. XCode isn't perfect but it does a really good job of not getting in your way, and occasionally actually helping out (like the reference panel that automatically calls up info on the function your cursor is over
(3) Code layout. I'm not sure how much of it being a Java thing, or how much it is google, but the fact that I need to go 3-4 directories in just to get to the source code is very frustrating. I'm pretty sure there's better ways to do that.
(4) I have an iPhone. I'm waiting for the iPhone SDK to be released
(5) It appears to come with an emulator, which is very cool! That is a major win for fast development times.
Give all my complaints, I'm probably going to try writing an app or two for it ASAP. Code should be fun to write, which will be my major test for how good/bad the platform is. I also wonder how configurable it is. Did they come up with good conventions? If not, can you override them, or will all apps suffer the same?
Yep - you have to pay a "license fee" of 10% of the potential prize to the government as a "permit" - even if nobody wins.
Of course, the simple way around that is to submit it via the web, naming a relative in another province/state.
Kevin Smith on Prince
I belive that should be SQLite (www.SQLite.org)
http://www.intellipool.se/ - Intellipool Network Monitor
If you can be a billionaire wearing shirts that you slept in I don't even know why I even bother wearing a collar at all :).
Other way 'round. Sergey can wear whatever shirt he wants because he is a billionaire (also note his hair looks as if it has just been slept in as well in that video). You, on the other hand, not being a billionaire, must wear the shirt that The Man tells you to wear.
-jimbo
XML Tools for Mac OS X
SDL is included in the android emulator source that I'm looking at.
more of the same on Twitter.
Let me think about that for a sec...
.NET ES.
.NET ES is a bytecode interpreter platform for VB, C#, J#, etc.
:)
.NET and Java are pretty mixed when it comes to real world performance and memory usage. In a tiny app I wrote as an experiment in C#, I found .NET about 10% faster and 20% less memory efficient than the Java app it was based on. I've read .NET apps outperform java memory-wise in some real world conditions, as well as .NET having a problem with hitting memory bounds (and running very slow or crashing) much faster than java so as we say in the industry, YMWV. Both are generally about 10%-30% slower than C/C++, and both require memory tweaking by the programmer at times. For most mobile uses, this will be a non-issue - either is fast enough, and most apps won't put too much stress on available memory.
Windows Mobile is essentially Windows CE +
ergo, by postulate "Java means Real slow phones,"
Windows Mobile also means real slow phones.
Anyone have a problem with that?
Seriously, both
I have a feeling that you are looking at programming in completely separate way from the GP. JVM managed garbage collection has proven useful as it can schedule memory management at appropriate times as opposed to freeing/allocating memory at every stack pop (depending on where it was allocated). I know how you feel, and I was completely anti-Java up until I had to use it for work, and there are some things that make me fight Java (Lack of operator overloading, and multiple inheritance), but they aren't core issues, and it is more an issue of style.
If you don't have an OOP related problem, don't do it, but apart from goto, you can do some pretty straight forward procedural programming in Java. It's not optimized for that, but its completely doable (I've seen some legacy code, its not pretty).
You can write your own libraries in C, and expose them to Java, nothing stopping you there. If you are afraid that it won't run at the same efficiency/performance on others machines, compile it using gjc and distribute it as an executable, and negate many of the performance issues. Use all the libraries you want, do it your way, but don't look at Java and say bad for standardizing. I know that I am able to write code that is bug free and works the way I expect it, on every JVM (for the most part), as opposed to getting 100 different versions of String. Standardization has some costs, and its normally with letting the little things go and focusing on the real problems like building software, and not optimizing my string concatenation code for a specific processor.
And Reflection. If you fear reflection as a viable means of programming, I fear you live in a different world than most. Many times reflection is abused by the lazy, but somethings are just not doable without reflection, or tedious hardcoding/code generation. Java's reflection has seen tremendous speed improvements in recent versions to the point where it is almost the same speed as native commands. I mean, even taking a second to think about certain design patterns, e.g. Aspect Oriented Programming, and its clear that certain things are much more elegant and understandable with reflection. I don't know how it is a design mistake, but you might as well say the same thing for recursions while your at it.
Another point is the fact that the JVM has the ability to dynamically optimize code execution and find pieces of code that are being run more than others, and perform more specific optimizations to increase speed of execution. Java is not as fast as C, but it is getting closer to C++ and the benefits of a standardized, feature-rich environment is amazing when working with complex systems.
I'm not saying your points are wrong in a given context, but for the bulk of software I've seen developed, it seems that Java can fit the bill quite nicely.
je suis parce que j'aime
Part 1 of 3: http://youtube.com/watch?v=Mm6Ju0xhUW8
Part 2 of 3: http://www.youtube.com/watch?v=ITfRuRkf2TM
Part 3 of 3: http://www.youtube.com/watch?v=iiD4fGjjXcc