Previously, our team published a post how this was accomplished for the iOS SNKRS Pass experience. Today, you will learn how our team accomplished this for Android. This post focuses on the wave animation portion of the feature.

Our first attempt at the animation was a Lottie Drawable generated by our design team and it worked marvelously. However, we ran into issues. We couldn’t scale it properly to center the animation on the spinning circle view origin without making the animation view larger than the display size or leaving an awkward space at the bottom of the screen. Ideally, we’d want to set the wave origin at runtime. Since we were unable to go with the “easy” solution of using the Lottie asset, we instead set out to create the animation manually. We try to use Lottie for most of our animations, but it didn’t fit our case of a fullscreen animation being centered on a separate view.

After an introductory attempt by our team, we were fortunate enough to have the always incredible Nick Butcher point us in the right direction with a proof of concept of what we were trying to achieve. Below is our implementation which heavily leaned on Nick’s proof of concept.

Creating the wave animation

Let’s create a similar UI to the animated wave and circle view in SNKRS Pass. First, you’ll start by drawing circles and animating them out from the center of the screen.

You’ll define attributes for the space between each rendered circle and the circle color and stroke width:

Next, you will need to define a layout and custom view that shows a number of concentric circles.

In this view:

1. Initialize the paint object with the custom attributes
2. Define the initial and max radius of the smallest/largest circle
3. Define the position where to start drawing the circles
4. Draw all the circles with a radius of initialRadius to maxRadius with each separated by a space of waveGap

Now, you should see a static representation of circles that flood our screen:

This is done by creating a value animator that runs for 1.5 seconds, repeating in an endless loop. On every animation frame, the waveRadiusOffset will be updated — waveRadiusOffset is the value that tracks the circle expansion from its original position. Next we call postInvalidateOnAnimation() in the setter to redraw our view’s next frame. Finally, onDraw runs using the new offset in order to simulate the animation.

Reminds me of the Twilight Zone’s intro.

More than a Circle

Circles are fine, but the animation needs a defined shape. Taking a cue from the iOS article from our team, here you will be making a 10-point star.

We’ll use simple trigonometry (still remember sohcahtoa?) to draw our star. For reference and if you need a refresher: https://en.wikipedia.org/wiki/Trigonometry#Mnemonics

Creating the star path line by line looks like so:

First you need to figure out where each point will lie. Since a full rotation is 360 degrees (2π in radians), we just need to divide that by the number of points to know the angle at which each point will sit. Knowing the angle and the diagonal distance each point is from the center (also known as the radius/hypotenuse), we can use sin() and cos() to find the opposite (or y) and adjacent (or x) distances to plot each line between points.

sin(angle) = opposite/hypotenuse    cos(angle) = adjacent/hypotenuse

rearrange to find unknown:

opposite = hypotenuse*sin(angle)   adjacent = hypotenuse*cos(angle)

If we put it all together and draw this star instead of the circle we will end up with this new wave animation:

Changes made to onDraw:

The Gradient

The SNKRS Pass voucher has a gradient that moves as you tilt your phone. It applies to the waves but not the background.

To highlight the wave portions that fall within the gradient, we can use PorterDuff.Mode.SRC_IN to color the parts of the canvas that have already been touched. (more information here)

Next we need to create and draw our gradient using different green alphas.

Finally, we need to update our view to use the software layer since PorterDuff.Mode.SRC_IN doesn’t work with hardware acceleration.

And, voila:

Motion

To move the gradient on the canvas, we’ll translate the gradient paint shader’s local matrix by a calculated amount.

Now we’ll use the acceleration and magnetic sensor to get the phone’s orientation and determine how much to translate the gradient as we tilt the phone.

Further sensor reading: https://developer.android.com/guide/topics/sensors/sensors_position

Let’s create a class WaveTiltSensor that will hold the logic for getting the device’s orientation angles. You’ll define an interface for the tilt sensor along with an associated listener and the initialization logic for the accelerometer and magnetic sensors:

Next, you will need to implement the tilt detection logic in onSensorChanged. The sensor data you need is the angle the phone is on the x and y axis as it rotates.

Now, you have the pitch (degrees of rotation about the x axis) and roll (degrees of rotation about the y axis) in radians. Since you’re translating the phone’s rotation to a 2D motion, the azimuth (degrees of rotation about the -z axis) doesn’t matter.

When your device’s pitch changes, you want to move the gradient up and down the y-axis. When the roll changes, the gradient should move left/right on the x-axis. The center of the gradient shouldn’t move past the edges of the screen so you need to constrain movement by half the height/width since it’s centered.

Let’s change the view to handle device tilt updates. We’ll have it implement the TiltListener interface.

As we get tilt events, the code performs a bit of trigonometry to get the adjacent vertical offset distance that the device is from its resting state for both the pitch and roll. In this example, the device is starting from a flat resting point on a table. Then, the code will translate the gradient by no more than half the screen height/width.

I updated the background color to give a little more contrast to the green gradient in the video.

Conclusion

Attached you’ll find an example Github project that you can play around with. I hope this post has made doing trigonometric and gyro based animations easier for you!

alexio/Android-AnimatedWaveView

Geometric Android Animations using the Canvas was originally published in S23NYC: Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last week our API Services team attended the AWS Re:Invent Conference in Las Vegas. In between trips to the El Cortez Casino and the Bacchanal Buffet, it was quite the week.

Here at S23NYC we rely on AWS Serverless technologies — mostly Lambda and DynamoDB — to support the Nike SNKRS App and its admin tools. DynamoDB and Lambda definitely have their strongpoints: automatic scaling, thorough documentation, concise, easy to maintain business logic and fast iterative development and deployment. And best of all, they’re fully managed, allowing our lean team to turn out APIs effectively and with lightning fast turnaround. While no platform is without its quirks or drawbacks, a handful of announcements last week whittled away quite a few big ones.

API Gateway Web Sockets
This one’s a doozy. Because most of our APIs run on Lambda behind a VPC, other than running a socket server on an EC2 Cluster (no thanks) or using a third party service like Pubnub, there was no obvious solution to real-time client-server communication.

