Valve Announces Steam Will Stream to Phones and Tablets

Game streaming may not have conquered the world the way some pundits thought it might, but we’ve seen real improvements in the capability across the last few years. Nintendo’s Wii U was an early iteration on the concept, Sony added the ability to stream some games to the Vita from the PS4, Microsoft will stream games to a Windows computer if you have an Xbox on a local network, and Nvidia’s GameStream can stream titles from a local PC with a GeForce GPU to other devices. Up until now, Valve’s Steam Link device has served a similar function — but the company is taking steps to expand what Steam Link offers by moving from a hardware solution to a much more flexible app.

The company writes:

The Steam Link app, slated to launch the week of May 21st, allows gamers to experience their Steam library of games on their Android (phone, tablet, TV) and iOS-based (iPhone, iPad, Apple TV) devices while connected via 5Ghz network or wired Ethernet to a host system (Mac or PC), with Android access initially offered in beta. The Steam Link App will feature support for the Steam Controller, MFI controllers, and more across both platforms.

The app will be capable of detecting Steam installations for Mac, PC, Linux, and SteamOS and can support controllers that use USB, Bluetooth, or wired input. The Steam controller and MFi-certified iOS controllers will also be supported. Valve told Ars Technica that keyboards and mice will also be supported, though how well this all works may very much depend on how nicely your tablet or phone plays with the same peripherals.

Valve has also announced that it intends to launch a Steam Video app that will let users watch thousands of movies and shows available on Steam “directly via their Android and iOS devices over Wi-Fi or LTE,” and that “in direct response to customer feedback, it will offer the ability to enjoy content in offline and streaming modes.”

Steam streaming should be available on much more than just Steam Link after this update. Who’s up for PUBG on an iPhone SE? Anyone? Bueller?

Yes, we can now look forward to Steam’s stellar curation capabilities and discerning eye being applied to video content. Also, as near as I can tell, under the broadest search terms, there are about 1,400 pieces of film and TV content on Steam, most of which I’ve never heard of. Prices for the content I’ve heard of does appear to be in line with what’s available in other venues, so if you particularly like buying things on Steam, hey, it’s an option.

It’s a smart move for the company to take, and it comes at a time when more and more AAA games are popping up on mobile devices. How far this trend will go is uncertain — there will inevitably be titles that don’t translate well to small screens — but having more built-in options for moving game content from Point A to B is never a bad thing. There’s no word yet on how this will interface with features like library sharing. Presumably, titles shared with other users can be streamed within the same local network.

Introducing Buffer for Android

Over at Android on Buffer, we recently hit 1 Million downloads – so we’d like to take this opportunity to say a big thank you to all of our users for making this happen! This also came with great timing, as we’ve just launched a brand new version of our Android app (something we’ve been calling v6 internally for a short while) ? We made a bunch of changes to the app (both visually and behind the scenes) with the aim to make it easier to use, easier to maintain and also more stable for our users.

Because of these changes, we thought we’d take a little time to show what’s new and some of the changes/improvements we’ve made technically.

Motivation

But first, why did we need a change? Well, if you’ve read a previous post of ours, you may have noticed that the project reached a state where it had become difficult for us to extend on, maintain and test. Now the Composer rebuild had been out in the wild for a bit, we felt it was about time to tackle the next part of our codebase that needed some love 

This began with the main screen of our app, the point at where users are able to view and manage their posts. We decided that this part of our app needed rebuilding as the state at which it had reached was quite difficult for us to work with. Making changes to these screens was a big task, even for small tweaks and fixes it was hard for us to maintain the code due to the way the screens were built. And when changes were made, we often faced fears of bug regressions with the lack of tests that were in place.

Now with the rebuild in place, Clean Architecture coupled with SOLID principles is allowing us to move quicker with both changes and fixes to this rebuilt part of our app. We also introduced a large number of tests into this part of the application, with the aim to reduce future regressions and also boost our confidence in the implementations that we ship.

Remove dependancy on Third Party Libraries

In the previous version of our app we had quite a heavy reliance on several third-party libraries which were no longer maintained. The features that these libraries provided us with are now available as native implementations with the Android Support Library, so we’ve been able to remove these libraries from our app.

The removal of these brings us several benefits. To begin with we’ve managed to reduce the size of our APK from the removal of these libraries. It’s also made our application less-dependant on other parties, meaning that we have greater control over our project. And finally, because the Android Support Libraries are better supported the implementations within our app are both more stable and more maintainable – meaning things will work smoother for both you and us. ?

Improving the native experience and performance

