Android Listeners and Toasts

This video, part of my Android Quick Code Access series of posts, explains Android Listeners and Toasts. It's from my course Learning Android App Programming published by InfiniteSkills.

The Java code for the example is below...

import java.util.Random;
import android.app.Activity;
import android.content.Context;
import android.os.Bundle;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;
import android.widget.Toast;

public class ListenerToastMain extends Activity {
	
    // onCreate method.
	@Override
	protected void onCreate(Bundle savedInstanceState) {
	    super.onCreate(savedInstanceState);
	    
	    // Initialize display.
	    setContentView(R.layout.main);
	        
           // Declare button variable for Get Answer.
	    Button getAnswer =
               (Button)findViewById(R.id.getAnswerButton);
	        
	    // Set listener for button.
	    getAnswer.setOnClickListener(getAnswerListener);    
	}   
    // Define OnClickListener for getAnswer button.
    private OnClickListener getAnswerListener = new OnClickListener() {
        public void onClick(View v){
       		
            // Generate answer number.
            Random toastGen = new Random();
            int toastNum = toastGen.nextInt(19);
            toastNum++;
       		
            // Get answer text.
            CharSequence text = "";
            switch (toastNum) {
                case 1:  text = getString(R.string.answer1);  break;
                case 2:  text = getString(R.string.answer2);  break;
                case 3:  text = getString(R.string.answer3);  break;
                case 4:  text = getString(R.string.answer4);  break;
                case 5:  text = getString(R.string.answer5);  break;
                case 6:  text = getString(R.string.answer6);  break;
                case 7:  text = getString(R.string.answer7);  break;
                case 8:  text = getString(R.string.answer8);  break; 
                case 9:  text = getString(R.string.answer9);  break;
                case 10: text = getString(R.string.answer10); break;
                case 11: text = getString(R.string.answer11); break;
                case 12: text = getString(R.string.answer12); break;
                case 13: text = getString(R.string.answer13); break;
                case 14: text = getString(R.string.answer14); break;
                case 15: text = getString(R.string.answer15); break;
                case 16: text = getString(R.string.answer16); break;
                case 17: text = getString(R.string.answer17); break;
                case 18: text = getString(R.string.answer18); break;
                case 19: text = getString(R.string.answer19); break;
                case 20: text = getString(R.string.answer20); break;       		    
            }
            // Toast answer.
            Context context = getApplicationContext();
            int duration = Toast.LENGTH_LONG;
            Toast toast = Toast.makeText(context, text, duration);
            toast.show();
        }	        	
    };
}

P Versus NP Complexity Theory

The P Versus NP issue deals with whether every problem whose solution can be quickly verified by a computer can also be quickly solved by a computer. This is a major unsolved problem in computer science.

In common, practical terms, it deals with how to identify problems that are either extremely difficult or impossible to solve.  In order of difficulty from easy to hard, problems are classified as P, NP, NP-Complete and NP-Hard.

So why do we care? When approaching complex problems, it's useful to have at least some idea of whether the problem is precisely solvable, or if an approximation is the best that can be accomplished. 

Android Release and Device Support Summary

Below is a summary of Android releases and device support.  It shows that by using the  Android Support Libraries you can code your apps to run on a large percentage of Android devices.

For more information on the compatibility Support Libraries see: http://developer.android.com/tools/extras/support-library.html 

For more information on Device Support see: http://developer.android.com/about/dashboards/index.html

Android WebView Combines Native and HTML5 Code

A battle is raging over whether native mobile code apps, such as those for Android and iOS, are a better approach than using HTML5.  Each has its advantages.

There is, though, a way to blend the two in order to take advantages of the benefits each has to offer.  The graphic below shows the anatomy of an app that displays an HTML5 Canvas on an Android screen display.

This app is from the Learning Android App Programming video training course.

The HTML5 Canvas animation displayed is from HTML5 Canvas for Dummies.

You can see the HTML5 Canvas animation by clicking here. To see the JavaScript code that generates the animation, right click on the display page and select View Source Code.

Android/PHP/JQuery RESTful JSON MySQL Client-Server Overview

The title of this blog entry is quite a mouthful.  The purpose is to give a broad overview of the moving parts necessary to implement an application with client mobile and desktop devices that interact with a server database to alter and retrieve data.

I won't define all the classes, methods and acronyms on the graphic as they're easy to look up using an Internet search.  There are other choices that can be made for the details of the implementation, but this should provide a starting point for thinking through the necessary elements.

