I don't have a lot to add to all that, except that you are running an extremely old build of Android - it would be interesting to hear your thoughts on the platform when you get the 2.1 update later this month (with a little luck?)
Don't expect it to compare to the Nokia 8310 though, that was a neat bit of kit! If a little limited when compared to the Hero on functionality (as you've already said). I see your point of view on smartphones (I assume we're including the iPhone and Nokia N900 in this as well now), but in reality the operative word for smartphone is "smart", for better or worse. I've yet to see a smartphone that is a better at being a "phone" than a standard phone. On Wed, Apr 7, 2010 at 5:13 PM, debuti <[email protected]> wrote: > I think it is a base problem. I think for example about my old nokia > 8310, in which you pressed buttons quickly and the response was > immediate, yeah, I know it has no OS and not even the capabilities we > have at the android, but it was what should be a phone. We must > remember that the term smartphone is phone and smart, but primarly > phone. > > So I think that the design should have been raised differently, not as > regards the manner in which applications are handled, if not in the > way they handled the phone functions, and I do not talk about there > shouldn't be cuts in a conversation, I speak also of the interfaces > that the user must navigate to get to make a call ( and write text > messages, etc) > > Then will come the applications, but I think it's a must to solve the > user experience we had with old cell phones and unfortunately we lost. > > I think the system should be designed from a standpoint of real-time > system. Giving specific quarks to specific and real time functions. > > pd. Unfortunately my phone has the filtered version of Eris, I hope in > the htc version this problem would be issued. > > > > On 7 abr, 17:49, Sean Hodges <[email protected]> wrote: >> What I think is that there are lot of little issues, not one big one. >> >> I'm also suggesting that the problem has very little to do with the >> Java specific aspects of Android, and more to do with a composite of >> problems. I base a lot of that from my experience working on other >> software projects; the underlying problem is usually numerous, very >> specific and hidden behind a curtain of assumptions... >> >> What are your thoughts debuti? You asked the question originally, do >> you think there is one big spanner stuck in the works? Or a collection >> of issues that could be ironed out through optimisation efforts and >> accurate bug reporting? >> >> Also, could you let us know if your HTC Hero is still running the old >> 1.5 build of Android? >> >> On Wed, Apr 7, 2010 at 4:33 PM, debuti <[email protected]> wrote: >> > Dont you think that the big issue here is a base problem?: >> >> > We are talking about a real time system (in most functions) and the >> > current architecture dont behave accordingly. Appart from java. >> >> > On 7 abr, 17:25, Sean Hodges <[email protected]> wrote: >> >> Hey Tim, >> >> >> On Wed, Apr 7, 2010 at 2:51 PM, Tim <[email protected]> wrote: >> >> > The programs are written in Java, compiled to a bytecode that is >> >> > primarily used to represent Java source, and executed on a virtual >> >> > machine that is primarily intended to execute these Java programs. >> >> >> Primarily used to represent a Java program in an instruction set >> >> designed for efficient execution by a VM, not to represent Java >> >> source. I was pointing out that the Java language is not interpreted >> >> in the VM, is that what you are disagreeing with? >> >> >> > Only a pedant would say 'Android is not Java', not that that even >> >> > makes sense - Android is the OS not the VM/language. >> >> >> Sorry, did I do something to you to deserve the name calling? Thanks >> >> for pointing out the terminology slip, I did not mean to insinuate >> >> that. >> >> >> > Google it (and remember Dalvik is currently JIT-less). >> >> > There's some debate about whether JIT'ed Java is as fast as C, but in >> >> > most cases it isn't (good microbenchmark website: >> >> >http://shootout.alioth.debian.org/u32/benchmark.php?test=all〈=jav... >> >> > ) >> >> >> It's funny, only today I was talking to a colleague about how people >> >> often use the Shootout tests and Google Trends to make their point >> >> about language performance. Please read the caveats on the Shootout >> >> test suite, particularly the comparison >> >> section:http://shootout.alioth.debian.org/flawed-benchmarks.php#comparison. >> >> As >> >> a rule of thumb, you shouldn't use the shootout suite to generalise on >> >> performance differences. >> >> >> All the same, I do agree that on average, C and it's derivatives >> >> out-perform Java (particularly without JIT) on a good number of >> >> benchmarks. What I don't want to do is get pulled into a low-level >> >> benchmarking argument (perhaps it's too late?) as we are talking about >> >> significant responsiveness issues on the UI, not evaluating a >> >> controlled Fibonacci test between the 2 platforms. >> >> >> > Either way, Dalvik doesn't have a JIT compiler so it is *much* slower >> >> > than native code. Additionally it uses a 'stop the world' garbage >> >> > collector which periodically freezes the UI for around 0.1-0.2 >> >> > seconds. That causes little hiccups. >> >> >> The "stop the world" garbage collection is an interesting point to >> >> make. I've heard it before, and at the time I saw a response from >> >> Dianne Hackborn that stated that the GC of one app does not affect the >> >> functioning of another in normal handset operation. However, right now >> >> I can't find that email, so I won't argue the point :) >> >> >> It would be interesting to see any bugs logged for this particular GC >> >> issue. I do know that when I execute a background Service that >> >> deliberately triggers the GC regularly, that service responds slowly >> >> but my Home app continues to function properly. It is not a scientific >> >> test, but I think it makes the "stop the world" scenario more subtle >> >> than you suggest. >> >> >> > So the following are reasons that contribute to Android being much >> >> > less responsive than the iPhone, in order of how much I'd guess they >> >> > affect things: >> >> >> > 1. Interpreted code rather than compiled. >> >> > 2. Stop-the-world garbage collector. >> >> > 3. Lack of hardware OpenGL accelleration for the UI (afaik, maybe this >> >> > has changed in the latest versions?) >> >> > 4. Background apps. >> >> > 5. Maybe the UI thread isn't given high enough priority? >> >> >> Some of those have question marks against them, so perhaps you should >> >> say "the following are the reasons I think contribute to Android being >> >> much less responsive than the iPhone". I won't argue any of them as >> >> potential factors (most significantly, your first point does not >> >> mention "Java code", which makes it valid), but I would say that there >> >> is a lot more going on than your list above. I personally think my >> >> list is a bit more concise, but then I did write it :) >> >> >> > By the way, I think the whole "You have to make sure you don't >> >> > allocate too many objects, e.g. strings in loops" kind of cancels out >> >> > the "Java is great, you don't need to worry about memory management!" >> >> >> Couldn't agree with you more, and of course every good programmer >> >> (Java or otherwise) knows this. The problem is there are a lot of bad >> >> programmers out there, and they propagate the myth. >> >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "Android Discuss" 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 >> > athttp://groups.google.com/group/android-discuss?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Android Discuss" 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-discuss?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Android Discuss" 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-discuss?hl=en.