Our content feeds are now making use of the RecyclerView component which means it’s easier for us to support native-like behaviour and animations. This gives a more natural and familiar feel to our application, as well as making it easier for us to maintain. Switching to modern solutions also allows us to make use of awesome tools such as DiffUtil to improve the performance of operations performed on our RecyclerView data. ??

Moving to Bottom Navigation

When Google announced the release of the Bottom Navigation View in the design support library, we knew it was time for us to switch and gain the benefits of simpler navigation throughout our app. Now, you can access the core areas of our application (Content, Analytics, Schedule and Settings) from the shiny new Bottom Navigation View at the bottom of the screen.

This view makes it super quick to hop between these different sections of the application without needing to open the navigation drawer or move your hand to the top of the screen to operate tabs frequently. You’ll now be able to get to where you want in fewer clicks and effort. ?

Psst: We also open-sourced a little library to make implementing Bottom Navigation into your own Android apps a little easier ? https://github.com/bufferapp/AdaptableBottomNavigation

Introducing Buffy

We’d like to introduce to a new friend that has joined us in the latest version of the app, say Hi to Buffy ?. Buffy will be there for you within the app to help you out at any time that it’s needed!

Faster Profile switching with a new Navigation Drawer

We wanted to make it quicker for our users to switch between profiles that are connected to their account, so we decided to shift the profile selection to be immediately visible when opening the navigation drawer.

Upgrade your Account Plan through Google Play

We’ve now made it possible for you to upgrade your Buffer account from within the app using Google In-App Billing. This means you can upgrade your account and pay directly with your Google account, making the upgrade process much more frictionless. ?

Preview your Instagram profile with Grid Preview

We’ve added a cool new feature for Buffer for Business users which allows you to preview your Instagram Grid before sending your posts out to your profile! (Remember those native-like animations that I spoke of ?).

With Grid Preview you can drag-and-drop Instagram reminders to re-order them before posting, allowing you to get your Instagram profile looking spot-on before they go out. ?

Compose updates quicker with the Composer App Shortcut

In Android 7.0, Google added the ability for applications to add shortcuts for quicker access to functionalities within their app. We’ve decided to make use of this and make it easy for you to quickly jump into the composer to compose an update for your queue. ?

To access the shortcut all you need to do is perform a long press on the application and the “Compose” shortcut will appear. From here you can either click it to open the composer (as shown below) or drag it onto your home screen so you can access it even quicker!

Is there anything else you’d find useful as a shortcut? We’d love to hear from you if so. Feel free to leave a comment or send me a tweet. ?

Hashtag Suggestions

Within the Composer, we now provide you with hashtag suggestions when you begin typing a hashtag. This means you can compose your updates both more quickly and easily. ?

Try out Version 6 for yourself!

Thanks so much for reading! Now we’ve told you all about version 6, why not go check it out for yourself? We’d love to hear what you think.?

Testing Android App Shortcuts with UI Automator

In case you haven’t used App Shortcuts in Android yet, it’s an awesome feature that allows us to provide our users with a way to quickly access parts of our apps from the home screen of their device. As developers, we can make these shortcuts either static (meaning they’re statically defined in an XML file) or dynamic(meaning they’re dynamically added and removed at runtime). Currently in the Buffer app for Android we have 2 types of dynamic shortcuts:

• A shortcut that allows you to access the composer
• Three shortcuts for the 3 previously selected profiles (this one is in currently only available in beta!)

But why do we need to write tests for this?

All of these shortcuts are dynamic, meaning that they are only accessible when you are signed in to an account. This means that we have to add them when a user signs-in and removes them when the user signs out – thankfully for us, the shortcut api makes it super easy to do this. However, just like any features of an application, this could easily get broken in the future – this means that if these do somehow break:

• Users may not be able to see the shortcuts when they are signed in
• Users may still be able to see the shortcuts when they have signed out. Without being signed in, it could be quite confusing for these shortcuts to show – so we want to be sure they’re never shown in this situation
• Users may be shown the wrong recently selected profiles – this could be quite annoying and defeats the point of the shortcuts in the first place!

This sounds like a perfect situation to write tests to ensure that these situations never occur. However, because these shortcuts are outside of our application it means we can’t use Espresso to test them.

But! Whilst we can’t use Espresso, luckily we have what is known as UI Automator available to us, it’s all good!

If you haven’t used UI Automator before, it’s essentially a testing tool that allows us to interact with system-wide components – it’s useful for testing things outside of your app (such as notifications) or components invoked by the system (such as permission dialogs). Because of this, it means we can use it to test our App Shortcuts 

Nice! But how do I do this?

If you don’t want to learn about how to do this for yourself, we’ve bundled some handy functions into our testing utility library Biscotti that will allow you to test for app shortcuts. In this library you’ll find two handy methods:

assertAppShortcutsExist()

This method allows you to check that an app shortcut exists for your application. For example:

1 2	BiscottiShortcuts.assertAppShortcutsExists("Buffer", InstrumentationRegistry         .getTargetContext().getString(R.string.shortcut_compose_update))

assertAppShortcutsDoNotExist()

This method allows you to check that an app shortcut does not exist for your application. For example:

1 2	BiscottiShortcuts.assertAppShortcutsDoNotExist("Buffer", InstrumentationRegistry         .getTargetContext().getString(R.string.shortcut_compose_update))

Both of these methods also allow you to pass in multiple strings for checking multiple labels, just in case you need a test to check multiple related app shortcuts.

Cool! I want to know how this works!

So let’s take a dive into how we’re doing this with UI Automator, here is the complete code for checking that an app shortcut exists:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

fun assertAppShortcutsExists(appName: String, vararg shortcutLabels: String) {     if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N_MR1) {         val device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation())         findAppIcon(device, appName).longClick()         shortcutLabels.forEach {             if (!device.hasObject(By.text(it))) {                 Assert.fail("The specified shortcut was not found")             }         }     } }   private fun findAppIcon(device: UiDevice, appName: String): UiObject {     device.pressHome()       if (device.hasObject(By.desc("Apps"))) {         device.findObject(By.desc("Apps")).click()     }       val appDrawer = UiScrollable(UiSelector().scrollable(true))     appDrawer.scrollForward()     appDrawer.scrollTextIntoView(appName)     return device.findObject(UiSelector().text(appName)) }

We have two methods here; assertAppShortcutsExists() which is used by our application to test the app shortcut and findAppIcon() which is used for finding the app icon on the device. Let’s begin by taking a look at the assertAppShortcutsExists() method.

Wait, won’t this fail on devices running < 7.1?

Good question! You’ll notice here that the logic within this method is only used if the Build version of the device is Android 7.1 or newer – this is because app shortcuts are only available on there, so we don’t want these tests running on older versions of Android as they will fail. It would be nicer to have the test not run at all on devices that are running less than 7.1, but I’m not sure of a way to do this yet 

Navigating to the application icon

The first step we need to carry out is navigating to the icon for our application, this is so that we can invoke the action to show the app shortcuts. We begin by retrieving a reference to the current device as a UiDevice instance:

1	val device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation())

We then use this value when calling the findAppIcon() method. This is used, along with the given app name, to find the application icon that we want to check for app shortcuts. Within this method we begin by using the pressHome() method to press the home button on the device, this will cause our app to be exited and the home screen of the device to be shown.

1	device.pressHome()

Once we’re on the home screen of our device, we need to find the icon of our app. Now, the way we do this can differ between devices – some devices will have an app launcher icon, yet some will have the pixel style launcher that swipes up from the bottom of the screen. To account for this we’re going to first check if the device has the App Launcher button like so:

1	device.hasObject(By.desc("Apps"))

If the device has this button, you’ll notice that we go ahead and click it:

1	device.findObject(By.desc("Apps")).click()

If the device doesn’t have this button then it’s ok because we make use of the UiScrollable class to scroll up on the screen, this will bring up the pixel style launcher, revealing the apps on the devices. We still need to use this UiScrollable class here even if the device does have the app launcher button as we will need to scroll to the app icon anyway – this just means we are now accounted for both situations 

Note: I haven’t yet tested this on devices that swipe horizontally. These tests will only be run on Android 7.1 above which I think makes this behaviour less common, but you may need to tweak this code if your tests are running on devices that use this approach.

1 2	val appDrawer = UiScrollable(UiSelector().scrollable(true)) appDrawer.scrollForward()

Next, we need to actually scroll to our app icon, this is done by the appDrawer.scrollTextIntoView(appName) call. Once our app icon is found it is returned by again using the findObject() method.

1 2	appDrawer.scrollTextIntoView(appName) return device.findObject(UiSelector().text(appName))

Asserting the object state

If we head back on over to our assertAppShortcutsExists() method, we now have the reference to our app icon so we immediately perform a longClick() action on it. A long click is what causes our app shortcuts to be shown. Now that these are showing, we can go ahead and check that our desired shortcuts are shown. We again use the hasObject() method to check whether or not the given shortcut label is shown and if not, we cause the test to fail.

1 2 3

if (!device.hasObject(By.text(it))) {     Assert.fail("The specified shortcut was not found") }

The assertAppShortcutsDoNotExist() method works in the same way except we just assert that the given shortcut label is not shown on the screen.