Next version of the android coming out soon

Android donut (cupcake was c, donut is d, eclair will be e, and then flan, etc...) has had it's code dropped to the main dev branch of the project. What does that mean?
check out this post from engadget.com:

Early Android 2.0 "Donut" build available, up and running on G1

by Chris Ziegler, posted Jul 26th 2009 at 1:51AM

Android's official code repository has been updated with a fresh load of Donut stuff in the past day or so, and as you might imagine, the dev community is already having a field day with it. Early reports show that all of the features demoed at I/O this year have made it into this cut in one form or another, including universal search, text-to-speech, and system-wide multitouch with gesture support, allowing users to draw symbols on the screen to trigger actions. What's more, though, the codebase is showing signs of CDMA support -- a must for Sprint and Verizon, of course, both of whom will almost certainly have Android sets at one point or another -- and a cool 5-in-1 bank of toggle switches in a home screen widget that can be used to control common features like Bluetooth and WiFi.

Perhaps more excitingly, the community is hard at work on a couple major fronts here: first off, the Donut build is actively being ported to current handsets, and an Android Dev Phone 1 / T-Mobile G1 version is already available (though very, very crashy and incomplete right now). Secondly, work is being conducted to extract major elements of Donut (some of the new widgets, for example) and roll them into cooked 1.5 builds, making the best stuff available in a more solid, accessible form without having to wait for 2.0 to become stable. If you're an adventurous -- nay, borderline mental -- G1 owner, though, you can start your journey to Donut right now.

and from androidCommunity:

Google have released elements of Android OS 2.0 Donut to the developer community, and the changelist is already prompting excitement. Among the differences already noted are multitouch and gesture support, together with CDMA compatibility opening up the possibility of Android devices on US networks like Verizon and Sprint.

There’s also improved universal search, automated backups and what developers are already calling a huge amount of performance tweaking that should hopefully see the platform running more smoothly even on existing hardware. More technical issues have been tweaked, too, with WPA Enterprise encryption support together with VPN functionality.

It seems Google and HTC have been thinking along the same lines, too, as one of the most visible changes is the connectivity bar in the above screenshot, which allows for one-touch homescreen control over WiFi, Bluetooth and other connections. The first hacked ROM suitable for the G1 has already been prepared, though be warned: core aspects such as network connectivity do not work, and this is really a build for early testers rather than those looking for the most functionality from their Android devices. Such users should wait a while, as the frontline devs are promising new versions of OS 1.5 Cupcake with elements taken from 2.0 Donut.

and slashgear:

Has the HTC Hero’s moment in the spotlight been short-lived? Google have released an early development build for Android OS 2.0 Donut, the follow-up to OS 1.5 Cupcake which debuted alongside the HTC Magic, and with it delivered the promise of multitouch support, CMDA and similar homescreen control widgets to those found in HTC Sense.

Among the key changes in OS 2.0 Donut are much improved speed and performance, automated backups and gesture support. There’s also full universal search across all applications, together with WPA Enterprise encryption and VPN support.

While we’re far from an official release for commercial devices, this hasn’t stopped the frontline developer community from playing with Donut and getting it to run on existing handsets. One project has already seen a release, with a build of the new version for the original G1; however this is very unstable and early, with core functionality such as network support missing. Of more interest to general users is the news that developers are working on bringing some of Donut’s more interesting aspects to new builds of Android OS 1.5 Cupcake, adding elements such as mutlitouch and universal search to current smartphones in a more stable form.

What does this all mean?
well, we're gonna have multi-touch ot of the box soon and some other cool stuff!

Pico Post - New Google maps on Android

Google has released a new version of the included maps application. This is available for download through the market - which is kind of odd since it is part of the OS (just think if they told you to update the calculator through the market...)
But anyway, here it is - and finally we have Google transit and walking available for the Android!
What else is new?
Voice search
better support for Latitude
Reviews and more business information


http://www.google.com/mobile/android/maps.html

Pico Post - E3 on G4

Be sure to watch e3 tonight at 7:00 eastern on G4 or check it out online at http://e3.g4tv.com/e32009/pressconferences/index.html
E3 is the Electronic Entertainment Expo and is a must watch for ppl interested in computer gaming and that industry!

