[android-developers] API to access spreadhseet rows and columns

[Arun Kumar]

Hi All,

Are there any android libraries to access the Google drive spreadsheet's
rows and columns.

-- 
Regards,
Arun Kumar
http://clicknscroll.blogspot.com

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

[李白|字一日]

a global event based rendering machine plus HTML5 + javascrip + css Bundle
will surely be more faster. firefox os maybe an existing example.

it consumes less resources. while android is not.

http://propakistani.pk/2013/04/29/how-and-why-firefox-os-is-better-than-android-and-ios/


2014-05-12 13:52 GMT+08:00 李白|字一日 :

> you even don't know what javascript is .
> although javascript needs more than one threads to execute, but it is
> event based. in run time, it has no needs to create new thread.
>
> like epoll vs select in network io.
>
> the differences are obvious.
>
> java can't make it.
>
> the switch between ui thread to network thread is not needed in javascript.
>
> but it is a must in java.
>
> as to clear, i give some my opinions on why i like javascript and possibly
> be a fast language:
>
> 1、can be compiled to native when possible, requires no vm
> 2、event based
> 3、async executed
> 4、no more threading
> 5、no inheritance need.
> 6、object based, prototype based, native to have the ability to extends but
> require no new classes.
> 7、no classes to objects translation.
>
>
>
>
>
> 2014-05-12 13:30 GMT+08:00 Kristopher Micinski :
>
> What are you even talking about: Any JavaScript program is also going
>> to have threads, too.
>>
>> You seem to be making this argument: Java has multiple threads, and
>> that makes the programs slow.
>>
>> It sounds like all of this is coming from a completely uneducated
>> viewpoint on systems design, but there are a number of
>> issues.
>>
>> Please understand, however, that all of the issues in Java carry over
>> (and worse) to JavaScript, you still need multiple threads, you still
>> need a garbage collector.
>>
>> Please also quit citing other Java products as evidence that it has
>> anything to do with Android.  Forget Java, android doesn't run Java.
>> Android runs Dalvik.  Which is completely different than Java.  You
>> can translate anything into Dalvik, people usually translate Java,
>> there's no reason you couldn't also translate anything else.
>>
>> Kris
>>
>>
>>
>> On Mon, May 12, 2014 at 1:22 AM, 李白|字一日  wrote:
>> > the slow comes not just from the loading of java based apps. but the
>> java
>> > itself and the bad programming guidance, which uses too many threads and
>> > classes which take a lot space. and what even worse is you will
>> sometimes
>> > have to do deep inheritance.
>> >
>> > it adds extra overheads to make itself run.
>> > these are ignored while benchmark.
>> >
>> > i am by no means expert in languages. but it is true that java is slow
>> to
>> > what ever products made by java.
>> >
>> > eclipse, android, j2me, netbeans, idea.
>> > none of them are famous for their speed and memory saving.
>> >
>> >
>> >
>> >
>> > 2014-05-12 11:22 GMT+08:00 bjv :
>> >>
>> >> Ugh! You don't get it and likely never will. There are so many things
>> >> wrong with your assumptions/statements in all of these threads. It
>> really
>> >> isn't worth the time to debunk them all.
>> >>
>> >> But for what its worth, there is small overhead with respect to running
>> >> Java/Dalvik on Android. That said, it is mostly upfront. JS is an
>> >> interpreted language. Outside of the various ASM-JS experiments, Your
>> >> html5+JS likely will always be interpreted. In a broad comparison, it
>> will
>> >> almost always be slower. Your thinking that you get to share all those
>> JS
>> >> object goodies between various apps/components is in itself a cause for
>> >> concern.
>> >>
>> >> In an effort to remove the Dalvik overhead on Android, the Android guys
>> >> are now rolling out ART (a variant of llvm) that will transfer most of
>> that
>> >> overhead to installation time. At that point, Java isn't going to be
>> much
>> >> different than C++ from an execution perspective.
>> >>
>> >>
>> >> On Sunday, May 11, 2014 1:41:41 PM UTC-5, 李白，字一日 wrote:
>> >>>
>> >>> if it is not, why should you go native with c/c++ based ndk
>> programming?
>> >>>
>> >>> it is surely related to the programming language.
>> >>>
>> >>> javascript 's speed acceleration is also related to the language and
>> its
>> >>> optimization, which is almost always c/c++.
>> >>>
>> >>> i have never experienced the fast feeling of java technology both in
>> >>> desktop or server side.
>> >>>
>> >>> i never experienced fast  feeling in android, eclipse, java ee, j2me.
>>  am
>> >>> i fooled?
>> >>>
>> >>> eclipse is famous for it's slow and memory consuming, though it is the
>> >>> greatest  ide i ever used.
>> >>>
>> >>> javascript based ide, like local compiled c9.io is very fast and
>> >>> responsive, thought it is not that mature.
>> >>>
>> >>> why ? ? ?
>> >>>
>> >>> and if android ui design can be written directly in html + css, it has
>> >>> all the flexibility css and html have now. If you know the web
>> technologies,
>> >>> you should know what i mean.
>> >>>
>> >>> it is meaningless to discuss about the languages' performance, but the
>> >>> trend is that javascript will play a more important r

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

[李白|字一日]

you even don't know what javascript is .
although javascript needs more than one threads to execute, but it is event
based. in run time, it has no needs to create new thread.

like epoll vs select in network io.

the differences are obvious.

java can't make it.

the switch between ui thread to network thread is not needed in javascript.

but it is a must in java.

as to clear, i give some my opinions on why i like javascript and possibly
be a fast language:

1、can be compiled to native when possible, requires no vm
2、event based
3、async executed
4、no more threading
5、no inheritance need.
6、object based, prototype based, native to have the ability to extends but
require no new classes.
7、no classes to objects translation.





2014-05-12 13:30 GMT+08:00 Kristopher Micinski :

> What are you even talking about: Any JavaScript program is also going
> to have threads, too.
>
> You seem to be making this argument: Java has multiple threads, and
> that makes the programs slow.
>
> It sounds like all of this is coming from a completely uneducated
> viewpoint on systems design, but there are a number of
> issues.
>
> Please understand, however, that all of the issues in Java carry over
> (and worse) to JavaScript, you still need multiple threads, you still
> need a garbage collector.
>
> Please also quit citing other Java products as evidence that it has
> anything to do with Android.  Forget Java, android doesn't run Java.
> Android runs Dalvik.  Which is completely different than Java.  You
> can translate anything into Dalvik, people usually translate Java,
> there's no reason you couldn't also translate anything else.
>
> Kris
>
>
>
> On Mon, May 12, 2014 at 1:22 AM, 李白|字一日  wrote:
> > the slow comes not just from the loading of java based apps. but the java
> > itself and the bad programming guidance, which uses too many threads and
> > classes which take a lot space. and what even worse is you will sometimes
> > have to do deep inheritance.
> >
> > it adds extra overheads to make itself run.
> > these are ignored while benchmark.
> >
> > i am by no means expert in languages. but it is true that java is slow to
> > what ever products made by java.
> >
> > eclipse, android, j2me, netbeans, idea.
> > none of them are famous for their speed and memory saving.
> >
> >
> >
> >
> > 2014-05-12 11:22 GMT+08:00 bjv :
> >>
> >> Ugh! You don't get it and likely never will. There are so many things
> >> wrong with your assumptions/statements in all of these threads. It
> really
> >> isn't worth the time to debunk them all.
> >>
> >> But for what its worth, there is small overhead with respect to running
> >> Java/Dalvik on Android. That said, it is mostly upfront. JS is an
> >> interpreted language. Outside of the various ASM-JS experiments, Your
> >> html5+JS likely will always be interpreted. In a broad comparison, it
> will
> >> almost always be slower. Your thinking that you get to share all those
> JS
> >> object goodies between various apps/components is in itself a cause for
> >> concern.
> >>
> >> In an effort to remove the Dalvik overhead on Android, the Android guys
> >> are now rolling out ART (a variant of llvm) that will transfer most of
> that
> >> overhead to installation time. At that point, Java isn't going to be
> much
> >> different than C++ from an execution perspective.
> >>
> >>
> >> On Sunday, May 11, 2014 1:41:41 PM UTC-5, 李白，字一日 wrote:
> >>>
> >>> if it is not, why should you go native with c/c++ based ndk
> programming?
> >>>
> >>> it is surely related to the programming language.
> >>>
> >>> javascript 's speed acceleration is also related to the language and
> its
> >>> optimization, which is almost always c/c++.
> >>>
> >>> i have never experienced the fast feeling of java technology both in
> >>> desktop or server side.
> >>>
> >>> i never experienced fast  feeling in android, eclipse, java ee, j2me.
>  am
> >>> i fooled?
> >>>
> >>> eclipse is famous for it's slow and memory consuming, though it is the
> >>> greatest  ide i ever used.
> >>>
> >>> javascript based ide, like local compiled c9.io is very fast and
> >>> responsive, thought it is not that mature.
> >>>
> >>> why ? ? ?
> >>>
> >>> and if android ui design can be written directly in html + css, it has
> >>> all the flexibility css and html have now. If you know the web
> technologies,
> >>> you should know what i mean.
> >>>
> >>> it is meaningless to discuss about the languages' performance, but the
> >>> trend is that javascript will play a more important role in server side
> >>> programming, hardware based programming and browser side programming.
> >>>
> >>>
> >>> 2014-05-12 1:03 GMT+08:00 Colin M :
> >>>
>  I'll ignore the unqualified claim that the slowness of Android is due
> to
>  Java.
> 
>  It sounds like your complaint is that you can't develop native apps in
>  your preferred language and that you're using an outdated claim about
> Java
>  to support your desire to change the current language 

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

