KioDev

Recently I learned about a SUPER awesome little library that you should consider adding into your projects: The Percent Support Library.

This library allows you to specify a percentage value for layout width and height when you are using RelativeLayout or FrameLayout. Yipee!!!! Gone are the days of switching everything over to a LinearLayout when you realize halfway through coding that you really need weights in your layout.

First step is to pull the library into your project. Just add this line in your app level build.gradle:

compile 'com.android.support:percent:23.0.0'

Now you can use percents in your XML layout files. The library defines a new layout type called PercentRelativeLayout, which inherits from RelativeLayout. Here is a basic example on how to use it:

<android.support.percent.PercentRelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">

    <ImageView
        android:id="@+id/centered_image_2"
        android:layout_gravity="center"
        android:contentDescription="Android Robot"
        android:src="@mipmap/ic_launcher"
        app:layout_heightPercent="30%"
        app:layout_widthPercent="50%" />
    
</android.support.percent.PercentRelativeLayout>

Note that you must include percent symbols as units when defining the parameters (in place of dp).

Continue reading →

Performance, or ‘perf’ as all the cool kids now say, is a big topic in the Android world.  No matter how sleek your UX / UI, if your app is laggy or crashy, users will not be happy. Unfortunately, there is no silver bullet for performance; there is no one line code fix, and no library you can import to get good performance.  A high performing application is the result of many incremental software design and implementation decisions. On top of that, you have to be constantly monitoring your app’s performance. Any refactoring or new feature could result in a drop in performance. In other words, its not exactly easy.

Recently I refactored my Lunch In Receiver code a little. It was a simple refactor that could help performance, so I figured I’d share it!

An Android Broadcast Receiver is a background entity that receives information about the surrounding environment it has been designated to care about.  By default receivers are “always on,” meaning they are always listening in for their designated event to occur.  This means a user could download your app but never open it, yet a Broadcast Receiver in your app is firing away.

For many apps, a Broadcast Receiver’s actions might not make sense if the user hasn’t at least opened the app and performed some tasks. This was the case for the LunchOutDetectionReceiver in Lunch In.

This Broadcast Receiver listens for a change in wifi state to detect if you have left your office by moving off the office wifi signal.  The actual receiver fires if there is any change in wifi state, and then the code within the receiver checks to see if your change was related to your work wifi or not. Since receivers are “on” as soon as the app is installed, the receiver could be firing and checking against the user’s work wifi, before the user has even registered their work wifi in the apps settings. 🙁 This is wasteful!

Luckily, you can disable your Receiver until it makes sense to turn it on. The solution is easy and has 2 parts:

Continue reading →