Tuesday, May 31, 2016

If you are trying to test your app that has a ProgressDialog in it, STOP RIGHT THERE! You are gonna be in a world of pain, when your tests keep failing for no apparent reason after failing to find the progressDialog that is vividly visible on the screen.

The problem isn't in your code. It's the shortcoming of the Espresso Testing Framework. The framework can't really handle the animations of the progress dialog. I am still digging around the exact reason, however from the little bit of research I have figured out that the drawable animation of the circle gives the impression of non idle state to the Espresso framework. So what does it mean? It means Espresso keeps waiting for the app to enter the idle state and as long as the progress dialog is visible on the screen, the app stays in the busy state. By the time animation ends, the progress dialog is gone.

When the app enters the idle state and espresso comes out of the waiting loop to start running tests, it fails toexecutes the test command for the progress dialog as there is no progress dialog on the screen now.

So now you might be saying enough with this useless banter. How about telling the solution about this problem?

The answer is simple, DON'T use ProgressDialog. But sometimes you have gotta use them. So the workaround is, use an AlertDialog instead for testing purposes.

Define the BuildConfig for testing purposes, I use DEBUG config for running espresso tests and show alert dialog box in debug config. In release config you can show the ProgressDialog since you won't be running the espresso tests in release config. This resolves the failing test issue and makes sure your UI is working perfectly as well.

Saturday, May 21, 2016

Back in July 2014 when I was doing my research work for the scholarly publication  of my Computer Systems Engineering graduation, I got intrigued by Android Wear watches. I remember watching the  Google IO in which they showed off the upcoming watches and the cool new ways we could interact with our phones. At the time of Google IO I didn't pay much attention to Android wear and focused completely on my research. However at the launch of Android wear, I saw LG G watch and Moto 360, the later was planned to be released a few months later. I was fascinated by the cool design of Moto 360 and got interested in wear development.

I looked at the workings of Wear OS & to my surprise, Google didn't include a handy application launcher considering Android Wear was all about enhancing user experience and keeping us away from our phones when necessary. The only way one could launch an app was via voice, otherwise you had to dig deep into the system to get to list of installed apps.

This was an opportunity for me to improve the UX of Android wear. That's how Swipify came into being. Swipify is an application launcher, multi-tasker and automaton that could be accessed from anywhere in the Wear system with just a simple gesture or floating icon.

For writing Android Wear applications you had to have a phone running Jelly Bean 4.3 and a wear watch. I neither had a phone running Android 4.3 nor did I have a wear watch. Though one could test the app on the bundled emulators but the emulators were so buggy that they couldn't identify if they were round watch emulators or square watch emulators, which ultimately means developing without a wear watch and Android 4.3 phone was an utter nightmare.

I started writing Swipify anyway besides not having the required resources. I was done writing the first release of Swipify in the first week of the launch and decided to publish it on Google Play. When I sat down to make developer account with a debit card, Google wouldn't let me. Later I found out Google didn't allow transactions from a debit card for creating a developer's account in my country. Being a broke student, I couldn't afford a credit card, so I borrowed the account of one my friends and published it on his developer's account.

Soon after the release, Swipify took the internet by storm. The likes of Android Police and Android Community were featuring it and writing reviews about the app. I was astonished because I wasn't even sure if the app would run properly or get pushed to Wear watch from the phone since I couldn't test it on real world devices.

Radial Design & Android Wear 2.0:

Swipify has 3 launchers, Grid Launcher, Floating Launcher and Radial Launcher. Radial launcher being the most prominent and wear friendly one.

Many Moto 360 or circular watch users made Radial launcher their default launcher because it was so natural to use an interface that was designed & crafted for the circular watches.

Since then several 3rd party app developers copied the idea of Radial Launcher and included in their apps.