[Kristopher Micinski]

What are you even talking about: Any JavaScript program is also going
to have threads, too.

You seem to be making this argument: Java has multiple threads, and
that makes the programs slow.

It sounds like all of this is coming from a completely uneducated
viewpoint on systems design, but there are a number of
issues.

Please understand, however, that all of the issues in Java carry over
(and worse) to JavaScript, you still need multiple threads, you still
need a garbage collector.

Please also quit citing other Java products as evidence that it has
anything to do with Android.  Forget Java, android doesn't run Java.
Android runs Dalvik.  Which is completely different than Java.  You
can translate anything into Dalvik, people usually translate Java,
there's no reason you couldn't also translate anything else.

Kris



On Mon, May 12, 2014 at 1:22 AM, 李白|字一日  wrote:
> the slow comes not just from the loading of java based apps. but the java
> itself and the bad programming guidance, which uses too many threads and
> classes which take a lot space. and what even worse is you will sometimes
> have to do deep inheritance.
>
> it adds extra overheads to make itself run.
> these are ignored while benchmark.
>
> i am by no means expert in languages. but it is true that java is slow to
> what ever products made by java.
>
> eclipse, android, j2me, netbeans, idea.
> none of them are famous for their speed and memory saving.
>
>
>
>
> 2014-05-12 11:22 GMT+08:00 bjv :
>>
>> Ugh! You don't get it and likely never will. There are so many things
>> wrong with your assumptions/statements in all of these threads. It really
>> isn't worth the time to debunk them all.
>>
>> But for what its worth, there is small overhead with respect to running
>> Java/Dalvik on Android. That said, it is mostly upfront. JS is an
>> interpreted language. Outside of the various ASM-JS experiments, Your
>> html5+JS likely will always be interpreted. In a broad comparison, it will
>> almost always be slower. Your thinking that you get to share all those JS
>> object goodies between various apps/components is in itself a cause for
>> concern.
>>
>> In an effort to remove the Dalvik overhead on Android, the Android guys
>> are now rolling out ART (a variant of llvm) that will transfer most of that
>> overhead to installation time. At that point, Java isn't going to be much
>> different than C++ from an execution perspective.
>>
>>
>> On Sunday, May 11, 2014 1:41:41 PM UTC-5, 李白，字一日 wrote:
>>>
>>> if it is not, why should you go native with c/c++ based ndk programming?
>>>
>>> it is surely related to the programming language.
>>>
>>> javascript 's speed acceleration is also related to the language and its
>>> optimization, which is almost always c/c++.
>>>
>>> i have never experienced the fast feeling of java technology both in
>>> desktop or server side.
>>>
>>> i never experienced fast  feeling in android, eclipse, java ee, j2me.  am
>>> i fooled?
>>>
>>> eclipse is famous for it's slow and memory consuming, though it is the
>>> greatest  ide i ever used.
>>>
>>> javascript based ide, like local compiled c9.io is very fast and
>>> responsive, thought it is not that mature.
>>>
>>> why ? ? ?
>>>
>>> and if android ui design can be written directly in html + css, it has
>>> all the flexibility css and html have now. If you know the web technologies,
>>> you should know what i mean.
>>>
>>> it is meaningless to discuss about the languages' performance, but the
>>> trend is that javascript will play a more important role in server side
>>> programming, hardware based programming and browser side programming.
>>>
>>>
>>> 2014-05-12 1:03 GMT+08:00 Colin M :
>>>
 I'll ignore the unqualified claim that the slowness of Android is due to
 Java.

 It sounds like your complaint is that you can't develop native apps in
 your preferred language and that you're using an outdated claim about Java
 to support your desire to change the current language of choice for Android
 development.

 The XML based components can all be done via code.  Do you have an
 example of how they are "far from flexible"?  There are many limitations,
 but you are welcome to write your own custom Views to get around any
 limitations.  I have many of my own complaints about some of the UI system,
 but I have no reason to believe the current state of things would be faster
 or more flexible if it were in another language.  That's not the thing
 limiting flexibility or causing speed issues, that's more about the
 implementations.  I've created and seen many fast and fluid and complex UIs
 on Android, but you sometimes have to do some real work to get them and 
 they
 don't always drop right out of the API in your lap :)  A better argument
 would be to single out issues with the UI libraries and talk about how to
 improve them.  This has little-to-nothing to do with implementation
 language.

 

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

[李白|字一日]

the slow comes not just from the loading of java based apps. but the java
itself and the bad programming guidance, which uses too many threads and
classes which take a lot space. and what even worse is you will sometimes
have to do deep inheritance.

it adds extra overheads to make itself run.
these are ignored while benchmark.

i am by no means expert in languages. but it is true that java is slow to
what ever products made by java.

eclipse, android, j2me, netbeans, idea.
none of them are famous for their speed and memory saving.




2014-05-12 11:22 GMT+08:00 bjv :

