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
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 erjd...@gmail.com
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
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 gpi...@gmail.com:
I've come across something like that before. RelativeLayouts do not like
their
2014-05-11 14:00 GMT+02:00 Piren gpi...@gmail.com:
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.
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
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, 李白|字一日 calid...@gmail.com wrote:
thanks for the reply.
but i may think differently.
javascript runtime can be shared, and no new memory
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
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 krismicin...@gmail.com:
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,
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 李白|字一日 calid...@gmail.com:
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
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
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
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
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
On May 10, 2014 11:41 AM, android-developers@googlegroups.com 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
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
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 bjvet...@gmail.com:
Ugh! You don't get it and
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
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.
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
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
21 matches
Mail list logo
