Many of you already know the buzz going on with iOS 8 and some critical issues which occurred with Apple’s first iOS 8.0.1 software update on Wednesday, September 24th. A major bug with the HealthKit feature was discovered prior to the iOS 8.0 release, which resulted in Apple pulling all HealthKit enabled apps from the App Store ahead of the public release, leaving 3rd-party devs uncertain as to the fate of their Apps.
More than just Mobile Devices: Where touch detection breaks down
When you think of “touch,” mobile phones and tablets may immediately come to mind. Unfortunately, it’s far too easy to overlook the newest crop of touch-driven devices, such as Chromebook laptops that employ both a touchscreen and a trackpad, and Windows 8 machines paired with touchscreen monitors. In this article, you’ll learn how to conquer the interesting challenges presented by these “hybrid” devices that can employ both mouse and touch input. In the browser, the Document Object Model (DOM) started with one main interface to facilitate user pointer input: MouseEvent. Over the years, the methods of input have grown to include the pen/stylus, touch, and a plethora of others. Modern web browsers must continually stay on top of these new input devices by either converting to mouse events or adding an additional event interface. In recent years, however, it has become apparent that dividing these forms of input – as opposed to unifying and normalizing – is becoming problematic when hardware supports more than one method of input. Programmers are then forced to write entire libraries just to unify all the event interfaces (mouse, touch, pen, etc). So how did mouse and touch events come to be separate interfaces? Going forward, are all new forms of input going to need their own event interface? How do I unify mouse and touch now?
It’s not uncommon to encounter a few roadblocks during a project and the typical next-step might involve doing a quick Google search for the answer. Unfortunately there are occasions in which we are on own with a unique problem. In this case we had to roll up our sleeves and discover the answer that works. We hope this helps the next person looking for this answer.
“I spent a bit of time reading documentation and testing and getting increasingly frustrated.”
I ran into an interesting problem this week. I have a staging site in active development that needs to remain behind a firewall, but we plan to use the WordPress REST API to serve content from the site to iOS and Android Apps. Unfortunately, for the API to work Continue reading Apache Configuration for Testing WordPress REST API on Secured Sites
An experienced quality assurance (QA) engineer will have their spidey-senses tingling with every announcement of a new OS version, hardware refresh, or browser update. These are all good things for innovation, it just means we all need to be ready for launch day by starting to plan today. Continue reading Features Most Likely to Break When Upgrading to iOS 8 and What to Plan For
When a client asked me to address the performance problems with their Solr full-imports (9+ hours), I knew I was going to have to put on my computer-detective hat.
So you want to embed Google Maps in your website. Maybe you have a list of locations you want to display, or perhaps you need to provide directions or perform simple GIS operations. You’re a pragmatic person, so you don’t want to reinvent the wheel. You’ve settled on Google Maps as your mapping platform, acquired your API key, and you’re raring to go. Awesome! I’m so excited! Google Maps has great bang for the buck, and their API is well documented and easy enough to use. But there’s a downside. Google Maps has become the Power Point of cartography.
Responsive images are hard. At least for now anyways. The good news is a community of incredibly smart people have been working hard at providing a solution to this problem.
So what’s the problem?
Back in June of 2013 I was contacted by Packt Publishing to ask if I was interested in producing and publishing a video tutorial series after they saw a video of a live presentation I gave here at The Nerdery. I was a little hesitant at first, but after after some encouragement from Ryan Carlson, our Tech Evangelist, I went for it.
“Building a Single Page Web Application with Knockout.js” is a video tutorial series that guides the user through building a fully functional application using Knockout.js. The tutorial itself is aimed towards both back-end and front-end web developers with the assumption that the viewer has a basic level of familiarity with HTML/CSS/JS.
I designed the tutorial with the purpose of not only teaching the Knockout.js library, but also to introduce software architectural elements that are helpful when building a full-blown single page application. Knockout.js works really well with an architecture and structure more commonly seen in back-end development while using front-end technology, so the melding of the disciplines is something that many aren’t used to. When people start out with Knockout, they often end up building applications that aren’t scaleable. The tutorial we made focuses on application architecture for scalable websites using Knockout.js. This results in architecture (or lack thereof) that isn’t scalable in complexity.
The production took much longer than anticipated and other life events caused me to not have enough time to finish producing the videos in a timely fashion. It was at this point that I reached out to my fellow nerds, and Chris Black volunteered to help complete this endeavor. He did a fantastic job of recording and editing the videos to submit to the publisher. For anyone attempting a similar task, we found Camtasia was a very useful tool for this.
Here is a sample of the video we made
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.
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.
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.
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.
en = Off
tags = ios,android,web
comment = Off
de = AUS seit
es = Apagado
fr = Arrêt
nl = Uit
en = On
tags = ios,android,web
comment = On
de = An seit
es = Encendido
fr = Marche
nl = Aan
en = Edit
tags = ios,android,web
comment = Edit
de = Bearbeiten
es = Editar
fr = Modifier
nl = Bewerken
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.
tags = ios, Android, web
tags = ios,android,web
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.
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
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.
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.