The Android world is split in their choice between Eclipse and Android Studio as the preferred IDE. The momentum is definitely with Android Studio and in most of my talks this year, I have tried to push that message across to the developers that they need to start getting familiar with Android Studio. Yes, there would be bugs in Android Studio but get into the game while it is early.

Having said that, productivity definitely takes a hit if you have been in Eclipse land and coming over to Android Studio. This is because you are familiar with short-cuts (strange key combinations) that help you not just navigate your way, open files/classes, refactor code , be super productive with the editor and much more.

There is a great set of Android Studio tips that have been prepared meticulously with description and video by Philippe Breault. They have been even collected into a Github Repository for your reference. This is a fantastic collection of tips and one you should pick up one by one to get familiar and see the power of Android Studio.

Here are the 2 resources for your reference:

• Github: Android Studio Tips by Philippe Breault
• Google+ page of Philippe Breault

 

In the last month, I have presented on Android Wear on two Google Developer hosted events in India. Android Wear is a popular topic among developers and any talk on this topic brings up curious minds wanting to harness what wearable technology can bring to the table.

1. Google Developer Group Mumbai : This event was held on 12th October 2015 at IIT Bombay. I covered a 2 hour session that introduced participants to Android Wear and how to get started on Android Wear Development. More than 120+ participants were present at this event. This session was followed up by a session on Material Design by Faiz Malkani. Check out some pics from the event.
2. Google Developer Group Indore : This event was held on 1st November 2015 (as part of 2-day Devfest Indore) and we had a full day event dedicated to Android Wear. The event had a introduction to Android Wear in the morning following by a Code Lab and a Design Sprint on Android Wear. More than 60+ participants were present for this event.

Android Wear – Presentations, Code – everything for you

If you are looking at conducting similar Android Wear events, I have put up the entire material on Github. Feel free to use the material.

The material includes:

• Presentation Deck on Android Wear Introduction
• Code Lab PDF and 3 sample Android Wear projects to try out

In addition to the above, do check out official documentation from Google:

• Building Apps for Wearables
• Wear Design

I have also created other presentations / blog posts that could be useful to you:

• Introduction to Android Wear (No code)
• Casting your Android Wear screen to all
• Quick Tip : Setting up an Android Wear Emulator

Hope you find it useful. If you have any questions – reach out to me.

My article on getting started with Android Wear Development was recently published on ProgrammableWeb.

Here is the link.

If you are planning on Android Wear Development, chances are that you probably do not have an Android Wear device and wish to setup a Wear Emulator.

So, the scenario is something like this:

• You want to get started with Android Wear Development
• You have the Development Tools (Eclipse or Android Studio) and the necessary SDKs in place via the SDK Download Manager
• You have an Android Phone Device
• You do not have an Android Wear Device and wish to use the Emulator for that

Continue reading →

There has never been a better time to be a developer. I believe this statement will remain true irrespective of the times we live in.

As a developer today, it is important to look at the full stack when developing applications today. This includes :

• Web client
• Native client (Android / iOS / etc)
• Server side. Yes. You need the server too to power your mobile application functionality.

And not just that, it is important to understand design. Design is increasingly becoming an area that Developers need to understand and be part of, to create applications that not just wow your users but also make it intuitive to use.

As part of its Developer outreach, Google has teamed up with Udacity to provide several courses that address each of the above areas. These courses in my opinion are supported by best in class tools, teachers and materials and if you were looking to start off, these are great resources.

Here are the courses:

1. Android Development
2. UX Design for Mobile Developers
3. Developing Scalable Apps on App Engine (PaaS)
4. Website Performance Optimization
5. There are couple of other courses, which have been there for a while and are still available:
   1. Mobile Web Development
   2. HTML5 Game Development

All the materials have been completely opened up for access by anyone. You do not have to pay the $150 / month. Just sign up and go for the Courseware link.

I recommend these courses strongly and hope you do take them. For inspiration, check out Reto Meier’s article titled “Enabling the next 50 Million Developers” and build apps for all.

In a presentation that I recently did on Android Wear, one of my challenges was to cast my Samsung Gear Live watch to the audience, so that they can understand the basic working of the device.

Note that these set of instructions also apply in case you are looking at setting up a development environment with a connected Android Phone and Wear Device. So except for the last step, where you have to cast the screen to all, the rest of the steps are the same. 

In the past I have done Android trainings in which I have used Droid@Screen utility to do the same and I have a write up on that titled “Project Your Android Screen to All“, if you are interested.

The Android Wear device presented its own little challenges to get things working but I will lay out the precise steps here for you to follow.

Note that these set of instructions also apply in case you are looking at setting up a development environment with a connected Android Phone and Wear Device. So except for the last step, where you have to cast the screen to all, the rest of the steps are the same. 

Assumptions

