Feeling overwhelmed? Start here.

[Jerry McManus]

I've noticed that a few teams are getting a bit overwhelmed by the switch to Android based robotics. It's easy to see why, there is a lot to learn if you are new to Java and/or Android. The biggest problem seems to be people trying to learn it all at once, which can easily get painful. Much better to take it one step at a time. There are a ton of resources available for learning how to write and deploy Android apps that people can start doing now, long before we get to see the FTC SDK. Here are my recommendations:

STEP ONE: Learn Java.

If you have no experience with Java then this is the place to start, especially before you tackle Android development which has its own complicated SDK to master. And remember, Java is a compiled language and is NOT the same as Javascript which is a web browser based interpreted language.

A google search on "learn java" yields thousands of results, here is a nifty online learning environment that you can start using now without installing a Java IDE:
http://www.learnjavaonline.org/

Which brings us to:

STEP TWO: Install and learn to use a Java IDE.

Once you are familiar with Java basics it is time to take the plunge and install an Integrated Development Environment (IDE). The obvious choice is Android Studio:
https://developer.android.com/sdk/index.html

but there are other options available including Eclipse (among others):
http://eclipse.org/users/

It is important to note that the Android SDK and Android Development Tools (ADT) can be installed after you install a Java IDE. In the days before Android Studio it was typical to install an IDE such as Eclipse first and then install and configure the Android SDK and ADT.

If you choose to install Android Studio as your IDE then installing and configuring the Android SDK and ADT is already part of that installation process. Much more information here:
https://developer.android.com/sdk/index.html

The other IDE option that has been endorsed by FTC is the MIT App Inventor, a cloud-based tool which means that you can build apps right in your web browser. More information here:
http://appinventor.mit.edu/explore/

STEP THREE: Learn how to create and deploy Android apps.

This is where most teams are really going to need to do their homework. The Android SDK can seem overwhelming at first, and there are a number of concepts that are unique to Android such as "activities" and "intents". There are also a number of different "flavors" of Android SDK to choose from (and new ones coming out all the time), so it is important to understand what your target SDK is and what features it supports.

Fortunately there are a ton of resources for getting started with the SDK on the Android Developers website:
https://developer.android.com/training/index.html

It is well worth taking the time to thoroughly understand the basics of the Android SDK before you tackle the next step, which is:

STEP FOUR: Mastering the Android development workflow.

Your first taste of this should be the "hello world" app at the training link above, but at a minimum you should learn and understand all of these concepts:

- Creating an Android project from scratch
- Connecting and managing devices for testing, these can include software emulators known as "AVD's".
- Compiling and deploying an app to a device from the IDE
- Debugging an app from the IDE

Much more information here:
http://developer.android.com/tools/workflow/index.html

STEP FIVE: Mastering the Adroid Debug Bridge (ADB)

For much (if not most) Android development this step is optional, ADB typically works in the background to manage connected devices and it is usually enough to simply connect a device over USB cable, or create software emulators, and let ADB do the rest.

For purposes of FTC, however, it could be extremely useful to understand how to connect devices wirelessly to avoid being tethered to a USB cable. This is where mastering ADB comes in very handy. There are a number of command line options available for viewing and interacting with connected devices via ADB, including options for connecting to devices wirelessly. Much more information here (scroll to bottom to see wireless instructions):
http://developer.android.com/tools/help/adb.html

If you do not have (or do not wish to use) an available wifi network for wireless communication then you may need to take the extra step of setting up a host network on your dev machine. Fortunately this is not hard to do, more information on how to do this in Windows8 here:
http://www.serverwatch.com/server-tu...windows-8.html

It is very important to note that ADB is NOT the same as the debugging environment which is invoked manually by either running the app in debug mode or setting breakpoints in the code. You can also use the Logging service to output simple events and messages to the Log window without invoking the debugger. More information on debugging here:
https://developer.android.com/tools/...ng-studio.html

STEP SIX: Robots!

Now that you have mastered all of the steps above you are finally ready to program some robots! Unfortunately, at the time of this writing, the FTC SDK has not been released and so we do not know much about the specifics of it yet.

We do know that the primary purpose of the SDK is to interface with the new USB control and power modules, and that it will probably come in the form of Java libraries that you make available to your Android project via the IDE.

FTC has also made clear the intention to provide template Android projects and other training resources available for those that don't mind waiting until the SDK is released. More information here:
http://www.usfirst.org/roboticsprograms/ftc/technology
http://firsttechchallenge.blogspot.com/

This is not meant to be a comprehensive guide to Android development by any means, but hopefully it will help get people started with as little pain as possible. Keep an eye on the FTC technology forum for more details and helpful answers:
http://ftcforum.usfirst.org/forumdis...FTC-Technology

[mannie]

