To 2019, and Beyond!

Technology is always growing and improving, so it’s always good to know what new things are around the corner.
In the spirit of the new year, I’d like to share some of the things I’m excited to learn more about in 2019.

What Was Will Be Wasm

If you’re not yet familiar with WebAssembly (Wasm for short), it’s a new binary format for web applications. Engines like Unity or languages such as Rust, C, C++, Kotlin, or Reason can compile to Wasm.
As Wasm takes off, developers will be able to develop apps in Rust, C, Reason or other languages that compile into WebAssembly and deploy them to the web.
Wasm is already supported in all 4 major browsers and we’ll see more widespread usage in 2019.

Wasm offers many benefits, such as trivially being able to call a module in one language from a module in another language.
Other benefits include smaller binaries sent to the browser and built-in obfuscation.

Next steps for Wasm include formalizing its specification; creating better tooling; and improving support for threading, exception handling, and garbage collection.
For more info, check out the WebAssembly future features tracker.

Gary Bernhardt’s 2014 talk “The Birth & Death of JavaScript” about the future of JavaScript and Wasm is quickly becoming reality.
I encourage you to watch the talk!
It’s funny, insightful, and paints a good picture of your job as a developer might look like in a year or two.
His talk makes me think that instead of having all of our apps in an electron container, maybe we’ll just compile down to Wasm and deploy on the web.

Time to Fold? Samsung’s Not the Only One All-In!

Late in 2018, Samsung announced plans to sell a foldable device in 2019.
Rumor has it Samsung’s foldable phone will sell for more than $1,600.
That may be too expensive for most people.
Not to be outdone, other device manufactures like Huawei, Motorola, and LG have filed patents for foldable phones and we could see them offer a foldable device in 2019.
Nobody knows if anyone actually wants to buy these, though.
If you’re interested in learning more about getting your apps ready for Android’s foldable devices, check out the article I wrote about Android’s upcoming support for foldable phones.

5G Whiz!

4G let us share more real-time content and stream video on the go.
5G wireless connectivity will start arriving in 2019, and it increases bandwidth and reduces latency.
4G connection latency is about 20 milliseconds. 5G promises to reduce that to 1 millisecond.
The increased connectivity of 5G will allow IoT devices and smart cars to communicate with each other and share information faster.
Drones, augmented & virtual reality will use 5G speeds to enhance the experience by sending higher definition video and allowing users to chat and live-stream in real time.
But don’t expect 5G connectivity to change everything overnight; there are rumors that Apple will not offer 5G devices until 2020.
Most likely there won’t be a majority of 5G devices until about 2022.
AT&T is currently offering 5G hotspots.
Samsung is partnering with AT&T and Verizon to launch their first 5G phones in the first half of 2019.

Turn It Up (or Down) a Notch

Like it or not, notches in your smartphone screen are here to stay.
Both the flagship Android and iPhones have one for their sensor housing and cameras to ensure an edge to edge display.
Now some Android manufacturers like Sharp and ZTE are adding a second notch for fingerprint scanners or forward-facing speakers.

One alternative to adding more notches is placing the sensors under the display.
The OnePlus 6T, Huawei Mate 20 Pro, Oppo R17, Xiaomi Mi 8 Explorer Edition, Vivo V11 Pro, and Vivo Nex all contain an in-display fingerprint reader.

Samsung will most likely include an in-display camera for selfies on the Galaxy S10.
If people like it, expect other manufacturers to add it to their phones as well.

It’s a Multiplatform World After All

React Native is still popular and will continue to be.
But 2018 saw well-known adopters Airbnb and Udacity publicly break-up with the technology.
At the same time, new options for multiplatform development have arisen such as Flutter and Kotlin/Native.

Google’s All a-Flutter

Flutter has its first stable release at 1.0 and the Flutter team tells us many other apps have shipped to production with flutter! At the Flutter Live event Google developers announced new features such as support for webviews, maps, and taking payments with Square.
Other big news included improved support for adding Flutter to an existing iOS or Android project and experimental support for building apps for macOS, Windows, Linux, and the Web with Hummingbird.

Code Sharing Is Caring With Kotlin/Native

Unlike Flutter or React Native, Kotlin/Native doesn’t aim to unify UI logic across platforms.
Instead, it supports code sharing by compiling for Linux, macOS, iOS, Android, Windows, & WebAssembly and supporting two-way interoperability in the codebase.
For a good primer, check out the Kotlin/Native overview page.
I recommend checking out the KotlinConf, droidcon NYC, and droidcon SF apps as examples of what can be built with Kotlin/Native.

These are just a few of the things that excite me about tech in 2019.
What new technologies are you interested in?
Let us know in the comments!

The post To 2019, and beyond! appeared first on Big Nerd Ranch.

Last week, a few nerds at Big Nerd Ranch attended the 2018 Android Dev Summit .
While the conference covered multiple topics, the biggest piece of news was support for foldable devices.

Foldables provide a new user experience – while folded, apps on the the device should prioritize quick and easy access.
Users can then unfold a device to get a tablet-like experience with more info and context for the current activity.
Samsung unveiled mockups for device that will go on sale in 2019 that has one window when folded but can display up to three when unfolded.
The unfolded display will contain one large screen and up to two more smaller screens on the side, allowing the user to move activities across these screens.
It’s important to note though that any foldable device will be able to choose how many windows activities can display on.

Screen Continuity

The first concept that Google introduced is “screen continuity” – where the user should be able to seamlessly continue what they’re doing after they fold or unfold the device.
If the device is unfolded, the user will be able to dive deeper into the current task.
So as a developer, how will you handle screen continuity?
The good news is that the guidelines and APIs for this already exist!

