If a tree falls in a forest and no one is around to hear it – does it make a sound? If a feature is added and nobody can find it – does it exist?
If a tree falls in a forest and no one is around to hear it – does it make a sound? If a feature is added and nobody can find it – does it exist?
Each year, the tech giants that power the computers in our pockets release a wide range of new features and capabilities for their platforms – though some features you might not see until the following year. Whether the feature is in Beta or because we haven't found a need for it in a client's app, it is important to take the time to learn and play with them anyway. We’d rather constantly run into roadblocks building an app that literally has no purpose instead of discovering the problems in an active project.
When asked about hackathons, a Rocketeer involved in the event said, “I used to think hackathons were just for kids and college students, but I couldn’t be more wrong. They’re fun, fast-paced, and exciting, which is a great way to get students involved, but they’re still just as fun for adults.” Hackathons are a time away from the pressure of client work, where failure is without consequence. There’s no breaking of keyboards, just laughing along with the insanity of it all.
Unknowns are the bane of project estimations. The more we know about the tech in question, the fewer variables there are in planning. Instead of jumping into a project that suddenly doubles in duration due to unforeseen problems with a feature or how to best implement it, hackathons give us the time to learn everything we need to know. Then, when the time comes to add a new feature for a client, we already know what to expect.
But enough about hackathons, here’s what happened in our latest event.
This team (seen in photo above) explored the new Android feature Picture-in-Picture mode. The goal was to have a live scoreboard of country medal counts displayed as you use your phone for other day-to-day tasks. They were able to get a functioning prototype completed and even discovered a few fun facts along the way. For instance, they found that if you make the aspect ratio of the minimized screen to extreme, it’ll crash. Also, they found that you could make the panel transparent – a totally useless feature unless you want to confuse your users, but a cool find nonetheless.
Seeking to better understand the capabilities of connectivity in iOS 11, The Gas House Gang made a curling(-like) game in which you slide pucks into area marked with a target. The reason this is interesting is that they had it running in two different applications – not the same application on two devices, but two different applications. While this might not sound like a feat, it shows the potential of having two completely different applications updating in real time to display information from each other.
Riding off the concept of tracking athletes’ diets, The Things explored one of the newer sides of IoT devices in the Android ecosystem – Android Things. Using a Raspberry Pi, the team had a functioning prototype that allowed them to photograph the food they were about to eat and then automatically post it to a channel of their choice. This could, for example, allow athletes to easily snap a photo and share it with their dietitian with the click of a button.
Everyone’s a winner in our eyes when it comes to hackathons. While some may not have finished, others found that the technology they were trying to leverage was actually not ready for the spotlight.
Brand New Wizbangs
This team put Apple’s ARKit 2D image detection and face mapping to the test with this face-painting experience. However, they ran into a roadblock trying to merge some features as the application would not allow it and crashed during each attempt to do so.
Leveraging Android’s Autofill Framework and Firebase Realtime Database, Javelin worked to create an up-to-date, real-time database that could update information and provide it as an autofill suggestion on the fly.
Alloy explored Metal, Apple’s proprietary graphics processing engine, and was able to have the five rings of the Olympics animated used 1,000 triangles.
Got an idea for your business but not sure where or how to start? Reach out to Bottle Rocket. We may just have an answer for you.
Mobile software testing involves many variables such as operating system versions, types of connectivity, networks, devices, and environments. To account for so many variables, the approach to testing apps poses an interesting dilemma: Should testing be performed on physical devices, simulators, emulators, or cloud-based devices? Is there a unique value in sticking to physical devices? At Bottle Rocket, we use a combination of these with an emphasis on physical devices—and we do mean emphasis. We recently surpassed 400 test devices in our library.
Users expect apps, including those with the ability to sync between devices with shared accounts, to work flawlessly on their devices. So, a comprehensive library of devices to mimic the user experience is essential in testing. However, the number of combinations of devices and operating systems that users have is huge. For this reason, many companies opt to rely mostly on simulators, emulators, and/or cloud-based devices for their software testing.
These device alternatives can be very helpful in the beginning of the application development lifecycle, but they are not ideal as the sole testing resource. Many important pieces of mobile interaction are lost when physical devices are left out.
Real-world users are equipped with real devices in different environments, meaning the effects of the following items may vary:
Recreating the user experience as closely as possible is what Bottle Rocket strives for. In our efforts to do this, we recently surpassed four hundred test devices in our QA arsenal! This is a milestone in itself since one of the biggest challenges that exists in application testing is the cost of obtaining and maintaining such a large volume of physical devices for testing purposes.
Our device lab contains Griffin cabinets with a capacity to hold and charge up to eighty devices at a time. Rocketeers pick out the devices they need, check them out library-style with our device checkout software, and begin their testing. All Rocketeers can access the checkout software remotely, so devices can be easily located and accounted for conveniently.
This system allows testers to plan ahead and dedicate certain devices to their project for as long as they are needed. Once a project starts, the lead tester maps out which devices will be needed during the testing process. They are checked out from the device cabinets and used throughout the project, only being returned when all testing is completed. When finished, checking the devices back in is as easy as pushing a button.
Solely relying on physical devices to test requires a great deal of time and money. Maintaining such a library involves frequent upgrades in order to remain relevant and effective. If our system doesn’t contain the latest and greatest mobile devices, a big chunk of tech-savvy users and their experiences will be unaccounted for. We need to remain ahead when it comes to testing on the latest hardware. We pay close attention to mobile announcements such as Google I/O and WWDC every year to gather intel on what’s coming and plan ahead by preordering any new devices or scoping out the latest operating system and its release date. So why all the focus on what’s coming? It’s important to know the adoption trends, new hardware features, such as aspect ratios, or if any new peripherals are announced.
New operating systems are especially impactful as they can touch any part of the device and installed applications. New features and tweaks to existing operating systems can affect corresponding areas of our applications, so we must look into the patch notes of any release and test our applications accordingly. A recent example of this is the release of iOS 11 – for every new beta released, we update our device operating systems and run tests on all of our applications. It’s a quick sanity check to verify all features cooperate with the updates. Developers have taken advantage of these betas as well in order to research and experiment with the new ARKit.
It is beneficial to have varying device types - high end and low end, new and old. Keeping old operating systems on devices is part of this method. Android users especially are not pushed to upgrade operating systems as aggressively as other platforms. Android OS 6 is still the most widely used according to Android’s developer portal, despite OS 7 having been out for more than a year. Covering OS 4, 5, 6, and 7 is necessary to ensure quality for all users.
In summary, using physical devices will assure the most accurate testing and analysis since that is the only way to duplicate the diversity of users’ environments, network settings, operating system versions, and hardware. Keeping up with current and future devices and operating system versions will also ensure quality results. Bottle Rocket will continue to build its device library – we’re beyond 400 now, and have no plans of stopping!
Interested in testing your app in our device library? Let us know at [email protected]
In iOS 11, Apple has made a number of improvements to the URLSession family of APIs. These improvements range from developer quality of life updates, to significant performance gains that will undoubtedly improve user experiences across the platform. In this post, we’ll go over two improvements in particular: Multipath TCP support and reachability monitoring built-in to URLSession.
Elegantly handling poor network conditions is a sure sign of a well-built and polished app. Compared to most other apps on your phone, have you ever noticed how rarely Siri seems to have connectivity issues? The reason for this is Multipath TCP. When Siri makes a network request, the app actually opens up two connections to the server: one over Wi-Fi and one over cellular. These connections work together to deliver data to the app as quickly as possible. As long as your device has a decent connection on one of the two channels, Siri works.
Multipath TCP is a relatively new protocol, designed specifically for mobile devices. It is built on top of TCP, so it benefits from the reliability and congestion controls built into TCP. Additionally, MPTCP allows for seamlessly switching between a wireless and cellular connection. It even supports using both connections simultaneously to increase throughput (more on this later).
In order to take advantage of MPTCP, support is required at both the Client and Server level. Not all server infrastructures currently support MPTCP, but popular vendors like AWS do. With iOS 11, app developers can now support MPTCP at the client level as well.
In iOS 11, apps can opt into three different MPTCP modes: Handover Mode, Interactive Mode, and Aggregate Mode
Regardless of which mode is used, the cellular link will be disabled if your app hits the Wi-Fi assist data limit. Be on the lookout for this if you are testing your apps and notice MPTCP no longer switching over to cellular. This is a good indicator that you may need to rethink which calls are opted in to MPTCP.
So, how do you opt in? Apple has made this extremely easy. Simply add the “multipath” capability to your app in Xcode, and set the multipathServiceType property on your URLSessionConfiguration to either .handover or .interactive. That’s it!
Good reachability handling has always been tricky in iOS, mostly due to the absence of solid high-level support for it. Most apps use third- partyreachability libraries, all of which are built on top of Apple’s SCNetworkReachability low-level API. There are some issues with this approach: the libraries are not particularly reliable, and they are not integrated with URLSession. If a developer needs to hold off on making a network request until network conditions improve, or retry a network request, they have to build that functionality up from scratch themselves. That ends up being cumbersome for developers, results in less than ideal reachability handling, and also takes time away from polishing the user experience. Developers often take the easy route and present a full-screen modal as soon as connectivity is lost, blocking the user out of the app completely.
Apple has improved a number of these pain points in iOS 11. URLSession now has the ability to monitor network conditions and wait to start tasks. You can easily opt in to this behavior by setting waitsForConnectivity to true on your session’s configuration. When opted in to waitsForConnectivity, URLSession will either load the request immediately or load the request as soon as network conditions allow. While waitsForConnectivity is defaulted to false for backwards compatibility, Apple recommends enabling it for almost all requests.
In addition to delaying network requests, URLSession will now notify your app when it experiences poor connectivity. This is accomplished via the urlSession(_:taskIsWaitingForConnectivity:) delegate callback. You can hook into this delegate callback and use it to toggle Connectivity UI.
Do you have burning questions about connectivity with iOS 11? Our developers, responsible for numerous award-winning apps and connected device experiences, have the answers. Tell us what you’re wondering at [email protected]
Android O, the upcoming OS for Android revealed at this year’s Google I/O, features many updates that developers are excited about. But you shouldn’t wait until its release to begin thinking about how O will affect your current or future apps. Let’s look at what you can prepare for right now before Android O’s release. Before you dive in, we should explain that we’re not reviewing what’s new for users here—this post is a rundown for Android developers. So let’s talk code!
We’ve divided the subject into two main sections. The first section deals with apps that target any API level and reveals changes that your app will see even without targeting Android O. The second section deals with new APIs and behavior changes when targeting Android O. Both of these sections assume that your app is running on an O device.
All links point to the Android developer preview site and are subject to change once O is officially released into the wild—we’ll update these as they change so you don’t miss out on anything.
Consider the following behavior changes that will take place even if your app doesn’t target O just yet.
The full list of changes can be found here.
You’ll basically want to test out your app on a device with the O Preview or an emulator focusing on system behavior changes and going through all app flows. Read more on this on the Android developer site.
Consider the following behavior changes that you will need to handle (if they affect your app).
Check out your strategy around background execution considering the following changes:
By default, these restrictions are enabled when targeting O, but the user on an O device can still enable them from Device Settings even if you don’t target O.
The following is a list of things you are free to implement (or not) in your app. Doing these things is not required but will result in a better experience on O devices.
The full list of Android O behavior changes can be found here.
You’ll basically want to test out your app on a device with the O Preview or an emulator focusing by targeting O, addressing system behavior changes, implementing O specific features and going through all app flows. Learn more on migrating apps to Android O on the Android developer page.
Want even more insight on Android updates and their impact on brand experiences? As one of only 25 global Android Certified Agencies, we’re always thinking ahead for our clients. Ask your questions at [email protected]
© 2020 Bottle Rocket. All Rights Reserved.