- Senior iOS Developer
- Android Developer
- Dev Ops
- …and more!
A year has passed since our U.S. Retail Apps Report – 2013 Edition. By including rankings, reviews, and commentary about major brands like Walgreens, Amazon, and Best Buy, it attracted the attention of leading publications such as Forbes, Mobile Commerce Daily, and Biz Report. For these and other companies, the report was instrumental in helping them recognize our expertise in the space – for over 25 years, Pivotal Labs has developed award-winning mobile and web solutions across multiple industries, including retail, media, healthcare, and financial services.
Our 2014 report is no exception, having already been featured in Internet Retailer.
With their billions of dollars in annual revenue, the top 25 U.S. mCommerce retailers (based on Internet Retailer’s Top 500 Mobile Guide) certainly have the resources to build stellar apps that drive revenue, brand awareness, and customer loyalty. So why are some still falling behind, launching poorly executed products that tarnish the brand image and turn customers to competitors?
We investigate these issues and more in the report. Our 2014 report delves further into the features that users are looking for, how to build a high-performance app, and why great design is important. Using research based on public ratings and reviews from iTunes and Google Play, the report describes how retail apps have evolved and whether they meet the needs of their users. More areas of coverage include:
Download our exclusive 2014 Retail Apps Report – U.S. Edition to understand what retail apps are leading, what makes them successful, and why mobile is an opportunity for all retailers to boost engagement and drive the bottom line.
A few weeks ago, Google announced Android Wear – a development platform for extending Android to wearable technologies. This is an effort by Google to stay up-to-date with current trends over the past year which have seen the rise of wearable technologies such as the Pebble, JawboneUP, FitBit, etc. Keeping true with Google’s mantra, they have open-sourced the SDK for developers. The success of Android Wear really depends on the applications made by the developers using this SDK. Google’s aim is to leave it for the developers to figure out what they can do with this SDK and with the new UI guidelines, as well as how traditional smartwatch app concepts (fitness tracking, email and location services, etc.) will be put to use in a wearable Android environment.
While Wear may be adapted to different wearable devices, Google is currently focusing only on smartwatches. Traditional Android OEM partners such as Motorola, Samsung, LG, HTC and ASUS have already signed up. Almost all of the hype for Android Wear has been generated via the 2 launch devices:
LG G Watch: The first smartwatch to have the WearOS
The smartwatches will support features such as Google Now and a rich notifications system. Since the screen sizes are small, there is not much real-estate, and the Google Now cue cards system seems to be perfect for that. Additionally, like the MotoX, the Moto360 may take advantage of user gestures (e.g. twisting a wrist will show an alert for the next calendar event).
As for other devices, Google is already working with several consumer electronics manufacturers, including Asus, HTC, LG, and chip makers like Intel and Qualcomm, as well as fashion brands like the Fossil Group.
The Android Wear UI will have 2 main fragments centred around the core functions of ‘Suggest’ and ‘Demand’. The ‘Suggest’ function is a context stream of vertical cards that show useful pieces of information tailored to user specifications. Navigation is done by swiping vertically with only one card displayed at a time, and background images are used to provide additional information. All in all, the features seem to extend the functionality of Google Now. The ‘Demand’ space is brought up when the context stream is not able to anticipate what the user wants to do, and opens a cue card on voice commands (“Ok Google”) or tapping on a little ‘g’ icon. Unlike Glass, the Android Wear SDK allows developers to work more with voice commands in a more customizable way by sending Android intents that trigger specific voice actions in their applications.
Apart from its features, Moto360 also introduces a unique element to smartwatches – a circular design and UI. The Motorola blog boasts it as a watch that looks and feels great and gives you the information you need, when you need it. Considering Google is highly particular about developers making apps that follows strict UI guidelines, one of the more interesting aspects is to see what developers can do with the new circular design and get creative with the Android UI in a smartwatch context. This includes how they can make use of some use-cases that may appeal to consumers who like traditional smartwatches.
The circular UI demands maximum information to be conveyed in a flat, clear manner – demanding zero-to-low user interaction and contextual awareness. One comment by Lior Ron, VP of Product Management at Motorola states “….there’s something efficient, useful, and easy-to-glance-at in that round face; to take one look and get a 360. That circular shape allows you to convey that information.”
All in all, Android Wear design principles are substantially thorough enough to demand a separate blog article of its own, but it is definitely the most exciting part of the new Android Wear smartwatches.
Google has introduced a developer preview of its Wear SDK. The SDK allows notifications and voice commands, but developers can extend these features by customizing their app notifications for the smartwatches. Google wants developers to focus on making applications that are helpful at a glance and contextually smart – to display the right information at the right time while being aware of the situation and state. It also seems like Google doesn’t want developers to make full-fledged applications using the SDK, but rather just make use of APIs like Activity Detection to extend and enhance a regular smartphone app’s notifications with the Wear’s voice actions and special notification pages.
Some of the drawbacks the community has outlined include:
Fragmentation: The modular, open-source nature of Android makes development for Wear complicated because the developers will have to make/tailor applications for different designs and functionalities. Developers may just choose to support one platform over another with reasons being manufacturer preference, or even just design preference – a circular UI has less screen real estate than the traditional rectangular UI, and an app making creative use of the circular design will look weird and out-of-place with other layouts. This problem is not new to Android developers of course, and Google will have fleshed out the Wear SDK enough to make multi-device support a small burden to bear.
Battery Life: Smartwatches have always had to deal with the hubris of battery life. With the rich UI and action-intensive Google Now feel of Wear smartwatches, it’ll be interesting to see how that issue is dealt with. Some ways may include long-lasting batteries, or making it easier to top up charge while on the move, or even some combination of both. The MotoX was power-optimized, and Motorola has plans to optimize power consumption in a similar manner for the 360.
It is exciting to see the plans Google has in store going forward for Android Wear – custom UI for cards and data transfer between phones and watches. The first of the Android Wear smartwatches are scheduled to arrive this Summer, and by the looks of the positive reaction by the community, will certainly give the other wearables technologies some stiff competition.
Test-driven development is an iterative process of writing automated tests that define a feature before development, writing code to pass the tests, and finally refactoring the code to meet project architecture standards. The concept has been an integral part of software development since 1999 and Kent Beck championed it as part of the Agile Manifesto. Companies (such as Pivotal Labs) have made pragmatic use as they successfully developed client applications and internal support tools using this approach. As the world goes mobile, greater emphasis has to be placed on test-driving mobile development as well. Specifically, proper TDD is essential when you consider a platform such as Android, a fragmented and relatively test-hostile environment. This blog will be a highlight into the various testing frameworks available for Android, what’s nice about them and what’s not, and what will work to successfully TDD Android applications, relating it back to the importance of Mobile TDD in general.
There are multiple frameworks for test-driven development on Android. Most of these are built on top of the default Android JUnit testing library, and are useful for post-development testing. Android testing is tedious, but important and beneficial considering the vast, fragmented world of Android.
In current implementations in Pivotal Labs Toronto, we experimented with different testing frameworks on a few applications. This was helpful for the senior Android developers to figure out which framework suits their projects the best. As a result, Robolectric is currently being implemented successfully on certain major Android projects. The developers and QA collaborated to successfully integrate these projects with an internal Jenkins CI server and a Pulse Project Monitor, which ensures collaborative quality control and clean builds on every version control push.
Android TDD Generics
Android testing in general is done using JUnit and InstrumentationTestRunners that are provided by Google by default. These are good for writing Unit Test Cases after application development and prototyping. The class ActivityInstrumentationTestCase2<YourActivityName> provides complete functional testing, whereas the class ActivityUnitTestCase provides isolated unit testing of a single activity. Mocking is by default done using Mock Contexts. However, basic Unit Testing and mocking with the Android Dalvik VM has many speed and performance issues. This does not help the fact that Android is the most fragmented and, as a result, a rather hostile environment for test-driven development .
What about other frameworks?
Android has a handful of other frameworks set up to help developers practice TDD. Some examples include: Espresso and JUnit for on-device functionality testing; Robotium for user scenario testing (i.e. on-device GUI and UI testing); Robolectric for off-device testing ; and Borachio for easy on-device testing using mock objects . There are frameworks that take a more behavioural approach towards testing on Android. These include the Calabash framework, which uses the Cucumber language to write automated UI tests for post development.
Robolectric: An in-depth look
Robolectric was developed and open-sourced with love by Pivotal Labs. It uses the Java programming language to write tests, complementing Android’s default language. The framework provides testable behaviour by intercepting calls to Android classes through “shadow classes” and mocking part of the Android framework (contained in the android.jar file). Robolectric can be combined with build automation tools (Maven), mocking frameworks (Mockito), and dependency injection frameworks (Roboguice) to provide a modular way of testing bulk of the Android SDK functionality (including layouts, services and networking) in a more flexible manner than Google’s default testing framework.
An important feature of Robolectric is that it works without the need for emulation on a device or emulator, which can be slow and cumbersome. Robolectric instead runs your tests directly in the JVM (Java Virtual Machine), and reduces typical test overhead times significantly, thus providing the quick turnaround a developer needs to write tests, write code and then refactor . This also enables the developers to run the Android tests in continuous integration environments without any additional setup.
Having given a highlight for test-driven development on mobile, there do exist a few pros and cons:
1. In general, mobile TDD is extremely beneficial for agile companies. In an environment where developers pair-program for 8 hours a day in relatively large teams, and follow an iterative approach to weekly clean builds, it has proven to be highly useful for Pivotal Labs as a company.
2. Specifically in terms of Android TDD, Robolectric compiles tests and actual Java code, and runs the tests on the JVM. The framework tests your application’s core functionality and code without initial device setup. Provided the developer writes proper tests and makes them pass, he/she can be confident that the application behaves as expected when run on the device.
3. In cases when collaborating teams push changes to their project’s version control state many times a day, it is important to track the sanity of the builds. Android TDD frameworks are easy to integrate with Jenkins or other CI systems, and build states can thus be visually logged in Pulse trackers or internal TDD Dashboards. Robolectric in particular makes this process simpler, as it tests your application on the JVM and CI integration requires no additional setup.
1. In a mobile development world, where projects move fast and clients expect rapid delivery, test-driven development is a time consuming process. Robolectric requires the following to be set up – Maven, Android Studio, an Android SDK deployer (Maven-based), and all global and IDE-specific paths to be set up just the right way. This setup ensures that the project is set up for every pair on the team to run tests and deploy the application as they want. For a developer coming into the project and accessing a workstation not set up for Android/TDD development, this could take up to a day. And in the world of mobile where sprints can be as small as a few weeks, this is a day lost in project ramp-up.
2. The architecture and design patterns and scope of the project may have to be rethought. Developers need to achieve a fine balance between writing sensible tests for a feature, and planning and designing the project architecture that include that feature. It is important to know if the code written to pass tests in specific areas fits in well with the overall project design. An example could be: if a developer is writing network architecture for a retail application where thousands of transactions could be happening every hour, then the code should be architected to ensure scalability, reliability and security, and tests should concentrate on the stability of these broader concepts. But, doing as much TDD as possible can solve this problem – practice makes perfect.
In the end, mobile TDD has its pros and cons, but certain tools like Robolectric reduce testing overhead and allow for easy setup with CI. Experience proves that when developers practice it consistently and in a disciplined manner, the pros outweigh the cons, and definite results are visible in the long-term. TDD methods have thus become the primary approaches for agile companies to ensure effective architecture, requirements and design.
This past week the Pivotal PM team engaged in a discussion about a blog post that claimed that our love affair with tablets was over.
It seems that many of us have tablets and use them in a variety of ways. We think that tablets are a great way for people who are new to computers to get their feet wet, but we generally still use our laptops to get work done.
Here are some ways we think tablets will continue to be helpful:
When traveling: It’s a cheap computer to take with you to watch movies, store photos, check email, video chat, and browse international non-mobile friendly websites
For the kids: Tablets are not only the perfect size for little hands, but their intuitive interfaces are great for even toddlers to play around.
If you’re reading A lot: It is much lighter to carry than multiple books and is more eco-friendly for reviewing PDFs / news/ magazines. Also, they allow for quick googling of more info.
By event marketers: Teams of event marketing folks use them to quickly collect prospects’ information at street fairs, conferences, and expos.
When a laptop is too much: Note taking in meetings, sales presentations, emails on a train, viewing docs from a cloud drive, etc.
On the non-responsive web: There are still millions of sites that have not been mobile optimized yet.
Tell us what you use your tablet for…
I have seen many design mockups for Android applications that were beautiful but did not translate appropriately to devices. The mock up/design process tends to happen separately or before the development process and reconciling the two can become a time-consuming process. Designs also set expectations and imply user flows that do not always translate to the development paradigms Android enforces. Here are a few concrete steps that will help you minimize some of the churn.
Many of you know how slow the emulator is. Programmers are likely to have finished development and submitted the app to the Play Store before the emulator is done booting up. Fortunately, Google announced that the emulator can now run native on the machine, therefore performing much faster. I spent a bit of time working on this and figured out a useful workflow!
We do a lot of Android software development at Xtreme Labs. Every two months we have a retrospective meeting to look back and reflect on the exciting discoveries, petty frustrations, and disseminate our findings to the group. There are some lessons that we’ve learned time and time again.
Until recently, Android design lacked definition and we had to fend for attractive apps as best we could. Now with Honeycomb and Ice Cream Sandwich, Google has shaped up and come out with an awesome design vision for the platform. For 3.0+, beauty can be native and the Action Bar is the new standard.
Yet, the majority of the Android market isn’t 3.0+, and isn’t likely to be for a while. Back-porting is time consuming, but Jake Wharton has conveniently done almost all of it for us with his ActionBarSherlock library.
A few weekends ago, Jamie Halpern and I presented at FITC Spotlight: Android to teach new Android developers in the tech community in Toronto their first steps in Android development. Jamie did a great presentation at the event on how to move an iOS app over to Android. We had a great time sharing our experiences at this event.
The Business News Network is now stretching its reach a little further to bring you the latest business news wherever you go. Xtreme Labs is proud to be part of BNN’s mobile portal, designed for today’s business professional on the move. Getting your fill of business news has never been easier.
Powered by XL Magic, BNN Mobile delivers on-demand clips for shows such as MarketSense, Headline, Market Call and Market Call Tonight. In addition, you can also find blogs by prominent BNN personalities and up-to-date schedule information.
Offering a streamlined experience on multiple devices including iPhone, Android Phone and BlackBerry, BNN mobile is your destination for business news. Check it out today by clicking here but we encourage you to experience it in your mobile web browser.