Tag Archives: Android

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.

screen-image-pointerSo what do we know about what these smart watches can do? We know they’ll do what all watches do – tell time – but there’s a lot more as well. Wear devices will have a voice-input button that will trigger a launcher somewhat like Google Now.

Click the image to the right or follow this link for a quick animated example of the Android Wear user-interface.

They’ll also be able to display a number of different notifications to the user at the flick of a wrist. We as app developers will be able to make these notifications deliver a user’s response back to an app on your phone. For example, we can present the user with a notification from a messenger app that lets the user click a button to open the associated app on a phone. There’s also a “Remote Input” feature that offers the user the ability to speak a message to the Wear device that will be sent to the app on the phone.

Notifications are just the start. According to Google, down the road we’ll be able to do the following:

  • Create custom card layouts and run activities directly on wearables.
  • Send data and actions between a phone and a wearable with a data replication APIs and RPCs.
  • Gather sensor data and display it in real-time on Android wearables.
  • Register your app to handle voice actions, like “OK Google, take a note.”

What’s more, Google is working with an impressive list of hardware partners including Fossil, Samsung, HTC, Asus, and Intel. With all of the work they’re doing, one might wonder why they focused on notifications first. The most pressing reason is that this will affect every existing and upcoming Android device that offers notifications. Because this will affect so many apps, Google is trying to give us time to get our apps ready for the wrist. Regardless of whether your app was built with Wear in mind, users with Wear will be able to get your app’s notifications on their wrist. It’s in every app developer’s best interest to make sure that notifications are making their way to Wear.

Because this is so important for so many apps, we need to focus on how to interface with Android Wear correctly. Keep in mind that notifying users on their wrist is a powerful way to get information to the user, but it cannot be taken for granted. The goal is to give users information they need right when they need it. Users don’t want to be spammed with too many notifications. Instead, the focus should on maximizing signal and minimizing noise. For example, notifications shouldn’t vibrate unless they need the user’s urgent attention or action. A couple of examples that Google offers are a time-based reminder or a message from a friend. Similarly, a notification shouldn’t have sound unless there’s a good reason to. The goal with Wear is to make notifications glance-able. This means doing things like collapsing multiple notifications into a more compact view. There are five different priority buckets – Max, High, Default, Low, and Min. It’s important to know how to use these correctly. For more information on designing great notifications, read The Official Wear Design Guidelines.

We’re only scratching the surface of cool things that can be done to display information quickly while brushing disruptions aside conveniently. I’m excited to see what we can come up with next.

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

Why Developers and Consumers Should Care About The Android 4.4 (KitKat) Announcement

android-kitkat-google-surprise-chocolate-key-lime-pie-370x229Google quietly revealed the latest version of Android (4.4) today almost two months after announcing that this version would be nicknamed KitKat. Unlike the latest version of Jelly Bean (4.3), which didn’t introduce many new features features for consumers and developers, KitKat brings along a huge variety of improvements to the operating system.

The good news for developers and businesses with Android apps is that the vast majority of apps on the Play Store will not break in 4.4, and there are no major design changes that will make your current applications look out of place on a device running KitKat.

Let’s dive in and examine some of the new features!

For Android Users:

Fighting Fragmentation

The biggest change that Google is touting for KitKat is its ability to run on a wide array of devices. Thanks to a focus on slimming down the operating system and introducing new memory management techniques, Android can run on devices with as little as 512MB of RAM. This means that you will start seeing Android on more devices. Manufacturers have been making a big push with smart watches lately, and Google has been working on Google Glass for a while now, so we already have an idea of what low-memory devices running Android might look like.

Updated System UI

A more obvious change that users will start seeing as KitKat begins to roll out is that the system UI is getting out of the way. The status bar at the top of every Android device is now translucent, putting a bigger focus on your content and applications. KitKat also introduces a new “Immersive mode” for application that allow application to hide both the status bar and the navigation buttons. Videos, photos, games, and books can all take up 100% of your device’s screen.

Magic-Enhanced Search

Though consumers are using their smartphones as actual phones less and less these days, Google has given the boring dialer a push into the future with some Google search magic. Contacts are now sorted in the dialer by who you talk to the most and who is nearby, and local businesses will also be included in your search. When you receive a call from an unknown number, Google will use Google Maps listings to try to pair the caller with a name.

