In this post I will show you how to use the still image FaceDetector class from the Android SDK to achieve (mostly) real-time face detection.  The following method was used in the creation of the MonkeyCam application.

Since its first release, the Android SDK has made available the FaceDetector class, which “identifies the faces of people in a Bitmap graphic object”.  By using the FaceDetector on preview frames from the camera, we approximate the real-time face detection.  For example in the MonkeyCam application we achieved a rate of slightly over one second per frame which is in the same range as other solutions found around the Internet using more complex solutions like third party computer vision libraries.  Short of using the NDK to do GPU programming for the face detection algorithm this was a very usable compromise.

Read more »

Labels: Android, Face detection, FaceDetector, Mobile App, Mobile Application, Mobile Development, MonkeyCam, Smartphones

Some time ago I was doing development on an Android phone and using a BlueTooth keyboard I came across an intriguing behaviour.  Hitting the Alt+Left or Alt+Right key combo, the phone would seemingly stop working and give all the symptoms of a frozen device, no more animated wallpaper and unresponsive touchscreen.  This stems from a functionality inherited from Linux for the desktop.  In this article I will describe the origin of the issue, how to recover from it and how it can be fixed at the kernel level.

Background information

In Linux there exist some special key combinations that are handled at the kernel level.  In this article we'll be looking at the console key combinations, specifically:

• Alt+F1 through F12
• Ctrl+Alt+F1 through F12
• Alt+Left
• Alt+Right

* Alt refers to the left Alt key on the keyboard


Let's start with Alt+F1 through F12; these allow accessing the tty's.  On a typical Linux installation Alt+F1 through F6 allows the user to switch between tty1 through tty6 respectively directly and Alt+F7 (F1 in Fedora) is a special tty in which the graphical interface runs.  This can change from distro to distro.

Read more »

Labels: Android, Console, keymap, Linux

This application allows you to send URL link with your location through SMS message. Receiver will be able to see your location on the map(Google Maps) by simply clicking on the link. First thing we need to do is to get our location using GPS. Android SDK has set of classes and interfaces which makes dealing with location services quite easy. Another positive thing is that SDK is well documented. We need to get an instance of LocationManager:

LocationManager lm = (LocationManager) getSystemService(Context.LOCATION_SERVICE);

Now that we have location manager we need to request location updates from it. The location is requested using requestLocationUpdates method, it registers the current activity to be notified periodically by the named provider. In our case provider is GPS. For tracking location changes we are using LocationListener which is for receiving notifications from the LocationManager when the location has changed.

lm.requestLocationUpdates(LocationManager.GPS_PROVIDER, 1000, 0, 
                new LocationListener() {
                    public void onLocationChanged(Location location) 
                    {
                        double lat = location.getLatitude();
                        double lng = location.getLongitude();                        

                        latitude.setText( Double.toString( lat ) );
                        longitude.setText( Double.toString( lng ) );
                    }

                    public void onProviderDisabled(String provider){}
                    public void onProviderEnabled(String provider){}
                    public void onStatusChanged(String provider, int status,Bundle extras){}
        });

Just getting last known location...

Location location = lm.getLastKnownLocation(LocationManager.GPS_PROVIDER);

Good! We got the location. Now we just need to generate the URL and send SMS. Android offers full access to SMS functionality from within your applications with the SMSManager. We are geeting a reference to the SMS Manager using the static method SmsManger.getDefault. For sending SMS message use sendTextMessage, which allows you to send SMS message by specifying text message and receiver's phone number.

final SmsManager sm = SmsManager.getDefault();
String phoneNumber = number.getText().toString();
String URL = "http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=";
URL += latitude.getText() + "," + longitude.getText(); 
sm.sendTextMessage(phoneNumber, null, URL, null, null);

That's it! Just one note - in order to send SMS message and request GPS location application require following two permissions:

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.SEND_SMS"/> 

Thanks to my friend Aaron Olson from Macadamian for the help in testing this code.

Source

Labels: Android, GPS, SMS

The latest Macadamian Barcamp session focused on Apple's iPhone SDK. We found that the iPhone SDK shined by the quality of the tools it bundled. Instruments, the included profiler was rather impressive. This seems to be one of the framework's strong points. Templates to start building applications out of the box are also provided in Xcode.

We agreed that since the iPhone framework requires the use of Objective-C, it will have a fairly extensive learning curve for any person not used to native OSX development. In comparison, Google's Android is based on technologies we are more familiar with, but still has some rough edges. It will be nice to see how the two SDKs stack up, once the Android platform becomes more mature.

Below's a Barcamp style comparison chart of the smartphone SDKs we looked at:

Labels: Android, Barcamp, iPhone, Smartphones

Macadamian is made up of many different people with a very large space of interests. Any given trip across the office can net one a variety of lessons, covering anything from how extremely large microwave dishes work and where not to point them, to car operating systems, and how to tie gmail into an extremely effective and professional GTD setup with a couple of greasemonkey scripts. It is to capitalize on this aggregation of knowledge that I have decided to start organizing Barcamps at our Ottawa office. What better way to work through ideas, practical or "what if?", than to lure a bunch of engineers together in a room and change some lightbulbs.


Barcamps were traditionally intended as "hack-a-thons", or "open source workshops". It is the latter definition I have chosen to concentrate on. A workshop without a plan, also known as "winging it", will put fear in the hearts of anybody who has ever organized any presentation. But this is where the strength of the Barcamp lies. The organizer of Barcamp needs only to set the meeting in motion, and it takes on life of it's own. The immediate disadvantage would appear to be that without organization, the members will not stay on topic and the collective attention will wander off topic. In practice, however, the common interest of all attendees will steer the workshop on a relatively tangent topic. And this is the key: when the attendees walk away from a completed Barcamp, they have participated in an active, hands-on, discussion of the primary topic and relevant related topics.
What starts as a Barcamp to learn about Google Android's architecture, will also cover the history of open mobile platforms, wireless signaling, carrier business practices, and competitor behavior. This sort of many-to-many learning ensures that all questions are raised and answered. Compare that with a one-to-many presentation that might have to rush through certain topics that are not immediately relevant to the stated topic, and you start to see how
a Barcamp can become an extremely powerful tool. Instead of following the presenter's ideas, the workshop will follow at the pace set by its attendees.

So how does one organize such an ad-hoc workshop?

Step 1: One Foundation

Imagination sparks innovation. Not all attendees are going to be aware of Google Android in detail, or mobile platforms at all. Prepare to have several high level introductory items to get the discussion going. Google's original announcement of the Android SDK is a good start. It doesn't go into heavy detail and establishes context. More importantly, instead of showing code or
documentation, it shows practical uses and what is possible with their new platform.

Step 2: Punky Reggae Party

Discussion ensues. This is the event horizon of the Barcamp. What starts as a discussion about Google Android can cover any hundred different topics, from UI design, JVM design, hardware design, or even be a practical walkthrough installing eclipse, creating applications, and attempting to install them in the Android VM (which we never did get to work properly, for the record).

Step 3: Pass It On

A Barcamp should have some tangible output, if only notes. Attendees should be able to look at minutes or resulting code to review what was covered as a refresher, or a base for further research. What's more, those that couldn't attend would also have something to look at, and would be able to follow along on their own.

Labels: Android, Barcamp, Google, MacCamp