Upgrading Rugged Legacy Devices and Mobile Device Management: How to avoid common risks during an upgrade – Part 1

By | Android, Ideas For Your Business, Mobile Development

Eleven years ago Steve Jobs stood on the stage and boldly introduced the iPhone, sending a shockwave through the technology community and ushering in a new era for mobile devices. A year later, the Android platform was introduced – the Darth Vader to the Jedi iPhone. Instead of being told what you need, Android provided openness and experimentation. Unlocking the potential of a mobile device and providing a counterbalance to Apple’s closed (these are not the Droids you seek) operating system. This new wave of devices opened the door to numerous possibilities in enterprise mobility. These devices also required new types of enterprise administration through mobile device management tools. Some companies are testing and investing heavily in replacing rugged, Windows CE legacy devices with cheaper and sleeker consumer mobile devices.

Read More

The Intern Experience – Jeffrey Wongo

By | Android, Ideas For Your Business

Jeffrey Wongo – Android Developer

Relaxed but Professional

As an intern at BlueFletch, I could not have asked for a better environment to gain professional exposure and hone my skills as a software developer. The days leading up to to my first day on job were hopeful and nerve wracking; however, upon starting I quickly came to realize that what little nerves I had were completely negated by the combination of my friendly, approachable coworkers and a work environment that promotes open communication and collaboration. With weekly company-wide standups, frequent code reviews, and lunch-and-learn presentations, BlueFletch makes it clear that learning and open interaction are key foundations to a successful organization.

The Work

BlueFletch Enterprise LauncherThe first project I worked on was the Enterprise Launcher for BlueFletch’s Enterprise Mobility System (EMS). Similar in function to the home screen on a regular Android device, the Enterprise Launcher, designed for rugged devices, adds a layer of control and meets the needs of any organization with multiple shared android devices. Specifically, I was tasked with updating and consolidating the different ways an associate could log into the Launcher (currently LDAP, Google Sign In, and Office 365). The end result would be that an organization would have the ability to select from these options without any external support. While working on this project some of the things I learned about included oAuth2 authentication, API calls using Retrofit, android navigation control, and much more.

After wrapping up the previous project I was tasked with replacing the backing local database for the Support Analytics android app. This app, also part of the EMS system, was responsible for displaying and sending information about the device (battery percentage, network status, temperature, etc) to a server. The issue was that the local database it used to store the data was not only difficult to test, but also unnecessarily inflated the app’s file size. While migrating the database to a different, more lightweight implementation, I had a first-hand experience of how external libraries interact and sometimes conflict with each other. I was also introduced to the idea of mocking when testing an application.

For the remainder of my internship I worked on two projects as part of an agile-driven team. I worked on bug fixes and implemented new features on several android apps. Unlike EMS, these projects involved active sprints and high client interaction. In addition to improving my skills and knowledge of android development, working on these projects gave me the valuable experience of collaborating with a team where each person had a specific role.  From daily team standups to tracking progress with task management software, I was able to witness the SCRUM methodology in a real world context.

Having the opportunity to work on multiple relevant products was an invaluable aspect of this experience. I was able to witness the different design patterns and architectures I learned and heard of in school being implemented in projects with actual value. As someone kicking off their career as a developer, BlueFletch was the perfect environment to advance my knowledge while working on interesting, challenging problems.

Painless Legacy to Android Migration for Zebra Devices

By | Android, Mobile Development

OS Migrations Made Simple

Over the last 6 years, BlueFletch has been assisting enterprises in their migration from their legacy windows CE devices to Rugged Android Zebra devices.

BlueFletch typically helps organizations with:

  • Proof of Concept
  • Mobile Strategy
  • Application Conversion
  • MDM Structure / Setup
  • Deployment Management

In the attached PDF,  we cover the highlights of our approach and how we can assist organizations with moving to modern rugged Android devices.

Download Here:  BlueFletch OS Migration

 

 

 

 

Take aways from a Friday Code Review

By | Android, Ideas For Your Business, Mobile Development

Do you do code reviews? If so, why? What do you benefit from your code reviews?

Most companies do code reviews to prevent future program errors, but in my opinion a major benefit of code reviews is to ensure the code is maintainable, that others can read and follow the code.

If you have not read the book Clean Code by Bob Martin, I highly recommend it, as it will give you techniques for writing maintainable code.

code reveiwCode Review Fridays

Here at BlueFletch we have a standing weekly code review meeting.  The engineers meet as a group and review some portion of code from a current project.  This meeting does not replace individual project code reviews, but is meant to benefit everyone in the company not working on the project.

Some of the benefits are:

1. See what others in the company are working on
2. Get insight into different technologies
3. Get help with a tricky piece of code
4. Ideas on doing a project differently

During our code reviews we look for the following items:

1. Readability — is the code easy to read / follow
2. Maintainability — can our customers easily maintain it
3. Usability — are the classes easy to use, are they overly complicated?
4. Does the code make sense?

Additional items we look for can be found here

A Recent Review

On a recent Friday we reviewed a couple of Android projects we inherited from other companies. As per our practice, we reviewed the code from the aspect of clean code and best practices, discussing how we would make the code maintainable and easier to read.

During the review four major issues jumped out:

1. Pyramid of doom
2. Project organization
3. Code Reuse
4. Hardcode Strings

code reviewPyramid of doom (or Callback Hell)

Every engineer has run into this, regardless of the language or platform, you have a function that has many, many levels of indention. This could a HUGE if statement with many conditions or a series of callbacks within callbacks. The deeper the code, the harder it is to follow and maintain.

Example:


if ( conditionA) {
    if ( conditionB ) {
        if ( conditionC ) {
            block of code doing something 1
         } else {
            if ( conditionD ) {
                block of code doing something 2
            } else {
                block of code doing something 3
            }
        }
    } else {
       if ( conditionE ) {
            block of code doing something 4
       } else {
            block of code doing something 5
       }
    }
}

 

Tip: If you find yourself coding such a monstrosity, STOP! Refactor the code. Start with the inner code and place the code into separate methods. Yes, you end up with more methods, but the code will be more readable, and with smaller methods you get code that is easier to write unit tests.

A possible rewrite (one of many ways, but easier to write unit tests):

..
 if ( conditionA) {
    methodConditionA()
 }
..

methodConditionA() {
   if ( conditionB ) {
       methodCondtionB()
   } else {
       methodCondtionE()
   }
}
methodCondtionB() {
    if ( conditionC ) {
       methodHandlerProcssingLogic1 ()
    } else {
       methodCondtionD()
    }
}
methodCondtionD() {
    if ( conditionD ) {
        methodHandlerProcssingLogic2()
    } else {
        methodHandlerProcssingLogic3()
    }
}
methodCondtionE() {
    if ( conditionE ) {
        methodHandlerProcssingLogic4()
    } else {
        methodHandlerProcssingLogic5()
    }
}
methodHandlerProcssingLogic1() {
    block of code doing something 1
}
methodHandlerProcssingLogic2() {
    block of code doing something 2
}
methodHandlerProcssingLogic3() {
    block of code doing something 3
}
methodHandleProcssingLogic4() {
    block of code doing something 4
}
methodHandlerProcssingLogic5() {
    block of code doing something 5
}


 

Project organization

Within one of the projects we reviewed, there were 67 fragments, all within one package. For non-Java programmers, imagine 67 code files within one folder, with the files having similar names.

There were 11 fragments referring to devices; 4 related to signing in; various fragments for product registration, and 2 About fragments.

How are these 67 fragments related? Which ones need to be looked at when enhancing a feature of the application? Where do we start?

Tip: How you organize your code can help those that follow. If you make it easier to identify features and/or the process flow, then those that follow will be able to understand your project.

If the engineer building the project had separated the fragments out by features or relating the code in some manner, then working with the project would be easier.

Some suggestions for organization include placing all the “User” related (sign in, forgot password, account creation) into one package.   Place settings related fragments into another package.  Place device related fragments into another package.

Get the idea? Organize the project by context.

Code Reuse

Within one of the projects we reviewed the code utilized simple REST API calls to gather data. A simple pattern of URL creation with HttpUrlConnection classes and code to handle the result.

After some research we noticed the same endpoint was used in multiple places. Then we found the same exact code pattern, almost line for line, in 15 other places.  The code had been copied from place to place, with minor changes to suit the need.

And there was a bug within the code that required a major change within each piece of code. Yuck!

Another project we reviewed had a common error message display, but the display code was copied into each Activity (25 code files). Imagine if they decided to change the look/feel of the error display, 25 code files would have to be updated and tested. Dooh!

Yes, as software developers we need to get things done fast, but the consequences of copying code from one part of the project to another will cause you headaches down the road. As no code is perfect, at some point it will need to be fixed or enhanced, how many places do you want to make changes?

Tip: if you find yourself copying a block of code from one part of the project to another, almost line for line, then build a reusable code object, either a new method, a new base class, something common. This will reduce the amount of code to maintain, and if a bug does arise, you have one location to fix it.

Hardcode Strings

Imagine opening a code file for the main activity of a project and having to scroll through 1,300 lines of hardcoded string literals? Yes, we had to do that during our code review.

We as engineers get lazy, we need to add a new UI label or a new error message, instead of doing it correctly we put the text directly in code. It never fails, later the project needs to be localized and now you have to pull all the strings out to a string resource file. How time consuming! How much time does it take to add the initial string to the resource file, less than a minute?

Tip: Take the time up front, do it right, and for the sanity of the engineer that follows you into the code base, do not hard code 1,300 lines of string literals into the main activity.

Conclusion

As software developers/engineers, we should take pride in our code. We should build our code to be readable, maintainable, and testable. Doing code reviews either as a group or individually will help you and others to learn and improve code.

And please: organize your code, write reusable modules, do not hard code strings, and break down your large unruly code blocks into smaller methods.

Specifying your Android Host URL using Gradle

By | Android, Enterprise, Mobile Development

Using Gradle has many cool features, the one that I really like is the ability to change configurations based on build type (release or debug).

Background

One of the headaches of building Internet enabled applications is pointing your application to a different API service based on the stage of development. For instance, for a QA build of a product I have had the need to point an application to a QA API Instance, or during initial development of APIs, to a development server. There are many ways to accomplish this, from reading a configuration file loaded on the device or changing a string resource to a new host. But I have started using my Gradle configurations to point my Android applications to different API host servers.

Gradle

Common Configuration Switching

A common method for switching host configurations is a complicate if statements:

if (BuildConfig.Debug) {
… use host A
} else {
… use host B
}

Of course, using this approach has many downsides, one of which is ugly “if” statements scattered through out your code. And when you have multiple flavors of the product with different debug versus release host API’s, it can get really ugly.

Another method is to use string resources that are loaded per flavor of build. A debug resource string file could contain Host A URL, which Staging flavor could contain Host B URL. This keeps the complicated if statements to a simple string load. But now your URL’s are in different files, and maintaining the multiple files always leads to ‘which is getting loaded’, ‘what is the current host’, etc.

This is where Gradle configurations can help clean up the code, and to me the main benefit is there is one source of truth of the host configuration settings.

Read More

Creating an Android application to read data from Near Field Communication tags

By | Android

I was recently tasked with creating an Android application to read data from Near Field Communication tags. In the process of understanding this technology’s history, standards, and then actually writing the app, I spent a large chunk of time digging through old documentation, out of date web tutorials, and unanswered Stack Overflow questions. In the spirit of Larry Wall’s Three Virtues, I’ve created this primer as a condensed explanation and implementation for those looking to add Near Field Communication tag reading to their own Android project.

BlueFletch NFC

 

“When all else fails, read the instructions.”

An Introduction

Like Bluetooth, Wifi, and other forms of wireless signals, Near Field Communication (NFC) is a communication technology based around the idea of transmitting data over radio waves. NFC uses the same type of technology found in other products, such as mobile payment systems, RFID cards, and electronic key fobs. The main advantage of NFC over these other forms of wireless communications is its ability to store and transmit small amounts of information between a passive, unpowered storage system and an external, powered reader. And it can transmit data without having to pair devices traditionally, like with Bluetooth or Wifi. An NFC storage device can be something as small as a sticker, coin, business card, or bracelet. Additionally, most Android phones come with a built-in NFC reader. So let’s get to the good stuff.

Required Tech

Software:

Android API level 10+ (Gingerbread) is required for NFC support.
Android API level 19+ (Kit Kat) is recommended.
(optional) Android Studio

Hardware:

An Android device with NFC support
(optional) NFC tags

Implementation Read More

Windows Mobile Web Apps to Android, Fast.

By | Android, Enterprise, Ideas For Your Business, Mobile Development

As technology advances, enterprises are finding themselves wondering what do we do to catch up? A lot of companies have their systems designed to work on older devices that run operating systems such as Windows CE and many of their apps are in a form of web applications . Most of these corporations are struggling with the decision of how to upgrade to newer platforms fast and without spending tons of money.  The solution could be as simple as “Let’s leverage what we have and temporarily adapt it to what we need until we can fully integrate the new technology.”   Using the following steps could help companies migrate fast and allow them to migrate to newer platforms with only a couple of lines of code.

 

15w809

Read More

Adding a Round Static Google Map To Your Android App

By | Android, Mobile Development

If you need a static map in your Android project this is the place for you. While there are plenty of resources already out there, there are some gotcha’s and I needed to piece together information from several different sites to do something that should be (and is) pretty trivial. So here it is, all in one place.

Objective: To add a static round to an existing Android project. Here’s what you will end up with when you’re done:

screen-shot-2016-10-24-at-4-36-39-pm

Easy enough right. So let’s get to it.

First, add the Google Maps library to your project. In your build.gradle:

compile ‘com.google.android.gms:play-services-maps:9.6.1’

Next (and this is probably the reason for this post), add some meta tags to your AndroidManifest.xml. You will need to generate an API key for this step so head over to the Google site and do that:
<meta-data

  android:name=”com.google.android.gms.version”

  android:value=”@integer/google_play_services_version” />

<meta-data android:name=”com.google.android.geo.API_KEY” android:value=”YOUR API KEY HERE”/>

Without these tags you will get errors like:

android.view.InflateException: Binary XML file line #221: Error inflating class fragment

and:

java.lang.RuntimeException: API key not found

OK, now that we have the Play Services library and our meta tags we can add our map to our activity.

Add the map to your layout:

<fragment

  xmlns:android=”http://schemas.android.com/apk/res/android”

  xmlns:map=”http://schemas.android.com/apk/res-auto”

  android:name=”com.google.android.gms.maps.MapFragment”

  android:id=”@+id/map”

  android:layout_width=”150dp”

  android:layout_height=”150dp”

  map:cameraZoom=”13″

  map:mapType=”normal”

  map:liteMode=”true” />

Implement OnMapReadyCallback in your Activity class:

@Override

public void onMapReady(GoogleMap googleMap) {

     // Add a marker and move the camera (i.e. the center of the map).

     LatLng offerLocation = new LatLng(33.7490, -84.3880);

     googleMap.addMarker(new MarkerOptions().position(offerLocation).title(“Suzi’s Sushi”));

     googleMap.moveCamera(CameraUpdateFactory.newLatLng(offerLocation));

}

So now we have a map, but we need a round map. We can achieve this by adding a mask on top of our map using a FrameLayout and a square with a circle cutout vector image. This is kind of a negative space concept if you’ve ever taken any art courses, but I digress. First our vector image. You can get it here.

To import the svg you just downloaded in Android Studio, Ctrl + click the assets folder and select “New > Vector asset”. Select t the ‘Local File option and navigate to the path of the vector image. Next, select 150dp x 150dp (or whatever size you want your map to be) as your size. Click ‘Finish’ and your drawable is now ready to use as the map mask.

Add the FrameLayout the MapFragment and the newly imports vector asset in an ImageView like so:

<FrameLayout

  android:layout_width=”wrap_content”

  android:layout_height=”wrap_content”

  android:layout_alignParentRight=”true”>

  <fragment

      xmlns:android=”http://schemas.android.com/apk/res/android”

      xmlns:map=”http://schemas.android.com/apk/res-auto”

      android:name=”com.google.android.gms.maps.MapFragment”

      android:id=”@+id/map”

      android:layout_width=”150dp”

      android:layout_height=”150dp”

      map:cameraZoom=”13″

      map:mapType=”normal”

      map:liteMode=”true” />

  <LinearLayout

      android:layout_width=”wrap_content”

      android:layout_height=”wrap_content”

      android:background=”@drawable/circle_mask”

      android:orientation=”vertical” >

  </LinearLayout>

</FrameLayout>

That’s it! Run your project and you now have a round static map in your app. Now go out and appreciate some negative space.