But now with the announcement of web socket support for API Gateway, deploying our own, fully managed socket service is easier than ever. API Gateway sends and accepts socket requests to and from the client, invoking stateless lambda functions as needed while connection information can be persisted through DynamoDB. For a deeper dive on this, there’s a great write-up on a simple chat client implementation over at serverless.com.

Lambda Layers and Custom Runtimes
We love Python! But hey, maybe it’s not your language of choice. Maybe you prefer a functional language like Haskell or you’re ride-or-die PHP. Maybe you’d prefer a compiled language like C# or Java that isn’t C# or Java. Well, in addition to newly announced supported runtimes for Rust, C++, and Ruby, AWS now allows custom runtimes for Lambda. If it runs on Unix, you can run it on Lambda.

Of course, simplicity and ease of deployment are big advantages with using Lambda so it’s recommended that you use the prepackaged runtimes provided by AWS whenever possible. The core component that enables these custom runtimes is the ability to share code across multiple functions with Lambda Layers. This can be leveraged for much more practical outcomes, such as speeding up your CI builds, shrinking the size of your deployment packages, or potentially reducing your function’s cold start times.

Say for instance you have a shared API wrapper for an often used third-party service across your various Lambda functions. You can create a Lambda Layer containing these packages and modules and configure your function to reference it by ARN. We ran a test with one of our services and the size of our deployment ZIP dropped from 28MB to 9K. Layers can be isolated to a single AWS account or publicly available to other AWS developers. Some companies, such as Datadog, have already announced their own publicly available Lambda Layers.

As with any system of dependency management, there are a few gotchas when it comes to using Lambda Layers. Layers are immutable, meaning in order to update a layer’s shared code a Lambda’s configuration needs to be updated to point at a new ARN. When deleting a Layer or revoking its use permissions, functions that were using that layer will still run, but you won’t be able to create new functions that use the deleted layer. It’s also important to note that the overall size of the function code, its custom runtime and any configured layers must comply with the usual deployment package size limit.

DynamoDB On Demand Capacity
A major challenge we face working on SNKRS is intense bursts of API traffic, usually the result of a high heat product launch with a feature like SNKRS Pass. Without allocating a prohibitively expensive base capacity, this has required logging in to AWS and manually raising the read and write allocations to prevent throttling and service timeouts. Not a huge deal if a drop falls in the middle of the day here on the East Coast, but when supporting launches in China or Japan it can be quite the bummer.

Now with DynamoDB On Demand, instead of specifying a maximum RCU and WCU and enabling adaptive capacity (which can take a few minutes to kick in, leading to temporary throttling) you can opt to pay per request. Just make sure you know what you’re getting into, as this bypasses any estimated cost predictions.

DynamoDB ACID Transactions
Speaking of DynamoDB, on the last day of the conference I ran into my Uncle Bob on my way to the casino. I had no idea that he was in town, and to be honest, I didn’t think he’d be be interested in NoSQL—he’s a software engineer for the FBI and I just assumed they use Oracle—but one thing we were both super excited about was the announcement of DynamoDB Transactions.

What does this mean? Prior to this announcement, DynamoDB met two of the four requirements of ACID: Consistency and Durability. Thanks to ConditionExpressions, Atomicity and Isolation applied, but only pertaining to updates to a single item or row. Now with transactions, we can specify conditional reads or writes across not only multiple rows of a table, but multiple rows in multiple tables.

This means we can now leverage one of the key advantages of relational databases without any of the downside like unmanaged concurrency or deadlocks. Yes, the recommended use cases for DynamoDB encourage single table designs, a key tenant of non-relational document-store patterns, but situations can arise over the course of an application’s lifetime where conditionally manipulating data across multiple tables becomes useful or even necessary.

Recommended Viewing
These are my 3 favorite talks from last week. For a deeper dive on any of these subjects check out the following:

AWS Re:Invent 2018 — Serverless Shock Drops was originally published in S23NYC: Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Recently, our Android team started going through tech debt and spiking on how we can continue to have a best in class SNKRS experience for our users. While the app is beloved, as evident by our 4.5 rating on Play Store, we still felt that it was necessary to update our architecture to the latest and greatest that Android has to offer. In this post I’ll be going over the work we are doing to take the old persistence model, which stored flattened feed objects into Sqlite directly, and convert it to a relation schema using Google’s fantastic Room ORM. I’ll be going over the good, the bad, and the ugly of using Room.

The Good

Kotlin Support

Room works with Kotlin out of the box, you never have to write a line of java to work with Room. Your data models, DAOs, & database can all be written in Kotlin.

API Done Right

It takes all of ten minutes to be up and running with Room:

First, create Kotlin data class and annotate them as room entities

@Entity
data class Sneaker(
        @PrimaryKey val id: String,
        ...
)

Next, create a BaseDAO (Thanks Florina for the tip!)

interface BaseDao<T> {
    @Insert(onConflict = OnConflictStrategy.REPLACE)
    fun insert(vararg obj: T)

    @Delete
    fun delete(vararg obj: T)
}

Now, you can create abstract DAOs like the one below. You will only have to define query functions. Insert/Delete functionality will be inherited from your base DAO. Overall, find the syntax to feel familiar for those that use retrofit

@Dao
abstract class SneakerDAO : BaseDao<Sneaker> {
    @Query("Select * from Sneaker where id like :id")
    abstract fun getSneakerById(id: String): Sneaker
}

Once you have your DAOs, you create an abstract class with your DAOs and entities:

@Database(
        entities = [Sneaker::class, ...],
        version = 1)
abstract class SnkrsDB : RoomDatabase() {
    abstract fun sneakerDAO(): SneakerDAO
    ...
}

Finally, you create an instance of your DB:

@Singleton fun provideRoomDB(context: Context): SnkrsDB =
 Room.databaseBuilder(context, SnkrsDB::class.java, "coredb")
            .build()

Anytime you want to access your data you only need to call the function made above:

val sneaker = snkrsDB
.sneakersDAO
.getSneakerById(5)

Code Generation

Room is great because it allows you to access your DAOs which will have auto-generated implementations of all your db operations (no more cursors/content values necessary). Developers can now focus on writing beautiful features rather than binding parameters to sql statements or handwriting all the content values boilerplate that was previously required.

Native RxJava Support (It’s Reactive!)

Let’s go back to our query. The way we currently have it written we would only be able to access the data on a background thread (in a blocking fashion). Rarely would you want data on a background thread. Instead, it would be nice to have all database calls be observables similar to how retrofit allows observable call adapters.

The function can now be changed to return a Flowable<Sneakers> rather than just a Sneaker scalar value

    @Query("Select * from Sneaker where id like :id")
    abstract fun getSneakerById(id: String): Flowable<Sneaker>

Now the data can be accessed with all the power of RxJava

snkrsDB
.sneakersDAO
.getSneakerById(5)
.toObservable
.observeOn(Schedulers.io())
.subscribeOn(AndroidSchedulers.mainThread())
.subscribe({updateScreen(it)},{logError{it})

The biggest advantage of exposing queries as “endless streams” is that an update to the database will trigger a new emission to the emission above.

Anytime another insert/delete/update is run that will update the Sneaker color, my getSneakerByID backed observable will emit a new value. Additionally, schedulers can be used to allow database access on a background thread and responses to be delivered on the main thread.

Paging Support

So far there has been only a single record from the Sneaker table. What if instead all Sneakers need to be shown in a feed? Room allows writing a query like the one below to return all Sneakers:

@Query("Select * from Sneaker")
    abstract fun getSneakerById(id: String): Flowable<List<Sneaker>>

This doesn’t scale very well since the table could have thousands of records in it. Luckily the architecture components team integrated the Paging Library with Room.

Now a pagedList can be built that will bind to a RecyclerView rather than returning all records:

First, return a DataSource.Factory:

@Query("Select * from Sneaker")
    abstract fun getSneakerById(id: String): DataSource.Factory<Int, Sneaker>

Then build up your PagedList, in our case we return 10 items per page:

 val config = PagedList
        .Config.Builder()
        .setPageSize(10)
        .setInitialLoadSizeHint(20)
        .build()
 
val dataSourceFactory = snkrsDB
        .sneakerDAO()
        .getPage()
       
val pages = RxPagedListBuilder(
        dataSourceFactory, config)
        .buildObservable()

Testing Support(!!!!)

One of the most exciting features of room is that it provides a straightforward API for writing connected JUnit tests. While you can’t do unit testing due to differences in sqlite on android/jvm, you can write connected junit tests that work flawlessly with Room. Here’s an example:

First you create an instance of your DB as an in memory database:

val snkrsDB = Room.inMemoryDatabaseBuilder(InstrumentationRegistry.getTargetContext(), SnkrsDB::class.java).build()

Next, you work with your DB same as you would in your production app

val model=testSneaker(id=5,...)
snkrsDB.sneakerDAO.insert(model)
asssertThat(snkrsDB.sneakerDAO.getByID(5)).isEqualTo(model)

TDD with SQL is now a reality and dramatically sped up my development time.

Type Converters:

Want to save a date to the db as a long? You can write a type converter for how that works:

object MyConverters {
    
    @TypeConverter
    @JvmStatic
    fun toDate(value: Long?): Date? {
        return if (value == null) null else Date(value)
    }

    @TypeConverter
    @JvmStatic
    fun toLong(value: Date?): Long? {
        return value?.time
    }

}

Similar you can have type converters for saving a list of strings to a single column:

fun stringAdapter(): JsonAdapter<List<String>> {
    val listOfStringsType = Types.newParameterizedType(List::class.java, String::class.java)
    val adapter: JsonAdapter<List<String>> = moshi.adapter(listOfStringsType)
    return adapter
}

@TypeConverter
@JvmStatic
fun toJSON(list: List<String>?): String? = stringAdapter().toJson(list)

@TypeConverter
@JvmStatic
fun fromJson(list: String): List<String>? = stringAdapter().fromJson(list)

Notice that we used Moshi to marshal/unmarshal the String

We can now add the Type Converter to our data class which will tell Room how to save/read the field from db

@Entity
@TypeConverters(value = [MyConverters::class])
data class Sneaker(
        @PrimaryKey val id: String,
        val sizes: List<String>
)

It’s really nice to be able to encode the type converter logic and never have to worry about it again.

1:1 relationships with Embedded

Let’s say our Sneaker needs has a 1:1 relationship with a barcode, we can leverage an Embedded annotation which will save the barcode to the same table as the Sneaker:

data class Sneaker(
        @PrimaryKey val id: String,
        @Embedded val barcode:Barcode
)

Anytime we insert or query a Sneaker from Room, it will properly set the Barcode field with any scalar values the Barcode contains. Think of it as flattening and unflattening the two objects. The only caveat is that Barcode & Sneaker cannot have any fields that are named the same (more on that in the Bad/Ugly part)

The Bad

No support for saving nested objects

Most annoyingly, there is no support for saving nested objects. Even if we define the relations and embedded objects above, we still will need to iterate through our network models and save each object separately. Hopefully, the arch component team can improve on this process.

Embedded fields need unique names

Back to our embedded example above. If Barcode contains a field called name and Sneakers contains a field called name you will get an error on compile. Since Embedded fields are saved to the same table you need to have unique names for each field. One workaround is to manually rename the column in one object or another like the following:

@ColumnInfo(name = "barcodeName") val name: String?,

Another way is:

@Embedded(prefix = barcode)

which will then prefix all columns pertaining to barcode to barcode*FIELDNAME*

No support for recursive relations

Even if we go through the trouble of creating the above “view” of data, we still cannot load recursive relationships. For example, if a FeedItem contains images and barcodes, Room’s compilation will fail if each barcode contains an image as well.. This lead us to have to lazy load a Barcode’s images on our own.

The Ugly

1 to many relations are pretty messy

As mentioned at the top of the post, we are migrated from a data schema where we saved each Feed Item in a single table where all nested objects are serialized to json strings. Unless we rewrote every caller of the old sqlite db, we need to support callers that expect to get “fat models” back from room. Unfortunately this is not easy. Below are steps we needed to take to return a FeedItem which contained 1:1 & 1:many relationships 4 levels deep:

Need to make views

1. views should contain all 1:1 as embedded & all 1:many as relations
2. all relations need to be nullable since they get selected after embeddeds
3. entities need to have a second constructor for nullable fields
4. relation fields need to be marked as @ignore and nullable

Below is an example of a data schema that is similar to what we have in our app. Below are the additional objects and annotations you’d need to create if you wanted to load the following FeedItem with:

• 1:1 relationship with a Barcode
• 1:many relationship with Other linked items
• 1:many relationship with properties
• Properties that have a 1:many relationship with Images

data class FeedItemFull(
        @Embedded var thread: FeedItem,
        @Embedded var barcode: BarcodeFull?
) {
    @Relation(entity = LinkedItem::class, parentColumn = "itemId", entityColumn = "itemId")
    lateinit var relations: List<LinkedItem>
    @Relation(entity = Property::class, parentColumn = "itemId", entityColumn = "itemId")
    lateinit var properties: List<PropertFull>
}

class BarcodeFull(@Embedded
                  var barcode: Barcode? = null) {

    @Relation(entity = Barcode::class, parentColumn = "ItemId", entityColumn = "itemId")
    var barcode: List<Barcode>? = null
}

data class PropertyFull(@Embedded val property: Property) {

    @Relation(parentColumn = "propertyId", entityColumn = "propertyId")
    var images: List<Image>? = null
}

We were hoping that Room would “just work” when it comes to relationships and be able to save/load nested objects without all the ceremony above. Hopefully someday we can get to a better place with this. We considered writing an annotation processor to save FeedItems which would, in turn, save all nested complex objects to their own table.

Conclusion

After using Room for the first time we can definitely say that the good far outweigh the bad. The biggest pain point is how relationships are handled, otherwise doing sql on android is dramatically easier than its ever been. We will continue to migrate more and more of our data layer to Room and hope that the always amazing Architecture Component team will continue to make improvements

Room with a View was originally published in S23NYC: Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Video has been shown to increase engagement in apps and with content. How else could gif servicing apps be worth tens of millions and Youtube influencers be selling billions of dollars of product?

The problem is that video in Android can be difficult. You are given the assumption that the video types you will support are pretty basic : embedded MPEG video, URLs to MP4/AVI files, and HLS Streaming. A naive approach would be to use the embedded video player sent with Intents, but that takes the user out of your app. You think, 🤔 “ I’ll just use the Android VideoView class with AppCompat .” Then you realize that it is nearly impossible to make the experience consistent across users because of codec support and whatever the phone manufacturer may have customized in the video player. Finally you settle on Exoplayer2 because it is the package everyone, including Google, uses. Upon further inspection, you quickly realize that it requires a lot of code to make it work and the example application on the Github is confusing, far too extensive for what you are doing. Another route you could take is ExoMedia by Brian Wernick, but it trades extensibility, theming, and control for simplicity.

Fortunately, you only need the Exoplayer2 libraries to have a fantastic video player experience within your app.

SimpleExoplayer “2” the Rescue

First you need to make an app which can receive a URL and play it using Exoplayer. For this, you will need SimpleExoplayer and the Playerview from the UI package. Playerview has easy to manipulate styling/theming elements as well as available media controls. SimpleExoPlayer gives you a preconfigured player to work with without having to handle deeper logic yourself.

Start by adding the Gradle dependencies to your build.gradle :

implementation 'com.google.android.exoplayer:exoplayer-core:2.X.X'
implementation 'com.google.android.exoplayer:exoplayer-hls:2.X.X'
implementation 'com.google.android.exoplayer:exoplayer-ui:2.X.X'
implementation 'com.google.android.exoplayer:extension-mediasession:2.X.X'

Prepare a layout for your video:

<?xml version="1.0" encoding="utf-8"?>
<android.support.constraint.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:background="@android:color/black">

    <com.google.android.exoplayer2.ui.PlayerView
        android:id="@+id/playerView"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:layout_gravity="center" />

</android.support.constraint.ConstraintLayout>

Implement Exoplayer in a VideoActivity (Kotlin) :

Quick Note : Exoplayer should be set up in the onStart() for quick initialization that does not interfere with onCreate().

lateinit var player : SimpleExoPlayer
var mUrl = *some string HLS/Standard video url passed to it*

override fun onStart() {
    super.onStart()


    player = ExoPlayerFactory
             .newSimpleInstance(this, DefaultTrackSelector())

    playerView.player = player

    val dataSourceFactory = 
                DefaultDataSourceFactory(this, 
                Util.getUserAgent(this,                  
                applicationInfo.loadLabel(packageManager)
                .toString()))

    when (Util.inferContentType(Uri.parse(mUrl))) {
        C.TYPE_HLS -> {
            val mediaSource = HlsMediaSource
                .Factory(dataSourceFactory)
                .createMediaSource(Uri.parse(mUrl))
            player.prepare(mediaSource)
        }

        C.TYPE_OTHER -> {
            val mediaSource = ExtractorMediaSource
                .Factory(dataSourceFactory)
                .createMediaSource(Uri.parse(mUrl))
            player.prepare(mediaSource)
        }

        else -> {
            //This is to catch SmoothStreaming and
            //DASH types which we won't support currently, exit
            finish()
        }
    } 
    player.playWhenReady = true
}

override fun onStop() {
    super.onStop()
    playerView.player = null
    player.release()
}

That was almost too easy!

Boost it with Picture-in-Picture

This is where things get interesting.

According to the basic documentation on AndroidDevelopers, this is all you need to get started with Picture in Picture :

//For N devices that support it, not "officially"
@Suppress("DEPRECATION")
fun enterPIPMode(){
    if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.N
            && packageManager
            .hasSystemFeature(
            PackageManager.FEATURE_PICTURE_IN_PICTURE)) {
        videoPosition = player.currentPosition
        playerView.useController = false
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            val params = PictureInPictureParams.Builder()
            this.enterPictureInPictureMode(params.build())
        } else {
            this.enterPictureInPictureMode()
        }
}

Now, I will say that while implementing Picture in Picture support, Google was notified of issues in documentation. It’s better now and includes some of the things like checking if the system has the feature (some devices will not have Picture in Picture because of RAM considerations) which is shown above. 👏

Next, hook up switching to Picture in Picture when the user hits the Recents, Home, and Back buttons here :

override fun onBackPressed(){
    if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.N
            && packageManager
            .hasSystemFeature(
            PackageManager.FEATURE_PICTURE_IN_PICTURE)){
        enterPIPMode()
    } else {
        super.onBackPressed()
    }
}

/Called when the user touches the Home or Recents button to leave the app.
override fun onUserLeaveHint() {
    super.onUserLeaveHint()
    enterPIPMode()
}

Google has added some of this to the documentation recently 😀, but not onBackPressed() 🧐 . What could be unique about onBackPressed()?

Permission Handling

The user can turn off this permission as part of the Advanced permissions.

If you are familiar with deeper permission handling as well as the system the normal Permissions tie into, you should just be able to handle this case in AppOpsManager. In that case, the code would look like this :

val appOpsManager = 
    getSystemService(Context.APP_OPS_SERVICE) as AppOpsManager

if(appOpsManager.checkOpNoThrow(
    AppOpManager.OP_PICTURE_IN_PICTURE, 
    packageManager.getApplicationInfo(packageName, 
    PackageManager.GET_META_DATA).uid, packageName)
    == AppOpsManager.MODE_ALLOWED){
     //Picture in Picture is enabled, yay!
}

Oh, there is a problem with that. It’s not valid in Android Studio 😠.

https://github.com/aosp-mirror/platform_frameworks_base/blob/studio-3.1.2/core/java/android/app/AppOpsManager.java#L1640

For the Integer-Op-type, unlike the String-Op-type version, the ability to check the permission is hidden 🙅.

WHY?!?!

One likely answer is that this was a carry-over from N where Google didn’t anticipate Picture in Picture becoming a public feature or Google could be trying to enforce certain developer behavior. Right now, if the user does not have the Picture in Picture mode enabled in these special permissions, it will not work and there isn’t a nice way to check it 😥. For apps, it means that you cannot enable Picture in Picture mode for onBackPressed() without risking needless crashes and an unpleasant user experience.

Pressing the back button seems like the most common use-case for small video content, so this lack of handling the Back button doesn’t entirely make sense.

Again, they could have this fixed in the proper AndroidStudio 3.2.X release, but that isn’t out yet.

So, you need to be a little creative here 🤔 :

fun enterPIPMode(){
        if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.N
            && packageManager
            .hasSystemFeature(
            PackageManager.FEATURE_PICTURE_IN_PICTURE)) {

         ...
         ...

    Handler().postDelayed({checkPIPPermission()}, 30)
    }
}

@RequiresApi(Build.VERSION_CODES.N)
fun checkPIPPermission(){
    isPIPModeeEnabled = isInPictureInPictureMode
    if(!isInPictureInPictureMode){
        onBackPressed()
    }
}

I know, it seems a bit jank. But, 25–30ms to check whether the Activity actually went into Picture in Picture mode is plenty of time, even devices that have very limited memory (512mb + running other apps), to enter Picture in Picture mode as far as the system is concerned. It also gives you enough time to send the onBackPressed() so that the system knows you aren’t holding the user hostage and the delay is neigh imperceptible by the user. Yes, this is under the AOSP “Bad Behavior” timer. 😜

More Picture in Picture oddness discovered

Now that Picture in Picture mode is working and no crashes can really happen, there is another scenario which comes up.

The user hits the “X” or drags the Picture in Picture window down to dismiss. You would expect that this simply calls finish() and the window disappears into the ether. But, it doesn’t. You can still see the activity lingering in the Recents for what seems like forever as you wait for it to be collected………*3 minutes later*………….now. 😞

This is a problem because:

1. It doesn’t look good for your app
2. It can be a major headache if you want to start up a new Picture in Picture instance because the old one is just lingering there.

If you watch to see what is getting called when the user “closes” a Picture in Picture window you see this being called :

override fun onStop() {
    super.onStop()
}

Logically, finish() is being called and that is one of the first LifecycleEvents part of that flow. But, not in the traditional sense.

Picture-in-Picture mode is unique, especially in the separate Activity case, because it acts like it is entirely its own app.

To get around this problem and clear out the VideoActivity quickly and efficiently implement this :

override fun onStop() {
    ....
    ....
    if ((Build.VERSION.SDK_INT >= Build.VERSION_CODES.N)
        && packageManager.hasSystemFeature(
        PackageManager.FEATURE_PICTURE_IN_PICTURE)) {
        finishAndRemoveTask()
    }
}

Done. Killed and removed appropriately.

Adding Media Controls to Picture-in-Picture

Start/Stop/Next

By default, Exoplayer + Picture in Picture does not give you the Picture in Picture media controls you see in the Youtube player for instance. Picture in Picture mode depends on a MediaSession to handle that communication. If you have written an AndroidTV application, audioplayer, or video-centric app before, you should be familiar with it. It can also be used for handling media controls from outside devices (like bluetooth headsets), widgets or advanced notifications with media controls. Here, you will be using the MediaSession Extension Library to take care of this. ⏯

Just add this code in the onStart() after handling your Exoplayer :

val mediaSession = MediaSessionCompat(this, packageName)
val mediaSessionConnector = MediaSessionConnector(mediaSession)
mediaSessionConnector.setPlayer(player, null)
mediaSession.isActive = true

One More Thing

Since Picture in Picture essentially acts like its own Application, it can live on without the Main App.

