Android Material

1. Application Localization Process Android loads text and media resources from the project’s  ‘res’  directory. Additionally, Android can select and load resources from different directories, based on the current device configuration and locale. For example, if the code loads a string called ‘R.string.title’ , Android will choose the correct value for that string at runtime by loading the appropriate strings.xml  file from a matching  ‘res/values’  directory. In order to have a multilingual Android app you need to provide Android with the localized resource files. If the locale is  ‘en-US’ , Android will look for a value of “R.string.title”  by searching the files in the following order: ‘res/values-en-rUS/strings.xml’ ‘res/values-en/strings.xml’ ‘res/values/strings.xml’ When it manages to find the string in the resource file, it uses that value and stops searching. This means that the default language acts as a fall-back option and when translation exists, it’s used

Handling Different Device Displays Android devices come in a variety of different screen sizes and resolutions. The ideal solution is to design the user interface of your application so that it appears correctly on the widest possible range of devices. The best way to achieve this is to design the user interface using layout managers that do not rely on absolute positioning (in other words specific X and Y coordinates) such as the RelativeLayout so that views are positioned relative to both the size of the display and each other. Similarly, avoid using specific width and height properties wherever possible. When such properties are unavoidable, always use density-independent (dp) values as these are automatically scaled to match the device display at application runtime. Having designed the user interface, be sure to test it on each device on which it is intended to be supported. In the absence of the physical device hardware, use the emulator templates wherever possible to tes

Solution 1: You can create different graphic objects for use at different pixel densities. Android treats mdpi (160 pixels/inch) as the base density. So for mdpi devices, 1 dp = 1 pixel. At higher densities, there are more pixels per inch (240 for hdpi, 320 for xhdpi). Android attempts to make graphic images occupy the same physical dimensions on the screen regardless of the device pixel density. So if all it finds is an mdpi resource, and the device is hdpi, it will scale the graphic by 240/160 = 150%, and it will double the size of the graphic for xhdpi. If you don't want this automatic scaling (which can make graphics look poor), you can simply supply your own version of graphic resources for use at higher densities. These graphics should be of the same size that Android would scale an mdpi resource. Note that the pixels/inch that was stored in the image file has nothing to do with this. It's all based on where you put the graphics files in the resources directory f

This Android tutorial is to walk you through create an Android chat application using Google Cloud Messaging (GCM) using its Google Cloud Connection Server (CSS) via XMPP. Using Google CCS we can send upstream messages from an Android device to another and we will be using that feature primarily to do this chat application. If you are new to Google Cloud Messaging (GCM), then you need to check a previous introductory tutorial “ Google Cloud Messaging GCM for Android and Push Notifications ”. This tutorial will help to understand the basics, setup the prerequisite and start this wonderful GCM journey. Making of GCM Chat Application •A cool Splash screen (just for fun)  •A Simple Android List View (available chat users list screen)  •A List View wit Row Layout (chat conversation display)  •Chat Bubble  •GCM upstream communication with XMPP  When we put together all the above, we get a nice Android chat application. I have already written detailed tutorials on all the above top