Integrated Messaging

Finally, Google has taken a page from Apple’s popular iMessage service by integrating SMS and MMS in the hangouts application. All your chats, SMS, MMS, and hangouts will be in one place on your phone.

Check out the complete introduction Android 4.4 for consumers here.

For businesses and developers:

The first new feature that businesses can leverage is the new printing framework. The printing framework allows applications to send content to printers that users have connected to their devices via WiFi or cloud printing services. If you are taking your application to a trade show, maybe you want to set up your application to print customized brochures, name tags, or other such items. Apps that allow users to create their own content (such as painting applications or photo-editing applications) can leverage these APIs to allow their users to print their content at home.

Animation Support

One area that Android has been consistently lagging behind iOS is in supporting animations. Though the animation APIs improved a lot in Android 3.0, Android has taken another huge step forward in 4.4. Developers can now define animation “scenes” that will make grouping animations for UI changes simple. Android 4.4 also provides default animations for scene changes, so developers may not even need to worry about creating their own animations.

Cross-Platform Solutions

Cross-platform solutions for mobile applications are very popular due to their ability to lower development time in some cases by keeping a single codebase for multiple mobile platforms. These applications typically run in a WebView in Android, which is essentially a miniature web browser in your application. These can be difficult to debug, and do not always conform to the same web standards that your desktop browsers follow. This is changing in KitKat with WebViews based on Chromium. These new WebViews provide support for HTML5, CSS3, and most modern JavaScript APIs, along with an updated JavaScript engine for better performance. Even better, WebViews are now debuggable remotely with Chrome DevTools.

Debugging

Debugging all applications for businesses has become easier thanks to screen recording. You can now take a video of your screen and send it to the developer to help demonstrate how to reproduce bugs. Businesses can also leverage this tool to help create promotional videos for the Play Store, giving users valuable insight into how the app looks while running.

As a part of KitKat’s focus on support for low-memory devices, developers also now have access to powerful memory diagnostic tools to see how much memory their app is consuming over time. This should lead to better app performance and fewer crashes.

This is just the tip of the iceberg for new developer features in 4.4. You can find the complete list of new features for developers here.

Potentially breaking changes:

There are a few changes that could cause some applications to behave unexpectedly in Android 4.4.

  • If your application reads from the public external storage directories, your application will need to request a new permission from 4.4 devices.
  • Applications that use WebViews will want to ensure that everything looks and behaves as expected with the new Chromium-based WebViews.
  • AlarmManager alarms may not fire quite when you expect them to, as alarms are now batched together with all apps that have alarms set to fire within a reasonably similar time frame.
  • Similarly, ContentResolvers that sync periodically will sync within 4% of the period you specify, so you shouldn’t rely on the sync occurring at a specific time.
Filed under Tech News, Technology

Square Cash – square dealio?

kwin-studio

KTWIN Logo 96.3

Nerdery Tech Evangalist Ryan Carlson and K-TWIN’s Cane & Co. talked about Square Cash and how it differs from PayPal for online transactions. Ryan also reports on the eye-popping stat that iOS users are 1,780% more likely to click on a mobile ad than Android users, and gives a shout-out to Nerdery CEO Mike Derheim’s TED talk.

Must-hear radio like this can be heard at 8 a.m. Monday mornings on K-TWIN (96.3 FM, Twin Cities). Or, hear our rebroadcast, here.

Play

NerdCast #51: Nerdery Webinar Q&A – Planning Your Mobile App in a Fragmented Mobile Landscape

NerdCastIn this episode of the NerdCast we have Ellen Shapiro the host of our recent webinar about building apps for multiple mobile platforms and welcome back Chris Black, a regular to the show to lend his experience for our Q&A in which we address the various questions that we couldn’t answering during the webinar. Some great questions about mobile planning and a few technical zingers at the end.

HostRyan Carlson

Guests: Ellen Shapiro & Chris Black, Interactive Developers at The Nerdery

Listen Now:

Running Time: 0:22:20 / Subscribe on iTunes

Play
Filed under NerdCast