• You have setup the Android SDK on your machine. Specifically, you need to be aware where you have setup your Android SDK and Tools and are aware of the adb command.
• You have an Android Phone that you have paired up with your Android Wear Device. This means that you have setup the Android Wear Play App on your Android Phone.
• You have an Android Wear Device (as of current writing, this means the LG G Watch or the Samsung Gear Live Watch) and it has been paired and setup successfully with your Android Phone.
• You are familiar with basic usage of the Wear device i.e. going to Settings and so on.

I have a Samsung Gear Live device and the instructions will contain screenshots from there but I assume that things will pretty much be the same on the LG G Watch too!

Step 1 : Enable Developer Options on your Android Wear device

If you have setup Developer Options on your Android Phone, the steps to do that on your Wear device is the same.

1. Go to Settings on your Wear device

2. Click on Settings and go to About

Note that you will not see the Developer Options item that you are seeing in the menu above if you are doing this for the first time. Since I have already enabled it, that’s why it is visible there. But your goal should be to get this option on your device and that is what is explained next.

3. Go to Build Number list item and tap that 7 times (yes 7 times!).

Once you do that, it will display a message that it has setup Developer options successfully. This should allow you to see the Developer Options in the Settings list.

OK, now let us move over to the Android phone.

Step 2 : Enabling Debugging over Bluetooth on your Android Phone

We are now go setup the debugging over Bluetooth between your Android Phone and Wear Device. To do this, follow these steps:

1. Launch the Android Wear App on your Android phone.

2. Go to Settings from the Action Bar. This should bring up a screen as shown below:

3. By default, the option Debugging over Bluetooth will not be selected. Selected that as shown above. This will show the following:

Host : disconnected
Target : disconnected

Our goal is to get both of these in the connected state.

Step 3 : Enable ADB Debugging on your Android Wear Device

Now, switch over to your Android Wear Device.

1. Go to Settings and then Developer Options.

2. Enable that ADB Debugging and Debug over Bluetooth are set to Enabled as shown below. If they are not, just tap on them.

 

Once you do this, you will see the Debugging over Bluetooth enabled on your Wear Device. This screen will be persistent on your Wear device. So once you are done with your debugging and want to go back to using your watch normally, do disable the ADB Debugging from the Settings->Developer Options->ADB Debugging on your Wear Device to remove this screen.

3. If you look at the Android Phone screen now, it should show the Target as connected, as given below:

 

In case you find that the Target is remaining in disconnected mode, simply toggle the Debugging over Bluetooth option and it should take effect. I have seen this happen sometimes.

Step 4 : Fire up a few ADB Commands

Great ! We now have to adb forward and adb connect commands to get the Host connected too.

To do this, launch the Command Line (Terminal). This will assume that you have the adb executable present in the PATH. The adb executable will be found typically in the <sdk>/platform-tools folder.

The two commands to give are:

adb forward tcp:6666 localabstract:/adb-hub

and then

adb connect localhost:6666

Please use any other port that you see fit. When you fire the 2nd command, a security confirmation dialog will come up on your phone. Please give the permission. This will finally, turn the Host also into connected mode and you are now all set.

Step 5 : Verify that both Android Device and Wear Device appear in the ADB devices

You could do that in two ways:

1. You can use the adb devices command to see a list of devices. On my machine, I see the following output:

Romins-MacBook-Pro:~ rominirani$ adb devices

List of devices attached
TA93305YW5    device
localhost:6666   device

The first one is my Android Phone and the other one is the Gear Device.

2. I can also launch the ADB Monitor and see that both the devices are visible:

You can now take screenshots if you want from within this tool itself for any of the devices. Cool, isn’t it ?

Step 6 : Use any of the ADB Screen Casting Tools

We are now in the final lap. We just have to select which casting utility now to use for projecting any of the screens, in this specific case the screen of our wear device.

I have used 2 utilities till now that both do the job and you are free to choose any one of them.

1. Droid @Screen

You can download this utility from here. It provides you a JAR (droidAtScreen-1.1.jar). The version numbers can change over time.

To run this utility, make sure you have Java setup on your machine and that the java executable is available in the PATH. Simply go to the Terminal (Command Line) and give the following command:

java -jar droidAtScreen-1.1.jar

This will bring up a screen which shows both the devices connected as given below:

You can optionally deselect any one of them and simply cast your Wear device as shown below:

2. Android Screen Monitor (ASM) 

You can download this utility from here. It provides you a JAR (asm.jar). Thank you to Adam Singer for mentioning this utility.

To run this utility, make sure you have Java setup on your machine and that the java executable is available in the PATH. Simply go to the Terminal (Command Line) and give the following command:

java -jar asm.jar

This will bring up a screen as shown below where you can select which of the two devices you want to cast. We shall select the Wear device setup on localhost:6666.

The utility then starts casting the Wear device as shown below:

Final Comments

I have found both these utilities good enough to do the job but there is one big problem at the moment. Since the bridging is over Bluetooth, there is a severe lag at times before the audience can see the screen refresh. This could potentially create confusion but I am not sure what can be done more to reduce this lag.

In my tests, I found the utilities performing much better on Mac rather than Windows and additionally the ASM utility displayed a much reduced lag as compared to Droid@Screen but you are free to do your own tests.

 

