Skip navigation

Tag Archives: android

Week two proved to be surprising in a lot of ways. I didn’t code much (I didn’t code at all last Wednesday) and there were more group meetings than I expected. We spent it laying down the foundations for our project. That means coding the basic functions for some, creating database schemas for others, and doing user interface (UI) related stuff for me.

UI is an interesting thing. I’ve coded quite a lot of projects already, personal and academic, but only in a few of them did I consider the UI seriously, mainly because for the most part of those projects (academics, *hem**hem*) the requirement was purely back-end (i.e., functional but without UI) code. I’ve read quite a lot on it but my most considerable brush with UI design was in my Software Engineering class. What makes it particularly challenging to me is the amount of cognitive psychology involved: elements must be intuitive, the transitions from screen to screen must be logical, users must not have a hard time navigating around the features, etc.

I’m doing UI largely because of my considerable proficiency in Photoshop. I’m not a god, heck no. But I’m pretty good at it that I can make decent freemouse images in a matter of minutes, making good use of layers that I can easily make variations, should they be needed.

It’s actually been a long time since I last used Photoshop. The last version I used was CS2 and it’s now at CS5. The last Photoshop job I’ve ever done was on my personal site. Every image-job I did after that was done in GIMP and, setting aside my FOSS fanboyishness, GIMP is still a very far cry from Photoshop’s awesomeness. So, I’m quite pleased with myself that I still remember where to find what around Photoshop.

I can’t really post my creations because I think that would fall under my lips being sealed. But I can tell you about the nitty-gritties of designing a UI for Android.

1) The screen is small and its size varies across devices.

I’ve done UI for desktop applications (not much problem; just let Swing/AWT’s Layout Managers do the job) and web dev (absolutely fantastic if not for the fact that Internet Explorer is such a pain in the *$$) but this is my absolute first time for a mobile device.

And the most obvious challenge for Android is its screen size. The fact that I’m designing overlays for Google Maps doesn’t help much either. I try to keep the opaque areas of my overlays to a minimum so as not to appear intrusive on the Map.

And the varying screen sizes? Sure it’d be easy to call some system function determining the screen size then resize according to that. However, this leads us to my second point which is…

2) Android’s Canvas class doesn’t seem to have a resize() method or something for Bitmaps. To resize Bitmap objects, you need to use a Matrix.

Or, at least, I haven’t found any easier way yet. Not much of a nuisance except that what takes a single line in java.awt takes around 4-5 in Android.

3) The screen size varies across devices.

Just wanted to say it again. I love open-source but when the issue of screen size came up in our meetings, I can’t help but think fragmentation.

Three points for the three days of week two seem fair enough. Till next time. ~ The Chad Estioco