#include....

Knock 'em out...

Nautical Glory

So how does Android support Device Diversity ?

Android attempts to address device diversity by the following techniques:

• By providing density specific resource folders. 
• By providing resource folders for screens with different sizes.
• By providing an ever upgraded Compatibility library which is used to extend the capabilities exposed on the later versions of OS, to older versions of the OS. For example, Fragments were introduced from 3.x onwards. However, by using the Compatibility Library, you can use Fragments even in Apps targeted to Android 1.6.
• By unifying the Tablet and Phone experience ( Android 4.0 onwards ). 
• Third-party libraries also exist which can provide similar capabilities ( or in some cases even better ) to extend capabilities to previous platforms. An example of this is, ActionBarSherlock.

The above are some of the ways which Android developers can use to tackle device diversity for their Apps.

.... and then Google+ entered

Google.com is one of the hottest properties on the internet, and that has enabled the search giant to get to where it is. Several years passed since 1998 ( when Google was launched ), and then in 2005, Zuck launched Facebook. Gradually the engagement factor of Facebook became a force to reckon with. 

Google’s business model was to provide adverts highly specific to the search query, and it has been a grand success for them so far. One potential pro / con of this approach was the fact that the results were independent of who searched for the results. However, in real life, this is not the case. This is because the same search query can mean multiple things to different people. Google searches, while being highly relevant, were completely devoid of this calculation, and yet it all worked out great for Google…

Then Facebook entered, and with it the user specified a myriad number of their personal preferences, and choices, and likes and dislikes. All of this information was subsequently available to Facebook, and to the other third-party vendors who dealt with Facebook as well. The difference in the level of targeting that Google could provide, versus what Facebook could provide was astounding… This is because Facebook could not only take into account what the user was searching for, but also use a plethora of information about user’s likes, dislikes etc. and then subsequently present advertisements which were relevant not just from the search query POV, but also from the user’s POV…

I believe that Google did not anticipate an attack on their core business from this attack vector, and were complacent initially. Finally Google decided that social was an important angle to the whole targeted advertisement business, and tried to enter the social space. After a few ‘failed’ social experiments ( Orkut, Buzz ), Google finally launched Google+, and also updated it’s privacy policy to more broadly integrate user’s interactions across different Google properties. With this change, Google encourages users to log-in and stay logged-in across the different Google product offerings, and also enables Google to learn more about the logged-in user. Slowly, but surely, Google is on it’s way to building a solid social graph…

Notes from Google I/O 2012 session - ” What’s New in Android ( 4.1 ) “

The official page for this session is here . The session is specifically about the latest iteration of the Android OS, i.e. Android 4.1 / JellyBean.

Google has now also made available the entire changelog, which is another good source of information about JellyBean . 

Below are my notes from this session, organized by category.

Performance, Memory

• Using V’sync + Triple buffering to make overall performance much better ( or much butter - as google likes to call it ! ).
• Non-editable TextViews use less memory.
• New Memory inspection APIs introduced for the application to be able to better inspect system memory, and then respond to it.
• RenderScript updates.
• Ability to cancel Database queries.

Widgets

• Android Widgets can now be hosted in third-party launchers.
• Widgets can respond to size changes. In Android 4.0, while re-sizing widgets was possible, intercepting this event was not possible. However, intercepting this change is now possible with Android 4.1, and consequently you can do stuff like update layouts etc.
• Widgets can now have different layouts for portrait mode, versus landscape mode.

Layout

• The new layout called as ‘GridLayout’ which was introduced in Android 4.0 for Activities / Fragments, is now also available for Widgets.
• GridLayouts were specifically created to solve the problem of deeply nested layouts for certain use cases in a more performant manner. 
• TextureView : Enhanced SurfaceView essentially.
• The above layouts are not Android 4.1 specific, but were actually introduced in Android 4.0 .

Animation

• Multiple Animation related updates to make animations easier.
• Activity Animation updates. Now, you can easily animate the ‘zooming out’ expansion of activities from a specific point + dimension on the screen. Android 4.1 JellyBean is replete with examples of this functionality / behavior.

ClipBoard

• ClipBoard can now hold styled text, I.e. Not just raw text.

Navigation

• Now you can manually create synthetic task stacks ! This is huge in my opinion. Also, this update is available within Google-developed Android compatibility package, which goes all the way back to Android 1.6, so this should be available for us as well.
• Automatic ‘Up’ navigation support for Activities, in context of Action Bar.
• Still no official Action Bar support within the Support package. Romain Guy recommended using ActionBarSherlock for this.

Internationalization

• 18 new locales, support for right to left text – Arabic, Hebrew.

Accessibility

• Enhanced in a major way. For visually challenged folks, you can perform gestures which will gradually traverse, and describe the various views to you, without looking at the screen. Once you choose the right area / view that you want to interact with, you perform another gesture ( double tap ) anywhere on the screen to execute the action. This way, you don’t have to figure out exactly where to tap. Also included is accessibility support to make complex Custom views more accessible. All of this exists in the support library, and therefore works all the way unto Android 1.6 !

