#AndroidTO 2015 - Martin's notes and higlights

The opening keynotes of AndroidTO started with Jake Wharton and a splash screen "Developer's Renaissance". Delving into the past of where Android began and where it is today. In the early days developers were using Eclipse, which was by all the must have tool. It was complicated, convoluted even in its early days.

In 2015, this is entirely different, the number of tools has increased, there's more access to resources and it's more flexible for developers.

Not so long ago, more light was shined for developers of Android with the Android Studio release, which was available early on in 2013 and by the end of 2014 a stable build was released to the public. This launched the developers in a whole new direction.

It was all done so that it would bring in quality, resources and options in an effort to bring great apps to the consumer market.

For anyone that has followed Android from its early years in 2007, we've seen it grow, the evolution has been nothing but spectacular. We are now at a point where Android as an OS has matured and more so in Marshmallow.

While this may be somewhat complicated for the general consumer market to grasp the evolution that Android has been through beside the typical UI changes, developers went through loops with it over the last 8 years. Now today, we are able to see these changes, the effort in all the applications being released.

This leads me to talk about a very interesting project that was demonstrated at AndroidTO 2015, the 180 degrees matrix like photo by Ray Tsang group from Google. Ok, this was actually really cool! Setting up several cameras to take pictures in a matrix like effect with multiple smartphones doesn't sound easy, but Ray mentioned that they did achieve this within 3 weeks times they had it going.

Of course, since then, they've refined the process.

We had our own +Sivan Rehan take part into the matrix like effect!

There's a few things that had to happen before they could get to what you see. Finding the right tech or building it. Would some engineering be needed or could it be done with off the shelf items?

Ray did mention that they leverage a lot of the processing, storage directly from Google, it was now just a matter of getting this setup properly so that you could sync all the different phones with the same settings for the camera and getting an image that is synchronized and stitched together.

They did it! Which is why, they've been in demand to come to different places and show the technology at hand!

There was plenty of information being shared, whether this was from the speakers to the developers taking part, it was a very fun time. We were hit with a presentation called "Squeaky Clean Android" which presented developers with the proper ways of maintaining their code to make it faster, optimized and easy to understand. By doing this the right way the first time, it allows for a vastly improved code and performance, but it also provides developers an easier way to maintain the application they're working with.


The talk was centered around 4 points; Library, Domain design, Code quality and Unit Testing. It was highlighted that proper usage of libraries and selecting libraries that were relevant to your application was key, but it's not hard to see how this could get complicated over time if you don't maintain every part of your application.

Then came the time to talk about keeping the code simple, by keeping it simple, you are able to focus better, write faster, implement and maintain. Within your domain design, it's also important to use MV pattern, perform functional testing and use all the tools that are available at your disposal.

Now, if you're actively keeping everything simple, you'll be able to have descent code quality. You need to be able to read your code and understand it, even if it's months later. It was noted that many forget to use checkstyle, helps you, so why wouldn't you use it? It has the ability to detect many Android related programming issues and it just makes complete sense to use it, but while doing so refactor gradually and not all at once.

All the while, you should always perform unit testing on everything. A unit test generally tests the smallest possible unit of code (which could be a method, class, or component), without dependencies on system or network resources. Why not use everything you can, right? There's a need for having continuous integration and proper code coverage. This was an interesting talk and it brought to light some elements that even I didn't know.


The talk or I should say the highlight for me at AndroidTO was the talk about Google's OnHub. What was the reason behind the release of the Google OnHub? I wanted to know the why's. Google wanted to make WiFi better, faster, more performance, ease of use and to ultimately overcome what is referred to as "Broken WiFi, please fix" that consumers will experience.

They went to see typical users to see how they used their WiFi, the setup, placement, configuration. This allowed them to see that consumers were simply taking it the router, tucking it behind items, storing it in an enclosed space or they had it setup in the basement beside the cable box and in hopes to get a signal on the top floor.

With this notion, they wanted to make a device that would be somewhat user "proof" to some extent. There was a lot of discussion about how they should go about it. A lot of discovering, considering, purchasing, testing to ultimately come out with a product that would meet the consumer needs.

This led to the automatic channel selection for the router, to the best signal and performance possible that the On Hub will make with all the relevant data around it. Google wanted to make sure that this would be taken care of for them and not to have to play with all these different settings.

Using an audible signal coming from the speaker on the OnHub, Google was able to make the pairing of the router and phone, seamless to the user experience, but also more secure than conventional WPS. The network check on the OnHub lets you check to see your internal performance and as well see your Internet speed or if there's an issue. It's all part of bringing some diagnostics to the user. A sort of a feel better knowing what's going on.

Hiding latency and optimizing the information allows to pre-fetch, parallelize, dazzle & inform the consume all the while making the experience as painless as possible.

It was a very interesting conference, there was a lot of material presented and as much as I'd like to talk about everything, I had to choose a few points of interest among the various topics.

Congrats to BNOTIONS and the AndroidTO group!
Previous
Next Post »