We’ve been using Redux a lot lately at Atomic, and we’ve come to appreciate how a centralized holder of application state can simplify application architecture. In a few different projects, we’ve used this architecture as inspiration for mobile applications in Objective C, Java (for Android), and Swift.
In Part 1 and Part 2, I showed you how we structured and styled a decimal picker for mobile devices. In this final part, we’ll set up a basic Ember.js app to showcase the control and then wire up its components.
In Part 1 of this series, I laid the groundwork for setting up a custom decimal picker. In this post, I’ll show you how to finish styling the control. To make our decimal picker look just right, we employed some advanced CSS trickery.
Read more on Super-fast Numeric Input with HTML Ranges – Part 2…
During a recent project, we were tasked with improving the experience of entering a handful of decimal numbers into a mobile web app. In this part of the app, we knew users would be repeatedly entering a number, followed by a decimal point, then two more numbers. The stock ascii keyboards were cumbersome, requiring seven taps and an awkward page scroll on most devices. The numeric keyboards saved a tap or two depending on the platform, but they still suffered from the page scroll problem. With either generic keyboard, we knew we’d have to add form validation to make sure the values were in the right range. Read more on Super-fast Numeric Input with HTML Ranges – Part 1…
Our tests were crashing. They ran fine individually, but when run as a group, certain tests sometimes failed with a spectacular memory access error.
After experimenting with skipping some of the tests, I was able to narrow it down to tests that ran immediately after some database calls. (This was a mobile project for iOS, and we were using Realm.)
For a recent project, a client wanted a mobile phone application that would work across both iOS and Android. As someone with more experience with web development than either iOS or Android, turning to Adobe’s PhoneGap seemed a fairly obvious path. I would be able to leverage more of my existing skill set, and could use awesome tools like Ember.js.
I started digging through some getting started guides for PhoneGap and quickly realized that the default platform and build management tooling (cordova-cli) had no support for any sort of asset processing. Read more on Using Ember CLI with PhoneGap’s CLI Tools…
Are you thinking about developing the next great mobile app? When creating your business strategy you’ll want to know:
- How many potential app users there are?
- What platform you should develop for?
- What apps have the greatest reach?
- What apps generate the most revenue?
The mobile app market is evolving quickly, so the answers to the above questions change frequently. In this blog post, I will report the most recent numbers, and also provide links to resources that you can use to stay up to date with the information you need. Read more on Developing a Mobile App? Some Numbers You’ll Need to Know…
Recently I had switched to an iPhone on T-Mobile’s network. T-Mobile has been slowly rolling out their high-speed 3G and 4G connection to iPhones on their network. Most of my time is spent on Wi-Fi or EDGE data connection (about 500kb/s tops). It’s those times on the EDGE data that I realize something: many apps and websites are not built with slow connections in mind.
Why does it matter?
A few months back, I wrote an article about user feedback in AJAX data transfers — the need to tell the user that the system is processing behind the scenes. In many cases, when you are building applications, you use a local machine as the server, so response times can be lightning fast. When you don’t consider slower connections (even a 6mb/s DSL connection can be considered “slow”), users are left waiting.
SEO best practices point out that slow loading pages and applications increase bounce rate and decrease your conversions. A SEO study on page loads and the effects on user experience shows that the slower the load time of the site, the more people give up and close the window.
Recently, I wrote about using Varnish Cache to speed up websites. However, not all websites appear identically on all devices. For example, many web applications will deliver different content to mobile devices such as phones, tablets, screen-readers, etc. What happens when Varnish receives a request for a resource from one of these devices?
Without additional configuration, Varnish will return the only version of a resource that it has cached for a particular URL — regardless of its appropriateness for the device performing the request.
This can be problematic. For example, if a mobile phone performs the first request for a resource, the request may return specific mobile content, and Varnish will likely cache it. However, if a desktop browser subsequently performs a request for the same resource, it may receive the mobile content that Varnish has cached. This could cause mobile-specific content to appear in the desktop browser.
jQuery to the rescue again! jQuery Mobile is built on jQuery and helps ease work on mobile based web applications. The framework gives a great start to a mobile site with very little effort making a custom mobile interface. The examples below are also found on github.
jQuery Mobile Basics