Profile cover photo
Profile photo
Brian Hoffmann
77 followers -
I'm a peacock. You gotta let me fly!
I'm a peacock. You gotta let me fly!

77 followers
About
Brian's posts

Post has shared content
Use cold start time effectively with a branded launch theme
Pro-tip by +Ian Lake

When your app isn’t in memory and is launched, that ‘cold start’ can take significantly longer than if your app is already in memory. Depending on the size of your app and what you’re doing in your Application’s onCreate() (as little as possible I hope!), there may be lag between when the user starts your app and your Activity’s onCreate() is actually called. During that time, the window manager makes its best effort to draw a placeholder UI using elements from your theme such as the background and status bar color.

But the background doesn’t have to be a solid color: it can be an opportunity to add a little more personality and branding to your app without slowing down the user through the use of a branded launch screen (http://goo.gl/gp6FDE), allowing your app UI to focus on content rather than additional branding. The key is creating a custom theme that overrides android:windowBackground, then replacing that custom theme with your standard theme before calling super.onCreate().

Assuming you have a theme called AppTheme, your launcher theme would be:
<style name="AppTheme.Launcher">
  <item name="android:windowBackground">@drawable/launch_screen</item>
</style>

This implies that everything about the launcher theme is inherited from your main theme - you’re just changing the windowBackground. One other attribute you may consider changing here is colorPrimaryDark: the status bar color on Android 5.0+ devices. Setting colorPrimaryDark to your main background color can put more emphasis on your branding at the expense of another element changing when transitioning to your final theme.

But drawable/launch_screen can’t be just a simple image, unfortunately - it’ll end up stretched to fill the entire screen. Instead, you can use an XML file such as:
<layer-list xmlns:android="http://schemas.android.com/apk/res/android" android:opacity="opaque">
  <!-- The background color, preferably the same as your normal theme -->
  <item android:drawable="@android:color/white"/>
  <!-- Your product logo - 144dp color version of your app icon -->
  <item>
    <bitmap
      android:src="@drawable/product_logo_144dp"
      android:gravity="center"/>
  </item>
</layer-list>

Make particular note of the android:opacity=”opaque” line - this is critical in preventing a flash of black as your theme transitions.

Then apply your theme to your activity in your AndroidManifest.xml using android:theme="@style/AppTheme.Launcher".

The easiest way to transition back to your normal theme is to call setTheme(R.style.AppTheme) before super.onCreate() and setContentView():
public class MyMainActivity extends AppCompatActivity {
 @Override
  protected void onCreate(Bundle savedInstanceState) {
    // Make sure this is before calling super.onCreate
    setTheme(R.style.Theme_MyApp);
    super.onCreate(savedInstanceState);
    // ...
  }
}


Things to note with this approach:
- No launchpad activity - there’s no delay such as there would be if you were launching a second activity from a dedicated splash screen style activity
- No artificial delays - you’re only using the time that you have, just taking advantage of theming
- No extra overdraw - resetting your theme removes a layer of overdraw compared to having an opaque view with your normal background above the custom windowBackground
- Only for your launcher activity - this isn’t appropriate for deep links into your app or handling a URI, but for launches done through the home screen - the point is to minimize dead time, not to annoy users.
- Fast is best - keeping your app lean and minimizing work done at startup is critical to a good experience, even if that means slightly less time for branding - remember: getting users to the content they care about should be your #1 priority.
- Watch your transition - keep both the number and complexity of your transitions to a minimum by sharing as many elements (colors, etc) as possible to make for a seamless transition straight to content.

#BuildBetterApps  

Post has attachment

Post has attachment
Awesome: PSD to Vector conversion right in Android Studio. Is this new in Preview 3?

#androiddev   #androidstudio   #vector  
Photo

Post has attachment

Post has shared content

Post has shared content
Slides from my talk at the +G D G Dublin  #devfest  are now on Speaker Deck. Something interesting happened with the color after uploading the PDF, but the content is the same ;)

#gde   #techtalk   #androiddev  

Post has attachment

Post has shared content
Vysor Share

Remote screen and ADB access

There's a few tools already out that that lets you control your Android through your PC. Vysor isn't unique in that regard. However, I think I have the other apps beat in with seamless setup and compatibility (no root to boot). :)

However, I had actually envisioned Vysor as a developer tool. Vysor gives you all the benefits of a physical device, but with the ease and integration of an emulator in your development environment.

The headline feature of Vysor is Vysor Share. You can share your device to another Vysor user, across the office or across the globe. This means screen and ADB. This is something I've wanted as an indie dev for a long time: a way to deploy and debug on a remote tester's device. It's as easy as sending a link.

Vysor was actually leaked before I was ready to release, but the roadmap also includes Vysor Server: a device farm that your Android dev team can access remotely. Test device specific issues, run automated suites across a dozen devices, etc. You don't need to pass test devices around anymore, just access them through Vysor.

http://www.vysor.io/

Post has shared content

Post has shared content
Launching Google beacon platform

Helping your apps work smarter: Introducing the #GoogleBeaconPlatform and the #Eddystone BLE beacon format.
Wait while more posts are being loaded