My Android adventure started this summer by learning Java. I was eager to learn Java and I was so determined to carry the book by Herbert Schildt about Java programming with 1024 pages from San Diego to Turkey. I did, and even I carried the book from one visit stop to another. I developed a game whenever I found tiny time slices free of my kids during five weeks vacation in summer houses. The book was written in a well organized manner with clear explanations therefore I enjoyed very much with Java.
When I returned from the vacation alone I had three weeks before my family came back to San Diego. I had some ideas on web programming for education. However, web applications seemed to me a little obsolete as I was reading some articles on mobility and computations, and some comments on iPhone and Android. Then I have decided to extend my expertise with iPhone and Android. Quickly I learned that iPhone needs an apple computer for accessing a development platform easily and I had no an apple computer. Therefore, I focused to Android as it has development platform for Windows and Linux.
I started to read Android development guide and reference documents. At the first shot I saw the architectural differences between Java AWT/Swing and Android. I had to learn Android layout, views, activity class, and many others. This was the most challenging part but after this the development got easier. Still there are some details to learn such as orientation change and reconfiguring the screen but these seems to be not difficult. The Android development kit comes with debugger and simulator. It allows to test and verify the software before testing on an actual phone. Currently my game is working on my Android phone, Motorola CLIQ.
One of the challenges in front of Android is to develop an application for various phones with varying user interface options such as display size, keyboard, navigation buttons. Some formal modeling is necessary to develop an application that is capable to adapt with varying user interfaces without updating the code or with minimal code changes. For example feature definitions should be general enough and easy to access by an application to determine the run environment, and to adapt itself to varying configuration changes from one phone to another. The phone manufacturers has to comply to these standards for rigorous application development for predictable platforms.
Another challenge is the power efficiency. If you have a phone without mobile computing but just a simple talk feature, its battery time is measured in days. However, a smart phone which needs synchronization to the news channels, email accounts, consumes much power. My phone, Motorola CLIQ, spends its battery in a day even I do not make much calls. I removed news channels but this didn't help much. Something invisible draining the battery. A customizable usage profiling tool may help for the end users and application developers. This tool may monitor applications running, measure their run frequency and durations, and notify when an abnormal operation is caught. As an end user, I would like to see if an application remains running at the background, or the processor is kept abnormally at high computation clock cycle when there is no user interaction. As an application developer I would like to check the computation efficiency. For example, in a puzzle game, there is no constant user interaction. The duration between two user actions is long compared with the computation time per a user action. The average computation duration within an expected game session could be helpful to asses the power efficiency of an application.
If a phone is changing the clock frequency of its application processor automatically depending on the computation need in a reasonably small time resolution, or the phone allows applications to request varying computation speed at certain phases, then more power efficient design can be achieved. Of course, clock frequency is one of the factor for power efficiency. As the smaller technology nodes are being in use, due to static current leakage and operation speed trade-off, multi-core processor architecture becomes preferable. Enabling and disabling computation cores in multi-core application processors can also be used for varying computation speeds to drain battery more efficiently while an application is running.
I believe Android can make a better mobile computation world if it brings some more recommended guideline to both hardware and software architectures.
Monday, November 16, 2009
Subscribe to:
Posts (Atom)