Automated testing, both of the UI and the back-end service APIs, will make you more confident that everything works as intended and will reduce stress when developing, refactoring, adding new features, or changing existing ones.
Every Android developer, at one point or another, needs to deal with threads in their application. In this article, you will learn about some common scenarios in Android development where threading becomes essential and some simple solutions that can be applied to those scenarios and more.
Today’s constantly connected consumers are using smartphones in-store more than ever. A recent Google survey states that a staggering 80 percent of shoppers are using smartphones to make purchasing decisions. Retailers and start-ups have taken notice, and the concepts of mobile location analytics and proximity marketing are emerging out of that. But when you clear away all the buzzwords, what exactly is this shift we’re seeing? It’s the world customizing itself to you. The world is reacting to your presence, specific to you as an individual.
Testing back-ends is easy. You take your language of choice, pair it with your favorite framework, write some tests, and hit “run.” Your console says “Yay! It works!” Your continuous integration service runs your tests on every push, life is great. Sure, test-driven development (TDD) is weird at first, but a predictable environment, multiple test runners, test tooling baked into frameworks, and continuous integration support, make life easy. Five years ago I thought tests were the solution to every problem I’ve ever had. Then Backbone got big. We all switched to front-end MVC. Our testable backends became glorified database servers. Our most complicated code moved into the browser. And our apps were no longer testable in practice. That’s because testing front-end code and UI components is kinda hard.