jeudi 25 septembre 2008

First feedback on Android framework [EN]

After few months developing a little try under Android API, I wanted to make feedback on benefits of the Google OS. I want to achieve the first version of my project and then make aconstructive criticism about Android regarding to other graphical or mobile APIs, like the iPhone.
Since the beginning of the year, I established a personal project to develop a small Android application, quite independent, using GUI at maximum of its capacities, a database (SQLite) and a few onboard Google Maps onboard. I'll give small screenshots in a way that says enough along on the usefulness of the program, because I do not know yet exactly what I will do with my application.
My first impressions over development were:
  • Firstly, the ownership of the GUI as a developer is quite long : you cannot learn to make a good GUI in a week, it takes more time (about 2 months). But when you play well with this API, you have fun. The GUI is certainly more easy to control than the Swing one, my only point of comparison in Java.
  • Despite this, the GUI is not as good as the iPhone one : technologically, it lacks important points (difficult to achieve, I know): the multi-touch is not supported at all and will probably never (or only partially, if we can hope?); the fluidity of the scrolls with the finger is not as impressive as on the iPhone and at the same time it lost ergonomism ; the sequence of screens and transitions between them are not automatic : you must integrate or develop it by yourself: it has its advantages but also disadvantages: each program will behave differently on transistions, resulting in a loss of landmarks for the user ; API adopted by Google is a little too oriented "1 screen means 1 Java class", which is sometimes a strong constraint to generate clear source code.
  • The screen resolution of Android is variable! Several resolutions will be possible: this advantage allows manufacturers of phones to have screens of different size depending on the targeted markets: it is good for them. For developers, that's another story! You must design applications with screens nor too rich (to fit on small screens), nor too poor (to avoid empty large screens), or (solution that I had adopted) set up screens for each resolution . This work is long, and if an application does not handle many resolutions (as I saw many applications as ADC Challenge winners...), small screen will not display everything, and therefore the application does not run properly on low resolutions, which are - I presume - being the first resolutions to emerge on the market, given the current technological possibilities.
  • Application side, we do what we want, as long as it is possible in Java, and if it is not too heavy to execute : we must not forget that Java is a language interpreted by a JVM, and it is basically heavy and power consumer. On a small phone, we have the computing power of a PC made five years ago. See how Windows Mobile is slow: it will be worse under Android, unless you have a very big phone tht cost a lot (see the dimensions of the HTC Dream / G1, the first android phone to be released, for about $300).
  • Synchronization side, between Android / Desktop, is for the moment inexisting: either I missed a big detail in the framework, or it is a huge mistake made by Google: I have not found any tool in the emulator to synchronize laptop with a PC... If every developer must do its own synchronization program, there will be problems quickly. I intend to look at this at the end of my project to analyze the feasibility and simplicity to develop a database sync.
  • Finally, as the framework version 0.9 was released recently, I was able to experience a transition of versions with my application. The changes in the API showed me about 550 errors in Eclipse. Classes have disappeared, others are displaced or have become private. Many methods have been renamed (without any logical intention), and Google Maps API has changed a lot. I had to fully rewrite the classes of my application using MAPS. For 550 errors, 30 hours were needed to bring my application up to version 0.9 (the gain is still significant in terms of fluidity, features ...).

Aucun commentaire:

Enregistrer un commentaire