BlueFletch and The Home Depot deliver key insights on rugged vs. consumer-grade devices at Zebra Partner Summit

By | Enterprise, Events & Awards, Mobile Development

Brett Cooper, a Partner at BlueFletch, will be joining a session panel at the Zebra Partner Summit on Thursday, November 8th at the Orlando Omni Championsgate to discuss Zebra’s real-world mobility solutions that give them an advantage over competitors. He will share the stage with fellow panelist Todd Stankiewicz, Senior Manager Information Systems at The Home Depot, and moderator Andy Cauffman, Zebra Account Manager for the Home Depot.

Read More

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

By | Enterprise, Ideas For Your Business, Mobile Development

Delta Air Lines has a well planned and effective enterprise mobile strategy. Delta employs a healthy mix of devices based on the role, environment and required tasks. The employees in the terminals need business mobility devices as rugged as Thor’s Hammer and for everyone else, there are consumer devices. Their business mobility development team is focused on one hybrid platform, which supports their fleet of Android rugged devices and iOS devices.

Read More

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

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

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.

 

Using Meteor with React Native

By | Enterprise, Ideas For Your Business, Mobile Development

The number of JavaScript frameworks these days has become mind-numbing. Back-end frameworks, front-end frameworks, isometric frameworks that do both at once. As a less experienced programmer, moving into the web-app world can be a daunting task. Where to begin? What is the most efficient path to take?

Using these frameworks in a mobile context can get even worse, as the hardware limitations of mobile coupled with a quickly evolving tech landscape and development costs can scare even the most experienced programmers.

Read More