Tag Archives: Android

Apple and Google Announcements Point To The Same Horizon

 

apple-android-hero
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, you can see mobile devices sitting at the center of a connected web of devices and services – from cars to televisions to wearables.

If these other initiatives develop traction, expect to see their impact on each platform’s growth and consumers’ buying decisions in the years to come.

Cars: Car Play and Android Auto

Many cars ship with onboard navigation or entertainment systems; Apple and Google both seem to believe they can provide a better experience for users than the current manufacturers do. They’ve adopted similar strategies.

“Apple and Google have both shown themselves to be better at designing user-facing software than most of the car manufacturers. So, you should expect an all-around more polished experience…”

In contrast to electronics manufacturers who create hardware installed in cars, Apple and Google have each created a protocol for allowing a person’s phone to become the brains behind the in-car screen. By separating the device and software running the screen, from the device installed in the car, several significant economies can be realized.

First, people generally upgrade their phones more frequently than their cars or in-car entertainment systems – so the computing power driving the experience will increase significantly faster.

Second, Apple and Google have both shown themselves to be better at designing user-facing software than most of the car manufacturers. So, you should expect an all-around more polished experience and – based on the available demonstrations, both companies appear to have succeeded in that regard.

Third, Apple and Google have significant existing developer communities and the infrastructure to support those communities. Users are diverse and it is very difficult for a single company to fill every niche in a market. By opening the door to third-party developers, Apple and Google create the opportunity for companies like Pandora, Spotify, or MLB to create their own high-quality offering based on existing codebases and assets. Both companies expose a limited sub-set of the power of the operating system to third-party developers.

Most of the constraints in the programming interface are designed to prevent developers from creating apps that will lead to distracted drivers. There are some differences between the two offerings, but they are minor. Many major car manufacturers have announced support for both platforms. In this space, Google’s vision and Apple’s vision seem particularly aligned.

Television: Apple TV and Android TV

Apple debuted the hockey-puck attached to your TV in 2007. The first version looked a lot more like a Mac mini than the current hockey puck which wasn’t introduced until 2010; however, the core offering over that time has remained stable and grown. Today Apple, Roku, and Amazon are shipping products in the space.

“Feature-for-feature, it can be difficult to tell the platforms apart. Some provide voice controls. Some don’t, but core features are very similar.”

As of Google I/O 2014, Google is moving into that space as well with it’s Android TV product. The core of the offering is the ability to purchase or rent movies or television shows from the vendor’s online store. On top of that is layered apps that provide integration with streaming video services, streaming audio services and photo libraries. Control of the ecosystem can be managed from the user’s phone.

Alternately, a phone, tablet, or computer can wirelessly send a signal to directly take over the television as a second screen. Feature-for-feature, it can be difficult to tell the platforms apart. Some provide voice controls. Some don’t, but core features are very similar.

Google has announced support for playing video games stored and powered by Android devices and controlled with traditional-style video game controllers. Apple has all of the pieces in place to make a similar announcement (i.e. controller support and operating system support) – however, Apple has not made an official announcement. Both Google and Apple announced updates to their 3D graphics-programming APIs that appear to be directly targeted significantly at improving the gaming experience on their devices.

Computer: Mac OS and ChromeBooks

Apple has an approximate 7% market share for their OS X operating system. Google’s Chrome books have a minisicule market adoption, however, Google’s apps (e.g. mail, drive, and maps) have significant adoption rates. Both companies spent a portion of their dev-conference keynotes focusing on ways to make platform integration tighter.

From answering phone calls on the computer to automatically authenticating a user based on proximity or automatically synchronizing scroll-position when sharing the same document between two devices, the companies are experimenting with how to make the tranisitions between computer and mobile device seamless.

Health: HealthKit and Google Fit

Both Apple and Google have also announced support for centralized health-tracking applications. The initial feature-set is relatively limited. However, it is clear that both companies see a market here – likely driven by the success of Nike+ and Fitbit.

Not all of these initiatives will bear fruit, and not all of the initiatives will be equally effective for each company. However, given the close parallels between each company’s approach and announcements, it certainly appears that Apple and Google share a very similar vision for the technology that will shape our lives for the next few years.

Filed under Technology

What will Google do? A view from The Nerdery: Google I/O Extended coming June 25

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.

 