Pico Post - an interesting comparison

Hi there, long time no see :)
just a small one (working on a big one on wave)
I'm currently looking for a job in New York, and I stumbled upon this little thingy - check it out:
http://www.indeed.com/salary?q1=android&l1=New+York%2C+NY&q2=iphone&l2=New+York%2C+NY

android in New York, NY $133,000
iphone in New York, NY $96,000

What does this mean? start working on your android skills :)

Some words about my blog...

Hi again!

Time to talk about the Blog
It's been a while since I started this blog and I think it's time to say a little bit about it.
When I started writing it I wasn't really sure what is the direction it will take. I'm hardly an android expert - I have just started out so it's not going to be one of those sites that teach you how to perform tasks in android. In a way, it's the exact opposite of that...

What do I Mean?
Well, as opposed to other blogs that will discuss android development tutorials and teach you what to do if you want to add a button or show a dialog box, this blog will show you what happens when you experiment - what happens when you do things WRONG. The learning of a new platform in my opinion should not be a smooth ride - you need to fall down and scrape you knees a few times so you will learn. Learning from a book or just following the tutorial doesn't give you that bloody feeling that you would get if you were to use an int instead of an integer early on in the development just to find out that you also need a null value for that int (for me it was a Joker card that didnt have an int value). No you have to learn those things the hard way - but as Nathan Hale once said : "I only regret that I have but one life to lose for my country" - you can't make all the mistakes yourself - that's where I come in! :)

How it should work
So it's real simple, remember the post I made about the UI hell I went through trying to show the thrown cards in the right way - well it might not be the most accurate and concise way to explain the mistakes to avoid when wprking with views, but when you start to write something and come across the same issue - you can say oh yeah, I've been here - I can fix this.

How you can help
Tell me about your experiences, share your mistakes with the community - You can learn allot about your mistakes just by writing them down - and you will surely help others.
It doesnt have to be android mistakes, it can be genral software development issues, like I used a '=' sign instead of a '==' sign and nulled out a bunch of stuff, or I used generics in a very wrong way, etc...

Give it a try - it's cathartic, confess your sins!

Pico-Post a great weather widget for cupcake - and it's open source!

Check this guy out
http://jsharkey.org/blog/
He wrote the new weather widget

truly a great and simple application and a great way to learn how to make an android widget - I'm so gonna copy off of him :)

Running the Android API demos on the 1.5 SDK

As you may know, version 1.1 of the sdk came with a bunch of examples in the samples directory.
A huge part of that was the APIdemos project that was not included in 1.5 for some reason.
So if you do want to run it on the new SDK, this is what you have to do:
a) Download and extract the old (1.1) SDK here
b) Import the API project into your eclipse workspace
c) Change the project properties so that the project build target will be the Google APIs
d) Create a new AVD with the Google API target. see here for how-to's
e) Upadte the run configuration so that the target AVD will be the newly created one
f) Optional: you might find that in cameraPreview.java Line 69 you will get an error - an uncaught exception kind of thing. that is because the setPreviewDisplay method now throws an IOException that needs to be handled - just 'try catch' it and you'll be fine
If you need any more help, please comment here and I'll answer any questions you might have.
good luck

Pico-Post #2 - just a thought

You guys remember the game Jones in the fast lane?
http://en.wikipedia.org/wiki/Jones_in_the_Fast_Lane
wouldn't it be cool if it were to come out for android?
Something like:

1st Pico-Post: How to add an SD card to an existing AVD (SDK 1.5 - Cupcake)

Hi, so first things first - what's a pico-post?
well it's basically a cool geeky way of saying a short post - I made it up and hopefully I'll make a few of those every once in a while.
Now for the pico-post itself:
With the shift to SDK v 1.5 the way that the android emulator works has been changed - you can now create several customized AVD's (Android Virtual Devices) that have different properties - this way you can test your app on several types of emulators and simulate different types of display settings etc.
The only problem is that the guys in Android forgot to add an update command to an existing AVD to add an SD card emulation.
This was much easier in the previous version of the API since all you had to do then is create an SD card and then run the emulator with a command line paramater saying - use this card (see here)
But in the new AVD that doesnt work, so we're gonna have to patch it up a bit
so for now here is the guide \ tutorial on how to add an SD card to an existing AVD in android SDK
1- find the path where your avd is stored by running the android list avd command:

$ SDK/tools/android list avd
....
Path: /home/user/.android/avd/myAVD.avd
...

2- create an "sdcard.img" in that directory -- that name is the
default and the emulator will pick it up automatically:

$ SDK/tools/mksdcard 16M /home/user/.android/avd/myAVD.avd/sdcard.img

You can pick any size you want\need for it

Note that "list avd" will not display it after (it only displays what's in the myAVD.avd/config.ini file...) so if you want it to show you can add a line like "sdcard=16M"

That's it.

Thanks to Raphael from the android handset alliance for helping me out on this!

Code clarity

Hi all, a little off topic today, I got this funny mail, you know the ones, you get the same mail in a interval of 6-9 months and it always cracks you up and it got me thinking about code clarity.
So in school, they were on our case for commenting every bit of code we write which made most of writing our code like this:
//An Integer
int i;
// Another Integer (the second one)
int j;
and so on...
Now the reason that was is that at that time most of us have never worked on a really old and big project that has code that was written before they found out about commenting (or the wheel for that matter) and we didn't know what bad undocumented code is.
well, 4 years after college, I can safely say I know.
I won't name any names, but in one of the companies I worked at the code was so convoluted that they had lines of code that were commented out and they would not allow me to remove it because: "if it ain't broken, don't fix it".
Now these days, I document my code like the memento guy tattoos his body - basically work under the assumption that I'm forgetting what I am writing, as I am writing it, so I comment allot, but that's only half of it. The other half is code clarity - and the question arises - should I sacrifice performance for code clarity - should I make the code a little slower to get better readability? The answer of course as always is: "it depends..." it depends on the type of project, the time requirements, and the hardware it's going to run on...
I still can't put my finger on the right border as far as android applications go, but I'm guessing it's an acquired skill and as I progress in this world, I'll figure it out.

By the way, here's the E-mail I got, cracks me up every time I get it:

What is the best comment in source code you have ever encountered?

Spotted on the web:

1.

///

/// Class used to work around Richard being a fucking idiot
///

///
/// The point of this is to work around his poor design so that paging will
/// work on a mobile control. The main problem is the BindCompany() method,
/// which he hoped would be able to do everything. I hope he dies.
///

2.

// I dedicate all this code, all my work, to my wife, Darlene, who will
// have to support me and our three children and the dog once it gets
// released into the public.

3.

// Magic. Do not touch.

4.

return 1; # returns 1

5.

/* This is O(scary), but seems quick enough in practice. */

6.

/*
* You may think you know what the following code does.
* But you dont. Trust me.
* Fiddle with it, and youll spend many a sleepless
* night cursing the moment you thought youd be clever
* enough to "optimize" the code below.
* Now close this file and go play with something else.
*/

7.

//When I wrote this, only God and I understood what I was doing
//Now, God only knows

Overcoming the AbsoluteLayout deprecation, Part Deux

Okay, so I fixed the bottom part as well - it was not fun...
first thing I did was to replace the absolutelayout to linearLayout
Surprisingly there were no compilation errors however when I tried running it, it crashed...

So I went about fixing it, but in order to explain the process I'm gonna have to give a little background, it's gonna be as short as possible, I swear!
The project I'm currently working on is a card game, and in it there is a method for redrawing the player's cards. It does this by going over the logical card objects and checking some properties and drawing them according to it. One of these properties is the "isSelected" status of the PlayingCard object. According to this property, we draw the card - if it is indeed selected - we show it as slightly (10px) above the rest of the cards, else, it is in line with the others.
One final thing to note is that this method is called after every action is done on any cards, and that this method is called and will henceforth be referred to as redrawHand().
The redrawHand() method used to draw the selected cards using absouluteLayout like this:

boolean isSelected = hand.isCardSelected(i);
android.view.ViewGroup.LayoutParams currentParams = cardView[i].getLayoutParams();
cardView[i].setLayoutParams(
   new AbsoluteLayout.LayoutParams
      (currentParams.width,currentParams.height,
         ((AbsoluteLayout.LayoutParams)currentParams).x,
isSelected ? 0 : 10));

basically, I would set the 'y' location (relative to it's container) to 0 or 10 according to the isSelected status.
Unfortunately, this is not possible in other layouts. and that's why the run failed on the first run after the change.
what I did next is try to use some of the properties inherited from LinearLayout to acheive the same result. I tried:

• setting the Layout_gravity of the selected cards to top and the others to bottom
• setting the Gravity of the selected cards to top and the others to bottom
• (Ever wonder what the difference is between Layout_Gravity and Gravity? well, it's simple - Layout_Gravity is the gravity of the view in relation to it's parent and Gravity is the gravity of the contents of the view itself)
• setting the bottom_padding to 10px for the selected cards
• setting the layout_margin_bottom to 10px for the selected cards
• setting the height to 10px bigger for the selected cards
• and other fun stuff...

as you can imagine, none of these worked - most of them did the same thing - when one card is selected, the others appear selected as well - the cards go up as one...
after allot of digging and frustration i figured it out - the container for the cards was in a wrap content mode in layout height and when one of the cards was selected, all the cards filled the content of the parent and in effect went up. now I know this doesn't make a whole lot of sense now, but after a while you get used to these things and they start making sense...
So I managed to get it to work in the layout xml (was able to change the bottom margin for 2 cards and see them up) , but when it came to run-time that was a whole different story: for some strange reason - when I clicked on one of the cards, it did seem selected, but it would be the only one I could select - now this was really weird for a few reasons: a) the method worked with absoluteLayout and b) the behaviour was extremely strange: if I pick card 2 and then card 3, card 2 will pop up but 3 won't, and if I would want to show 3 as selected, i would have to click it again (to unselect it) and then unselect card 2 and then select card 3.
WTF???
after posting yet another question on the group I was told to use the container.requestLayout() method at the end of the redraw method. What this method does is basically invalidate the view so that on the next drawing cycle, it will appear as dirty and will have to be drawn again by the graphics engine. Now this all would make perfect sense if it werent for the fact that I have have been using this method for a whole bunch of other stuff and they worked and the fact that have something that's supposed to do just that - the container.invalidate() method.
Amazingly - this fixed it - I'm still not completly sure how this miracle occured but I'm gonna get to the bottom of it and let you know if there are requests for that.
so now it all works, and you are all encouraged to go the project site and look at the code - should be intersting...
http://code.google.com/p/bestcardgameever-android/
Enjoy!

Overcoming the AbsoluteLayout deprecation, Part I

Hello constant readers :)
As you have probably read in the previous post, I've been having some problems with the new 1.5 SDK, one of which was to get the AbsoluteLayout removed from my project since it has been deprecated...
Now as I showed you before, I have two instances of it in my project - one for the thrown cards (in the middle of the screen) and one for the player hand (bottom of the screen).
The reason that I used the Absolute Layout for the thrown cards was that I needed to show cards that were overlapping. Now even as I was writing it, I thought to myself that using absolute layout would be a bad idea - why? because unlike the Iphone, the android system is not limited to one device and one screen size - at this time, there are NetBooks with 12" screens with a resolution of 1024X768 that can run android as well as more than 10(!!!) new devices scheduled to come out this or next year. So that means you cant count on absolute positioning by pixels because they can change and the game should work on all of them...

Android Netbook

So the mistake came back to bite me in the ass, and I needed to fix it, only question is how???
After making a few inquiries (1,2) it was pretty clear what I had to do - make a custom layout - and once again the question remained how...
I was starting to read up on that but have decided that before I'm going to go head first into a world of unknown pain, I'm gonna play around with the properties of the layouts I know.
Here is the process in pictures:

	My first attempt: I decided I'm going to use a FrameLayout instead of my AbsLay and add left padding for each card, thus creating an overlap... what I got was kinda weird (Isn't it always in UI?) The cards got smaller as the padding got bigger. so I had to scratch that idea...
	Attempt 2: Tried using left margin instead of padding - that didn't work, all that happened was that all the cards were on the same location - you could say that they were overlapping at 100% :) scratch that too...
	Attempt 3: Switched to LinearLayout and gave it some left margins - notice what happened there? the margins made the cards seem further apart instead of overlapping - and when you think about it - it makes sense - so what did i do? see attempt 4 below...