The communication vehicle for client-server interaction is typically the Internet Protocol Suite.

 

Android Button Listener Code Dissected

Android listeners are the mechanism used to respond to user interaction with a display screen.  Setting up a listener is a very common Android coding task.  Although it can be done with just a few lines of code, it involves a number of elements that must be configured to interact correctly.

The diagram below from the video training course Learning Android App Programming dissects the code to establish a listener for a screen button.

HTML5 vs. Native App Development

As you're likely aware, there's a big debate going on about whether HTML5 web sites are a better platform for mobile apps than native code development using Android, iOS and Windows.

The main selling point for HTML5 is the write-once-run-anywhere advantage. Web browsers on mobile devices can access web sites from any mobile platform. HTML5 is providing features that allow web page JavaScript code to access phone features like devices sensors and geo positioning. In theory, a well constructed HTML5 web page will look and perform like a mobile device native code app.

However, currently not all device features are available to HTML5 JavaScript code and native code apps have a performance advantage over HTML5 web pages viewed using a browser. Native code apps are presently the dominant choice among developers.

In HTML5's corner, though, the technology is improving and web browsers are ramping up their implementation of HTML5 features. Life would certainly be simpler for mobile developers if they could develop for only one platform, HTML5, instead of multiple native platforms.

Longer term, HTML5 will certainly continue to get better. But so will native platforms. In fact, native platforms may improve more rapidly than HTML5. HTML5 is a global standard developed by the W3C. It takes years of effort to change the standard and have these changes adopted by the various browsers. The individual native platforms (Android, iOS, Windows) can change as quickly as their developers (Google, Apple and Microsoft) want them to. So will HTML5 ever catch up?

Maybe not. Google, Apple and Microsoft have lots of developers and big budgets. They want their products to be competitive ... and that means constant improvements.

So, what's likely to happen? In my opinion, we'll have a blend of the two. In fact, this is taking place today. Native code platforms have Application Programming Interfaces (APIs) that support displaying web pages from within native code apps. Developers can use native code for what it does best and HTML5 web pages for what they do best. The exact mix will shift over time as all the platforms change and improve. 

For developers, this means that separate native code platforms will likely continue to exist. Write-once-run-anywhere will remain an elusive goal probably not realized for a long time, if ever. This doesn't mean that development costs can't be managed or reduced. HTML5 web pages can be developed and used by native code apps where appropriate. Functions specific to those pages can be write-once-run-anywhere. This may not be an optimal solution, but it's the game on the ground.

Smartphone Website with Laptop 2.png

Bridge Design Pattern

This entry is part of a series on programming Design Patterns that provides a framework for the rapid recall and use of patterns during application design. 

The Bridge design pattern is used to define multiple processes that work on multiple object types with similar aspects.

To understand how this pattern might be used, consider how software to control a real bridge might be constructed. Such an application would have two processes: trafficControl() and gateControl() which would control two types of objects: cars and boats. 

      class Bridge - contains methods to control bridge activities.

          trafficControl(trafficType) - method that controls traffic signals.

            gateControl(trafficType) - method that controls the bridge gates.

      class Traffic - contains objects describing types of traffic.

            cars() - defines car objects

            boats() - defines boat objects

Adapter Design Pattern

This entry is part of a series on programming Design Patterns that provides a framework for the rapid recall and use of patterns during application design. 

The Adapter design pattern is used to wrap a class in code that allows that class to be used via a different interface. Another name for the pattern is a Wrapper.

To understand how this pattern might be used, consider how software to display an image on a fixed size device might be constructed. Assume the following class and method are provided by the standard device software:

class Display - contains methods to create displays on the device.

displayImage(source) - method that displays an image with the dimensions of the device screen.

An adapter would fit an image of any size to the device screen:

class DisplayAdapter - contains methods that fit an image of any size to the device screen.

imageAdapter(original) - method that changes the size of the original image to fit the display screen.

imageResample(original, resized) - method that resamples the image for size change.

displayImage(resized) - uses the method built into the device to display the resized image.

Which is the Best Browser

An analysis of Internet browsers by Top Ten Reviews places Google Chrome at the head of the list. The analysis shows, however, that it's a real horse race between the top five: Chrome, Firefox, Internet Explorer, Opera and Safari. Here are some of my observations based on this analysis and personal tests and experience:

Change after new releases: All of the browser developers are working hard to improve their products. With each new browser version release, the competitive landscape can change. For example, Internet Explorer had recently lagged in speed due to the lack of graphics hardware acceleration. Based on my tests, they're now the fastest running HTML5 Canvas animations.