Yes, if you kill your Main App the Picture in Picture window will live on without you unless you kill it first. That means, if you have connecting information (such as multiple URLs or other streaming info) being sent and resetting the content of the Picture in Picture window that connection will be lost and it will become a ZOMBIE Picture in Picture WINDOW 😱.

What you can do to solve this is register an “Exit Event” Service to capture when the user Force Closes your app. In this Service, you need to override onTaskRemoved(rootIntent:Intent) and send a signal (RxJava Observable/Subscriber, Eventbus, Intent, etc.) which the Picture in Picture’d Activity can catch and call finishAndRemoveTask() to make a clean exit.

Code

There you have it folks! Lots of little gotchas taken care of.

Full code example with a DROP-IN VideoActivity.kt you can use right now.

http://bit.ly/exoplayerPIPexample

It includes some extra, useful features:

• Play/Pause/Resume/SeekTo controls for v ideo
• Show/Hide Exoplayer controls when the user goes in-out of Picture in Picture mode
• Rotation handling (fullscreen and vertical with no placement loss).

Drop-in Android Video — Exoplayer2 with Picture in Picture was originally published in S23NYC: Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’ll be using Kotlin data classes with Moshi to create value objects that are tested, have generated type adapters, and correctly handle api responses from a particular endpoint. We’ll also be using Okio to load our data from a test.

Collecting sample json

Let’s start with a consumer complaint database for our example, feel free to use your own. First step is to fire up a browser to inspect the initial json from the link above. It is a good idea to format our sample json by pasting it into your favorite json editor/formatter. Additionally you will want to copy the formatted json into your test resources folder and save it.

I’ve found doing this over the years to be invaluable. The formatted json acts a reference for yourself and future developers. We can test against it and not rely on any external systems. If the backend goes down, our tests will still pass. If anything does happen to change on the server we have a great reference in our tests to help us understand those changes.

Modeling your data

Let’s get started on the data model! We’re going to be using Moshi’s Kotlin code gen package to create a model from Kotlin data classes. Why Moshi? It provides type adapters for us as you would typically have to use a library with gson like Immutables.org or Auto Value. Also, Moshi respect’s the nullability rules of Kotlin and will disallow a null value in a non null field.

Kotlin data classes are also immutable. As mentioned, this makes our lives easier in a lot of ways. By not having to worry about data mutations we reduce complexity around working with data, particularly in a multi threaded environment like Android. If we did want to have the equivalence of a mutation, we can simply use the builtin copy method that we get for free from using Kotlin data classes.

We need to add in our dependencies like:

implementation "com.squareup.moshi:moshi:$moshi_version"
kapt("com.squareup.moshi:moshi-kotlin-codegen:$moshi_version")

Looking at the json data that we got from the url above, we can see that it is made up of an array of complaints with usual scalar values like id, description, createdAt and some json objects like owner and metadata.

@JsonClass(generateAdapter = true)
data class Complaint (
        val id: String,
        val description: String,
        val createdAt: Long,
        val owner: Owner
)

@JsonClass(generateAdapter = true)
data class Owner (
        val id: String,
        val displayName: String,
        val flags: List<String>
)

Notice the @JsonClass(generateAdapter = true). That’s how the magic happens — Moshi picks up this annotation and generates all of your type adapters for you. Zac Sweers wrote an excellent article that goes into the code generation internals and advanced usage. I encourage you to check it out.

Loading json for a unit test

Next, let’s add in Okio as a dependency as we’ll need it to load the sample json file from earlier. Why are we doing this again? We want to load the json response to test against and we don’t want to have to hit the server each time.

implementation "com.squareup.okio:okio:$okio_verison"

I’ve had a hard time consistently accessing the file system during tests and have found that the best way is to do something like this:

private fun inputStream(path: String): InputStream {
    return ComplaintsTest::class.java!!.getResourceAsStream(path)
}

@Test
fun loadData () {
    val myStream = inputStream("/gov_complaints.json")
    Assert.assertNotNull(myStream)
}

You can see in the above example that we are a getting a runtime reference to the Kotlin test class and using that load the data file as a stream: ComplaintsTest::class.java!!.getResourceAsStream(path)

Now that we can access our data on disk, let’s use Moshi to get it into the form we want. But first, how do we handle that stream? We can see Moshi’s fromJson() method which takes either a JsonReader, BufferedSoruce, or a String. Okio makes transforming a stream a simple one liner like this:

Okio.buffer(Okio.source(inputStream("/gov_complaints.json")))

That’s it! we’re good to go! You now have a buffered source that Moshi can read from. If you’ve never had to deal with a raw list in Moshi, you do it with a ParameterizedType like this:

val listType = Types.newParameterizedType(List::class.java, Complaint::class.java)

And create the Moshi adapter like so:

moshi.adapter<List<Complaint>>(listType)

Putting this altogether we get the following:

Validating your data model

Running our test fails immediately with the following error:

JsonDataException: Required property ‘flags’ missing at $[0].owner

The flags value in one of our json samples is either missing or null which breaks Kotlin’s non nullable type that we declared in our data model. We should probably make this optional. We’ll go ahead and add a “?” on the flags value. We finally end up with:

Running our test over and over again will allow us to validate and fix any missing types. While sometimes you have a json schema, in our case this is a great way to prevent crashes at runtime. When we connect to the endpoint or pass that work to another developer, a good bit of the leg work will already be done and time spent on figuring this out will be kept to a minimum. Any issues or inconsistent data can be caught early.

Summary

Regardless of how you are getting the data or what libraries you are using, this pattern of steps will be applicable to you. Over many years of working on a variety of applications large and small, I have found that this has saved me time and effort again and again. The next time you have to model some data, follow these steps. You’ll impress your coworkers and bring some sanity back.

To summarize:

• Collect json samples, format them, add them to test resources folder and check them into source control. You now have human-readable datasets to test against and refer to as needed.
• Design the data model from a unit test, resulting in less turnaround time and reducing overall time spent on this task.
• Load the datasets via tests as this will allow you to validate any mapping logic you require for your data model.