1 - one card on the table	2- several cards on the table
Attempt 4: You guessed it! I used negative values... as you can see - that got me a little closer but not quite there yet... for some reason - the first card had almost no overlapping and it seemed like the overlapping between the last two cards was exactly what i was looking for so I was encouraged and made some more attempts...
	Attempt 5 : here I tried reversing the order of the margins - so the card were now arranged in ascending negative margin order - I got the exact opposite of the previous attempt... wanna guess what I did next? I'll give you a hint - in attempt 4 I used descending negative values between cards and in 5, ascending... guess!
	Attempt 6.1 Perfect, almost... Here I used a constant negative left margin (of 10 pixels) only problem was that I also sized the frame that contains all the cards with the sum of the cards images so it won't shrink the cards on the right and left of it and for it cropped the right of that King card there...
	Attempt 6.2 So I gave it a little extra - what do I mean? The cards were 72px wide each, I have 5 cards and a margin of 10 for each card so it should have been 72+10+10+10+10 = 112 it worked with 130 :) good enough for me :D

so there you have it, success, sorta.

So I managed to do it without creating a new Layout, but next I'm going to have to change the layout for the bottom cards, will I be able to do that without creating a new layout? It's gonna be fun finding out!
Stick around for more, and comment if you like it or if you feel something is missing!
See you soon
Elad Katz

Cupcake

So cupcake is out - also known as version 1.5 of the SDK.
As the early adopter that I am, I immediately went about to upgrading my project.
updating the ADT in eclipse was really quite simple (followed the instructions at http://developer.android.com/sdk/1.5_r1/upgrading.html ), but once the upgrade was complete the problems started...
First thing was that now you have to make you own Emulator (now known as AVD - Android Virtual Device) - that went pretty smoothly, the only thing that kinda bothered me is that the camcorder does not work in the emulator but according to google, it's not supposed to...(http://groups.google.com/group/android-developers/browse_thread/thread/a32a2f351f2fa004/9811bcf7bef9254d#9811bcf7bef9254d)
the second thing i noticed was that the device is a little sluggish but we'll see about that
third thing was that since the new API contains a new Widget for a sliding drawer

i of course tried to put it in my project but failed due to an exception which google is looking into:
http://groups.google.com/group/android-developers/browse_thread/thread/c579d40ff8bca172/58d4fcef1762259a#58d4fcef1762259a

next thing i noticed is that absoluteLayout is now deprecated :(
i knew it was a bad idea to use it the second i used it...
The reason i needed it was this:
notice the cards on the middle that are overlapping?
see the bottom cards that have some sticking up?
i'm gonna have to figure out a new way to do that without using the absolute layout...
stay tuned here or at http://code.google.com/p/bestcardgameever-android/
it'll show up soon

The Holodeck

Hi
My name is Elad Katz
I'm a software developer of 4 years and an avid blog reader.
I currently reside in New York, New York - a city so nice, they named it twice :)
I've recently decided to develop some apps for the new android operating system and thought I might share my experiences with the blogosphere.
Why Android?
Well, I'm a really big fan of everything Google, and when the G1 came out I pitched a tent outside of the T-mobile store and bought it.
I'm very very happy about it.
Why not Iphone?
Good question!
The short answer is that i don't have a mac and therefore can not develop apps for it, a slightly longer answer will cover the facts that while android development is a variation of Java\Flex, Iphone development is Object Oriented C, and the fact that the android OS is an open source project and is therefore more alluring to someone like me.
What am i doing?
The project I am working on right now, My first if you don't count the notepad tutorial and the hello world app, is an adaptation of a very addictive and fun card game which is based on a game called Yaniv - I picked up this game while traveling in South America and have become an addict ever since.
It therefore seemed suitable that I develop this game for the android platform.
you can have a look at some snapshots and even check out the code at http://code.google.com/p/bestcardgameever-android/.
What's next?
Well, I think I'll keep this blog updated so that whenever i face a problem and overcome it, I'll post it here.