July 2017

There were 5 posts published in July 2017 (this is page 1 of 1).

AnDevCon 2017 – How Yahoo Finance Scales on Android – Vikram Bodicherla

I saw Vikram‘s talk at Droidcon NYC 2016 talk about app performance, and wanted to make sure I made it to his talk.  He talks about overall processes for a successful development team along with tools and tips for shipping apps.

Developers shouldn’t be afraid to dip your toes into “product”.
 Contribute to feature definition to make your voice heard as a user and for technical implementation.

Understanding your users – Fantasy Football Example:
You should be aware of who is using your app. You might think everyone using a fantasy football app are very serious users, but we find that 12% randomly pick, and 60% are first year users. Try to find patterns between different types of users of your app. Build personas of your users. Building personas of your users is a way to explain behavior that would be hard to explain otherwise. Give these personas name and put them up on the wall in your office. Know who your users are and design for them.

Personas for fantasy football includes:

  • Seasoned pros
  • People that are forced to join by their friends
  • People that are serious, but learning
  • “average” users

Data Driven Decisions via Experiments:
DAUs and Downloads are really “Vanity Metrics”, since they don’t gain a ton of insight. Data driven insights are real; not opinions. Wrong decisions can be validated quickly, so feel empowered to test, measure, and grow. Instead of doing costly user research, you can push something to a small group of users, and gain data there vs. expensive user research.

Each experiment should have:

  • A hypothesis
  • An owner
  • A deadline for the end of the experiment.
  • Planned removal of the code from your app. You learned something from it, now “Let it go!!!”

Scrum
Planning is a good investment. You can see how long things will take, determine dependencies, and people can show interest in pieces of the work.  Agile is important because it’s not adverse to change like Waterfall is.

Types of stories in Scrum:

  • User story
  • Engineering story

Scrum story checklist:

  • Clear definition
  • Acceptance criteria
  • Edge cases and error scenarios
  • Analytics
  • Animations and design

Grooming

  • should be (1x/week for 1 hour)
  • It helps the team to understand stories -> Determine level of effort for stories (Points)
  • Stories should have reasonable detail. Be very critical and make sure the story is well defined.
  • Don’t get hung up on one story. If your getting hung up, move on and take that offline so you don’t waste your entire grooming on one thing.
  • NEVER write stories during Grooming.
  • NEVER point a story that doesn’t have all the details.

If you get roll-over and carry-over after a sprint consistently, you’re doing something wrong and should revisit your processes.

Daily stand-ups should be no greater than 10 minutes and should provide high level updates. Low level updates should be taken “offline”, or “parking lotted”.

At the end of the sprint, you can hold a retrospective and demo completed stories.  Please prepare up front for this so we don’t have to wait for you to launch the emulator or recompile your project.

“If you’re are not practicing scrum in sprit, you are better off not doing it.”

Continuous Delivery

  • Minimizing the time between “code complete” and “deployable”
  • deployable != deploy
  • This can only be achieved with continuous integration (CI)
  • If you do deploy immediately to your users, you get immediate feedback, but not always the best for your users. Vikram recommend every 2 weeks on average, but depends.
  • Have internal alpha and beta programs for internal users to try the app before it goes to production.

Pull Request (PR) Tools

  • facebook/mention-bot – Can tag reviewers based on “git blame” history
  • SonarCube
  • https://codecov.io for Code Coverage
  • Danger -> Keep PRs <500 lines, PR message should be >25 chars.
  • Emulator in an iframe, running the code in the PR.  -> https://appetize.io Removes need to compile and install.

APK storage and deployment:

Culture

  • How you act/think/interact. Keep high standards, because you are what your lowest standard is.
  • Ownership is important. Communicate deviations and compromises so it’s not lost. Proactively check app quality issues and triage as soon as you can.
  • Set goals, but aim for 70%. If you get 100%, then your goals are not high enough.

Meeting etiquite

  • Everyone needs to have value, or they shouldn’t be there
  • Reject meetings if they are not needed
  • Meeting owner should have adgenda, goals and come out with action items.
  • There should be a hard start and end type.

Code is a liability. Once it’s out there, you have to support it. Changing code is expensive.  Deleting code is a good thing.

Feature Flags – Client-side feature flags are important, along with remote feature flags.  Client-side flags should take priority, but if it’s on, then use the remote flag.

AnDevCon 2017 – A Room With a ViewModel – Mark Murphy (CommonsWare)

Word of the day: “Transmogrify”
“to transform, especially in a surprising or magical manner.”

Mark draws a great comparison between Room and Retrofit as they both use annotation processing, and describe either a URL path, or a DB query.  The @Query annotation in Room, is similar to the path in Retrofit that is provided to @GET, @POST, etc.

Parameters can be sent with the syntax :postalCodes.  You can pass parameters into a query this way:

@Query(“SELECT * FROM Customer WHERE postalCode IN (:postalCodes)”)
List<Customer> findCustomersInPostalCodes(String… postalCodes)

Cool DB Testing Tip for Android Instrumentation Tests: In-memory databases work the same way that SQLite databases do that are saved to the disk. In-memory database are great for instrumentation tests because they are fast, and when you are done with it, it’s gone from memory, and doesn’t persist to disk.  It’s not recommended to use in-memory databases in true client apps however.

