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 y
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 grou
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 for
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 wrote:
> Seems to be fixed!
>
> On 1 Ago, 13:31, kodlan wrote:
>
>
>
>
>
>
>
> > Damn,
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 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 across all apps. I've rep
+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 wrote:
> I would really like to see ActionBar support ad
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 --- wrote:
That inBitmap option sounds great. Thanks for that :-).
On 17 Jan., 21:21, Romain Guy 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 t
On 17 Jan., 21:21, Romain Guy 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
> BitmapFactory.Options
On 9 Dez., 14:20, Mark Murphy wrote:
> On Thu, Dec 9, 2010 at 3:50 AM, Ecthelion 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 with a third
On 8 Dez., 20:52, Mark Murphy wrote:
> On Wed, Dec 8, 2010 at 2:40 PM, Ecthelion 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 it works fine with t
On 8 Dez., 15:14, Mark Murphy 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
grep the library for a
On 7 Dez., 16:39, Mark Murphy wrote:
> On Tue, Dec 7, 2010 at 10:35 AM, Ecthelion 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, but I never sa
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 a
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
ting an ARMv5TE 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 wrote:
>
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 somethi
Hi,
On 24 Feb., 05:25, Jonathan 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 series of
ByteBuffer.c
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 wrote:
> The Dalvik JIT appears to result in a 1.7x improvement when run on an
> armv7.
>
> Here's the po
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)"
wrote:
> the next sdk release is suppose to have a Dalvik JIT i nit doubling
> speed/performance..
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
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 int
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 install.
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 install.
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
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 wrote:
> If Google were not forced by
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 wrote:
> Hello Android developers,
>
> We are building an Android-based device, and would like to k
27 matches
Mail list logo