Whenever a device is folded or unfolded, a configuration change will fire in the displayed activities.
Android gives you tools to handle state during configuration changes, such as when the device is rotated or if the window size changes.

By default, an activity that receives a configuration change will restart – which is not ideal.
To handle the configuration change without restarting you can use the android:configChanges attribute and declare resizableActivity=true in your manifest.
If your app targets API level 24 and you do not specify a value for this attribute, resizableActivity will default to true.
Then to properly handle the configuration change, you’ll want to override the onConfigChange callback in your activity.
ConstraintLayout can also be a useful tool for dealing with resizable activities, which is covered in detail by the Android App Resizing for Chrome OS codelab.

If you choose not to handle configuration changes yourself, you can rely on the activity restarting and use the onCreate and onSaveInstanceState callbacks to handle configuration changes. ViewModels can also be used to persist data across the Activity lifecycle.

Changes to the Lifecycle in Multi-Window

Currently in a multi-window environment, the activity the user last touched is in the resumed state, while all other visible activities are in the paused state. The current behavior is documented in the Android docs.
However, Google announced that starting in Android Q all activities will remain in the resumed state in a multi-window environment.

This is in large part because Google noticed it was not clear to users why some activities were in less interactive states in a multi-window environment and that apps weren’t properly handling the paused state.
While in the paused state, an activity could still be visible to the user, but some apps would not respect that behavior and instead started to tear down the activity in the onPause callback.
So while in the paused state, some activities displaying video might pause, or activities with real time chat may stop listening for new messages.
For apps that want to use the new multi-resume mode in Android P, they can opt in by adding the following meta-data to the Android Manifest:

<meta-data android:name="android.allow_multiple_resumed_activities" android:value="true">

However the device OEM must also opt in for multi-resume mode to occur and currently no devices do.
This is to prevent breaking changes for apps and devices that can’t properly handle multiple activities in the resumed state.

Multi-resume Mode Gotchas

If an app launches activities in multiple tasks, a user can view these activities side by side in a multi-window environment.
With the possibility of apps having multiple activities in the resumed state, one gotcha to look out for is your app or any dependencies attempting to hold a reference to “the only” resumed activity, since now there can be more than one!

Another thing to be cautious about is accessing shared state across your application.
Instead of having a LiveData singleton that is shared across activities – have a single database and use multiple LiveData instance to observe changes to that information.

Multiple Displays

Android apps can already support multiple displays on platforms such as Desktop Mode or Chrome OS.
So to ensure your app is ready for a foldable device, you can make sure your app performs correctly on those platforms.

Starting in Android Oreo, an activity can be launched on a non-default display.
These APIs allow you to query for what displays are available and what its characteristics are.
In a multiple display environment like a foldable device, you can use these APIs to launch on one of the available screens.
You may choose to inspect the characteristics of screens before you launching your activity.
Activities that are broadcasting media may choose to launch on larger displays, and you’ll want to filter out any displays that are currently off.

val displayManager = application.getSystemService(Context.DISPLAY_SERVICE) as DisplayManager
val displays = displayManager.displays
val targetDisplay = displays.first()

//Check if the display is public, private, or secure
targetDisplay.flags

//Get the size, resolution, and density of the display
targetDisplay.metrics

//Check if the display is on or off
targetDisplay.state

Then you can choose to launch your application on that screen.

val options = ActivityOptions.makeBasic()
options.launchDisplayId = targetDisplay.displayId
startActivity(intent, options.toBundle())

These screen can be windows on the device, or they could also be virtual displays that Android creates.
One example of this is Chromecast, where Android creates a virtual display on the user’s TV for apps to cast to.

Multi-Display Restrictions

However, there is the possibility that Android will not allow your app to launch in activity on that screen, even if it appears as an available screen.
In this case a SecurityException will be thrown, which can be handled with a try/catch.
This exception could be thrown because Android has deemed the window as not a safe place to display your activity, as is the case for virtual displays.

You also need to be careful about which context you use, since resources accessed by your activity and application may resolve differently.
If you were to ask for the bounds of the window with the activity’s context, you would get the size of screen that the activity is taking up.

val currentDisplay = activity.windowManager.defaultDisplay

But if you were to query for the bounds of the window with the application’s context you would get the size of the entire device that the user is holding.

val appWindowManager = application.getSystemService(Context.WINDOW_SERVICE) as WindowManager

Behavior for drilling deeper into some activities while stopping others when folding or unfolding can vary by device.
If there aren’t enough displays for resumed activities to take up, the device will choose which activities will be stopped.
There is no way for your app to know if it’s about to be stopped or not, so your app should gracefully handle the onCreate, onStop, and onConfigChange callbacks.

Emulator

The teams at Android and Samsung have committed to sharing an emulator for foldable devices by Q4 of this year.
This emulator will initially be geared towards Samsung’s Infinity Flex device and will be made available on Samsung’s Developer site.
Later, an AOSP emulator will be made available through Android Studio that will have a toggle for folding and unfolding the device, and some options for configuring multiple displays.

If you’re eager to start support for foldable devices, there are currently two ways to try out your apps in a multi-window environment:

• Use a Chrome OS device or the beta version of the emulator
• Activate “Simulate secondary displays” in the Developer Options on your device.

Next steps

To learn more about resizable activities or multi-window environments, check out Google’s codelab about Optimizing your Android App for Chrome OS as well as Kristin’s previous blog post on UI Updates in a Multi-Window World.

If you want a deeper dive into Google’s and Samsung’s announcement on foldable devices, check out the recording of Is Your App Ready For Foldable Phones from Android Dev Summit and be sure to read the accompanying blog post from the Android Developers Blog.

Do you have thoughts or further questions about supporting foldable devices? Let us know in the comment section below!

The post The Future of Android Unfolds appeared first on Big Nerd Ranch.