> Ugh! You don't get it and likely never will. There are so many things
> wrong with your assumptions/statements in all of these threads. It really
> isn't worth the time to debunk them all.
>
> But for what its worth, there is small overhead with respect to running
> Java/Dalvik on Android. That said, it is mostly upfront. JS is an
> interpreted language. Outside of the various ASM-JS experiments, Your
> html5+JS likely will always be interpreted. In a broad comparison, it will
> almost always be slower. Your thinking that you get to share all those JS
> object goodies between various apps/components is in itself a cause for
> concern.
>
> In an effort to remove the Dalvik overhead on Android, the Android guys
> are now rolling out ART (a variant of llvm) that will transfer most of that
> overhead to installation time. At that point, Java isn't going to be much
> different than C++ from an execution perspective.
>
>
> On Sunday, May 11, 2014 1:41:41 PM UTC-5, 李白，字一日 wrote:
>
>> if it is not, why should you go native with c/c++ based ndk programming?
>>
>> it is surely related to the programming language.
>>
>> javascript 's speed acceleration is also related to the language and its
>> optimization, which is almost always c/c++.
>>
>> i have never experienced the fast feeling of java technology both in
>> desktop or server side.
>>
>> i never experienced fast  feeling in android, eclipse, java ee, j2me.  am
>> i fooled?
>>
>> eclipse is famous for it's slow and memory consuming, though it is the
>> greatest  ide i ever used.
>>
>> javascript based ide, like local compiled 
>> c9.iois
>>  very fast and responsive, thought it is not that mature.
>>
>> why ? ? ?
>>
>> and if android ui design can be written directly in html + css, it has
>> all the flexibility css and html have now. If you know the web
>> technologies, you should know what i mean.
>>
>> it is meaningless to discuss about the languages' performance, but the
>> trend is that javascript will play a more important role in server side
>> programming, hardware based programming and browser side programming.
>>
>>
>> 2014-05-12 1:03 GMT+08:00 Colin M :
>>
>> I'll ignore the unqualified claim that the slowness of Android is due to
>>> Java.
>>>
>>> It sounds like your complaint is that you can't develop native apps in
>>> your preferred language and that you're using an outdated claim about Java
>>> to support your desire to change the current language of choice for Android
>>> development.
>>>
>>> The XML based components can all be done via code.  Do you have an
>>> example of how they are "far from flexible"?  There are many limitations,
>>> but you are welcome to write your own custom Views to get around any
>>> limitations.  I have many of my own complaints about some of the UI system,
>>> but I have no reason to believe the current state of things would be faster
>>> or more flexible if it were in another language.  That's not the thing
>>> limiting flexibility or causing speed issues, that's more about the
>>> implementations.  I've created and seen many fast and fluid and complex UIs
>>> on Android, but you sometimes have to do some real work to get them and
>>> they don't always drop right out of the API in your lap :)  A better
>>> argument would be to single out issues with the UI libraries and talk about
>>> how to improve them.  This has little-to-nothing to do with implementation
>>> language.
>>>
>>> On Saturday, May 10, 2014 10:50:44 AM UTC-7, 李白，字一日 wrote:

 Java-based Android is very slow and memory consuming.
 and the XML based UI components are far from flexible.

 if Android sdk provides an html5  + javascript alternative, it would
 greatly improve the android  app possibilities.

 as we have seen more and more popular apps are written by html, css and
 javascript.

 i think it is a good time to provide a javascript based SDK,

 with a standardized Android UI framework like Twitter's bootstrap,
 every web developer can develope his app with ease.

 the webkit and v8 are every mature to google.

 why should we stille using java? which is slow and  memory consuming?



>>  --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To po

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

[Kristopher Micinski]

I don't get your point: Java needs a runtime. JavaScript needs a
runtime.  Both of them need runtimes.  He never said Dalvik was
"slow," but everything can be optimized.  Does native code run faster
than interpreted / JIT code?  Probably.  The *exact same thing* is
going to be an issue with JavaScript.

So really, what is JS buying you that Java cannot?

I'm pretty sure you're just trolling at this point, since nobody can
seriously have this opinion if they know anything about VM or system
design.

Kris


On Mon, May 12, 2014 at 1:02 AM, 李白|字一日  wrote:
> in effect, you are making the acknowledgement that java is slow and fat not
> just because of the dalvik.
>
> even with ART, there is no evidence that Java will be more efficient, though
> there may be some improvement.
>
>
>
>
> 2014-05-12 11:22 GMT+08:00 bjv :
>>
>> Ugh! You don't get it and likely never will. There are so many things
>> wrong with your assumptions/statements in all of these threads. It really
>> isn't worth the time to debunk them all.
>>
>> But for what its worth, there is small overhead with respect to running
>> Java/Dalvik on Android. That said, it is mostly upfront. JS is an
>> interpreted language. Outside of the various ASM-JS experiments, Your
>> html5+JS likely will always be interpreted. In a broad comparison, it will
>> almost always be slower. Your thinking that you get to share all those JS
>> object goodies between various apps/components is in itself a cause for
>> concern.
>>
>> In an effort to remove the Dalvik overhead on Android, the Android guys
>> are now rolling out ART (a variant of llvm) that will transfer most of that
>> overhead to installation time. At that point, Java isn't going to be much
>> different than C++ from an execution perspective.
>>
>>
>> On Sunday, May 11, 2014 1:41:41 PM UTC-5, 李白，字一日 wrote:
>>>
>>> if it is not, why should you go native with c/c++ based ndk programming?
>>>
>>> it is surely related to the programming language.
>>>
>>> javascript 's speed acceleration is also related to the language and its
>>> optimization, which is almost always c/c++.
>>>
>>> i have never experienced the fast feeling of java technology both in
>>> desktop or server side.
>>>
>>> i never experienced fast  feeling in android, eclipse, java ee, j2me.  am
>>> i fooled?
>>>
>>> eclipse is famous for it's slow and memory consuming, though it is the
>>> greatest  ide i ever used.
>>>
>>> javascript based ide, like local compiled c9.io is very fast and
>>> responsive, thought it is not that mature.
>>>
>>> why ? ? ?
>>>
>>> and if android ui design can be written directly in html + css, it has
>>> all the flexibility css and html have now. If you know the web technologies,
>>> you should know what i mean.
>>>
>>> it is meaningless to discuss about the languages' performance, but the
>>> trend is that javascript will play a more important role in server side
>>> programming, hardware based programming and browser side programming.
>>>
>>>
>>> 2014-05-12 1:03 GMT+08:00 Colin M :
>>>
 I'll ignore the unqualified claim that the slowness of Android is due to
 Java.

 It sounds like your complaint is that you can't develop native apps in
 your preferred language and that you're using an outdated claim about Java
 to support your desire to change the current language of choice for Android
 development.

 The XML based components can all be done via code.  Do you have an
 example of how they are "far from flexible"?  There are many limitations,
 but you are welcome to write your own custom Views to get around any
 limitations.  I have many of my own complaints about some of the UI system,
 but I have no reason to believe the current state of things would be faster
 or more flexible if it were in another language.  That's not the thing
 limiting flexibility or causing speed issues, that's more about the
 implementations.  I've created and seen many fast and fluid and complex UIs
 on Android, but you sometimes have to do some real work to get them and 
 they
 don't always drop right out of the API in your lap :)  A better argument
 would be to single out issues with the UI libraries and talk about how to
 improve them.  This has little-to-nothing to do with implementation
 language.

 On Saturday, May 10, 2014 10:50:44 AM UTC-7, 李白，字一日 wrote:
>
> Java-based Android is very slow and memory consuming.
> and the XML based UI components are far from flexible.
>
> if Android sdk provides an html5  + javascript alternative, it would
> greatly improve the android  app possibilities.
>
> as we have seen more and more popular apps are written by html, css and
> javascript.
>
> i think it is a good time to provide a javascript based SDK,
>
> with a standardized Android UI framework like Twitter's bootstrap,
> every web developer can develope his app with ease.
>
> the webkit and

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

[李白|字一日]

in effect, you are making the acknowledgement that java is slow and fat not
just because of the dalvik.

even with ART, there is no evidence that Java will be more efficient,
though there may be some improvement.




2014-05-12 11:22 GMT+08:00 bjv :

