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


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

Proof for verification

Wednesday, February 11, 2015

Lately I have been working with MediaPlayer on Android. I went to Android docs, read the description of the apis. Great! Let's think a rough algo and start working on the app.

I wrote a simple app which just streams a video and provided media player controls in the app for seeking, play pause etc. Pushed it on my device and goofed around with it. Play, pause working great. Video is streaming nicely. What about seeking? Let's seek to some X position. BAAAAM!!! The whole app became unresponsive. I couldn't interact with my device any more. I thought may be I am doing something wrong so I better review the code. After reviewing I couldn't find anything that I might have been doing on the main thread which could have caused this ANR. I searched the internet and found a few questions on Stackoverflow complaining about the same issue and guess what those questions were posted back in 2011 and 2012. I asked some of those devs and to my surprise they had the assumption of these bugs being fixed long ago, but here I am scolding Google for not fixing the issues and releasing premature api's for the media player.

Let's forget about the UI responsiveness for a bit and focus on other apis. I implemented listeners for buffering callbacks. The algo for the app was developed keeping the documentation of those callbacks in the mind, however when I pushed the app on the device, the behavior of the app was totally unexpected. Forget about stuff that shouldn't be happening, things that should have been happening either never happened or occurred seldom. After extensive testing I found that the behavior of the callbacks was totally undefined. Either Android docs failed to mention other possible scenarios for them or they were the bastard child of the messed up code.

Now I looked towards lollipop in the hope that this crappy behavior might have been resolved in the latest and greatest OS. Google again didn't fail to surprise me. Not only the apis that weren't working on Pre-lollipop devices were still in the same buggy state, the apis that were working stopped working altogether. Now I am sitting ducks, frustrated by the piece of shit Google has provided in the name of Media Player, trying to patch the known issues in my player code making it a spaghetti code.

The only solution I can think of is abandon Media Player and write your own player from the scratch, which is a major pain in the ass or use some open source player.

FUCK YOU Google!!!