Taylor mentioned that he is programming in Java. The SDK you mentioned is
using C++ and Lua AFAIK and therefore does IMO not really fit.
Cheers
Am Mittwoch, 20. März 2013 23:27:20 UTC+1 schrieb Nathan:
A member of this forum works on
http://www.batterytechsdk.com/
Haven't used it yet.
Can you briefly explain why join() is supposed to be so bad to best almost
never use it?
--
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
Hi,
in my game I am checking the size of the SurfaceView in the
surfaceChanged method. Now with the latest SDK for Android 4.0 the
emulator reports incorrect size values, e.g. it reports 1280 x 720
pixels for a device with HVGA screen, where it should list 480x320
pixels, and 1425 x 720 pixels
Yes and no. In the developer console the ratings look fine now. In the
market app the wrong numbers still appear. But I hope that, with only
a short delay, these number will also be fine.
On 1 Aug., 19:05, pad e.pad...@gmail.com wrote:
Seems to be fixed!
On 1 Ago, 13:31, kodlan
Yes, I am having the same issue. But now changed ratings affected by
this bug are also visible on the market :-(.
On 30 Jul., 06:51, Nikolay Elenkov nikolay.elen...@gmail.com wrote:
This is new: woke up to find that the number of ratings is a few hundred
less
than the day before. And that's
+1 for ActionBar support in the compat library. ActionBarSherlock is
certainly nice, but for those who - like me - don't use Eclipse it is
not so good that it requires using a library project instead of a jar
library.
On 16 Jul., 12:34, b0b pujos.mich...@gmail.com wrote:
I would really like to
Did you set the filter parameter to true when invoking
createScaledBitmap? AFAIK it does the same as setting
Paint.FILTER_BITMAP_FLAG when otherwise painting bitmaps. This should
enable what you call antialiasing when scaling down the bitmaps.
Hope this helps
On 15 Mai, 11:05, FReDD ---
On 17 Jan., 21:21, Romain Guy romain...@android.com wrote:
Quick update:
Android 3.0 will give you the ability to load mutable bitmaps from
BitmapFactory. The API relies on BitmapFactory.Options, and a new field call
inMutable. While I'm at it, know that we've added another API to
That inBitmap option sounds great. Thanks for that :-).
On 17 Jan., 21:21, Romain Guy romain...@android.com wrote:
Quick update:
Android 3.0 will give you the ability to load mutable bitmaps from
BitmapFactory. The API relies on BitmapFactory.Options, and a new field call
inMutable. While
On 9 Dez., 14:20, Mark Murphy mmur...@commonsware.com wrote:
On Thu, Dec 9, 2010 at 3:50 AM, Ecthelion ep...@joergjahnke.de wrote:
Brilliant. But that essentially means that I cannot be 100% sure that
my changes would not cause undesired side effects.
You can't be 100% sure of anything
On 8 Dez., 20:52, Mark Murphy mmur...@commonsware.com wrote:
On Wed, Dec 8, 2010 at 2:40 PM, Ecthelion ep...@joergjahnke.de wrote:
But if I should find one of these resource names
thereby, how will I know whether the code inside the library relies on
the old string format or whether
On 7 Dez., 16:39, Mark Murphy mmur...@commonsware.com wrote:
On Tue, Dec 7, 2010 at 10:35 AM, Ecthelion ep...@joergjahnke.de wrote:
Yes, if the library project includes all the sources. But in this case
part of the foreign code is inside a jar file.
Resources cannot be in a JAR file.
Yes
On 8 Dez., 15:14, Mark Murphy mmur...@commonsware.com wrote:
Sure you can. It will be no different than if they accessed the string
via R.string.whatever.
Yes. And how would you know how the jar library is processing the
string if the code lies (obfuscated btw.) inside the library? I might
I agree with Bob that an error is a bit over the top. E.g. I include
software from another company as a library project in one of my apps.
This foreign software uses the old formatting using %s %s inside a few
strings, which is now reported as an error. Now I can neither change
the string, because
Yes, if the library project includes all the sources. But in this case
part of the foreign code is inside a jar file. And can I really be
sure that the string is not used somewhere inside this library (e.g.
via getResources().getIdentifier(...)) in a way that breaks once I
modify the resource? In
Hi,
after downloading the new Android 2.2 SDK I tested some of my more CPU-
intensive code with the integrated emulator, hoping to see some of the
promised performance improvements also in the emulator. But to my
disappointment the apps run just as fast/slow as with Android 2.1. Did
I miss
CPU with only soft-floating
point, which means that the JIT is not going to
accelerate FP operations there (unlike on a Nexus One where it will use the
hardware FPU).
Hope this helps
On Sun, May 23, 2010 at 10:35 AM, Ecthelion ep...@joergjahnke.de wrote:
Hi,
after downloading the new
Hi,
On 24 Feb., 05:25, Jonathan jon.aposto...@gmail.com wrote:
I have an array in memory that represents the screen. I then call
put() once to put that into the ByteBuffer that gets pased to OpenGL.
If you still want to use a ByteBuffer you could try
ByteBuffer.wrap(myByteArray) instead of a
The Android 2.1 SDK is out, but - at least from a first test on the
emulator that comes with the SDK - it does not look like the Dalvik
JIT has been activated :-(.
On 7 Jan., 17:55, Biosopher biosop...@gmail.com wrote:
The Dalvik JIT appears to result in a 1.7x improvement when run on an
armv7.
Do you have any references for the statement below? And does next sdk
release refer to the Android 2.1 SDK?
Thanks
On 6 Jan., 19:49, Fred Grott(Android Expert, http://mobilebytes.wordpress.com)
fred.gr...@gmail.com wrote:
the next sdk release is suppose to have a Dalvik JIT i nit doubling
Hi Matt,
you could try explicitly freeing the resources your bitmaps use by
invoking Bitmap.recycle(). The description of this method reads
Free up the memory associated with this bitmap's pixels, and mark the
bitmap as dead, meaning it will throw an exception if getPixels() or
setPixels() is
Perhaps a stupid question, what tools do I use to interpret the
resulting trace file. After a successful run of adb am profile pid
start /sdcard/profile I now have a file /sdcard/profile.trace on my
emulator. But that file is not really human readable, so that there
should be some kind of tool to
I have an application where users that already have an old version
installed tell me that they get a message saying the application
package was not signed properly. A fresh installation does work
without problems, so that I ask those who contact me to remove the old
version and do a fresh
I have an application where users that already have an old version
installed tell me that they get a message saying the application
package was not signed properly. A fresh installation does work
without problems, so that I ask those who contact me to remove the old
version and do a fresh
Google is not forced by Sun in any way. It's just that Sun requests
license fees for their JVM and that does not fit with Android being
planned by Google as a platform where the manufacturers have no
license fees to pay for.
On Mar 31, 8:42 pm, Stoyan Damov stoyan.da...@gmail.com wrote:
If
This I cannot confirm. The C64 emulator Mobile C64 runs with AFAIK
10-15% of the original C64 speed on a G1 with its 528 MHz CPU. On my
Samsung SGH-i600, with a 624 MHz CPU, the J2ME variant ran at close to
100% of the original C64 speed. This is a factor of 6-10 faster
although the device's CPU
I'd like to see:
1. JIT, or something else to speed up the applications in general.
2. Implement javax.sound.sampled classes (not really related to
performance).
On Jan 12, 11:21 pm, Tomei Ningen tomei.nin...@yahoo.com wrote:
Hello Android developers,
We are building an Android-based device,
27 matches
Mail list logo
