Hacking A Startup DroidRules HackedLabs Posts My Google KnolsThe Android 2.2 Sdk release is probably on Wed morning. But, this sdk release is different.
Not only do we have a quarter where android device sales surpassed iphone(remember I told you it was going to happen in 2010 not 2011), we also have an Android SDK that represents both Google and OHA taking outside suggestions and incorporating that into the SDK. Such improvements as a Dalvik Just-In-time(JIT) unit and being able to store applications on a SD-card.
![Reblog this post [with Zemanta]](https://i0.wp.com/img.zemanta.com/reblog_e.png)
You can see by list of changes at kernel.org that the Android .2. release might be coming shortly. Features that we know thus far:
1. Smaller Linux Kernel part to save ram
2. JIT
3. Improvement of UI widgets.
4. Possible storage of applications on sdcard
5. SDK side, package resources as a library project.
6. SDK side, improved ant support.
7. NDK update
8. Flash support
What the Android IO session this May indicate:
1. Dalvik JIT may be in Android 2.2. or Android 2.3, Dalvik JIT IO session.
2. UI Enhancements may be coming to Android 2.2. UI IO session.
3. Multiple Android versions expected on devices at least util end of year. Targeting Android Versions IO session.
The precedent is to release a new android SDK version during the IO sessions. Last year android 1.5 was rushed out in April with two quick fixes afterwards and thus I think that Android 2.2 will be released right before the IO sessions.
Okay, an Android Road-map. The idea is since I am tracking the changes anyway, make it a dynamic knol that I can update as I track new information. This is not Google supported or supplied an can form time to time suffer from inaccuracy. However, I am gleaning the hints from Google Group threads, etc and so it may have greater accuracy than other reports.
Please do not put an Android product in the Android Market that is defective and than have the gall to put ‘a bait and switch’ job ad on CL to fix the android application as it not only makes you look somewhat stupid but damages any professional sounding PR statement you made stating you can do production ready Android Applications.
There are ways to test an application for defects and there are ways to test an application for user experience that do not involve placing a defective Android Application in the Android Market.
Through my exploration of attempts of an all inclusive ANT build script for Android development I have come to a set of contrary conclusions. These conclusions while they run counter to the status quo do in fact indicate that some Enterprise and Web techniques can be re-used.
In a mobile system we often have to interface with the Mobile Device Application Environment to employ unit testing which strongly indicates that a centralized builder server is not an ideal option. It is not that we could not run unit tests in a desktop JVM, its that code coverage and mock tests we can do with the mobile framework offer more value as we cannot use class loader stuff in running unit tests of a mobile framework within the desktop JVM.
There are DSL java tools that are coming out that make unit testing easier for example Calculon, and the introduction blog post about it. But the android developer still needs to do unit testing on device or emulator.
And I had an event happen this week that caused me to once again focus on this. now, imagine you are a radio station marketing company. You probably only have o n mobile developer that is forced to develop on Blackberry, iPhone, and Android. So lead developer Ascott decides on the Android application to have SDK 1.5 as base to target 1.5, 1.6, 2.0.1, and 2.1.
If you have worked with mediaplayer through those OS versions and dealt with multiple screens you know what errors are going to pop up. Now remember shops like this typically do not invest in a whit4 box deviceanywhere testing solution as their marketing budget per client for non development stuff is often far bigger than the budget assigned to mobile application development.
Now what if we had a white-box solution that was easy to use say suing Groovy DSL that could some automatic tests on Android OS versions and device setups in a set of emulator instances. Than to get full re-use of our investment we use Groovy to make the android application build system more powerful and yet simple.
Because its groovy it already builds on the java knowledge and yet gives a DSL to leverage rather than ANT DSL. This reduction in developer use complexity and use at the single developer level than should translate into developers seeing it as benefiting their android development work flow. And the general idea is to have eclipse IDE execute this groovy/gradle build script as its incrementally compiling the project.
There is jvoegele’s android gradle plugin for gradle style android application build scripts but it forces the developer to manualy adjust the proejct each time its created because gradle prefers src/main/java rather than src. Because we are not using a gradle unit and coverage anyway stick with the Android ANT convention of src.
So the only part is breaking down the building the components of this Groovy/Gradle Android Application build system and using a sample Android Application build so that I am eating my own dog food. The sample android application will be an Atom/RSS reader. That should be complicated enough to cover unit testing, unit testing coverage, and white box testing implementations along with webkit webview stuff as well.
In the mean-time I am almost finished with an Android Programming knol detailing the ant build script I use. Thus, I should have that up shortly.
You know if you set android :windowBackground to a drawable and set your Layout container to either a background color or drawable that you get a nice very brief splash right? How could you use this?
As you know most of us recommend that use an activity as a dialog screen. You could use it to flash a splash screen for your dialogs as activities as youcan set a theme for each dialog activity.
That is a fully working custom set-up with text color changes, etc. Basically, I used the concept that since its a view group(TabWidget) I can manipulate the child elements. If it was just a plain view than you still can grab the object and manipulate.
Why is this important? With iPhone you are limited to the application UI guidelines that Mr Steve jobs wants you to follow. On Android you are not and thus use the look and feel of the application to establish your brand.
The problem happens to be that every UI implementation on the OS side has a different color color sets for focused and selected. HTC Sense is green, Android SDK is orange, and both Moto Blur and SonyEricsson Rachel are different colors.
On top of that not only are the image button colors changed but the hight light colors as well. Seems to me that if you could detect the build OS string to detect different UI implementations than set a theme:
setTheme(android.R.style.Theme_Dark); // ... setContentView(R.layout.main);
Bu t than you still have to change all your button and tabs etc. You still could use selectors but you would have an image set for each UI OS implementation and use an if then wrap code to select based on the build string.
Since most android training course do not cover these types of issues and solutions maybe you should bookmark those Android Knol collections links at the right side of this blog.
Tim Bray in his first Advocate post stated a daily sales figure of 60,000 versus iPhone’s daily 90,000 unit sales figure. Now, remember Apple has had 3 years to get to that 90,000 units per day figure. But, Android has reached 60,000 per day figure in less than 2 years. See why Apple is is scared yet?
A large part of that has been due the hard work of Verizon and Motorola. We as Nadrid Developers shoudl be prepared when it becomes 90,000 Android Devices sold per day later this year.
MobileBytes 