The app I'm building has a simple image button animation (rotate) before starting the next activity. I have tested it on the emulator and 5 different devices:
Samsung GT-I5500
Samsung Galaxy Nexus
Samsung Galaxy s2
Motorola Razr Maxx
HTC (I don't remember the model)
The animation worked fine on all of the models, except for the Nexus. On the Nexus, the device waits the duration of the animation (500ms) before starting the next activity, so instead of the animation - just an annoying (and seemingly inexplicable to the user) delay. All of the devices were running Jelly Bean except for the GT-I5500.
Questions:
1) Why would the animation work on some devices and not others, even running the same version OS?
2) Is there a way to check if the device is 'receptive' to the animation? (I had initially thought it had something to do with the SDK version, but it doesn't)
Audio, Video, GPU acceleration are hardware dependent. You can live in the trap of Java is platform independent and there are interfaces and inheritance.
In reality there is a Market:
each of manufacturer want something special to him to get new Customers Money
there are programs made by programs, those can have bugs, and if it can cave => it has, because none of testing is 100% cases.
Related
WallpaperEngine.onOffsetsChanged not being called using a HTC Sensation, but it is ok with my other two devices (Nexus 7, and a Nexus S).
I understand that this issue is related to the HTC Sense 3 carousel.
I have downloaded a number of Live wallpapers to test them out on the device and quite a lot of them don't pan between home screens.. But some do, so there MUST be a workaround for this bug/restriction.
Anyone know what it is?
At glowscript.org are various demo programs written in JavaScript or CoffeeScript that involve little code.
For example, the one-line program box() creates a 3D cube that can be rotated and zoomed, thanks to many defaults (which can be overridden), including basic lighting (two distant lights and some ambient lighting).
Problem:
These programs run fine in many browsers on Windows, Mac, and Linux, but in Firefox on the Samsung Galaxy S3 they are very dark. The appearance indicates that ambient light works (increasing it makes the scene bright) but the distant lights don't work (no difference with them on or off). I've tried running some WebGL demos found on the web and they look fine.
Can anyone think of where I should look for the problem? Why should the behavior be so different between desktop/laptop behavior and what happens on the Galaxy S3?
I fixed the problem on the Galaxy smartphone and added the following to the GlowScript help:
"Most tablets and smart phones do not yet support WebGL, though this is likely to change. On the Samsung Galaxy S3 smartphone, Firefox and Opera do run GlowScript programs, though animations are slow, transparency is buggy, and currently there is no way to zoom and rotate. There are reports that GlowScript also works on the Sony Experia smartphone."
The problem was that the Galaxy shader compiler does not handle for loops correctly. In the fragment shader there was a for loop over the various lights (up to 8 lights). Variables set in the for loop were often set to zero instead of to the specified value. The solution consisted of replacing the loop with a straight-line structure like this, where LP(i) and LC(i) are light positions and colors:
if (light_count == 0) return;
calc_color(LP(0), LC(0));
if (light_count == 1) return;
calc_color(LP(1), LC(1));
if (light_count == 2) return;
etc.
Yuck. Fortunately we only have to support a finite number of lights.
Recently, we had released an app. Before we releasing, we tested it on Samsung Nexus S, Samsung Galaxy S and Samsung Galaxy Tab.
However, recently, we realize our app cannot detect the front camera, for users who are running HTC EVO 4G Cyanogen 7
I was wondering, how do you guys start to debug on such edge cases, without purchasing new hardware?
The joys and sorrows of platform fragmentation, especially where custom firmware is concerned. The short answer? You can't test all the edge cases, and you'll certainly never catch the CM-derived defects. It's the nature of the beast. Even independent branches of the CM baseline do their own things that may entirely break something (e.g. the front camera) or get something else working (.e.g the CPU sleep). I mean, think about it: custom firmware is by definition custom. I could have -- and do! -- my own branch of CM7 that I could do anything in the world with. I could make it so that it ignores the ldpi resources altogether and always pulls hdpi, regardless of dot pitch or anything else. And, more importantly, I could completely screw it up. Unless you run my branch, you won't see that behavior.
The best you can do is program for the largest platforms (targeting API level 7 currently nets you about 99% of the overall market) and then wait for the edge cases to be reported and handle them as quickly as possible. Acquire devices that can cover the vast majority of platforms based on your spending resources. Elect beta testers to receive early builds on esoteric devices or firmware.
Then keep your fingers crossed :).
So I recently created a game with several activities. On my HTC Thunderbolt, all parts of the game seem to be running very fast; however, on my Galaxy 10.1, two of my five activities are running extremely slow (i.e. screen fading is slow, enemies and cursor are moving slow as well). I don't know what is wrong. The other activities are running at or at least near the speed my thunderbolt was running at. Can someone please help me?
Try enabling hardware accelerated graphics, which is available on Android 3.0+.
Or, if you are serious about game performance, use OpenGL instead.
First to thank you all for your great help, I have finally published my game puzzle, both full and free version. Not sure how would I do it without Stackoverflow.
I also learned a lot by helping others.
The issue I am having is that when I start applications I have developed, on Samsung Galaxy Tab, animations are jerky at first 10 seconds or so, then they become smooth. This is not the case on HTC desire or Samsung Europe mobile.
It does not matter whether the animation is a frame by frame canvas drawing or built in android view animations.
I wonder if there is something I can do to prevent this slow down; is it something to do the way Galaxy Tab buffers when loading an application and optimising the resources? Or is this to do with the fact that it has a higher resolution screen… or both.
One way to deal with this could be to create some kind of animated intro in the same activity which would preload/optimise Galaxy Tab for the game.
EDIT after few months of development:
When testing an app on Galaxy Tab it starts slow and the animation is jerky, but if I restart the app and/or unplug the USB link, then it run fast as it should.
It's hard to say without seeing any of you're code. I couldn't say if it's a general problem with your code that only becomes apparent on slower devices, or if it is actually an issue with the Tab.
When testing my applications on the Galaxy Tab the general user interface is slower than on a Galaxy S (2.2), Nexus S or HTC Hero (2.1) but there are reasons for this:
Nexus S has a better GPU and Android version
Samsung have enabled some hardware-acceleration wizardry in their later Galaxy S builds
The resolution of the Galaxy Tab is higher
My main experience has been that the effect of the garbage collector (GC) is much more prominent on the Tab, therefore it could be something to do with your memory management -- are you creating objects in your onDraw method?