Two nights ago when I was watching Google IO, they announced Android Wear 2.0. My excitement led me to look for the improvements and UI changes. Surprisingly, Google has included the Radial Launcher inspired interface in the Wear notification area.

 I am honored and at the same time have this mixed feeling, why didn't Google include this interface in the early days of Wear? Why didn't Google feature Swipify's radial inspired app launcher in Wear OS?



Though the development of Swipify is halted at the moment, however I am planning to resume Swipify's development, when I buy the Android Wear watch (or better yet if Google sends me one). Hopefully I will be able bring out more innovative interface and UX ideas that Google will incorporate in their Wear OS in the near future, Or may be in not too distant future, I will be sitting in Google's head quarters at Mountain View and working on the new release of Android Wear.

Monday, February 1, 2016

All the modern browsers have implemented a security protocol that prevents the website to access files from the disk. It's a really important security measure that forbids the websites to snoop into your disk and steal your 'data'. However sometimes you want to load the files anyway. May you are developing a web app and you want to load libraries stored on your disk. This security protocol will hinder this action.

You can use work arounds by setting certain flags of the browser that will disable these security fences but the catch is you will become vulnerable to the attacks. I don't advice disabling security in your browser. The workaround that I have found is very secure.

So for example if you want to reference a Jquery file on your disk, trying to access it with

src="file:///path/to/your/file.js"

wont work.

So the easiest workaround that doesn't require alot of effort is to serve these library files or any other file that you want to load by serving them via a local server on your system. So your next question will be how can I do that? Well it's pretty simple. Following steps should get you up and running in just a minute.

1. Install wamp/xamp or any other program of your choice.<
2. Put the files that you want to be served by the server in the /path/to/wamp/www/yourfile.js
3. Start the wamp server.
4. Put the local host path to server file where ever you want to access it. Eg. src="http://localhost:81/yourfile.js"


Voila! You should be able to fetch the files locally now.

Thursday, November 19, 2015

Google is rolling out the new Camera app v 3.1 gradually via playstore. The update was long due and the Google's current offering was lacking in several areas, performance is the most the notable one. I got my hands on the updated app via APKMirror. The app is intended for devices running Android Marshmallow. So bad luck for lollipop users.


From the early impressions, the app looks just an aesthetic overhaul. The app brings the UI from the Camera apps of Nexus 5x & 6P. However, it doesn't offer burst mode on neither Nexus 5 or 6. Not surprisingly the later has Auto HDR+ feature. Currently I have a Nexus 5, which is considered the best Nexus device Google has ever released. However the camera along the battery aren't the strong suits of the champ. Though the camera performance & picture qualities have improved plausibly since the inception of the device, the current release takes it to a whole new level.

The latest Google's camera app has improved in both performance & picture quality department. The app launches faster, takes snaps quickly by offloading the image processing on a handler thread & HDR+ enhances the details & shadows on a somewhat mediocre camera of the Nexus 5, like never before. HDR+ now preserves the sky color much better without leaning towards over exposure. The shadows are highlighted much better but there is still some prominent noise but it's not a big deal for me. There is an Auto Flash option available for the HDR+ mode but it never illuminated dark scenes and the photos are always dark.

Screenshot Credits: Phandroid

Non HDR photos are taken instantly. Even if you the camera hasn't focused on the subject, as soon as the shutter key is tapped, the photo will be snapped. Which is better then missing the moment in hunt of focus.

Video department has also been improved. It lets you touch to focus while recording the video. Whereas before you had to wait for a few seconds for the camera to focus & tap the display would result in capturing a photo.

The revamped user interface is also very welcoming. Swiping left from the right edge, switches to Video mode. To open the gallery, you have to tap on the picture icon at the right of the shutter button. Overall the new camera app has breathed new life in the Nexus 5's camera. Hopefully in the near future, Google will address the flash bug in the HDR+ mode & may be add features like Slo-mo & 60 fps video recording for Nexus 6 and may be for the Nexus 5 as well.

Tuesday, March 31, 2015

https://issues.sonatype.org/browse/OSSRH-14762

Proof for verification