Develop Reference

Should Android app make use of SVG's to maximum extent?

The official documentation Vector Asset Studio states that SVG can be used to reduce APK size. It also states that SVGs take much CPU cycles for drawing.
The initial loading of a vector graphic can cost more CPU cycles than
the corresponding raster image. Afterward, memory use and performance
are similar between the two. We recommend that you limit a vector
image to a maximum of 200 x 200 dp; otherwise, it can take too long to
draw.
Also, it is supported from Lollipop onwards. On backward compatibility, it states that-
Android 4.4 (API level 20) and lower doesn't support vector drawables.
If your minimum API level is set at one of these API levels, you have
two options when using Vector Asset Studio: generate Portable Network
Graphic (PNG) files (the default) or use the Support Library.
For backward-compatibility, Vector Asset Studio generates raster
images of the vector drawable. The vector and raster drawables are
packaged together in the APK.
Raster images look like more efficient than the SVGs. Also, though the size of APK will be reduced, what will be the impact of SVG on memory and app performance as the doc states that it will take time to draw large SVG files.
As an android developer, what should be my approach? Which of above or any other ways will ensure my apps be optimized and deliver good performance.
Edit : A query then, What should be the best approach among the two -
Reduce the apk size by using the SVGs but will increase CPU cycles for drawing
Use raster images

In my own experience Vector Asset Studio is picky about what it accepts in an SVG. If you are not well versed in SVG you are going to have a hard time massaging the SVG markup into something that VAS accepts. From the top of my head I recall it doesn't support defs or filter, but some vector graphics software seems to include it even if it's not strictly necessary. Given flat icons (no gradients or shadows, for example) you can work around this by manually editing the mark-up.
As for performance, it really depends on the amount of icons you will display per screen, and the complexity of these icons. You will have to conduct some stress tests to see if your target devices hold up. Note that this only impacts the initial load, behind the scenes these vector images are rasterized and—as the text you cited mentions: Afterward, memory use and performance are similar between the two.
Your approach should be pragmatic, attempt to draw a couple of your icons on the screen and see how smoothly it goes. This is a subjective question that depends on the constraints of the device and the person who implements it.

My experience using react-native-svg was very good, but animation performance that needs to recompute dynamic SVG suffered from I think they call it 'too many passes over the bridge'. There may be a way to optimise it, and I intend to investigate this on my next RN project. I should qualify this last statement by emphasising that animation only suffers when the SVG needs to be recomputed during the animation (on the JS side). For example have a native ScrollView component with your SVGs inside it, the ScrollView can animate perfectly performantly, but if you want to change the SVGs programatically as a function of scroll position within the React/JS side, you will have the bridge problem, and dropped frames galore.
Here is my boilerplate which sets up a few basic shapes in Android RN:
proto__33__boilerplate
Generally I would say (programmatic) SVGs are great for Android, but I haven't yet found a performant way to use them for animations. Will update if I find that.

Jquery performance on android

Just finalizing a project for a client, will remove link once answered.
http://da.cronus.fweb.com.au/
On iOS and desktop the animations/scrolling are very smooth. As soon as it hits android things get very laggy (tested on nexus 7, Galaxy S4 and galaxy tab 3)
Anything i can do to speed things up?

first of all some images are pretty heavy for mobile devices
it should not affect the animations but still ...
codewise the only part that seems slow to me is
$('.column p').each(function(){
if($(this).html().length < 1){ $(this).remove() }
})
in custom.js line 665
so i guess if the animations are slow it must be a device / spec issue
but there is probably something to change with those line of code that could help your javascript.

For Sliding you can use Flexslider plugin. Plugin supports touch and it is responsive. I think some problem with sliding plugin only.

Switch from java script animations to CSS3 animations - they are hardware accelerated on most Android 2.3+ devices.

jQuery itself is OK on Android. I use it all the time. This could be a poorly coded slider plugin. However, you have some large images around 2mb and I think this could be optimized. I would do this first. You can also move the js files to the bottom and also compress and merge them. These are all optimization techniques that need to be done first and are not a waste of time. I'd also use responsive CSS on the images to display different sizes for device resolutions. Bootstrap has some solutions for the images sizes. After your page is optimized for mobile then you can re-evaluate if the slider is still slow or it was just large images.

I tried it on my Galaxy Note II and it works quite smooth. If you are trying to improve it in anyway, i would recommend swipejs.com for mobile and flexslider for the desktop version (although flexslider is completely working on mobile too, i just found swipe.js to be easier to setup)
Good luck and have fun! :D

Your question is very generic.So i would say, you need to minimize background processing as for as possible in scrolling(if doing some processing for scrolled data) or in animation or in any other activities.
As mobile devices have less resources.

