On Monday 14 December 2009, Arie Skliarouk wrote: > Hi, > > I have used Android on Freerunner for about two months and decided to test > latests SHR, as I needed working navit and there were couple bugs in > Android that allegedly were fixed in SHR, and here are my impressions (and > disappointments):
Which version of shr exactly? It may be that some of the problems are known and/or fixed, or that a fix turns out just to be a partial fix. I'm running shr-unstable with updates from roughly the middle of last week - so much for 'exactly' ;-) > Impressions: > * numpty game is very addictive (albeit crashes from time to time). I would > love to see the game on Android. > * The SHR picked up the time (either from GPS or GSM) automatically > * Full image contains several useful apps out-of-the-box: calc, mokomaze, > pidgin, sketch, numpty > > Disappointments: > * By default the phone suspends even when charged During charging the screen blanks, but the phone doesn't suspend. This is usually what I want, but when I don't want blanking it is reasonably quick to disable it in the Settings app. > * The suspend begins from immediate blanking of the LCD, whereas I like > android's slowly dimming approach more Certainly prettier, and probably not a big job. > * Default suspend time is very short - mere 15 seconds Whether this is good or not depends on the use case. Whatever the value we will have people calling for the default to be longer or shorter. The short time is good for battery preservation (backlight on full takes >50% of power consumption) but is sometimes frustrating. Suspend is long enough after blanking that I rarely have problems with unexpected suspends. We will need to do some proper usability research to determine an optimum default value. At present an app can request the Display resource to block dimming, and the CPU resource to block suspend. We don't have a resource that would shift dimming to some intermediate value, but maybe we should. Perhaps it should be a window property like the proposed properties for preferred screen orientation. > * The AUX(Back) and Power(Menu) buttons are *very* intuitive on android. I find the button usage on Android anything but intuitive, but you get used to it. I'm sure this is mostly to do with 2 buttons on the FR taking the jobs of 4 or more on the android phones. > They are almost not used in SHR: > - Wakeup from suspend using Power button. (The iPhone-like swiper is just > ugly on SHR) Power also brings up the menu to let you suspend or shut down. Aux toggles the screen lock. I find this very useful when pocketing the phone while still powered, as when recording gps tracklogs. > - It is still not clear to me how to invoke Menu in applications Most apps don't have one to invoke, or have it present all the time. More seriously we don't have any consistent application style rules. This is partly because many of the apps are generic linux apps that happen to be usable (just about) on a 480x640 screen. > * The whole interface of SHR is hard to use without a stylus. Android's > interface poses almost no problem for finger-only usage. I find Android more consistent in its ease of use without a stylus. Default apps in the full shr image are more variable. Some are easier to use with fingers than Android, and some more difficult. In general the easy ones use enlightenment widgets and were written for small touchscreens, while the hard ones use gtk+ widgets and are ordinary desktop apps that happen to be usable on small touchscreens. > * Applications take much longer to start (I know it is apples and oranges, > it just my impression), the phone looks less responsive True, particularly with python apps. I suspect most apps could improve their apparent startup time, but it's not usually something developers concentrate on. It's the sort of annoyance that should be taken more seriously than it usually is. > * numpty once locked up hard, so I could not kill it. Software power off > did not work either... Had to remove the battery. That sounds a bit like running out of memory. Opkg can do this if there are a lot of packages to upgrade too. I use swap to guard against this, but many people still don't like the idea. > * Boot image is overlapped with text messages during boot That depends on the boot options, and is (mostly) easy to change. Until we get a stable image it's probably better to have ugliness with a hope of debugging than maximum pretty that's impossible to debug when it goes wrong. > To be continued... > > -- > Arie > _______________________________________________ Shr-User mailing list Shr-User@lists.shr-project.org http://lists.shr-project.org/mailman/listinfo/shr-user