> Ugh! You don't get it and likely never will. There are so many things
> wrong with your assumptions/statements in all of these threads. It really
> isn't worth the time to debunk them all.
>
> But for what its worth, there is small overhead with respect to running
> Java/Dalvik on Android. That said, it is mostly upfront. JS is an
> interpreted language. Outside of the various ASM-JS experiments, Your
> html5+JS likely will always be interpreted. In a broad comparison, it will
> almost always be slower. Your thinking that you get to share all those JS
> object goodies between various apps/components is in itself a cause for
> concern.
>
> In an effort to remove the Dalvik overhead on Android, the Android guys
> are now rolling out ART (a variant of llvm) that will transfer most of that
> overhead to installation time. At that point, Java isn't going to be much
> different than C++ from an execution perspective.
>
>
> On Sunday, May 11, 2014 1:41:41 PM UTC-5, 李白，字一日 wrote:
>
>> if it is not, why should you go native with c/c++ based ndk programming?
>>
>> it is surely related to the programming language.
>>
>> javascript 's speed acceleration is also related to the language and its
>> optimization, which is almost always c/c++.
>>
>> i have never experienced the fast feeling of java technology both in
>> desktop or server side.
>>
>> i never experienced fast  feeling in android, eclipse, java ee, j2me.  am
>> i fooled?
>>
>> eclipse is famous for it's slow and memory consuming, though it is the
>> greatest  ide i ever used.
>>
>> javascript based ide, like local compiled 
>> c9.iois
>>  very fast and responsive, thought it is not that mature.
>>
>> why ? ? ?
>>
>> and if android ui design can be written directly in html + css, it has
>> all the flexibility css and html have now. If you know the web
>> technologies, you should know what i mean.
>>
>> it is meaningless to discuss about the languages' performance, but the
>> trend is that javascript will play a more important role in server side
>> programming, hardware based programming and browser side programming.
>>
>>
>> 2014-05-12 1:03 GMT+08:00 Colin M :
>>
>> I'll ignore the unqualified claim that the slowness of Android is due to
>>> Java.
>>>
>>> It sounds like your complaint is that you can't develop native apps in
>>> your preferred language and that you're using an outdated claim about Java
>>> to support your desire to change the current language of choice for Android
>>> development.
>>>
>>> The XML based components can all be done via code.  Do you have an
>>> example of how they are "far from flexible"?  There are many limitations,
>>> but you are welcome to write your own custom Views to get around any
>>> limitations.  I have many of my own complaints about some of the UI system,
>>> but I have no reason to believe the current state of things would be faster
>>> or more flexible if it were in another language.  That's not the thing
>>> limiting flexibility or causing speed issues, that's more about the
>>> implementations.  I've created and seen many fast and fluid and complex UIs
>>> on Android, but you sometimes have to do some real work to get them and
>>> they don't always drop right out of the API in your lap :)  A better
>>> argument would be to single out issues with the UI libraries and talk about
>>> how to improve them.  This has little-to-nothing to do with implementation
>>> language.
>>>
>>> On Saturday, May 10, 2014 10:50:44 AM UTC-7, 李白，字一日 wrote:

 Java-based Android is very slow and memory consuming.
 and the XML based UI components are far from flexible.

 if Android sdk provides an html5  + javascript alternative, it would
 greatly improve the android  app possibilities.

 as we have seen more and more popular apps are written by html, css and
 javascript.

 i think it is a good time to provide a javascript based SDK,

 with a standardized Android UI framework like Twitter's bootstrap,
 every web developer can develope his app with ease.

 the webkit and v8 are every mature to google.

 why should we stille using java? which is slow and  memory consuming?



>>  --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
> ---
> You received this message because you are subscribed 

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

[bjv]

Ugh! You don't get it and likely never will. There are so many things wrong 
with your assumptions/statements in all of these threads. It really isn't 
worth the time to debunk them all.

But for what its worth, there is small overhead with respect to running 
Java/Dalvik on Android. That said, it is mostly upfront. JS is an 
interpreted language. Outside of the various ASM-JS experiments, Your 
html5+JS likely will always be interpreted. In a broad comparison, it will 
almost always be slower. Your thinking that you get to share all those JS 
object goodies between various apps/components is in itself a cause for 
concern.

In an effort to remove the Dalvik overhead on Android, the Android guys are 
now rolling out ART (a variant of llvm) that will transfer most of that 
overhead to installation time. At that point, Java isn't going to be much 
different than C++ from an execution perspective.

On Sunday, May 11, 2014 1:41:41 PM UTC-5, 李白，字一日 wrote:
>
> if it is not, why should you go native with c/c++ based ndk programming?
>
> it is surely related to the programming language.
>
> javascript 's speed acceleration is also related to the language and its 
> optimization, which is almost always c/c++.
>
> i have never experienced the fast feeling of java technology both in 
> desktop or server side.
>
> i never experienced fast  feeling in android, eclipse, java ee, j2me.  am 
> i fooled?
>
> eclipse is famous for it's slow and memory consuming, though it is the 
> greatest  ide i ever used. 
>
> javascript based ide, like local compiled 
> c9.iois
>  very fast and responsive, thought it is not that mature.
>
> why ? ? ?
>
> and if android ui design can be written directly in html + css, it has all 
> the flexibility css and html have now. If you know the web technologies, 
> you should know what i mean.
>
> it is meaningless to discuss about the languages' performance, but the 
> trend is that javascript will play a more important role in server side 
> programming, hardware based programming and browser side programming.
>
>
> 2014-05-12 1:03 GMT+08:00 Colin M >:
>
>> I'll ignore the unqualified claim that the slowness of Android is due to 
>> Java.
>>
>> It sounds like your complaint is that you can't develop native apps in 
>> your preferred language and that you're using an outdated claim about Java 
>> to support your desire to change the current language of choice for Android 
>> development.
>>
>> The XML based components can all be done via code.  Do you have an 
>> example of how they are "far from flexible"?  There are many limitations, 
>> but you are welcome to write your own custom Views to get around any 
>> limitations.  I have many of my own complaints about some of the UI system, 
>> but I have no reason to believe the current state of things would be faster 
>> or more flexible if it were in another language.  That's not the thing 
>> limiting flexibility or causing speed issues, that's more about the 
>> implementations.  I've created and seen many fast and fluid and complex UIs 
>> on Android, but you sometimes have to do some real work to get them and 
>> they don't always drop right out of the API in your lap :)  A better 
>> argument would be to single out issues with the UI libraries and talk about 
>> how to improve them.  This has little-to-nothing to do with implementation 
>> language.
>>
>> On Saturday, May 10, 2014 10:50:44 AM UTC-7, 李白，字一日 wrote:
>>>
>>> Java-based Android is very slow and memory consuming.
>>> and the XML based UI components are far from flexible.
>>>
>>> if Android sdk provides an html5  + javascript alternative, it would 
>>> greatly improve the android  app possibilities.
>>>
>>> as we have seen more and more popular apps are written by html, css and 
>>> javascript.
>>>
>>> i think it is a good time to provide a javascript based SDK,
>>>
>>> with a standardized Android UI framework like Twitter's bootstrap, every 
>>> web developer can develope his app with ease.
>>>
>>> the webkit and v8 are every mature to google.
>>>
>>> why should we stille using java? which is slow and  memory consuming?
>>>
>>>
>>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] Digest for android-developers@googlegroups.com - 12 updates in 5 topics

[Narendrasingh Shekhawat]

On May 10, 2014 11:41 AM,  wrote:

>   Today's topic summary
>
> Group: http://groups.google.com/group/android-developers/topics
>
>- Handling touch events inside a 
> listview<#145e4c1adb00dd20_group_thread_0>[2 Updates]
>- Activity Back Stack and 
> OutOfMemoryError<#145e4c1adb00dd20_group_thread_1>[4 Updates]
>- override earphone click button <#145e4c1adb00dd20_group_thread_2> [2
>Updates]
>- Does the Android emulator run inside a 
> VM?<#145e4c1adb00dd20_group_thread_3>[3 Updates]
>- Alarm Intent not triggered <#145e4c1adb00dd20_group_thread_4> [1
>Update]
>
>   Handling touch events inside a 
> listview
>
>dashman  May 09 10:41AM -0700
>
>I've got custom views inside a listview.
>
>I've noticed that built-in widgets and other apps have a certain
>behavior.
>
>1. When an item is tapped (DOWN) to initiate a move - the item is not
>hi-lighted (the listview starts to scroll)
>
>2. When an item is held down for a little bit longer - then it's
>hi-lighted.
>
>3. Of course if it's a quick DOWN and UP - it's also hi-lighted.
>
>How can I get a similar behavior - notably the one in the 2nd entry
>above.
>
>I'm doing this with a custom view items in the listview.
>
>
>
>
>TreKing  May 09 01:07PM -0500
>
>
>> How can I get a similar behavior - notably the one in the 2nd entry
>above.
>
>> I'm doing this with a custom view items in the listview.
>
>Your view's background should be a state-list drawable that defines the
>drawables to use for the relevant states.
>
>
>
> -
>TreKing  - Chicago
>transit tracking app for Android-powered devices
>
>
>
>   Activity Back Stack and 
> OutOfMemoryError
>
>Daniel Rindt  May 09 02:59PM +0200
>
>> Are you absolutely sure that your code does not leak memory?
>
>How to be "absolutely sure". :-) Just kidding.
>
>> Have you tried using Eclipse MAT and putting the app through the
>usual
>> paces, like rotating the screen, pausing / restarting, etc.?
>
>This i have done:
>* app started, before killed
>* dump hprof and load with mat (leak suspects)
>* rotate, rotate, rotate...
>* dump hprof again load with mat (leak suspects)
>
>i compared the mat reports with the suspects and i see no differences
>in the
>"leak suspects report". Which sould differ in the occupied size when i
>am not
>wrong?
>
>> You'd mentioned the app being heavy on image processing -- is your
>memory
>> allocation strategy based on how much memory your app's process
>gets? You
>> can use ActivityManager#getMemoryClass for that.
>
>Actually i am aware of this complicated and consequences so i use the
>universal image loader which is configured to scale the images exact
>in the
>bitmap which cost cpu time, but preserves memory.
>
>> Runtime.getRuntime().totalMemory()
>> Runtime.getRuntime().freeMemory()
>> ActivityManager.getMemoryClass()
>
>I am new to the memory thing, and it doesn't happen a lot. It happens
>mostly on a rare ressource device. But question again starting lots of
>activities
>where you can go back should not be the issue? If the activity itself
>isn't leaking
>anything it can be gc'ed? The backstack just fire the intent again?
>
>
>
>
>Kostya Vasilyev  May 09 05:53PM +0400
>
>> "leak suspects report". Which sould differ in the occupied size when
>i am
>> not
>> wrong?
>
>Well, personally, I usually use the object histogram at the starting
>point
>-- filtered by my app's package.
>
>When I see something that looks strange, I right click on a object
>class
>and do "merge shortest paths to object roots" to investigate.
>
>That's just me -- I've not used "leak suspects" -- but maybe you'd be
>able
>to see something interesting in the histogram?
>
>
>
>> Actually i am aware of this complicated and consequences so i use the
>> universal image loader which is configured to scale the images exact
>in the
>> bitmap which cost cpu time, but preserves memory.
>
>That's a well known library, but I guess it still needs to be
>configured in
>a way that makes sense for your app's flow.
>
>
>> > ActivityManager.getMemoryClass()
>
>> I am new to the memory thing, and it doesn't happen a lot. It happens
>> mostly on a rare ressource device.
>
>
>You can create an emulator image with lowered per-process memory
>quotas.
>Don't know if it actually works the way it's supposed to, but the
>setting
>is there.
>
>
>> where you can go back should not be the issue? If the activity

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

[Kristopher Micinski]

Everything you are saying here is

"I have heard Java is slow, and that's what is probably making Android
slow!  Here's an example of some things I think are slow because of
Java.  Now I'm going to apply this as evidence to the entire Android
platform to show why Java must be slow on it."

Please stop, this is 100% uninformed.

If you want to come back with any kind of solid performance numbers
reinforcing your points it might make sense, but it seems like all
you're doing is trying to say that Java is slow, and that somehow
JavaScript would be faster.  This really doesn't make any sense at
all, and it's silly to try to keep on arguing with absolutely no
empirical evidence to justify any of the claims you're making.

Kris


On Sun, May 11, 2014 at 2:41 PM, 李白|字一日  wrote:
> if it is not, why should you go native with c/c++ based ndk programming?
>
> it is surely related to the programming language.
>
> javascript 's speed acceleration is also related to the language and its
> optimization, which is almost always c/c++.
>
> i have never experienced the fast feeling of java technology both in desktop
> or server side.
>
> i never experienced fast  feeling in android, eclipse, java ee, j2me.  am i
> fooled?
>
> eclipse is famous for it's slow and memory consuming, though it is the
> greatest  ide i ever used.
>
> javascript based ide, like local compiled c9.io is very fast and responsive,
> thought it is not that mature.
>
> why ? ? ?
>
> and if android ui design can be written directly in html + css, it has all
> the flexibility css and html have now. If you know the web technologies, you
> should know what i mean.
>
> it is meaningless to discuss about the languages' performance, but the trend
> is that javascript will play a more important role in server side
> programming, hardware based programming and browser side programming.
>
>
> 2014-05-12 1:03 GMT+08:00 Colin M :
>>
>> I'll ignore the unqualified claim that the slowness of Android is due to
>> Java.
>>
>> It sounds like your complaint is that you can't develop native apps in
>> your preferred language and that you're using an outdated claim about Java
>> to support your desire to change the current language of choice for Android
>> development.
>>
>> The XML based components can all be done via code.  Do you have an example
>> of how they are "far from flexible"?  There are many limitations, but you
>> are welcome to write your own custom Views to get around any limitations.  I
>> have many of my own complaints about some of the UI system, but I have no
>> reason to believe the current state of things would be faster or more
>> flexible if it were in another language.  That's not the thing limiting
>> flexibility or causing speed issues, that's more about the implementations.
>> I've created and seen many fast and fluid and complex UIs on Android, but
>> you sometimes have to do some real work to get them and they don't always
>> drop right out of the API in your lap :)  A better argument would be to
>> single out issues with the UI libraries and talk about how to improve them.
>> This has little-to-nothing to do with implementation language.
>>
>> On Saturday, May 10, 2014 10:50:44 AM UTC-7, 李白，字一日 wrote:
>>>
>>> Java-based Android is very slow and memory consuming.
>>> and the XML based UI components are far from flexible.
>>>
>>> if Android sdk provides an html5  + javascript alternative, it would
>>> greatly improve the android  app possibilities.
>>>
>>> as we have seen more and more popular apps are written by html, css and
>>> javascript.
>>>
>>> i think it is a good time to provide a javascript based SDK,
>>>
>>> with a standardized Android UI framework like Twitter's bootstrap, every
>>> web developer can develope his app with ease.
>>>
>>> the webkit and v8 are every mature to google.
>>>
>>> why should we stille using java? which is slow and  memory consuming?
>>>
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Android Developers" group.
>> To post to this group, send email to android-developers@googlegroups.com
>> To unsubscribe from this group, send email to
>> android-developers+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/android-developers?hl=en
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Android Developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/android-developers/4UrtNOPympc/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> android-developers+unsubscr...@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+u

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

[李白|字一日]

if it is not, why should you go native with c/c++ based ndk programming?

it is surely related to the programming language.

javascript 's speed acceleration is also related to the language and its
optimization, which is almost always c/c++.

i have never experienced the fast feeling of java technology both in
desktop or server side.

i never experienced fast  feeling in android, eclipse, java ee, j2me.  am i
fooled?

eclipse is famous for it's slow and memory consuming, though it is the
greatest  ide i ever used.

javascript based ide, like local compiled c9.io is very fast and
responsive, thought it is not that mature.

why ? ? ?

and if android ui design can be written directly in html + css, it has all
the flexibility css and html have now. If you know the web technologies,
you should know what i mean.

it is meaningless to discuss about the languages' performance, but the
trend is that javascript will play a more important role in server side
programming, hardware based programming and browser side programming.


2014-05-12 1:03 GMT+08:00 Colin M :

> I'll ignore the unqualified claim that the slowness of Android is due to
> Java.
>
> It sounds like your complaint is that you can't develop native apps in
> your preferred language and that you're using an outdated claim about Java
> to support your desire to change the current language of choice for Android
> development.
>
> The XML based components can all be done via code.  Do you have an example
> of how they are "far from flexible"?  There are many limitations, but you
> are welcome to write your own custom Views to get around any limitations.
>  I have many of my own complaints about some of the UI system, but I have
> no reason to believe the current state of things would be faster or more
> flexible if it were in another language.  That's not the thing limiting
> flexibility or causing speed issues, that's more about the implementations.
>  I've created and seen many fast and fluid and complex UIs on Android, but
> you sometimes have to do some real work to get them and they don't always
> drop right out of the API in your lap :)  A better argument would be to
> single out issues with the UI libraries and talk about how to improve them.
>  This has little-to-nothing to do with implementation language.
>
> On Saturday, May 10, 2014 10:50:44 AM UTC-7, 李白，字一日 wrote:
>>
>> Java-based Android is very slow and memory consuming.
>> and the XML based UI components are far from flexible.
>>
>> if Android sdk provides an html5  + javascript alternative, it would
>> greatly improve the android  app possibilities.
>>
>> as we have seen more and more popular apps are written by html, css and
>> javascript.
>>
>> i think it is a good time to provide a javascript based SDK,
>>
>> with a standardized Android UI framework like Twitter's bootstrap, every
>> web developer can develope his app with ease.
>>
>> the webkit and v8 are every mature to google.
>>
>> why should we stille using java? which is slow and  memory consuming?
>>
>>
>>
>>  --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Android Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/android-developers/4UrtNOPympc/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> android-developers+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: looking for HTML5 and javascript based sdk....