I've noticed that a few teams are getting a bit overwhelmed by the switch to Android based robotics. It's easy to see why, there is a lot to learn if you are new to Java and/or Android. The biggest problem seems to be people trying to learn it all at once, which can easily get painful. Much better to take it one step at a time. There are a ton of resources available for learning how to write and deploy Android apps that people can start doing now, long before we get to see the FTC SDK. Here are my recommendations:

Jerry:

Great post. Can we quote it in our team and partner websites to help share the knowledge?

Mannie

[hexafraction]

A lot of it also seems to be that Android is extremely expansive--activities, intents, media handling, threads, services, etc. A lot of this simply doesn't apply--a lot of these APIs only really need a reference to the Context and proper choice of threads.

(speaking of which, when we extend OpMode, will we be able to get an Android Context reference in order to do stuff with the device's onboard sensors/equipment via a SensorManager?

[Jerry McManus]

Jerry:

Great post. Can we quote it in our team and partner websites to help share the knowledge?

Mannie

Thank you! Yes, please do share this as much as you wish.

[Jonathan Berling]

(speaking of which, when we extend OpMode, will we be able to get an Android Context reference in order to do stuff with the device's onboard sensors/equipment via a SensorManager?

We added the app context to the hardware map.

From your op mode, use:
Context context = hardwareMap.appContext;

This should allow you to access the various sensors on your Android device, along with anything else that requires the app context.

[hexafraction]

Thanks! I'm guessing hardwareMap is how we access all FTC/ModernRobotics-specific sensors, controllers, and modules?

How do we "declare" controllers and ports (as RobotC did with their #pragma config statements)? Can we do it as a runtime step (e.g. parse a config file of our own and use it to configure motor and servo controllers)?

[Philbot]

Hi

I have a ZTE Speed phone and I'm trying to setup the ADB driver on my Windows 7 32 bit machine.

I know this can be tricky, but I've recently done it successfully for a different Android device.
I've been writing and deploying apps on that device for a while.

On my "Other Devices" list The ZTE phone shows up as "ADB Interface" with a yellow exclamation (as expected).
I just can't seem to find a driver that the "Update Driver" step likes.

I started with the generic "\extras\google\usb_driver" driver, and windows says "Windows Cannot find driver software for your device".
After this I downloaded several ZTE drivers I could find, but none were specifically for the Speed. Regardless, none worked.

It would sure be great to find a master driver, or start making a ZTW Speed Driver collection for the different Windows versions available as an FTC resource.


Phil.

[Philbot]

Hi

I have a ZTE Speed phone and I'm trying to setup the ADB driver on my Windows 7 32 bit machine.

Phil.

Never mind, I found the solution to my problem.
In order to operate in ADB mode (required for Android Studio) I needed to turn set the phone to "USB Charging only."
This enables the Phone to correctly identify itself as supporting the Android Developer Bridge, and allow windows to select the correct driver.

This effectively stops the phone from appearing to Windows as a Media Device (for file sharing).

When set up as a Media device, the phone appears on the Windows "Devices list" as a "Mobile device", AND an "Other Device".
When setup to use the USB for Charging Only, and "USB Debugging" enabled, the Phone shows up on the Device list ONLY as a "ADB Interface".

I got to the appropriate screen on the Phone by swiping down from the top, clicking the USB icon, and then turning on "Charge Only" and "Enable USB Debugging".

This caused the correct driver to be loaded automatically. Now Android Studio can see the phone.

[AlanG]

The approach that succeeded for me is a bit different: I went into the ZTE's "Settings" menu and selected the "Connect to PC" settings. On that screen, I selected "Install driver", which automatically deselected the default "Media device (MTP)". Then, the first time that the ZTE connected to my laptop (running Windows 7 SP1), the Windows "ADB Interface" driver was among the drivers loaded onto the PC. Once that wireless connection to Windows' "hostednetwork" was made for the first time, I was able to use the Command Prompt window to do all of the "netsh" and "adb" commands that I needed to.

[Philbot]

The approach that succeeded for me is a bit different: I went into the ZTE's "Settings" menu and selected the "Connect to PC" settings. On that screen, I selected "Install driver", which automatically deselected the default "Media device (MTP)". Then, the first time that the ZTE connected to my laptop (running Windows 7 SP1), the Windows "ADB Interface" driver was among the drivers loaded onto the PC. Once that wireless connection to Windows' "hostednetwork" was made for the first time, I was able to use the Command Prompt window to do all of the "netsh" and "adb" commands that I needed to.

Cool, that sounds like it eliminated the step to locate a driver. I'll try it on the next phone setup.

Speaking of multiple phones... Have you found how to give the phone a custom name (like team number or drive/robot designation?)
All the generic help I found points to an option to change the name on either the "About Phone" or "Developer Options" settings menu.

But none of these options seem to exist on the ZTE phone.

My phone just shows up as ZTE N9130 Which is the make and model.

This is OK when you have a couple of phones, but how does it work with 100 in a room?
eg: How is the name displayed when doing a WiFi direct binding?