Types used in Room need a @TypeConverter.  You can specify the type converters to be used in the following way:

@TypeConverters({TypeConverter.class})

Caveats about relations:
You can use @ForeignKey on a child, but… <OMG head explosion />.  Foreign keys are there, but there aren’t any magical methods generated to retrieve a child. You can just get an ID for the child, and then have to re-query for that. You can specify cascading deletes however which is useful.

Room Migrations – Create instances of Migration –  A little more sane than just plain SQLite.

Note about SQLCipher – It was last updated in 2009, and the APIs are really hard (if not impossible) to integrate with Room.

LiveData – Room works really well with Rx programming. 🙂

Predictions: We will go through a lot of iterations of the APIs as kinks are worked out and things stabilized.  The guess is that a final version would be available around Google I/O 2018.

Check out Mark Murphy on the internet:

AnDevCon 2017 – An Introduction to RxJava – Matt Dupree

Here are some notes I took from Matt Dupree’s talk.  It was a really great intro to Rx, and done in a different way than most Rx talks I’ve seen.  He creates mental building blocks to get us from the Java Array to the Rx Observable.

“We are missing an abstraction”
Array -> Iterable -> Sequence -> Observable

Goal of this talk: Escape from “Callback Hell” (Too many nested callbacks, and Observables are here to help).

In Java, the “Iterable” interface allow us to abstract away from an Array, hiding us from the underlying implementation like LinkedList, HashSet, etc.  We just care that we are going through the items when we have an Iterable, and don’t really car how it’s done.

A button clicks example used:
* If you knew all your button clicks up front, you’d just do a “for” loop
* Instead you have an onClickListener since you don’t know when it’ll happen
* You instead subscribe to an observable stream (which looks like a loop), and for each observable event, you perform the action.

Interesting point: With an observable, data is not in memory necessarily, but you write code like it is.  This is another layer of abstraction that is helpful in doing delcarative programing instead of imperative programming.

Declarative Programming
This is “WHAT” I want to happen.

vs.

Imperative Programming
This is “HOW” I want it to happen.

Cool tip about “Debouncing”: I hadn’t heard of this before, but he shows another use case regarding a search text box, and he showed how EASY it was to use debouncing.  Debouncing can help you wait for the stream to settle, and in this case you can wait 300ms after the last event. You can just say wait until the observable hasn’t been called in XXX milliseconds, and if that’s the case, then continue on.

Resources:

Note: “Rx” means Reactive Extensions. (I, personally hear the term “Rx” so much, that I forget that it means something else sometimes)

Troubleshooting Auto Verification of Seamless Android App Deep Linking

You’ve read all of the Android documentation on how to add seamless deep-links into your app, but it still isn’t working, and you’re seeing the app-chooser dialog.

 

Here are a few things that helped me with troubleshooting, and hopefully they’ll help you as well.

Checklist for troubleshooting “autoVerify”:

  1. Have you use App Links Assistant in Android Studio?  There are tons of new features here to help you debug issues.
  2. Did you add an intent filter for your DeepLinkActivity with autoVerify=”true” to your manifest? 
    <activity
    android:name=".deeplink.DeepLinkActivity"
    android:theme="@android:style/Theme.NoDisplay">
    <intent-filter android:autoVerify="true">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="https" android:host="mycompany.com" />
    </intent-filter>
</activity>
  3. Is there an assetlinks.json file publicly accessible (the real internet, not just your corporate VPN) in the correct place like… 
    https://HOST/.well-known/assetlinks.json

    … for EVERY single one of the HOSTs listed in your manifest intent-filters?  Unless every, single one of them is valid, not even links to valid hosts will work.

  4. Is your the sha256 hash of your DEBUG and RELEASE keystores both in your assetlinks.json file?  It doesn’t hurt to include both signatures. 
    keytool -list -v -keystore my-keystore.keystore
  5. Have you monitored the Logcat filtered for SingleHostAsyncVerifier and IntentFilterIntentSvc?  They print out logs after an adb install that tell you the status of auto-verification. Filter for IntentFilterIntentSvc, and if you see “Success:true”, then you’re good!  See more details here. 
    I IntentFilterIntentSvc: Verification 6 complete. Success:true. Failed hosts:.

 

Best of luck, hopefully this helps a little!

—

Related Helpful Blog Posts:

How do I write static methods in Kotlin?

When I was starting to write Kotlin code, and one problem I faced was how the heck do I do static methods like I can add in Java?

The solution… The companion object in your Kotlin class.

class MyClass() {
  companion object {
    fun myStaticMethod() {
      //Do Stuff Here
    }
  }
}

Accessing this static method via Kotlin:

MyClass.myStaticMethod()

Accessing this static method via Java:

MyClass.Companion.myStaticMethod()

To avoid having to use the “.Companion” syntax, use the @JvmStatic annotation, allowing you to access the method without “.Companion”:

class MyClass() {
  companion object {
    @JvmStatic
    fun myStaticMethod() {
      //Do Stuff Here
    }
  }
}

Accessing this static method via Java and @JvmStatic:

MyClass.myStaticMethod()