[Colin M]

I'll ignore the unqualified claim that the slowness of Android is due to 
Java.

It sounds like your complaint is that you can't develop native apps in your 
preferred language and that you're using an outdated claim about Java to 
support your desire to change the current language of choice for Android 
development.

The XML based components can all be done via code.  Do you have an example 
of how they are "far from flexible"?  There are many limitations, but you 
are welcome to write your own custom Views to get around any limitations. 
 I have many of my own complaints about some of the UI system, but I have 
no reason to believe the current state of things would be faster or more 
flexible if it were in another language.  That's not the thing limiting 
flexibility or causing speed issues, that's more about the implementations. 
 I've created and seen many fast and fluid and complex UIs on Android, but 
you sometimes have to do some real work to get them and they don't always 
drop right out of the API in your lap :)  A better argument would be to 
single out issues with the UI libraries and talk about how to improve them. 
 This has little-to-nothing to do with implementation language.

On Saturday, May 10, 2014 10:50:44 AM UTC-7, 李白，字一日 wrote:
>
> Java-based Android is very slow and memory consuming.
> and the XML based UI components are far from flexible.
>
> if Android sdk provides an html5  + javascript alternative, it would 
> greatly improve the android  app possibilities.
>
> as we have seen more and more popular apps are written by html, css and 
> javascript.
>
> i think it is a good time to provide a javascript based SDK,
>
> with a standardized Android UI framework like Twitter's bootstrap, every 
> web developer can develope his app with ease.
>
> the webkit and v8 are every mature to google.
>
> why should we stille using java? which is slow and  memory consuming?
>
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] looking for HTML5 and javascript based sdk....

[Colin M]

Some operations are faster in Java these days, _most_ are functionally 
equal, and a few special cases (not relevant to most developers), C++ is a 
better choice.  Making the blanket "Java is slow" statement is just 
factually wrong today.  Can we move on from 1992, please?

I'd add to your last statement and say:

Write it in the supported platform and verify your assumptions that it is 
too slow, then see how you can optimize from there on that platform, and 
then if all that fails, try something custom.

http://c2.com/cgi/wiki?PrematureOptimization

On Sunday, May 11, 2014 7:40:37 AM UTC-7, Larry Meadors wrote:
>
> If you're thinking Java is slow on a desktop compared to c++, you're 
> right - it is. 
>
> But Android doesn't actually run Java. :-| 
>
> You write code using the Java language. It's compiled into Java bytecode. 
>
> That bytecode is then processed again to create Dalvik dex files for 
> Android. Dalvik is "designed to be suitable for systems that are 
> constrained in terms of memory and processor speed". 
>
> http://en.wikipedia.org/wiki/Dalvik_(software) 
>
> Your question is analogous to "Are trains better than boats?" If you 
> need to go across a desert, a train is far superior. If you need to go 
> across an ocean...not so much. 
>
> If you're trying to decide which way to go, your best bet is to try 
> both and see. 
>
> It really depends on what you are doing. 
>
> Larry 
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] looking for HTML5 and javascript based sdk....

[李白|字一日]

javascript is not java, which doesn't necesarily need a vm. It is dynamic,
but not a vm based language


2014-05-12 0:34 GMT+08:00 李白|字一日 :

> please have a look at this.
> http://www.reddit.com/comments/1jw6h7
>
> seems dalvik is slower.
>
> 2014-05-11 22:28 GMT+08:00 Kristopher Micinski :
>
> First of all, this is just downright false, JS *will* be slower than
>> Java, but I'll address each of your points.
>>
>> On Sun, May 11, 2014 at 12:51 AM, 李白|字一日  wrote:
>> > thanks for the reply.
>> >
>> > but i may think differently.
>> >
>> > javascript runtime can be shared, and no new memory allocation and
>> memory
>> > copying required, only the apps require new memories when running.
>>
>> The Android runtime is also shared, common memory pages are mapped
>> between processes.  This is the idea behind the "zygote" process,
>> which loads the VM in an initial process and then forks off new
>> processes, and due to copy on write (among other things) the VM is
>> never copied.
>>
>> Apps only require the new memory they need.  You can't just slam them
>> all together in the same process, because that will completely destroy
>> security and that will never happen.  By the way, the same thing
>> exists in JavaScript for multiple JavaScript tabs.
>
>
>> > but the android vm is not, at least you should allocation memory for
>> > inter-media code files like .class files.
>> > then allocate new memory for the vm and then allocate for the app.
>>
>> As I said, you don't allocate any new memory for the VM because of the
>> zygote.  You have to allocate pages to keep track of the code, but you
>> also do this with JS, but it's way worse because you need extra stuff
>> to do all the data structures for interpretation / JIT.
>>
>> > for java multi-threading, you may need extra memory to providing more
>> stacks
>> > and extra execution on how to coordinating the threads.
>> >
>> > but javascript may need only one thread, and no threads switching
>> needed, it
>> > is event based.
>>
>> You'll still need threads in JavaScript to make anything efficient.
>
>
>> > webkit and javascript event model is native implemented (using c/c++)
>> and vm
>> > free, while java sdk is compiled in java code and interpreted to native.
>>
>> There are open source Java compilers.  AOSP is open source.
>>
>> > html and javascript files are translated to native code or natived
>> > implemented interpretors when loaded.
>>
>> The same thing happens right now.
>>
>> > so i think java is by no means faster than javascript, especially when
>> you
>> > have very complicated interactions.
>>
>> It's up for debate, but your arguments for it don't show this.
>>
>> There are tricks to make this work,
>> http://en.wikipedia.org/wiki/Firefox_OS does them.
>>
>> However, JS doesn't have any inherent performance advantages over
>> Java: it's slower if implemented badly.
>>
>> > From all the above, i would like to say that javascript is easy and
>> fast to
>> > load and run, while java is slow to load and run.
>> > if that is true, i think that is the great performance gain.
>> >
>> > java server side is fast in that java programs have loaded and they are
>> all
>> > in memory and servers always provide large memory spaces, we can ignore
>> the
>> > loading and rebooting time it requires, but android is not for server
>> side
>> > programming, it may not have large memory space for too many apps and
>> users
>> > don't have patient to wait too long for starting a new app.
>>
>> Many apps are compiled natively or with a JIT, this is the exact same
>> as JavaScript.
>>
>> Kris
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Android Developers" group.
>> To post to this group, send email to android-developers@googlegroups.com
>> To unsubscribe from this group, send email to
>> android-developers+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/android-developers?hl=en
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Android Developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/android-developers/4UrtNOPympc/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> android-developers+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-deve

Re: [android-developers] looking for HTML5 and javascript based sdk....

[李白|字一日]

please have a look at this.
http://www.reddit.com/comments/1jw6h7

seems dalvik is slower.

2014-05-11 22:28 GMT+08:00 Kristopher Micinski :

> First of all, this is just downright false, JS *will* be slower than
> Java, but I'll address each of your points.
>
> On Sun, May 11, 2014 at 12:51 AM, 李白|字一日  wrote:
> > thanks for the reply.
> >
> > but i may think differently.
> >
> > javascript runtime can be shared, and no new memory allocation and memory
> > copying required, only the apps require new memories when running.
>
> The Android runtime is also shared, common memory pages are mapped
> between processes.  This is the idea behind the "zygote" process,
> which loads the VM in an initial process and then forks off new
> processes, and due to copy on write (among other things) the VM is
> never copied.
>
> Apps only require the new memory they need.  You can't just slam them
> all together in the same process, because that will completely destroy
> security and that will never happen.  By the way, the same thing
> exists in JavaScript for multiple JavaScript tabs.


> > but the android vm is not, at least you should allocation memory for
> > inter-media code files like .class files.
> > then allocate new memory for the vm and then allocate for the app.
>
> As I said, you don't allocate any new memory for the VM because of the
> zygote.  You have to allocate pages to keep track of the code, but you
> also do this with JS, but it's way worse because you need extra stuff
> to do all the data structures for interpretation / JIT.
>
> > for java multi-threading, you may need extra memory to providing more
> stacks
> > and extra execution on how to coordinating the threads.
> >
> > but javascript may need only one thread, and no threads switching
> needed, it
> > is event based.
>
> You'll still need threads in JavaScript to make anything efficient.


> > webkit and javascript event model is native implemented (using c/c++)
> and vm
> > free, while java sdk is compiled in java code and interpreted to native.
>
> There are open source Java compilers.  AOSP is open source.
>
> > html and javascript files are translated to native code or natived
> > implemented interpretors when loaded.
>
> The same thing happens right now.
>
> > so i think java is by no means faster than javascript, especially when
> you
> > have very complicated interactions.
>
> It's up for debate, but your arguments for it don't show this.
>
> There are tricks to make this work,
> http://en.wikipedia.org/wiki/Firefox_OS does them.
>
> However, JS doesn't have any inherent performance advantages over
> Java: it's slower if implemented badly.
>
> > From all the above, i would like to say that javascript is easy and fast
> to
> > load and run, while java is slow to load and run.
> > if that is true, i think that is the great performance gain.
> >
> > java server side is fast in that java programs have loaded and they are
> all
> > in memory and servers always provide large memory spaces, we can ignore
> the
> > loading and rebooting time it requires, but android is not for server
> side
> > programming, it may not have large memory space for too many apps and
> users
> > don't have patient to wait too long for starting a new app.
>
> Many apps are compiled natively or with a JIT, this is the exact same
> as JavaScript.
>
> Kris
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Android Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/android-developers/4UrtNOPympc/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> android-developers+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] looking for HTML5 and javascript based sdk....

[Larry Meadors]

If you're thinking Java is slow on a desktop compared to c++, you're
right - it is.

But Android doesn't actually run Java. :-|

You write code using the Java language. It's compiled into Java bytecode.

That bytecode is then processed again to create Dalvik dex files for
Android. Dalvik is "designed to be suitable for systems that are
constrained in terms of memory and processor speed".

http://en.wikipedia.org/wiki/Dalvik_(software)

Your question is analogous to "Are trains better than boats?" If you
need to go across a desert, a train is far superior. If you need to go
across an ocean...not so much.

If you're trying to decide which way to go, your best bet is to try
both and see.

It really depends on what you are doing.

Larry

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] looking for HTML5 and javascript based sdk....

[Kristopher Micinski]

First of all, this is just downright false, JS *will* be slower than
Java, but I'll address each of your points.

On Sun, May 11, 2014 at 12:51 AM, 李白|字一日  wrote:
> thanks for the reply.
>
> but i may think differently.
>
> javascript runtime can be shared, and no new memory allocation and memory
> copying required, only the apps require new memories when running.

The Android runtime is also shared, common memory pages are mapped
between processes.  This is the idea behind the "zygote" process,
which loads the VM in an initial process and then forks off new
processes, and due to copy on write (among other things) the VM is
never copied.

Apps only require the new memory they need.  You can't just slam them
all together in the same process, because that will completely destroy
security and that will never happen.  By the way, the same thing
exists in JavaScript for multiple JavaScript tabs.

> but the android vm is not, at least you should allocation memory for
> inter-media code files like .class files.
> then allocate new memory for the vm and then allocate for the app.

As I said, you don't allocate any new memory for the VM because of the
zygote.  You have to allocate pages to keep track of the code, but you
also do this with JS, but it's way worse because you need extra stuff
to do all the data structures for interpretation / JIT.

> for java multi-threading, you may need extra memory to providing more stacks
> and extra execution on how to coordinating the threads.
>
> but javascript may need only one thread, and no threads switching needed, it
> is event based.

You'll still need threads in JavaScript to make anything efficient.

> webkit and javascript event model is native implemented (using c/c++) and vm
> free, while java sdk is compiled in java code and interpreted to native.

There are open source Java compilers.  AOSP is open source.

> html and javascript files are translated to native code or natived
> implemented interpretors when loaded.

The same thing happens right now.

> so i think java is by no means faster than javascript, especially when you
> have very complicated interactions.

It's up for debate, but your arguments for it don't show this.

There are tricks to make this work,
http://en.wikipedia.org/wiki/Firefox_OS does them.

However, JS doesn't have any inherent performance advantages over
Java: it's slower if implemented badly.

> From all the above, i would like to say that javascript is easy and fast to
> load and run, while java is slow to load and run.
> if that is true, i think that is the great performance gain.
>
> java server side is fast in that java programs have loaded and they are all
> in memory and servers always provide large memory spaces, we can ignore the
> loading and rebooting time it requires, but android is not for server side
> programming, it may not have large memory space for too many apps and users
> don't have patient to wait too long for starting a new app.

Many apps are compiled natively or with a JIT, this is the exact same
as JavaScript.

Kris

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] RelativeLayout issue

[dashman]

But isn't the logical parent of the child - it's layout parent.

in that i've set the width explicitly.



On Sunday, May 11, 2014 9:12:00 AM UTC-4, Kostya Vasilyev wrote:
>
> Yep: a child with alignParentRight / alignParentBottom will cause the 
> parent (the RelativeLayout) to stretch to the entire width / height of 
> *its* parent.
>
> -- K
>
>
> 2014-05-11 17:05 GMT+04:00 Piren >:
>
>> I've come across something like that before. RelativeLayouts do not like 
>> their children doing something like that (or asking to be aligned to the 
>> right/bottom). 
>>
>> Just use a size variable for both the parent and child (see 
>> dimensions.xml), will save you the headache understanding android's layout 
>> mechanism. 
>>
>>
>> On Sunday, May 11, 2014 3:37:09 PM UTC+3, dashman wrote:
>>>
>>> android:layout_alignParentLeft="true"
>>> android:layout_alignParentRight="true"
>>>
>>>
>>> No changes - still the full width of the parent View (not layout)
>>>
>>>
>>>
>>> On Saturday, May 10, 2014 9:06:10 PM UTC-4, TreKing wrote:


 On Sat, May 10, 2014 at 6:57 PM, dashman  wrote:

> Shouldn't the width of the button be 60dp - 
> since i've set the width of the button to match-parent - and it's set 
> to 60dp in the layout.
>
> It's actually taking up the full width of the parent view - not layout.
>

 You'd think, right?

 To achieve what you're looking for, try setting both align_parentLeft 
 and align_parentRight

 
 -
 TreKing  - Chicago 
 transit tracking app for Android-powered devices
  
>>>  -- 
>> You received this message because you are subscribed to the Google
>> Groups "Android Developers" group.
>> To post to this group, send email to 
>> android-d...@googlegroups.com
>> To unsubscribe from this group, send email to
>> android-developers+unsubscr...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/android-developers?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Android Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to android-developers+unsubscr...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] Re: Activity Back Stack and OutOfMemoryError

[Daniel Rindt]

2014-05-11 14:00 GMT+02:00 Piren :
> Android has this particular annoying and weird behavior: Once the heap
> inflates to a certain size, no matter how much of it is actually used, you
> can no longer allocate files that are larger than the remaining memory.
> my guess, you're there.
>
> you should make sure your previous activities use as little memory as
> possible and make it a habit of unloading memory which might not be
> necessary once activities are changed.  This is especially true in apps that
> store large bitmaps and even more noticeable if you also have lots of small
> objects (memory fragmentation + large bitmaps = OOM exceptions)

I have inspected the code as Kostya mentioned, and i haven't seen anything
what looks like a leak, all the memory was released after causing a gc manually.
And i carefully checked every activity and its fragments.

I only come to the conclusion that what you said must be the case i
have no other
answer for that. So will change the behavior of opening lots of
activities. But in future
it should be wise considered in the concept.

Thank you for all readers and who respond.
Daniel

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] RelativeLayout issue

[Kostya Vasilyev]

Yep: a child with alignParentRight / alignParentBottom will cause the
parent (the RelativeLayout) to stretch to the entire width / height of
*its* parent.

-- K


2014-05-11 17:05 GMT+04:00 Piren :

> I've come across something like that before. RelativeLayouts do not like
> their children doing something like that (or asking to be aligned to the
> right/bottom).
>
> Just use a size variable for both the parent and child (see
> dimensions.xml), will save you the headache understanding android's layout
> mechanism.
>
>
> On Sunday, May 11, 2014 3:37:09 PM UTC+3, dashman wrote:
>>
>> android:layout_alignParentLeft="true"
>> android:layout_alignParentRight="true"
>>
>>
>> No changes - still the full width of the parent View (not layout)
>>
>>
>>
>> On Saturday, May 10, 2014 9:06:10 PM UTC-4, TreKing wrote:
>>>
>>>
>>> On Sat, May 10, 2014 at 6:57 PM, dashman  wrote:
>>>
 Shouldn't the width of the button be 60dp -
 since i've set the width of the button to match-parent - and it's set
 to 60dp in the layout.

 It's actually taking up the full width of the parent view - not layout.

>>>
>>> You'd think, right?
>>>
>>> To achieve what you're looking for, try setting both align_parentLeft
>>> and align_parentRight
>>>
>>> 
>>> -
>>> TreKing  - Chicago
>>> transit tracking app for Android-powered devices
>>>
>>  --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Android Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-developers+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] RelativeLayout issue

[Piren]

I've come across something like that before. RelativeLayouts do not like 
their children doing something like that (or asking to be aligned to the 
right/bottom). 

Just use a size variable for both the parent and child (see 
dimensions.xml), will save you the headache understanding android's layout 
mechanism. 

On Sunday, May 11, 2014 3:37:09 PM UTC+3, dashman wrote:
>
> android:layout_alignParentLeft="true"
> android:layout_alignParentRight="true"
>
>
> No changes - still the full width of the parent View (not layout)
>
>
>
> On Saturday, May 10, 2014 9:06:10 PM UTC-4, TreKing wrote:
>>
>>
>> On Sat, May 10, 2014 at 6:57 PM, dashman  wrote:
>>
>>> Shouldn't the width of the button be 60dp - 
>>> since i've set the width of the button to match-parent - and it's set to 
>>> 60dp in the layout.
>>>
>>> It's actually taking up the full width of the parent view - not layout.
>>>
>>
>> You'd think, right?
>>
>> To achieve what you're looking for, try setting both align_parentLeft and 
>> align_parentRight
>>
>>
>> -
>> TreKing  - Chicago 
>> transit tracking app for Android-powered devices
>>  
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] RelativeLayout issue

[dashman]

android:layout_alignParentLeft="true"
android:layout_alignParentRight="true"


No changes - still the full width of the parent View (not layout)



On Saturday, May 10, 2014 9:06:10 PM UTC-4, TreKing wrote:
>
>
> On Sat, May 10, 2014 at 6:57 PM, dashman  >wrote:
>
>> Shouldn't the width of the button be 60dp - 
>> since i've set the width of the button to match-parent - and it's set to 
>> 60dp in the layout.
>>
>> It's actually taking up the full width of the parent view - not layout.
>>
>
> You'd think, right?
>
> To achieve what you're looking for, try setting both align_parentLeft and 
> align_parentRight
>
>
> -
> TreKing  - Chicago 
> transit tracking app for Android-powered devices
>  

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: Activity Back Stack and OutOfMemoryError

[Piren]

Android has this particular annoying and weird behavior: Once the heap 
inflates to a certain size, no matter how much of it is actually used, you 
can no longer allocate files that are larger than the remaining memory.
my guess, you're there.

you should make sure your previous activities use as little memory as 
possible and make it a habit of unloading memory which might not 
be necessary once activities are changed.  This is especially true in apps 
that store large bitmaps and even more noticeable if you also have lots of 
small objects (memory fragmentation + large bitmaps = OOM exceptions)


On Thursday, May 8, 2014 5:47:06 PM UTC+3, Daniel Rindt wrote:
>
> Hello,
>
> in the application we open a chooser for selecting photos. I got 
> frequently crashes mostly from sony by doing this which says: 
> OutOfMemoryError which raises by showing the bitmaps. The stacktrace which 
> the
> system creates doesn't mention a class of our code which confuses me a bit.
> My assumption is that our app can open lots of activities and by opening 
> the image choose there is not much space left and the crash happen. So far 
> i read i shouldn't care about do finish(); and activity they
> can remain in the activity backstack. It would be great to get a bit more 
> clued.
> Here is the stacktrace i got:
>
> Package: com.viselabs.aquariummanager
> Version Code: 34
> Version Name: 0.16.34.g3cc9d12
> Android: 4.3
> Manufacturer: samsung
> Model: SPH-L710
> Date: Thu May 08 09:13:04 EDT 2014
>
> java.lang.RuntimeException: Unable to start activity 
> ComponentInfo{android/com.android.internal.app.ChooserActivity}: 
> android.view.InflateException: Binary XML file line #26: Error inflating 
> class 
>   at 
> android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2305)
>   at 
> android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2359)
>   at android.app.ActivityThread.access$700(ActivityThread.java:165)
>   at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1326)
>   at android.os.Handler.dispatchMessage(Handler.java:99)
>   at android.os.Looper.loop(Looper.java:137)
>   at android.app.ActivityThread.main(ActivityThread.java:5455)
>   at java.lang.reflect.Method.invokeNative(Native Method)
>   at java.lang.reflect.Method.invoke(Method.java:525)
>   at 
> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1187)
>   at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
>   at dalvik.system.NativeStart.main(Native Method)
> Caused by: android.view.InflateException: Binary XML file line #26: Error 
> inflating class 
>   at android.view.LayoutInflater.createView(LayoutInflater.java:626)
>   at 
> com.android.internal.policy.impl.PhoneLayoutInflater.onCreateView(PhoneLayoutInflater.java:56)
>   at android.view.LayoutInflater.onCreateView(LayoutInflater.java:675)
>   at 
> android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:700)
>   at android.view.LayoutInflater.rInflate(LayoutInflater.java:761)
>   at android.view.LayoutInflater.rInflate(LayoutInflater.java:769)
>   at android.view.LayoutInflater.inflate(LayoutInflater.java:498)
>   at android.view.LayoutInflater.inflate(LayoutInflater.java:398)
>   at android.view.LayoutInflater.inflate(LayoutInflater.java:354)
>   at 
> com.android.internal.app.ResolverActivity.onCreate(ResolverActivity.java:210)
>   at 
> com.android.internal.app.ChooserActivity.onCreate(ChooserActivity.java:69)
>   at android.app.Activity.performCreate(Activity.java:5372)
>   at 
> android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1104)
>   at 
> android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2267)
>   ... 11 more
> Caused by: java.lang.reflect.InvocationTargetException
>   at java.lang.reflect.Constructor.constructNative(Native Method)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:417)
>   at android.view.LayoutInflater.createView(LayoutInflater.java:600)
>   ... 24 more
> Caused by: java.lang.OutOfMemoryError
>   at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)
>   at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:596)
>   at 
> android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:444)
>   at 
> android.graphics.drawable.Drawable.createFromResourceStream(Drawable.java:832)
>   at android.content.res.Resources.loadDrawable(Resources.java:2988)
>   at android.content.res.Resources.getDrawable(Resources.java:1558)
>   at android.widget.EdgeEffect.(EdgeEffect.java:148)
>   at android.widget.AbsListView.setOverScrollMode(AbsListView.java:1220)
>   at android.view.View.(View.java:3458)
>   at android.view.View.(View.java:3528)
>   at android.view.ViewGroup.(ViewGroup.java:475)
>   at android.widget.AdapterView.(AdapterView.java:236)
>