Filed under Events

Long-time listeners, first-time Soundset mobile App makers

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. Read more

Filed under Design, Events, The UX Files

What is Android Wear, and Why Should You Care?

google-android-wearGoogle 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? Read more

Filed under Tech News, Technology

Getting Better Analytics for Naughty Native Apps Using Crashlytics

crashalyticsSomething 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.

Filed under Technology

NerdCast #89 – Developer Download: Mobile Data Edition

NerdCastToday 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 HerbstJesse Hemingway

Listen Now: Running Time: 0:35:59 / Subscribe on iTunes

Watch on  YouTube: http://youtu.be/f8hK-Fk2Z7k

Play
Filed under NerdCast

Nerdcast #88: Webinar Q&A – Anatomy of a Successful Mobile App

Webinar Q&A: Anatomy of a Successful Mobile AppOur 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)

Play
Filed under NerdCast

Webinar – Anatomy of a Successful Mobile App

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).

Filed under Nerdery Webinar

The Challenges of Testing Android

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.

The 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.

Closing Thoughts

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.

Manage Localization Strings for Mobile Apps with Twine

Problem:
Managing strings between iOS, Android and the web is prone to error and hard to manage. When you introduce multiple languages, even more headaches arise.

Solution:
Twine allows you to keep your localized strings in a central location that can easily be exported to iOS, Android and the web. Twine is great for any multi-platform or multi-language application. It keeps your strings in sync. On a project I’m currently working on, we’re using Twine to consolidate and manage five languages across three different platforms. It’s saved us time and help to cut down on the cost of translations.

Getting Started:
Before you begin, make sure that you don’t have any hard-coded strings in your application. This is the first step in localization for any platform and a best practice for mobile development. Make sure to backup your existing strings. Next, you’ll need to install Twine. You can find instructions here: https://github.com/mobiata/twine

After you’ve installed Twine, create a strings.txt file that will be used for storing strings. Twine is able to parse existing string files and write them back to your master data file. Top-level categories can be used to organize your strings, tag attributes for selecting the target platform and comment attributes to give context.

Example:

[[Uncategorized]]
[Off]
en = Off
tags = ios,android,web
comment = Off
de = AUS seit
es = Apagado
fr = Arrêt
nl = Uit
[On]
en = On
tags = ios,android,web
comment = On
de = An seit
es = Encendido
fr = Marche
nl = Aan
[[General]]
[Edit]
en = Edit
tags = ios,android,web
comment = Edit
de = Bearbeiten
es = Editar
fr = Modifier
nl = Bewerken
[Done]
en = Done
tags = ios,android,web
comment = Done
de = Fertig
es = listo
fr = Terminé
nl = Klaar

The “tags” field is case sensitive and should not include white space. Keep this in mind when generating your strings file.

Bad:

tags = ios, Android, web

Good:

tags = ios,android,web

Output Folders:
Running the Twine command will generate you strings files and put them in the correct sub-directories. For iOS, they will be put in the Locales folder and for Android, they will be put in the res folder. You will need to create the corresponding lproj (iOS) and values (Android) folders for each language prior to running Twine. As long as the folders exist, Twine will automatically overwrite the strings files.

Running Twine:
To export for Android, put the strings.txt file in your project directory and run the following command. Note: this will replace your existing strings.xml files. Make sure to back up your strings and write them back to the master data file before running this command for the first time.

twine generate-all-string-files "$PROJECT_DIR/strings.txt" "$PROJECT_DIR/res" --tags android

The command to export for iOS is very similar.

twine generate-all-string-files "$PROJECT_DIR/strings.txt" "$PROJECT_DIR/$PROJECT_NAME/Locales/" --tags ios

Updating Strings:
When you have new text or translations, update your strings.txt file and re-run the commands. All of the string files within your apps will be updated. My preferred editor for viewing the string.txt files is TextMate. Built in text editors like Notepad and TextEdit can have problems opening large string files.

Summary:
We have used Twine on a number of projects with great success. It’s made managing strings and translations significantly easier. Anyone who is managing strings across platforms or supporting multiple languages should look into Twine.

Additional resources:
http://www.mobiata.com/blog/2012/02/08/twine-string-management-ios-mac-os-x
https://github.com/mobiata/twine

Filed under Tech Tips