Thursday, 5 September 2013

BlueStacks: The app player for windows

It is a windows application which could run the android app.You might be asking what is the point my android emulator can do this? you are right but how is your emulator performance? can you play 3d games on emulator? the quick answer is no or its too slow. Yes it is slow because android emulator is nothing but a modified qemu( famous cross platfor emulator).In emulator  is complete  emulation of ARM architechture so for executing an typical android application there will be two converstions first from dalvik to arm them arm to i386/amd64 , in order to catchup these conversions the app will crawl.

As far from my understanding(from offical tweets ) Bluestack is using combination of both virtualization and native code implementation.

I personally use BlueStacks for debugging, its is really fast as compare to native emulator.

Animation between activity switching

For most of the android apps we do have multiple activities and when we start another activity either we get no animation (in older devices) or  a left-right translation. It is not so cool for a stylish app. 

So, the code to change the animation between two Activities is very simple: just call the overridePendingTransition() from the current Activity, after starting a new Intent. This method is available from Android version 2.0 (API level 5), and it takes two parameters, that are used to define the enter and exit animations of your current Activity. Here’s an example:

startActivity(new Intent(this, NewActivity.class));         
overridePendingTransition(R.anim.push_left_in,R.anim.push_out_up);   


These two parameters are resource IDs for animations defined with XML files (one for each animation). These files have to be placed inside the app’s res/anim folder. 

push_left_in.xml:-


 <?xml version="1.0" encoding="utf-8"?>   
 <set xmlns:android="http://schemas.android.com/apk/res/android">   
  <translate android:fromXDelta="100%p" android:toXDelta="0" android:duration="300"/>   
  <alpha android:fromAlpha="0.0" android:toAlpha="1.0" android:duration="300" />   
  </set>   

push_out_up.xml:-

 <?xml version="1.0" encoding="utf-8"?>   
 <set xmlns:android="http://schemas.android.com/apk/res/android">    
 <translate android:fromXDelta="100%p" android:fromYDelta="100%p" android:toXDelta="0" android:toXDelta="0" android:duration="300"/>   
 </set>   

The first xml code makes slides the View diagonally. The second one slides the View to the left and then up. 

Wednesday, 4 September 2013

Write Code for Different Android Versions in Your App

Fragmentation has been a big issue in Android since the beginning and everyone has different views about it. I personally don't think that there is an effective way to avoid fragmentation at the rate Android is growing at. 

it's actually not that hard to write code that handle different Android versions inside your application. I know, we can always publish different apks to handle different android versions, but this may not be the optimal choice in all cases. So, here is little code snippet showing how to handle fragmentation to a certain extent in Android:

 @SuppressLint("NewApi")  
  @Override  
  public boolean onCreateOptionsMenu(Menu menu) {  
  MenuInflater inflater = getMenuInflater();  
  inflater.inflate(R.menu.menu, menu);  
  return true;  
  }  

The above code is just a simple example, that shows how you can create different menu options for different Android versions.

Now you will have the question in mind that which will better between @SuppressLint 'NewApi' and @TargetApi(GINGERBREAD)

Answer is @TargetApi amd @SuppressLint have the same core effect: they suppress the Lint error.


The difference is that with @TargetApi, you declare, via the parameter, what API level you have addressed in your code, so that the error can pop up again if you later modify the method to try referencing something newer than the API level cited in @TargetApi.


Happy Coding.....:)