Data Model as your Table Stakes was originally published in S23NYC: Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the first libraries I open sourced was Store which was an implementation of the Repository pattern wrapped in RxJava. Store abstracted away the common pattern of load from memory, if not present load from disk parse the data, if not present load from network. This was all done with minimal setup by a user:

Initially Store was something I developed based on my use cases. While everything was interface based, I shipped a few implementations of parsers for Gson, Moshi, Jackson) and a FilePersister which eased in streaming data from a network to disk.

Fast forward 18 months and Store is up to 3000+ stars & 37 contributors mostly from folks I’ve never met (Thank you all!). In that time the community has helped implement:

• Memory & disk caching policies
• Wrappers for fetchers that return full objects rather than streams
• Result abstractions to determine which source data is coming from
• New API for refreshing get calls on clearing data
• A fluent Kotlin DSL
• Documentation including translations to Russian & Spanish
• An update to RxJava2
• Many other PRs full of performance improvements and bug fixes.

Store as it stands today is a full fledged data solution that both helps prevent extraneous data calls to your network and helps write apps that exhibit proper separation of concerns. Since moving on from the New York Times, I’ve had a chance to rethink how Store can better suit the needs of users in the modern Android ecosystem. I’m not just the primary maintainer of Store, I also use it in every project I have built since.

Time to get a Room

One of the most popular open source requests Store had was integration with Room. I was hesitant to integrate Room because I had never used it before and I wasn’t really sure how the integration would work. Now that I’m working at Nike’s s23NYC studio, we explored what data solution best fits into our re-architecting of the SNKRS Android app that we maintain. After exploring various solutions we decided that Room was by far the most robust and easy to use persistence solution. While Room was great at working with a database, it was still missing key features like request de-duping, memory caching, stale/refresh policies and all the other great features mentioned above. We still needed a repository abstraction that would wrap Room to implement these features. So, my team set out to fuse all the great features of Room with all the things we loved from Store.

Since most of Store was based on interfaces, we were able to integrate Room into Store by building a RoomPersister and StoreRoom, which is a specialized type of store. The StoreRoom includes the familiar features from Store while taking advantage of the reactive nature of Room & Flowables.

Room: Remind me what that is?

Room is a persistence library that is part of Google’s Architecture Components. Room is an ORM and does a fantastic job of giving you all the power of working with a database without any of the messiness of cursors, database connectors or having to map data yourself. Room is built on top of SQLite and takes care of a lot of the boilerplate associated with saving to or reading from a database.

Additionally, Room’s reactive API through its first class RxJava support transforms simple SQL queries into auto updating Flowables. Room queries exposed as RxJava Flowables is what I’ve always imagined as the perfect persistence layer to Store. It helped me get rid of messy code like the old stream & getRefreshing functions we previously used to fake endless streams. Using a Room backed persister allows Store subscriptions to update anytime the underlying data changes.

Store+Room a match made in Android heaven

Using the new StoreRoom is every bit as easy as using a regular Store.

First, create a Room DAO as you always do with Room. Within your DAO, expose an Insert & a Query function. The types do not need to be the same.

Next, implement Store’s Fetcher to tell StoreRoom how to get new network data. Below is an example that would use an API (Retrofit is recommended) to return a Single<User> based on a passed in user id.

Since both Retrofit & Room work with objects, there’s no reason to implement a parser anymore. We will let Retrofit take care of the parsing when a new network request comes in.

Next, we need to make an implementation of our RoomPersister. Notice how the read function returns a List<User> while the write function is only writing a single user each time.

You can of course change what the read and write functions return. As another example, you might want to write a collection or return a single item — the choice is up to you.

Now that we have our Fetcher & Persister, we can create an implementation of a StoreRoom:

Voila! All the functionality we always had with Stores but rather than being backed by a file persister we are now backed by a Room DAO.

Want to get data but don’t care about the source? Call store.get(). Need to bust through your cache and call network only? Call store.fresh()

So far this feels just like a normal Store. What do we gain by using Room besides ability to query & have different read/write types? Reactive reads, that’s what!

Since Room can expose data as Flowables, StoreRoom will expose endless reactive streams from your get and fetch calls. For example, if you call store.get() and subscribe to the results, anytime another call is made to your stores’ get or fetch method, your subscriber receive an updated value.

With StoreRoom we not only have disk and memory caching but we now have endless observables that will auto update subscribers if the underlying data we are querying for changes. Particularly in the above example every new user that gets fetched from the network and saved to the DB will cause an emission of all the users to any current subscribers.

Store and Room are a match made in heaven, Room is inherently reactive as the use case above demonstrates while Store gives you memory that sits on top of those DB requests and missing features like request throttling when you request the same data in parallel from various parts of your app (Think of reading the same config value N times on app start without having to hit your network or db more than once). As always with Store, new subscribers to Store.get() don’t need to go all the way to your DB if your memory cache has not expired. This leads to my ideal data workflow of fast reads from memory and reactive reads from disk all backed by a network source.

What’s next

I hope you enjoy using our new StoreRoom and RoomPersisterthat our s23NYC team is contributing back to Store. Next, we hope to work towards an annotation processor that would auto generate the above Store code from a Room DAO. As always community help is appreciated!

Resources:

NYTimes/Store

• 7 Steps To Room
• Room 🔗 RxJava

Store+Room — A Reactive Repository was originally published in S23NYC: Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Where to begin? It can be a daunting question when looking at a complex animation mock-up. In this blog post we will break down an animation into pieces and prototype iteratively to build a reusable, animated wave view.

Prototyping in a Playground

Before we dive in, it will be useful to setup an environment where we can rapidly prototype our animation without having to continuously build and run with every small change we make. Luckily, Apple gave us Swift Playgrounds, which is the perfect place to sketch out front-end code quickly without having to use a full application container.

Let’s create a new Playground in Xcode by selecting File > New > Playground… from the menu bar. We can choose the Single View playground template to get the Playground live view code written for us in a nice template. We’ll make sure to select the Assistant Editor so that we can see live updates as we code.