Graphics hardware acceleration: GPU (Graphics Processing Unit) hardware acceleration is an important factor in browser speed. A browser displaying video or animation with GPU acceleration will outperform a browser without it by a factor of 3-4. That's right, 300-400%. A computer using just the CPU to manipulate graphics displays simply can't keep up with one using the combination of CPU and GPU. Hardware acceleration is a fairly complex topic. Basically, the browser offloads calculations from the CPU to the GPU. If you're interesting in some of the details, take a look at this discussion of hardware acceleration from the Chromium Projects.

Mobile lags desktop: Especially in speed, the mobile browsers lag desktop versions. Mobile devices simply don't have the computing power to match desktop devices. 

Software Application Re-use

Software re-use has gained popularity and success due to technologies like Object Oriented Programming. Software classes and methods can be re-used based on their documented parameters and functionality.

The emergence of mobile apps over the last few years offers another level of re-use, that of whole applications. Instead of re-developing the functionality of an app (e.g. Google Maps) the app can be invoked by passing control to the app, providing it with a valid input (e.g. an address.)

Marketimpacts.com developed a series of Android apps based on applicaiton re-use. The Quickclick Locale series of apps uses the Google Maps API to map the locations of various types of places such as ATMs, Restaurants and Shops. The value added by Quickclick is an easy to use front end and app icons for different types of places.

To our surprise, there seems to be some resistance from other developers to app re-use. The only negative comments the Quickclick apps have received complain that the app is passing control to Google Maps to do the mapping.  Certainly, we could have created our own maps. But why? Are we really smart enough to out-develop Google? Would we really want to scramble to update our apps with new mapping capabilities to match Google? We think not. Google themselves promotes the idea of app re-use.

App re-use has some powerful advantages:

Lowered development costs: App functionality can be had for the cost of implementing a siimple interface to the app to be re-used.

Automatic upgrades: When the app you're re-using is upgraded, your app automatically benefits.

Higher quality: It's unlikely you'll be able to duplicate all the functionality of an existing app focused on a specific niche.

Leverage of user knowledge: If the app you're re-using is popular, many users will already know how to use it. This is certainly the case with Google Maps.

Access to complete app functionality: Some apps, including Google Maps, provide only limited functionality via an API (Application Programming Interface). By passing control to and re-using the entire app, your users gain access to full functionality.

What is HTML5 Canvas?

HTML5 Logo.png

The Canvas feature of HTML5 is one of the most exciting new developments in web based capabilities in many years. Here are some key aspects:

HTML5 - Canvas is a part of the latest revision and improvement of the previous version (HTML4, released in the late 1990's) markup language for displaying web pages on the Internet.

Canvas Tag - The <canvas> tag joins the other HTML tags (there are around 100 now) as a way to include single or multiple Canvas areas on a web  page. 

Bit Map DisplayThe Canvas area you define with a <canvas> tag is a bit map display. You can manipulate individual pixels to draw objects, images, animations and video.

JavaScript ControlThe JavaScript language is used to control what is seen on the Canvas. The JavaScript application code is placed between the <head></head> and <script></script> tags of the web page.

Browser Based - The computing needed to create a Canvas display is done within the browser. In other words, it's client based, not server based. The means that creating a Canvas application is simpler than one requiring server based programming. It also means that the computing power needed to generate the Canvas display is not concentrated in single servers. Each user's browser handles its own work.

Animation - Canvas applications can generate animations. This is accomplished using callbacks from the browser. The Canvas application designates one of its functions to be called from the browser at specified time intervals. During each of these callbacks, the application draws a new Canvas display, moving objects slightly. When viewed as a continuous flow of Canvas displays, an animation is generated.

Audio/Video - Audio and video can be incorporated into your Canvas applications. Moving objects can create sounds and video images can be melded into other application objects. This is done without the use of any audio or video plugins.

Gaming - Game developers have all to tools necessary to create compelling HTML5 Canvas games.

Fun - Putting aside the technical aspects of Canvas ... it can be described as just plain fun. An HTML5 Canvas is a place where as a developer you can express your creative energies and as a user you can have expanded and enjoyable experiences.

For a more details look at HTML5 Canvas, watch for my upcoming book: HTML5 Canvas for Dummies.

Integrating Audio with HTML5 Canvas

One of the useful features of HTML5 Canvas is the ability to integrate audio, either with or without an audio player. Click here or on the image to see if it works on your browser ... click on my dog Daisy and/or the pelican to test simultaneous sounds.

When the new browser window opens, you can view the page source to see the code that generates the Canvas display.

This is one of the sample applications from HTML5 Canvas for Dummies.

HTML5 Canvas Performance Test

Browser support for HTML5 Canvas is constantly improving. More features are being supported and performance is improving. Click here or on the image below to see how your browser performs. The app rotates a ten layer gradient and displays the Frame Rate.

HTML5 Canvas on a Smartphone

HTML5 Canvas is a highly anticipated feature that allows web developers to create sophisticated graphics on their website pages. Most desktop and laptop browsers now support the Canvas feature. Mobile browsers are catching up. To see if your browser supports Canvas, you can access www.html5test.com for an analysis and rating of your browser.  Also, give this Canvas app a try:

Smartphone Installations Will Soon Outnumber PCs

According to a new study by IDC, smartphone installations will soon outnumber those of PCs.  Not surprising, really, but we've lived in a PC dominant world for long enough that the shift seems monumental.

Chart: Worldwide Smart Connected Device Shipments, 2010-2016 (Unit Millions)Description: This data comes from IDC's WW Quarterly PC Tracker, WW Quarterly Mobile Phone Tracker, and WW Quarterly Media Tablet and eReader Tracker.Tags: Tracker, mobile phones, tablets, forecast, PCs, devices, consumer, IDC ...Author: IDCcharts powered by iCharts

 

Managing Android Devices

Google has quite a task ... to manage an installed base of over a thousand different types of Android devices. Multiple sizes, shapes, features, etc. The positive way to describe this is variety. On the other hand, it has also been refered to as fragmentation.

So how do they do it? In short, leverage. A good metaphor is a mechanical shovel. Relatively compact machines can move and lift very heavy objects using a system of joints and lever articulation. Android does something similar.

The code in Android applications doesn't manipulate devices directly. There are intermediate joints and levers that make the task manageable. Application code is programmed using component names to refer to layout elements. Layouts are adjusted to device characteristics automatically by the Android operating system. This lets an individual line of code manipulate many different types of devices.

This is a simplified view of how it all happens. There are a number of Android features that make it work: Themes, Styles, Action Bars, Fragments, Resources and much more. When implemented properly, an Android application can move a thousand different types of devices.

Dealing with Android Fragmentation

So called Android fragmentation is caused by the large number of Android device types and operating system versions deployed in the market.  It's the flip side to the benefit of having a wide variety Android devices and capabilities.

There are currently over a thousand different types of Android devices on the market. It's simply not possible to support all of these without accomodating variations in device design.

Google provides a number of tools for addressing the compatibility necessary to serve this diverse universe of devices. These include:

Unified Support for Tablets and Handsets

Android 4.0 combines the support of tablets and handsets into a single release.

The Holo Theme Family

In Android 4.0 Google has made the inclusion of the unmodified Holo theme family a compatibility requirement for devices running Android 4.0 and forward. This will provide a level of uniformity across device implementations.

Support for Multiple Screens

Provides mechanisms for supporting multiple screen sizes and densities.

Action Bar Backward Compatibility

Google has recently developed a set of classes to give the Action Bar backward compatibility for pre Android 3.0 devices.  These classes invoke the action bar design pattern on pre-API 11 devices and the built-in Action Bar on devices supporting API 11 or greater.

Android Compatibility Package

This library is available through the SDK Updater. It gives backward compatibility for the new Fragments feature.

Compatibility Guidelines

Google provides guidelines on achieving compatibility across devices.

Android Action Bar Backward Compatibility

The Action Bar is a consistently formatted navigation and option selection area at the top of a screen with an overflow area at the bottom.
 
Key aspects of the Action Bar include:
  • It's a replacement for the menu feature.
  • It was introduced in Android 3.0 and refined in Android 4.0.
  • It's included in activities that use the Holo theme family.

Elements of the Action Bar graphic include:

  • Application icon.
  • Application name.
  • Up navigation to a parent screen.
  • Built-in tab navigation for switching between fragments.
  • Drop-down list for alternative navigation such as sort by a different criteria.
  • Important actions for a given app such as search and share.

Google has recently developed a set of classes to give the Action Bar backward compatibility for pre Android 3.0 devices.  These classes invoke the action bar design pattern on pre-API 11 devices and the built-in Action Bar on devices supporting API 11 or greater.

This is part of a larger set of capabilities for supporting application compatibility with multiple device environments including tablets and handsets and various screen sizes.