On Wed, Jan 27, 2010 at 5:11 AM, Michael J McLean <[email protected]> wrote: > Mark, > Thank you for taking the time to reply. There are a lot of > restrictions placed on developers trying to provide a quality user > interface. I can live with this particular restriction but I would > appreciate help on one other issue. If I use the navigation buttons to > highlight and select an item in my listview, and then press MENU, the first > menu item is highlighted, where if I hadn't previously navigated to one of > the items on my list view, and press MENU, the menu item would not be > highlighted.. I would like to prevent this from happening for the sake of > consistency. >
There are two different modes of navigation. Touch mode and button mode (can't remember the real name). Basically if you press a navigation button like the d-pad it will switch out of touch mode. This means you will see items highlighted so you can tell where you are. If you're in touch mode you wont see this highlighting because there's no need to know where you are and you can touch anywhere on the screen. I's therefore a user aid to have this highlighting turned on where you activate the menu button and isn't really something you should be messing with. I'm sure it's possible to, however it would likely confuse users as it goes away from what normally happens on all other apps, and keeping things consistent means much happier users. Only change this if you really have to, not just because it looks better. > I wonder why the programmer doesn't just simply have the > ability to highlight or de-highlight an item with one command. But then I > also wonder why the programmer cannot simply call or hide the virtual > keyboard with one command each. Getting rid of the virtual keyboard proved > to be a messy affair with unwanted side effects. Even now, when doing a text > entry, I find that if I hold down some characters, such as e, g, and r, > unwanted options appear on the screen. I presume you've disabled the virtual keyboard and have the app in a portrait orientation. If you do it wont matter too much what you press on the emulators keyboard as only devices with a hardware keyboard (G1 and droid for example) will be able to press these keys, and even then only with the slider open. What was the reason for disabling the virtual keyboard? Surely if you have a text area you want people to be able to type into it on devices without a keybaord. > I would really appreciate help on > getting rid of that. I have purchsed two books including yours, enrolled in > a University course ( to withdraw after 3 weeks when I realised their lack > of their ability to help), and yet I find most knowledge comes from trial > and error, constantly reinventing the wheel, and the occasional tip from the > forums, if your lucky. I would love to know where I can find systematic > introductions and explanations for these basic Android features. The Android > documentation seems to be written as a reference source for people who > already understand it. Seeing links being given to the Android documentation > as an 'answer' to forum questions, is frustrating and annoying. People are > asking for help and examples. The existence of, and size of the forums, is > testament to the Android documentation not giving us developers what we > need. Much of my programming time and efforts seems to be in developing ad > hoc workarounds, to situations that prevent me from achieving the standard > of user interface that I require. > That's how development works for me as well. The books and documentation can only take you so far. Most of the experience comes from actually doing it. If you want to be able to read a book and then be able to go straight out to making a really complicated application you're going about it the wrong way. Treat the books and documentation as a reference and use your own project as a way of actually learning how to develop for android. > Two features that led me to invest most of last year into learning > Android, were 1) the fact that it was claimed that you didn't even need a > handset. If it worked on the emulator you could rely that it would work on > the phone, and 2) the App store. 1) Technically true but it's always good practice to test the application on a real device. It also helps to know how other applications on the device function so you can keep it consistent with that (like the touch mode example i gave above). 2) Gotta love open app stores :) > Both of these advantages are seriously > eroded by the fragmentation of Android. And it doesn't help to read of > Android engineers expressing their anger in forum replies to reference being > made to the fragmentation issues. > The fragmentation is an issue and Google does need to answer it seriously and soon I think. > All of the above strengthens the case for me to not merely " > rethink your user interface to avoid the question " as advised by you, but > to rethink the ultimate question of does Android offer enough to developers > to be worthwhile. Personally I think it overs a lot to developers and is far less restrictive than some other mobile platforms. Take a look at the app store and you'll see what's possible. > I hope that you are able to take these criticisms as being offered > constuctively. > They seem fair arguments to me :) Matt -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