Security , Permissions

• From now on, Apps that need to use external storage, need to explicitly request for this this permission. While this is not mandatory, at the moment, it will become mandatory in the future.

Networking, Throttling, $

• Android already supports determing whether user is on a WiFi network, or is using a regular cellphone network. However, this is a coarse-grained approach, for example, what if the user is on a metered Wifi HotSpot network ? In this case, the user can specify which networks are metered, and you can now query this setting from within your application before performing a network-intensive operation. 

MultiMedia

• Media Codec updates.
• Audio Latency improvements.

NFC

• Large payloads over Bluetooth, tap for pairing support.

Play Store

• You can respond to user comments, but this is for ‘Top Developers’.
• In-App subscription support.
• New seller countries.
• Entire Team can now access Android developer console.
• Sales report are now available.
• Android Expansion files -> Initial APK file can be unto 50 MB, and it can then be remotely augmented with extension files unto 4 GB.
• Incremental APK updates are now available, automatically ! Average saving ( data ) of 66 % per download, per Google stats.
• Unlocked devices now available directly from Google.

DevTools

• Emulator is much faster now, to the extent that you can run games on the same with good performance.
• Can test hardware acceleration, via Emulator.
• Sensor and multitouch support using physical Android devices. In this case, you actually run you application on the emulator, but can feed all sensor data + multitouch events using a connected Android device for thorough testing.
• ‘Lint’ Tool for automated checks of your code against Google recommendations.
• Tracer tool for Open GL ES.
• Device Monitor Tool. This is basically a newer version of DDMS, with a better UI.
• System Trace tool.
• Better NDK support.
• Support for creating standardized types of Applications.
• Layout editor updates.

Notifications

• New attribute introduced – priority. Support for opportunistic notifications. Opportunistic notifications are those which do not appear when the Notification drop-down is unexpanded, but show up once the user has pulled down the notification menu.
• bigContentView – 256dp tall ( 4 times previous contentViewSize )
• Notification Actions: you can add upto 3 buttons within your notification, from which the user can perform an action directly. If you want to add more than three buttons, you can use Custom Layouts.
• Styling updates with regards to Notifications.
• Notification sort order is first by priority, then by time.
• Users can now long-tap and find out which application posted a notification. If the user is annoyed by notifications coming from an application, they can just switch off the notifications from just that application.

Comments, questions and feedback are appreciated !

Enabling Android Webview to Ignore bad Certs..

Recently, in a small project I wanted to display a mobile optimized website inside of a WebView in a native Android App. So, I created the WebView and proceeded to load the website in it, and Voila ! it did not work ! I tried a few different settings for the webView, but each time I got a “Website not available” error.

Subsequently, I opened up the website on my desktop browser, and it worked great. Then, I opened up the website in the Android browser, and it opened up fine in either case. This was fairly baffling to me. [ Later I realized that in either case, I had set my browser to ignore bad SSL Certs ]

I was using a Custom webViewClient for loading the page, but was over-riding only three methods:

onPageFinished(WebView view, String url)

onPageStarted(WebView view, String url, Bitmap favicon)

onReceivedError(WebView view, int errorCode, String description, String failingUrl)

I had hoped that in-case of *any* kind of error, the onReceivedError would get triggered, but it was not getting triggered. After a little head-banging, I decided to take a deeper look at which other webViewClient methods I could over-ride and found some interesting ones.

onReceivedHttpAuthRequest(WebView view, HttpAuthHandler handler, String host, String realm)

onReceivedSslError(WebView view, SslErrorHandler handler, SslError error)

onTooManyRedirects(WebView view, Message cancelMsg, Message continueMsg)

So, I proceeded to over-ride the above three methods as well. In my subsequent test, I found that the method “onReceivedSslError” was getting triggered ! This was excellent, because now I had a clue of where the problem could be, and which direction to proceed in. I subsequently went to my desktop browser, and stock Android browser, and made sure that I got prompted in-case of a bad SSL Cert. After that change, I could see that the stock Android browser, gave me a Dialog with three options, kind of like the image below.

The above image communicated to me that the SSL Cert was not trusted, and that all I would need to do to make it work, would be to ‘intercept’ this Dialog within the WebViewClient, and ignore the bad Cert.

After a little bit of digging, I found this post ( image above is sourced from the same ) from Damian Flannery’s Blog which mentions :

engine.setWebViewClient(new WebViewClient() {
 public void onReceivedSslError (WebView view, SslErrorHandler handler, SslError error) {
 handler.proceed() ;
 }

The single bolded line of code above, will make sure that the webView will ignore bad Cert warnings, and continue to load the website. I made the above change, and it was all good after that. 

Hoping that this post could save someone’s time when faced with a similar issue in the future…