Animating Waves

This animation we’re building is one of the final parts of the SNKRS Pass experience, which is a new way to reserve access to the newest and hottest Nike shoes at retail stores. When a user goes to pick up their shoes, we want to give them a digital pass that feels like a golden ticket. The background animation is meant to mimic a holographic sticker of authenticity. When the user tilts the device, the animation reacts, and moves around as if a light is reflecting off of it.

Let’s start very simply by creating some concentric circles:

Easy enough. Now how to animate these outwards? We’ll make use of CAAnimation and Timer to continuously add and animate these CAShapes. There are two parts to this animation: scaling the shape’s path and increasing the shape’s bounds. It’s important to animate the bounds in tandem with a scale transform on the shape so that the circle moves to fill the screen. If we don’t animate the bounds, the circles would expand while keeping their initial origin at the center of the view (expanding down to the lower right corner). So let’s add both of these animations to an animation group to perform them at the same time. It’s important to remember that CAShape and CAAnimation require converting UIKit values to their CGPath and CGColor counter parts. Otherwise, the animation will just fail silently! We’ll also make use of the CAAnimation delegate method animationDidStop to remove the shape layer from the view once its animation completes.

Trippy! Next, we will swap out the circles for our custom path. In order to generate a custom path, we can use PaintCode to help generate code. In this blog post, we’ll be using a star shape for our wave path:

The tricky part with using a custom path is that we now need to scale this path instead of generating a final circle path from the bounds of the AnimatedWaveView. Since we want this view to be reusable, we need to calculate how much to scale the shape’s path and bounds based on the final destination rect. We can create a CGAffineTransform based on the ratio of the path’s final bounds to its initial bounds. We also multiply this ratio by the scaleFactor of 2.25 so that the path expands larger than the view before completing. We need to do this so that the shape completely fills the corners of our view, rather than just disappearing once it reaches the view’s size. Let’s build the initial and final paths during initialization and update the final path if our view’s frame changes:

After updating our animation group to use our new finalPath property and using the initialPath inside buildWave(), we’ll have an updated path animation:

The final piece to making sure we can reuse this wave animation in different sizes is to refactor the Timer approach. Rather than continuously creating new waves, we can create all of the waves at once and stagger the start time on CAAnimation. This is done by setting the timeOffset on the CAAnimation group. By giving each animation group a slightly different timeOffset, we run all animations in parallel from different starting points. We will calculate the offset by dividing the total duration of the animation by the number of waves on screen:

We’ll pass the duration and timeOffset down to the animateWave() method. Let’s add in a fade-in animation as part of the group to make things a bit smoother:

Now we can draw each waves and add animations all at once when calling makeWaves(). Let’s take a look at our hard work:

Woohoo! We now have a reusable animated wave view!

Adding a Gradient

The next step is to improve our wave animation by adding a gradient. We’d also like to animate the gradient in relation to device motion, so we will create a gradient layer and keep a reference to it. I explored putting semi-transparent wave layers on top of the gradient but the best solution was to add the wave layers to a parent layer and set it as the mask of the gradient layer. With this approach, the parent layer draws the gradient itself, which looks much more effective:

Motion Tracking

The next step is animating the gradient to move in correlation with device motion tracking. We want to create a holographic effect that mimics light reflecting against the surface of the view as you tilt it in your hands. To achieve this, we will add a gradient which rotates around the center of the view. We will use CoreMotion and the CMMotionManager to track accelerometer updates and use this data for our interactive animation. NSHipster has a fantastic write-up on CMDeviceMotion if you’re looking for a deeper dive into what CoreMotion has to offer. For our AnimatedWaveView, we will only need the CMDeviceMotion gravity property (CMAcceleration) which will give us the acceleration velocity of the device. We will only need to track the X and Y axis as the user tilts the device horizontally and vertically:

So X and Y will be from -1 to +1 with (0,0) being the origin (device resting flat on a table face up). Now how do we want to use this data?

At first, I tried using CAGradientLayer and thought rotating the gradient would create this shimmering effect. We could update its startPoint and endPoint based on the CMDeviceMotion gravity. CAGradientLayer is a linear gradient, so revolving startPoint and endPoint around the center will effectively rotate the gradient. Let’s convert the X and Y values from gravity to the degree value we would use to rotate the gradient:

Note: We can’t simulate motion tracking in the simulator or in a Playground so we’ll need to switch to working in a Xcode project with a real device.

After some initial testing with design, we felt the need to add a booster to the X value returned from gravity so that the gradient would rotate at a faster rate. So we multiply the gravity.x before converting to radians.

To perform the rotation of the gradient, we’ll need to convert the angle at which the device is rotated to the start and end points of the rotation arc: startPoint and endPoint for the gradient. There is a really smart StackOverflow answer we can use to achieve this:

Busting out some trigonometry! Now we’ve converted degrees to our new startPoint and endPoint.

This is ok…but can we do better? Most definitely! Let’s take this to the next level…

CAGradientLayer doesn’t support radial gradients…but that doesn’t mean it can’t be done! We can use CGGradient to create our own CALayer class, RadialGradientLayer. The tricky part here is making sure to cast an array of CGColors to a CFArray during the initialization of the CGGradient. It took a bit of trial and error to figure out exactly what kind of array needed to be casted to a CFArray and that locations could simply be an array of CGFloats to satisfy the UnsafePointer<CGFloat>? Type.

At last we have all the pieces in place! Now we can swap out the CAGradientLayer for our shiny new RadialGradientLayer and calculate a mapping of device gravity X and Y to a coordinate position for the gradient. We’ll convert the gravity values to a float percentage between 0.0 and 1.0 to calculate how to move the gradient.

Now let’s circle back to the makeWaves and addGradientLayer method and make sure everything is connected together:

Drumroll please…

Now that’s pretty slick!

Attached is the the final example project with all of the code in its final state. I encourage you to try running this on a device and play around with it!

j-wilkin/AnimatedWaveView

Prototyping Animations in Swift was originally published in S23NYC: Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.