Let me know via the comments if you find this useful and if you have used other tools that are better and provide a much less lag, I would be happy to learn about that.

Firefox OS is something that I truly believe in. The extent to which we could possibly have a Web OS is going to be interesting to see and for a majority of applications, I believe the line between native and mobile web applications is too fine to go either way.

Towards this, I have been writing a series of tutorials on Firefox OS and I kind of hit some limits in trying out newer things within the Simulator. The Simulator at the end of the day is not a real device and hence some device specific APIs are not going to work in it.

I was delighted to hear about the next round of “Calling All Porters“, where you share an existing live web application with Mozilla and if they approve it, they will send you a Developer Preview device for helping you port your application and to keep the device with you moving forward. I submitted my proposal within the day and was happy to learn that it was approved. Fast forward a couple of weeks and I had the Keon Device with me. Before I go forward, a big Thank You to Mozilla for sending this across. It will really help me write more tutorials that cover more of the Device specific APIs and to keep myself updated with the latest releases, as they roll out.

I knew that this was a Developer Preview and should not be considered to be a real phone but I was determined to use it as a primary phone. The reason I want to do that is to see and understand if the OS and Device will help me in my pattern of daily phone usage. This is important if I am asked to give real feedback. If I am just told to use this as a Developer device for testing, I am sure it will work out and it does indeed. But by using it as a primary phone, I might unknowingly discover pleasant or unpleasant things and it could be useful in providing feedback. So here it goes.

Unpacking and Setup

I loved the conservative and simple packing of the Keon device. Setup was easy – nothing special about it. It was very thoughtful of Mozilla to send across a 4GB microSD card also since several applications on the FirefoxOS like Camera, Music player, etc work with that.

One little point for Mozilla to take note. The Orange color rocks but given that Microsoft Lumia phones and Asha phones are coming with several bright colors, I have seen people remarking if I have a Windows phone. You might face a brand identity problem in several geographics – that’s my feedback there for you.

Operator Signal Goes away after each call

This was a serious problem, which made me finally stop using the phone. The Signal Strength for the Operator (Vodafone in my case) become zero (no bars) after each and every call. I make a call or receive a call and once I hang up, boom .. the signal bars have gone and the Phone goes into Emergency mode.

In the beginning, I was confused and years of using Microsoft Windows has ingrained in me that if normal attempts don’t cut it – reboot the device. On doing that, the bars used to come back and I kept doing that a few times.

However, soon I discovered a routine that seemed to work every single time. Once the call is completed, the signal bars used to go away. Then all I needed to do was go to Settings and then tap on Call Settings. Just by doing that, I was able to get all the bars back. I don’t know what part of the phone hardware gets woken up or is reset, when I go into that Settings -> Call Settings, but that is direct feedback for the Phone and OS team.

However, it was not possible to remember to go back into Call Settings all the time and a few times, I was unreachable and that presented problems. I finally had to call it off.

Touch Screen Usage

I sweat a bit more (a lot more) than others. And boy when the screen was a bit dusty, the touch just did not respond. I faced several situations where there was an incoming call and the buttons to accept the call. All I had to do was click but the touch click just wouldn’t register itself. No amount of frantic hitting the screen seemed to do the trick too. On a few occasions, I ended up rebooting the phone and giving it a nice clean shine to get it into a state of normal touch usage.

Screen Flicker

I noticed that the screen used to flicker or almost contrast from very light to a clearer shade every once in a while while using the phone or unlocking it, etc. It was definitely not one of the smoothest and at times even jerking, almost like a bad television signal. Did see a few sort of distortion signals too. I kind of reasoned out that the Auto-Brightness here was playing some games. Something did not seem right with its clock. Hence I moved it from an Auto-mode to a fixed setting. And the problem did go away.

General Usage

I was quite happy with the general usage. I am not a heavy Internet user on the phone. I found the phone, SMS and Email apps pretty ok to use. I would love to have threaded conversations shown in the email (maybe it is possible to have that view style via a setting), but I don’t know how). Once I turned the word prediction on, I found it quite good while sending SMS. I think a better email client is something that I would definitely love on this phone.

I believe Adaptive App Search is fantastic and would appeal to a different segment of users, given the kind of App discoverability problem that we are seeing in iTunes and Play stores. For people who do not have the time to evaluate applications, the applications that come up in each segment (Social, Sports, etc) are good enough to meet your daily dose of information. And if any specific app does interest you, just add it to phone screen – almost like a bookmarking concept.

Developer Testing

This phone is exactly what it is – a developer preview. And towards that, I have no complaints. I plugged it in, the drivers got installed in a jiffy and the Device Connected message came up in the OS Simulator. The Firefox OS Developer Tools still rank the quickest that I have seen to getting things up and running.

My final experiment ended about 3 days after switching to it. I had to go back to my old and tired Android phone (2+ years) with its hardware buttons almost begging me to let them go.

I hope my review is useful to the FFOS team. At the end of the day, in FirefoxOS – I still trust.