Our collaboration with composer Eric Whitacre to be featured at BBC Proms
In choral-music circles, Eric Whitacre is among the genre’s rock stars. An innovator in many ways, Eric hired The Nerdery to create a mobile app that he envisioned would allow his audience to become part of the performance by using their mobile phones, on his cue, for a shared musical experience.
Continue reading Deep Field App: Royal Albert Hall, Here We Come
It’s striking how closely Apple’s and Google’s recent slate of announcements parallel each other. Their respective developer conferences both focused on platform integration. Both iOS and Android are moving outside of the phone. The nature of that integration will have lasting effects on the way people interact with the world around them.
“…If you look at the strategy that each company is pursuing regarding their mobile operating systems, you can see mobile devices sitting at the center of a connected web of devices and services – from cars to televisions to wearables.”
In the late nineties, Apple was pushing the idea that your computer was the digital hub of your life. All your other gadgets (e.g. digital camera, iPod, video camera, etc.) were to be managed and coordinated by your computer. Today, if you look at the strategy that each company is pursuing regarding their mobile operating systems, Continue reading Apple and Google Announcements Point To The Same Horizon
Tech watchers not bound for San Francisco for Google I/O are welcome to experience Google’s annual developer conference at The Nerdery, an official Twin Cities host of Google I/O Extended.
Nerdery guests (clients, students, passersby, you?) for this free Google I/O Extended event will watch the keynote (11am-1pm, lunch served) and select portions of the Google I/O livestream on the Nerditorium’s big screen and engage with a panel of Twin Cities tech experts who’ll decode Google’s announcements.
Post-keynote, we’ll analyze Google I/O’s key takeaways, which will essentially be new marching orders for developers – and put context around what it all mean for users. Nerdery devs will present talks of their own on new Google tech, including Glass and other wearables. The Nerds who helped build Chrome Cube Lab in partnership with Google in support of their Rubik’s Cube Doodle will also give a talk.
What to expect when expecting Google I/O
Will Google release the hounds? Since they’re not in the hound business (that we know of) it’s more likely they’ll announce the release of the next Nexus phone and/or tablet, or a smartwatch or some other Android-Wear gadget that works with Google Fit, or a new version of Android, or maybe more apps for Chromecast – or all of the above. We’ll be watching/reacting. Join us? Full schedule and RSVP on our Google+ page.
Several Nerds will enjoy what’s become a traditional Memorial Day weekend at Soundset this Sunday, but for the first time there’s an app for that fine festival – and that’s because we built it for our friends at Rhymesayers. Continue reading Long-time listeners, first-time Soundset mobile App makers
Google rocked boats recently by announcing Android Wear. “What is Android Wear?” you ask? It’s a specialized version of Android designed to run on wearable computers. Right now, we’ve already seen two Android Wear devices slated for release in Q2 of 2014 – the square LG G Watch and the round Moto 360. These watches will pair with any Android handset running Android 4.3 or greater. This is a refreshing change from smart watches such as the Galaxy Gear which restrict the owners to pairing with the few compatible Galaxy devices. Right now, both of the Android Wear devices publicly announced are currently considered “smart watches.” However, the name “Wear” means more product form factors will be explored in the near future according to the lead designer of Moto 360.
So, what is to know about these devices? Continue reading What is Android Wear, and Why Should You Care?
Something most people don’t think about is what happens after someone presses the button to release an app into the wild. Development doesn’t always stop, issues crop up, and bugs happen. It doesn’t matter how much testing goes into an app or how many devices someone tested against. There will always be slightly different configurations of phones out there in the hands of real users. Most times, developers need to rely on vague bug reports submitted by users via reviews or emails. Thankfully there is something better we can do to lessen the burden of discovering where those issues are hiding in our apps. There are now tools we can use post-deployment that can track usage and even point us right to the issues at hand. The tool I will be covering today is called Crashlytics.
Crashlytics is a plugin for Android and iOS which is added to your projects via your IDE of choice. You simply download the plugin, add it to your IDE, and then follow the instructions to tie that app to your Crashlytics account. That’s it! You’re then ready to begin receiving analytics for your app. If the app crashes, you get everything from device type, OS version, whether or not the phone is rooted, current memory usage, and much more. The crash itself is detailed with the offending line of code, where it’s located, and if applicable the exception thrown.
The detail given for issues discovered by apps is great, but it gets better. When Crashlytics receives a crash dump it is categorized so the developer can easily sort issues. Crashes with more specificity than others are given higher priority, which means Crashlytics performs a level-of-issue triage for you. It will also lessen the severity of issues automatically if they stop happening for whatever reason. You can also specifically close issues as fixed in Crashlytics once you address them. This can be extremely powerful when coupled with bug-base integration, which is another useful feature of Crashlytics.
Crashlytics can be integrated with many different bug-tracking systems. These include Jira, Pivotal, and GitHub, among many others. In my experience this is one of the most helpful features of Crashlytics . Once a crash is received, Crashlytics automatically creates a bug in your issue tracker of choice and populates it with the relevant information. It will then set the bug’s severity for you – based on the number of crashes detected – and keep it updated. This is extremely helpful and time saving. It takes the burden off of testers and developers of transferring issues from Crashlytics to the bug base and keeping it updated.
These are just some of the powerful features packed into this tool. Another large plus of the tool is that it has become free after Crashlytics partnered with Twitter – they’ve promised to keep developing the tool and add even more features. I hope I have convinced you that discovering and fixing issues post-deployment doesn’t have to be a chore. With the right tools, it can be a relatively easy experience that will benefit users and developers.
Today on the Developer Download we are following up from our webinar Q&A earlier in the week, talking all things nerdy with respect to mobile data. We talk with 3 Nerdery developers who have experienced it all with mobile data. We talk best practices for clients and server, data caching strategies, api security and much more. And now you can watch the Developer Download if you you prefer. Hit the YouTube link provided below!
Host: Andrew Watson
Guests: Maxwell Vandervelde, Bryan Herbst, Jesse Hemingway
Listen Now: Running Time: 0:35:59 / Subscribe on iTunes
Watch on YouTube: http://youtu.be/f8hK-Fk2Z7k
Podcast: Play in new window | Download
Our webinar panelists reflect on questions about the makings of a good mobile app from our webinar audience – burning questions we just didn’t have time to address during the live event. Missed the webinar? Let’s take care of that right here then.
Host: Brian Rowe (UX)
Guests: Andrew Watson and Jon Rexeisen (mobile developers) and Jacob Ward (UX)
Podcast: Play in new window | Download
Consider the mobile apps you use all the time, and the ones you perhaps opened once or twice and then never touch again. There are so many things that factor into such variable quality, utility and popularity – and understanding the difference-makers is critical to anyone who has a hand in creating mobile experiences. Whether you make apps or simply use and/or discard them, this discussion will help you understand the key elements what makes for a successful mobile app.
Hosted by Brian Rowe (UX), this webinar features Andrew Watson and Jon Rexeisen (mobile developers) and Jacob Ward (UX).
There comes a time in every QA Engineer’s life when they are tasked with testing their first project on the Android platform. This sounds like an easy enough task. Just grab a few devices and follow the test plan. Unfortunately, it is not so easy. The constantly growing list of devices with a wide range of features and the different versions of Android all supporting a varying set of those features can seem very daunting at times. These two obstacles are only compounded by the device manufacturers who, most often, do not provide their devices with stock versions of Android but instead versions modified for their devices.
Android devices come in all shapes and sizes, each with their own hardware profiles, making it difficult to ensure an app’s look and feel is consistent for all Android users. An application may look pristine on a Nexus 5, but load it up on a Nexus One and pictures might overlap buttons and buttons might overlap text creating a poor user experience. It is critical we help the client select relevant and broadly supported Android devices during the scoping process, which can be tricky depending upon the application.
The Operating System
Three versions of Android currently (Feb. 2014) capture the largest market share: Jelly Bean, Ice Cream Sandwich, and Gingerbread. The newest version, Kitkat, holds only a 1.8% marketshare. We must be mindful of features unavailable on the older versions of Android while testing applications. If an app has a scoped feature not possible on some devices, we must be sure it gracefully handles older versions of Android and does not crash nor display any undesirable artifacts. The above-mentioned stumbling blocks are easily avoidable if we can pick a good range of targeted devices to cover the appropriate versions of Android.
Compounding the Problem
There are some lesser-known issues that can be easily missed, but would be disastrous for an end user. Most versions of Android installed on a user’s device are not stock – they are modified by the device manufacturer. As a result, testing an app on one device from one carrier might give you different results than testing the app on the same device from a different carrier. Knowing this can provide a buffer for these sorts of issues and ensure we are readily able to detect and squash those bugs.
Consider these common problems as food for thought while testing on the Android platform. Google may be taking steps towards alleviating some of these common Android issues for future releases. First, it is rumored they will begin requiring device manufacturers to use versions of Android within the last two released or not be certified to use Google Apps. End users would definitely benefit from such a decision, but it would also be good for developers and QA Engineers. The move would also lessen the fragmentation issues currently prevalent on the Android platform. Second, Google continues to provide new testing tools with each new release of Android, making it easier to ensure apps are stable across a wide range of devices. Third parties are also making tools available for a wide range of testing. These tools include new Automation tools that function differently from native tools and allow testing across platforms. Some tools tools encompass walls of devices running your app viewed through a webcam so people can easily test across device types using online controls. Scripts and other automated tools are great for making sure nothing is broken during any fixes and ensuring a service is up and running. However, nothing will ever replace a QA Engineer getting down to it with a range of actual, physical devices, testing without discretion, and finding bugs. A human’s intuition will always be the best.