http://sites.google.com/site/io/inside-the-android-application-framework In the presentation, an APK is called "an island" which is an appropriate metaphor. In this way assets and code are constructed and linked/bound together to allow developers can quickly access resources (layouts, images, etc.) using a main (precompiled) registry (i.e. R.strings.name) this convenience does much for things like making sure your get things correct at compile time so you don't push out a half baked application which is missing a string, image, sound, or other asset. (And that's a good thing)
Because the apk structure of an Android application is optimal for storage footprint and runtime performance, this means it is unfortunately sub-optimal for another aspect, and that would be for flexibility/quick iterations.
Let me explain (through a use case).
Designing Layouts in Android provides convenient ways of accessing resources (images, text, etc. in the res directory) directly from the Layout.xml file. In eclipse, there is even a "real time" editor and viewer which allows you to layout components (buttons, text, images) in and see what they "should" look like on the android device. This is no doubt a nice feature and time saver... Assuming what you are looking at in the preview pane is what you get on the device (which in my experience is not the case). In practice, what ends up happening is that the UI will:
- look one way in the Layout preview pane,
- a different way in the emulator,
- and a third way running on a specific target device.
Going through the development process where I had an emulator, the Layout preview, and a target phone (HTC Droid Incredible) and trying to get the layout to look right on all of these devices was tedious...
1) make one change to the layout.xml,
2) redeploying to phone.
3) enter information in the application until I get to the page I am testing (frequently the last one in the app).
4) realize the page doesn't look quite right and go back to step 1)
I must have spent a good 1/3 of my time just tweaking the UI to try to make things look right (and this was in development.)
Then when the application was in QA this continued. The QA leads were using 1st gen Android phones and regardless of my emulator settings, those screens were impossible to emulate, so I ended up receiving feedback such as ("the character needs to move up more", and "the guys hand is getting cut off to the right") I'm not blaming QA, they were stellar (They would even take pictures of what the screens looked like), but as a architect/developer, it was death by 1000 paper cuts.
The sad part of this was the fact that I was making the most minor changes (i.e. tweaking the number of dips (device independent pixels) between the header image and the content, etc.) in some xml file ... this was EJB deployment descriptors all over again...
In addition, we had internationalization issues, and the text (for things like buttons and screen verbiage) changed frequently, and for each (simple) change, we had the following process:
1) (QA) identified problem
2) (QA) JIRA writeup made (screenshots, etc)
3) (QA) assigned JIRA
4) (Management) scheduled and assigned JIRA
4) (Developer) a single XML file was changed
5) (Developer) redeployed app to dev phone
6) (Developer) check in change
7) (Developer) update JIRA status
8) (Developer) cross fingers/ pray it fixed problem (if not goto 1))
What I would love is to be able to make all of these changes (to things like layouts, strings, etc.) push out a debug version of the application, and allow changes to be made at runtime. (Until things are refined to the point where a production version is available)
Alternatively
Deploy a "debug" version of the application which resolves assets (layouts, strings, etc.) locally or from a Server, so effectively you can change (simple assets) at runtime. To accomplish this, we are looking at a combination of Google App Engine and C2DM http://www.youtube.com/watch?v=51F5LWzJqjg&feature=related
... where C2DM just notifies your android device that it should go out and reload some asset from the Server.)--- More later
No comments:
Post a Comment