Animation performance on android is not something you can just bolt-on with an IE jQuery plugin 'that makes it work in IE8' and expect it to work similar on android.
Remember that Android runs on a wide variety of devices, all with their own performance issues and some with even crappier versions of the android webkit variant than others. Expect huge differences between last-generation quad-core tablets/phones and low-budget devices.
My advice:
try a jquery plugin that automatically uses css3 animations instead of jquery looped where available (but no guarantees there)
try a jquery plugin that optimizes the jquery animations with the use of requestAnimationFrame (
http://www.paulirish.com/2011/requestanimationframe-for-smart-animating/ )
As others have mentioned: You can't just throw 2mb images to a phone and expect them to animate smoothly. Optimize assets for the device you're serving them to (e.g. a max 800x600 pic for a phone)
If all that fails: Optimize manually, by enabling android browser debug settings and adding -webkit-transform 3d-transitions to the elements that need to animate so that the layer is rendered by the GPU.

You mentioned performance on android, but the first time that I loaded the site on Firefox it was pretty slow as well. After looking at your slide images, I found that the slide are way too big (~2mb), as other people have mentioned.
PNGs aren't the best choice unless you must have transparency, as they are bigger than JPEGs right off the bat. I would take the images and optimize them for the web using Ps. If you really wanted to be super-efficient, you could have another set of smaller images intended for android. Hope this helps you out. Happy programming!
Grey

If I were you I'd use css transitions. I've found that they work much better on mobile especially Android. I realize that in a desktop environment you'd have much broader support using a javascript transition but mobile is a different story.
You could hybridize....
http://jsfiddle.net/PHPVT/
$("#target").on("click", function () {
$(this).addClass("clicked");
})
use javascript events to fire css transitions :)
I use it all the time when I have to build for ie8 since it doesn't fire :hover states on anything other than anchor tags.

Android devices GL_MAX_TEXTURE_SIZE limitation, safe texture size

I am working with AndEngine and OpenGL ES 2.0. I keep reading about GL_MAX_TEXTURE_SIZE and how I should keep my texures under 1024x1024. I started wrong before and while using tilesets in TMX extension (doesn't really matter what it is, if you don't know AndEngine) I get to a tileset that makes a texture wider than 1024px. I am thinking of splitting the tileset into two, making them "safe". But I can't find any device released in last couple of years that has this limit set under 2048x2048. Is there any list or website I can use to filter devices by GL_MAX_TEXTURE_SIZE?
I read the following questions:
Minimum required Texture Size for compliance with OpenGL-ES 2.0 on Android?
Is there any Android device with screen size greater than GL_MAX_TEXTURE_SIZE?
And I used this site to search for devices. But I can't search by/filter by GL_MAX_TEXTURE_SIZE, which makes the search tedious. I am asking mostly because I started wrong, it's a hobby project and the amount of work might be too large compared to the number of possible devices that will be enabled (I expect 0).

1024x1024 is about the safest you can go on any device, especially on older ones. Newer devices shouldn't have any problem, although I've seen recent devices (I recall a Galaxy Nexus, the newest ICS update fixed that though) render white quads with texture sizes of size 2048x1024.
If you're targeting new devices and want to keep older ones compatible, it shouldn't hurt to split your tilesets. After all, you aren't likely to do too many context switches if you use two or three spritesheets for background, etc.

If you still have the individual image files, breaking them into small sized Atlases or custom sized atlases is easy if you use the TexturePacker2 tool from the LibGdx library.
I don't know the exact limitation of devices, but it's always better to take into consideration the lowest end of device you want to support and build upward from there. Using the LibGdx tool, you can easily change your mind later, so it's the most flexible solution.
Look at:
LibGdx TexturePacker

webkit raster vs vector images

I am trying to address a resolution issue when designing HTML for webkit browsers.
So basically the problem is that webkit browsers can have resolution anywhere from 240x320 to 960x640 and I can't have a separate image/icon set for each one but I do want the pages to look the same on all devices (or very close at least).
Scaling the image (working with percentages) works but it's a performance degrade:
http://code.google.com/speed/page-speed/docs/rendering.html#SpecifyImageDimensions
The other option is using vector graphics which is supported in webkit but I am not aware of the performance implications that is going to have on the pages/app.
The other option is to have a few icon sets for some standard well know resolutions and when you get a browser which is outside of these groups you apply some minor scaling on the set which is closest to the users native resolution.
So basically what I am asking is, what would be the best route to achieve this with performance in mind?
Thanks
-Assaf

Vector graphics are always more expensive in terms of runtime performance as complex equations are run to create them. Having said that, I'm not sure if they're redrawn every frame from scratch, or if the result's cached unless it's in a dirty state.
I'd suggest having a few different icon sets for well known resolutions and applying minor scaling if required.

The first answer is not helpful at all. Vector graphics can be just as small as a PNG, and used right can support transparency and various other good features.
The only problem is if your looking for pixel perfect perfection having some of the images scale up might cause problems.
You can also use illustrator to html5 canvas plugin to export directly to html5 canvas.
For our webkit browsers on row icons, we set a property that doesn't allow webkit to scale the icons for desktop browsers. Or for some of the icons we include a small SVG.
They are well supported and work great. Even better would be to use a free font creation tool and paste your vector graphics from illustrator into a font, so that you could use web-font to simply call up ANY size icon, as simple text. We use this technic.

Android: advanced text drawing (columns, fixed height, paging). How?

I'm porting application from iPad to Galaxy Tab and, since I hadn't had much experience with programming for Android devices I'd like to know some "general" things.
I've used CoreText for all my ipad text drawing needs, what can I use in Android? How can I break large text apart dividing it in to frames/paths and then layout them on screen (think, columns in news application articles). It looks like that Paint class does some things related to what I need, but I don't know if that's the proper way to go.
Please, enlighten me :)

The Layout object is what you are looking for, in particular its subclass StaticLayout. It's what's used by TextView to shape the text and render it on screen. It's basically a smart wrapper around the various methods offered by Paint to measure and draw text.

Personally I would wait for Honeycomb, maybe Gingerbread if you're lucky. Currently Android is not optimized for tablets, plain and simple (can you imagine developing on the iPad with just the standard iPhone SDK?)
Gingerbread is going to be announced before the new year and we might get some tablet goodies, but Honeycomb (release soonish?) is when full tablet support will be available.
For the timebeing maybe develop for the standard phone size, but keep it modular enough so the upgrade for tablets is painless.