I wrote a quick sample app that utilizes the step counter. It acts like a simple pedometer, registering for the sensor events when it starts, and updating the UI with the latest step count whenever a new event is returned.
This updating won’t be in real-time, as the system batches up events. The code currently specifies SensorManager.SENSOR_DELAY_NORMAL as the update frequency – this amounts to 200000 microseconds, or 5 updates a second (should be good enough, even if you duct tape your phone to a cheetah).
I’m using the TYPE_STEP_COUNTER Sensor, which dispatches an event with the total number of steps periodically when a new step is detected. The other Sensor is TYPE_STEP_DETECTOR, which fires a timestamp sensitive event with every detected step (rather than the total number of steps detected so far).
For now, this only works on a Nexus 5 running KitKat, since the API was added in KitKat and the Nexus 5 is the first device to ship with a dedicated low-power step detecting chip.
So, I’ve played with Google Play Beta Testing for Android for a couple weeks since Google IO now. I think there’s a lot of promise, but for now the process is perhaps a bit overly complicated.
Here are the steps to get it working (first time only):
Create a Google+ community for the Beta tester group
Sign into the Google Play Developer console, go to the APK section, then the Beta (or Alpha) tab and click “Manage list of testers”
Select your community
Now for each new person, you have to do the following:
Invite tester to community (might have to sign up for Google+, might have to learn what Google+ is, etc)
Make tester click a link to switch them to the beta build (format of https://play.google.com/apps/testing/com.your.package.name)
Send them to the Google Play store to download your app (again?) to get beta build
If they do these steps out of order, it won’t work.
I really appreciate the effort Google has made to make it easier to distribute Beta versions of apps directly from the Developer Console and how easy it is to “Promote to Prod” when a given build has passed beta testing, but I think the first-time setup process could be better, and they could open it up to people without Google+ accounts (I’ve had at least one person decline to Beta test because they’re afraid of social media.)
Since my last update, I’ve moved to Chicago and started work at Orbitz. Last summer, some of my coworkers told me about the Chicago Transit Authority (CTA) Bus Tracker API, which provides live arrival predictions for each of the 1,700+ buses and 11,000+ bus stops in Chicago. Upon closer inspection, I also discovered that the CTA had recently added an API to track live arrivals for each of the 145 El Train stops.
After working on Android apps during my time at Michigan, I was excited to continue Android development and build out an app that took advantage of the live prediction data.
As the saying goes, “good software starts by scratching a developer’s personal itch” and I began development by wiring up a really simple app that had 3 buttons (home and work), called to the CTA Train Tracker Service, parsed the response and displayed a dialog to with the predicted arrival time
As simple as this first product was, it was actually quite functional, allowing me to save several minutes off my commute each day. With this successful proof of concept, I began to build out a system that would be useful to more people around Chicago (after all, not everyone lives in my neighborhood and works in my building).
My primary goals were:
Build an app that integrated the Bus Tracker API, Train Tracker API and favorite stops.
Make it FAST.
All routes/stops should be stored locally and only need network to get live predictions
Make it popular, which means it had to be free and ad-free.
I spent the next few months working nights/weekends on and off to build out a 1.0 version of the app. I constantly “ate my own dog food”, using solely my own app when riding the CTA.
After about 2 months of part time work, I finished the first beta. I enlisted a few of my coworkers to try out the app on their phones and give me feedback. This included design tweak suggestions as well as bug reports. At this time, bug reports looked like “Sort by Time – Refresh still sets it back to sort by bus.”
At Orbitz, we practice a form of Agile development, which features frequent releases and constant iteration. I tried to iterate quickly and add features that I wanted to see in the app. A few lessons learned about self-development:
It’s easy to be ashamed of the quality of your product. Don’t be. Ship and start iterating.
Ship early and ship often.
Even if your customers are co-workers who aren’t paying anything for your product, this early feedback is invaluable.
Instrument like crazy
In my app, I have lots of settings. In early versions of the app, I had no idea how users interact with my app. Free analytics tools like Flurry are immensely helpful in capturing these interactions.
After beta-testing personally and with office friends, I finally released “FastTimes: CTA” version 1.0 on October 18, 2011. The first week, I got 43 downloads (!). I was estatic. 43 people wanted to use something that I created in my spare time!
Throughout the fall, I shipped several updates to the app, adding features, updating the stop list and improving stability. After joining the Orbitz Android team, I slowed down development somewhat, but have continued to grow the active user base to more than 4,650 active users today.
In the last year or so, the tools surrounding Android have gotten significantly better (although too many still start with “Robo”). Here’s a sample of what I use:
These tools are generally pretty well documented. StackOverflow is of course a great resource if you get stuck. Let me know if you have specific questions about integrating these tools.
One of the most exciting trends in the analytics has been the growth of Android 4.0+ devices to almost 30% of the active installs of the app.
In the 2.0 version, I plan to update the visual style of the app to be more consistent with the Ice Cream Sandwich design style. I also want to expand into more push notifications and increased analytics about app usage.
Special thanks to Rob, Jonathan and Hari for being my beta testers.
“CTA Train Tracker (SM)” , “CTA Bus Tracker (SM)”, and their associated logos are trademarks of the Chicago Transit Authority.
The opinions above are solely my own and do not reflect those of Orbitz Worldwide or its affliates.
The Challenge was created for college students at Michigan, MIT, Carnegie Mellon, U Toledo and U Texas to create voice-controlled applications that run on the OnStar in-vehicle platform. We were given access to the QuickFuse voice development environment to work with and test.
I decided to develop an application similar to Glympse, the live location sharing application for mobile phones. The application was designed to allow drivers to seamlessly share the location of their vehicle with friends and family in real time via a website and Android phone application.
I was selected as one of six semi-finalist teams selected from the original group of entries from Michigan, MIT, Carnegie Mellon, U Toledo and U Texas.
Of the six semi-finalist teams, three were from Michigan and the other three were from MIT. I was the only one-man team selected as a semi-finalist.
After going to the conference Tuesday evening and Wednesday morning, we presented our applications to the judges: Robert Scoble (scobelizer.com), Daniel Jacobson (Netflix API), Matthew Ervin (The Plum Group(Voice Apps)), and Jeff Liedel (OnStar VP). The presentations went well, but clearly the best presentation of the day was from an MIT group with an application called “EatOn”, which allowed drivers to find nearby restaurants. “EatOn” ended up winning the $10,000 Grand Prize, which they definitely earned.
Despite not winning, I was very happy to be selected as a semi-finalist. The talks I was able to attend were very interesting and useful. Highlights of talks include: