• Quite a few bug fixes (such as when dragging an Editor Tab from one Editor Window to another when there is only one Tab in the initial Editor. At present this destroys the contents of the Tab, this won’t be the case in Beta 2).
• New Editor Windows will be dockable by default (with full-screen option next to the X on the Form’s Titlebar)
• Unit Cloning will become a standard option along with “New Edit Window”
• A “RADSplit” menu will be placed in the IDE
• Unit Cloning will be added to the context menu of the Editor
• (Possible) The dock’s Title Bar will be removed when an editor is docked, and you’ll be able to drag tabs or the editor itself to split them from their docked position.
• (Possible) Side-by-Side (Vertical or Horizontal) Editing for Forms/DataModules and their Source will be added as an option. So the Form and its Source (for example) will appear next to each other in the same Editor

Today I am happy to announce a full BETA release is available for RAD Studio 2007 to XE2!

Please head over to the temporary RADSplit page to watch a short demonstration video covering installation and various use-cases, as well as the installation download for the BETA.

Enjoy!

The update has been committed to the SVN repository, and an updated zip file has been uploaded too!

You can find more information on TTwitter, as well as the necessary download information/link on the TTwitter page.

Feel free to post comments here on this blog entry, or as comments on the Google+ entry (if you have a Google+ account).

• I have found and fixed multiple bugs, including one encountered by many of you which resulted in being unable to properly/accurately read values returned by Lua functions invoked by your Delphi code.
• Fixed a serious bug regarding Lua Stack Alignment (all tests now indicate that the Stack is properly maintained in all areas of Lua4Delphi).
• Refactored everything to use Interfaces now, including Stack Managers!
• You need to change all declarations of Delphi procedures to be registered with Lua. You need to change var AStack: TL4DMethodStack to var AStack: IL4DMethodStack, a minor change from your perspective, but makes a massive difference to the inner-workings.
• You can now read and write Lua tables and metatables. This is the key piece of the puzzle to be used by the next update (which will introduce all the Wrapper Units).
• The XE2 BasicLuaIntegration.exe demo has now been updated to demonstrate how to read and write Lua tables. Consider this code as a rough example only, as it adds no useful function to the demo at this time.

This is a prepartory update, to address everything which prevents the Wrapper Type system from working properly. The next update will be the single largest update thus far, and (assuming no major bug reports with this update) should be available within a week.

I’m planning a some-what improptu webinar for around 1:30PM UTC (London time), and will update this post with the URL to join. No registration is required!

So, if you’re confident enough to update your copy of Lua4Delphi (and make the necessary changes to your existing implementing code), feel free to do so now. If you’d rather wait for a demonstration of these changes and additional features, 1:30 PM London time is when the webinar begins.

Please keep in mind I still have a fairly annoying cough, so I ask for forgiveness in advance should I struggle to speak at times.

These are the very same idiots (and their descendants) whom whole-heartedly proclaimed at the rise of the Personal Computer that it spelt imminent doom for the common Calculator. Well, I’ve yet to encounter an office where every desk didn’t contain at least one common Calculator, alongside the Desktop Computer used to perform the more complex tasks.

Let us ignore the semantics of the term “PC” for a moment, and presume that they are using it to describe the traditional Desktop Computer, found in almost every home and office in the technological world.

Why is it that the birth of every new gadget simply must spell doom for whatever technology is at that time the most prevalent? I’ve genuinely been trying, and have yet to find a single example of a gadget’s birth leading imminantly to the death of other (more widely adopted) technologies… not a single example!

Indeed, it seems that the misguided fools who make such masochistic associations perceive that technology works in much the same way as America’s crusade (whoops, I mean “war on terrorism”): a ceaseless battle, which can never be won but always expands its reach to the next richest territory (device) to acquire its wealth (users) before it moves on to the next.

Technology simply does not work this way, never has worked this way, and never will work this way.

Gadgets exist to serve specific needs, in precise recognition that no one solution suits all. Your tablet device is useless as a phone, and your phone is useless when it comes to word processing, spreadsheets or database manipulation. Likewise, your Desktop Computer is useless in terms of portability.
The point is that no one device meets every need, and so diversity is required.

You cannot use the iPad (for example) as the basis for your proclamation of the death of the Desktop Computer (again, for example). You cannot claim that the iPhone spells imminent doom for the iPad, or that some new type of gadget as-yet unimagined requires the death of any existing technology to reach its rightful place in the market.

When you buy a device, you’re buying a product to meet a need. You’re not buying into a cult, requiring that you announce your absolute obedience through the renouncement of all other devices.
Your device does not come with a set of commandments featuring such biblical gems as “thou shalt not worship any other devices“, or “burn the unbelievers for they impact on our profit margins“.

This leads us neatly to another issue I want to mention:

“Native development will be dead within a year“

I read statements almost identical to the above when .NET was announced, with developers pledging their undying faith for Microsoft’s then-newest money spinner (now largely rendered worthless by Windows 8, by the way).

Indeed, similar statements were made with regard to almost all development frameworks, and yet native development still runs strong.

When performance and quality are primary considerations in a software product, native development is always chosen (by any executive who either listens to his/her team, or has one iota of knowledge of software development).

With Microsoft’s latest abomination (namely Windows 8) bringing a bastardized form of HTML5 and JavaScript to the desktop (quite frankly the dumbest idea in the history of dumb ideas), proclamations of the impending death of native development are once again running strong.

Of course, the type of thought-deprived fools making these inane statements haven’t considered that just because HTML5 and JavaScript work fine for the Web, it doesn’t mean they will work so well for other purposes. Indeed, this is why there has always been a clear division between technologies for the Desktop, and technologies for the Web (the two are simply so different that a clear line must always divide them).

I myself toyed with the idea of using JavaScript and HTML (HTML5 didn’t exist at the time) as a means of extending Desktop applications way back in 2008, only to abandon the idea in short-order when realizing the practical limitations of what I have since termed as “Frankensystems”.

A growing number of developers have begun to realize (as a different many of us – myself included – had realized long ago) that any form of runtime framework introduces critical limitations in the development of our software.
All of these can be summed up by the simple truth that, when you develop for a runtime framework, what you can produce is restricted only to what is made available by the runtime framework.

You will never, for example, encounter a Device Driver written in C#, or HTML5/JavaScript… it simply cannot be done, because the frameworks provide no means of accomplishing this.

So, while self-proclaimed “web developers” rejoice at this foolish belief that Windows 8 will make it easy for them to apply what they know of HTML and JavaScript to producing fully-functional Desktop applications, this simply isn’t true (at least, not in the way they think).
I’ve actually had a conversation with a web developer who genuinely believed they’d be able to use Joomla as the foundation of a complete Desktop application for Windows 8. I’m not joking! I won’t mention their name here to spare them the embarrassment, but sufficed to say I haven’t laughed so hard in a long, long time.

Anyway, the point I’m trying to make is that the same masochistic desires for one technology to succeed through the death of its more commonly adopted forebears runs as strong in the software industry as it does in that of the gadget.

I can sum this rant up by simply pointing out the following:

• The PC didn’t kill the Calculator.
• Mobile Gadgets haven’t killed the Desktop Computer.
• .NET didn’t kill native development (indeed, it has now begun to reinforce the market’s demand for native development)
• Windows 8 won’t transform web developers into software moguls, or advance software development in any positive way.
• If you believe that one technology’s success requires another’s utter failure, you need your head examined.

Despite the headline image (the mock tombstone), I shall not bid a peaceful rest to the Desktop Computer (or native software development)… not now, not ever. The simple truth is that there will always be a need for them, in whatever form into-which they evolve.

If you’ve properly read and understood this article, then I shall bid a peaceful rest to whatever misguided belief you may have held on this subject.

So, now here’s another poll I’d like to get your opinion on…

How much focus do you believe Embarcadero should apply to bug fixing versus new features in Delphi XE3?

I’m interested to see what the majority consensus is on this issue. As with the previous poll, there is a purpose to my asking this.

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Thanks again!

My well-known “anti-Apple” bias…

I want to be completely transparent about this… it is no great secret that I have a very strong anti-Apple bias (for reasons not of interest to this article). My bias plays no part in this article, nor are the pro’s and con’s of Android, Windows Phone or iOS, Google, Microsoft or Apple discussed here.

This article is intended to be fully objective, and serves merely to provide some fundamental understanding I believe is lacking at present.

My background…

Most of you only know me as a Windows developer using (primarily) Delphi and FreePascal/Lazarus.

What you may not know is that I do actually produce more than a few Android apps for clients (to be used within their respective companies as a replacement for PCs in certain departments such as dispatch).

I have subcontracted the development of the same apps for iOS devices where requested (based entirely on my designs), and I currently have two Android apps in development (one of which I’m also developing for Windows Phone, and am contemplating releasing on iOS as well).

The “mobile Apps” I have developed for clients had the requirement of being able to run on both Tablets and Phones.

© Robert Scoble

Why this article?

© Samsung

This article is born of a Google+ posting by Robert Scoble (a well-respected employee of Rackspace), in which he casts his opinions on various statements made by the CEO of Samsung

regarding the supposed lack of success of Android (more specifically: Samsung’s lack of success in the Tablet market) from Samsung’s perspective. This article also addresses many other statements around the Internet where the user count of an App between different platforms is used to judge the popularity of one platform over another (a naive practise at best, deliberately misleading at worst).

With the above said, let’s get on with the subject at hand…

The Device Divide

Let’s begin by taking a look at the differences between phones and tablets, as this is a major consideration many developers are simply ignoring, and many others not properly handling.

Android Tablet (Left), Phone (Right)

Physical Size

This is the most obvious difference, but also one of the most significantly overlooked.

Mobile phones tend to have a much smaller display than tablets (goes without saying). This means that the amount of information you can display on a phone at any one time is substantially less than the amount you can display on a tablet (stating the obvious again, I know).
The tendency of many developers (as I have witnessed more often than I’m happy to admit) is to essentially squeeze all of the information into the available display (sometimes by simply making the text, images and controls smaller overall). This kind of design is entirely ignorant of providing the best user experience for any given form-factor, and almost never works well.

With a phone, the limited real-estate afforded by the typical 3-4″ display means that the user interface needs to be concise. Simplicity is paramount as the display simply isn’t large enough (or even necessarily of high enough resolution) to accommodate large numbers of controls or menus.

In contrast, tablets have much more screen real-estate (7-10.1″), so more consideration should be given to logically dividing groups of controls and menus. That’s not to say that tablet apps should be in any way convoluted or overcomplicated, but rather that the larger display simply means that our apps can do more easily, and display much more at any one time, thus making it logical to exploit the additional real-estate to the benefit of the user.

Remember: Just because it is possible to produce a single app with a single GUI which will run on both phones and tablets, that doesn’t mean you should!

Connectivity

Connectivity

Given that mobile phones are primarily communication devices, it is a fairly safe assumption that these devices will almost always be connected to the Internet by one means or another (be that WiFi, 2G, 3G or 4G). That’s not to suggest that “mobile phones are always connected”, just that they are almost always connected, therefore it is acceptable for an App to rely on an Internet connection being present as the chances are it always will be when the app is required by the user.

Unfortunately, the same is not always true of tablet devices. Indeed, while iPads all have a SIM slot and 2G/3G data (edit: I’m now informed that not all iPads have a SIM slot… I didn’t know this), the same cannot always be said for Android tablet devices. A simple example is that I have the WiFi model of the Motorola Xoom tablet, which means it is only connected to the Internet when a WiFi network is present (or when I choose to tether it to my phone to share its data connection, but not everyone has the ability to do this).

Since not all Android tablets have a constant data connection, it is not a safe assumption that these devices will be connected to the Internet at any given moment. This means that your app should (if at all possible) be less dependant on Internet connectivity when running on a tablet device (certainly in the context of Android, anyway). Your app is no good on a tablet if it’s unable to function without an Internet connection when the tablet isn’t connected (I said it, even though it need not have been said).

Remember: Your app should behave gracefully when in the absence of an Internet connection, especially when running on an Android tablet!

Phone Virtual Keyboard

Ergonomics of input

Technically this topic relates to the difference in physical size between phones and tablets, but is in some ways more complicated so I’m discussing it separately.

We carry our phones everywhere, and for the most part they serve their purpose just fine. A fairly major issue occurs, however, whenever it becomes necessary to type any significant amount.

Personally I find it almost impossible to type an e-mail on any smart-phone (whether using a touchscreen, digit buttons or even a “full” QWERTY keyboard on the device itself).

To address this, phone apps should require as little typed input from the user as possible. There are countless instances I’ve encountered where an app requires me to type when it would easily have been possible to have used some form of logical selector (such as a “Progression Tree” or even a numeric slider).

Remember: When it comes to phone apps, the less typing involved the better!

Tablet devices provide for a much better typing experience, as the display size allows for larger (thus more accurate) virtual keyboard keys, and even for a more ergonomic virtual keyboard layout. It is therefore acceptable to allow for your app to involve more typed input from the user on a tablet device.

On a similar note: Tablet devices are being used more and more in offices now with a physical keyboard (sometimes even a physical mouse). This makes typing even easier as a physical keyboard provides instant tactile response both prior to and after pressing each key.

Differing performance

I believe it is fair to say that the majority of smart-phones on the market are of substantially lower performance than tablets. I of course acknowledge that there are some handsets currently – and soon to be – on the market which match or, in some cases, even exceed the performance of certain tablets, but these need to be considered as niche devices rather than common-place.

So, with the above in mind, and dependant on the features of your app, it may be necessary to scale for performance according to the most common hardware between phones and tablets.

For example: if you desire to include a fancy animated user interface, with lots of objects moving around or even high-detail animation in the background (both of which can often be tacky and should be given a great deal of consideration before making your decision to include such things), this may work great on most tablet devices, but could cause very low performance on phones.

Remember: It is generally better to conform to the lowest common denominator when it comes to performance, as this will make the largest possible user-base available for your app.

The tablet version of your user interface can include more performance-intensive elements than the phone counterpart, so you should accommodate this in your design (where applicable).

This consideration is not only limited to the user interface, of course, as, dependant on what your app is doing, it is possible that certain background processes could perform quite slowly.

If, for example, you are processing an XML dataset for display, it would be better to process less of it on a phone than on a tablet. This makes sense for two reasons, the first being that the phone will likely take longer to process the same portion of the XML dataset, and the second being that it gives you incentive to display less of the data on the screen at any one time (which is better given the smaller display of a phone, too)

Remember: The amount of “work” you make the device perform should be relative to the typical purpose of the device (less for a phone, slightly more for a tablet)

On a phone?

Different devices have different purposes

You may think this is as plain as the nose on your face, but it is actually the most commonly overlooked issue when it comes to making mobile apps.

Using myself as an example, I don’t do everything with my phone what I do with my tablet, and vice-versa. This is because different devices have different purposes (as almost anyone would agree without hesitation).

When you are planning your app, one of the very first questions you need to be asking yourself (and/or your team) should be “is this app for the phone, the tablet, or both?”
In many cases, your app will be best suited to either one type of device or the other, and acknowledging this early in the design process will not only spare you a lot of disappointment, but will save you a lot of design and development time too.

Remember: There is no point in developing your app to support both phones and tablets when only one of these device types will generate any user interest.

Whether your specific app is best suited to one, the other or both… that’s up to you to determine. Likewise, you should make your intended target device type clear in your app’s product description, to better guide prospective users as-to the best use of your app.

Parallel: You wouldn’t use your phone to do word processing, spreadsheets or database management! You wouldn’t use your tablet to place telephone calls (VOIP not-withstanding). You wouldn’t use your desktop PC as a mobile phone. You use the right device for any given job!

The Culture Clash

Moving away from the differences between phones and tablets, there is another equally important consideration developers need to make when targeting different mobile platforms (such as iOS, Android and Windows Phone) with the same app.

A person’s decision when choosing between devices is a direct expression of their culture.

An iOS user, for example, is a very different animal to an Android or Windows Phone user. Likewise an Android user is a very different animal to a Windows Phone user. I mean this in a very serious (non-insulting) way, and I don’t say this lightly… it is a well-studied phenomenon.

A person’s choice between iOS, Android and Windows Phone is (in almost all instances) anything but utilitarian. Studies (you can find them with a Google search) have shown that each consumers’ decision is almost always the result of their receptiveness to one marketing campaign over another. This bias of reception is in turn a result of who that individual is at a cultural level.

To put it quite bluntly: you’re either brainwashed by Apple, Google or Microsoft.

These studies typically involve teams of people at retailers asking a simple question to customers at the checkout paying for their iOS, Android or Windows Phone product: “what made you choose this device over the others?”. The results always clearly conclude that the overwhelming majority of customers based their decision entirely as a result of a particular advertising/marketing campaign, rather than a carefully considered weighing of each devices’ pros and cons.

This isn’t at all surprising, and is why marketing firms are paid so much money to create the most compelling campaigns. This observation extends far beyond mobile devices, of course, and influences almost every purchase decision a person makes throughout their entire life. Nobody (not even the marketers themselves) is entirely immune to its influence.

Why does this matter?

Well, given that iOS, Android and Windows Phone users are all culturally and socially different in so many ways, it means that their expectations, requirements and tastes also differ. This creates something of a “culture clash” when it comes to apps transcending the different platforms.

These differences are often ignored entirely by app developers, many of whom I would suggest have never even given it a moment’s thought, and this has led to a lot of inaccurate conclusions when it comes to the comparative popularity of the various platforms.

When the producer of a highly popular app releases the same app on two rival platforms (for example on both iOS and Android), they almost always try to make the app look, feel and perform the same way.

At first glance, this may seem appropriate as it saves on design time, and without considering the cultural and social differences between the users of each platform, you would have no reason to predict that your app’s popularity would differ significantly between them.

Even if the “look and feel” aren’t designed to be identical between platforms, often apps are developed with one platform in mind, and the other platform is tagged on as almost an after-thought, resulting in an inappropriate user experience for that platforms’ user-base. This also results in the satisfaction of users between platforms being disproportionate, and is still a failure to properly understand the platforms’ users.

Flurry "Stats"

So, when Mr. “I made a popular app, so listen to what I have to say” publishes an article condemning a platform as “less popular” based on nothing but the user count of their own product between two platforms, what they’re actually demonstrating is that they have failed to consider the cultural and social differences between the users of each platform, and therefore their product is simply not as popular on one platform as it is on the other.

The solution is fairly simple…

What I am suggesting (with the exception of such things as Games which will obviously want to look, feel and play the same way no matter the platform) is that you should have an entirely separate design and development process for each target platform.

You need to research the differing cultures of each target platforms’ respective users, and your design needs to reflect those differences as best you possibly can.

Even before you get to that stage, you need to actually consider whether your app (at its most fundamental level) is even remotely appealing to the users of each particular platform in the first place. There are certain types of app which hold little-to-no interest with the users of one platform, while standing to be immensely popular on another.

It is up to you (and/or your design team) to determine whether it is even worth pursuing a platform with your particular app.

One way of garnering this kind of information is to create a poll, asking your prospective users what their platform is, and whether your app is of interest to them. You can also visit community forums centric to particular platforms, and essentially “test” the popularity of your app as a concept before you even begin the detailed planning phase.

The best way to determine whether your particular app will be popular on any given platform is to diversify your team (to have an equal number of designers and developers from each target platform‘s user-base). Ask their opinion, and value their genuine responses.

Should it be apparent that your app could be well-received by a particular platforms’ user-base, allow your team(s) to come up with designs specific to each of those platforms, and invest as much time as it takes to achieve the full satisfaction of your design/development team(s).

Remember: Most mistakes in the success of an app occur before development even begins; with poor planning, a poor design, or a lack of adequate market research.

In conclusion…

I genuinely believe that if you heed the advice I have provided in this article, you and (where applicable) your team(s) will be able to produce a successful mobile app.

Failure need not be an option if you understand the users, the diversity of those users, the devices and their diversity. An idea is only poor if it is developed inconsiderately.

All of the mistakes I’ve indicated in this article are easy to avoid if you’re willing to put in the effort, and there is no reason why you shouldn’t be able to reach at least one market’s audience (perhaps even all of them).

A shameless “plug”…

Should you feel that the insights I have shared here are beneficial to your work, I am available (through my company LaKraven Studios Ltd) to contract as a consultant (as well as a developer on certain platforms).

I have proven experience in many facets of the software design, development, branding and marketing industry, as well as a wealth of resources I can bring to to any team. Above all, I understand the users of software! I may be able to spare your company from disappointment, as well as save you money (and time) on your investment.

My anti-Apple bias (should that be of concern to you) is one of business ethics. I acknowledge the merits of Apple’s products, and am more than happy to assist in the design/development process of apps on Apple platforms.

If this offer is of interest, feel free to leave a comment or contact me by any of the means displayed on the “Contact Me” widget on the right-hand column.

Blackberry

Whoops, I almost forgot…

Blackberry devices exist too. I’m told people still use these, but nobody I know (thus why I almost forgot about them).

Feel free to leave the humorous comments expressing your hatred of me for the picture of the broken Blackberry… it’s meant in good fun!

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Thanks!

A few days ago, I noticed that my Android tablet (Motorola Xoom) was collecting and transmitting my exact GPS co-ordinates every time I reboot it.

Naturally this raised a red flag with me, and so I set about trying to locate which app was responsible.

At first I thought it was Google+, as this was the only update I actually noticed at the time. Like many, I use “Allow Automatic Updates” on most apps I had put my trust in, thus many apps updated themselves without waiting for me to start that process manually.

Today I have finally traced the culpret…

SoundHound

I originally encountered this app when the free version came pre-bundled on my HTC Desire S from O2. At that time, its permissions were very reasonable, and GPS position data was never collected (the permission was never even requested by the app). I decided to buy the full version, which I have used from time to time when I can remember a tune, but not the name of the artist or track.

It is worth highlighting the fact that SoundHound comes prebundled on many Android devices.

If you have the SoundHound Widget placed on your homescreen, and have allowed it to update to the latest version, you will now notice that each time you reboot your device, it immediately attempts to pinpoint your exact GPS location. Once this is collected and a data connection is available, it appears as though this data is transmitted back to SoundHound’s servers (likely along with your phone’s unique ID, and your Google Account details as per its permission requirements).

EDIT: The reason I suspect that this information is being sent back to SoundHound’s servers is that the SoundHound process immediately triggers a transmission of data after the GPS location has been pinpointed (I have tested this by disabling all other network/internet-connecting apps and options, effectively isolating everything from attempting to communicate online except SoundHound)

This does not occur on boot if the widget is not on your homescreen, but in that event SoundHound simply does it when you run the app itself.

There is no logical reason for SoundHound to collect your GPS coordinates! It does not provide any additional functionality to the app itself (it’s not location-sensitive by nature).

SoundHound collecting your GPS coordinates in conjunction with your device’s unique ID and your Google Account information constitutes a major privacy risk.

As a result, I am strongly advising that you uninstall SoundHound from your Android device(s) immediately, and do not reinstall it at any time!

I am about to send a strongly-worded letter to SoundHound, requesting details of why they collect this information, and what they do with it. Should they choose to respond, I will post their reply in full as an update to this post (a detail of which I shall make them fully aware in my letter).

Update 1

SoundHound’s Android Market Page makes this one small note (at the very bottom of the app description) regarding its requirement of the GPS permission:

Note: Location is used to store where songs were discovered. It can be disabled from the Options menu.

The behaviour exhibited by SoundHound’s widget (collecting your GPS position the moment your Android device boots) contradicts this non-declaratory statement. Indeed, this statement does not explicitly state that Location data is only used to store where songs were discovered, nor does it make any mention as-to whether SoundHound are collecting your location information.

Indeed, SoundHound’s Privacy Policy admits that your GPS location is transmitted to their server(s), and that they even reserve the right to share this information with unnamed third-parties!

When you use the SoundHound applications, your mobile device supplies a unique identifier, which we use to associate search results, your bookmarks, and other information with your device. We improve the relevance of information provided in the applications using location information provided by your device, which you can choose to turn off. If your browser supplies location information (determined by your browser settings), we may use that information to improve the relevance of information provided by the web site. Content provided by advertisers and other third parties may be personalized in a similar manner.

This privacy statement makes mention that the location feature can be disabled should you choose, however it must be noted that in starting SoundHound to disable the location option, you have already transmitted your exact GPS coordinates to their server(s), thus also their third-parties!

If SoundHound are genuinely not interested in harvesting your personal information (particularly your location), all of the “features” which supposedly necessitate the harvesting of said information should be disabled by default, thus requiring the user to opt in, rather than opt out!

Indeed, because the “features” which supposedly necessitate the harvesting of device information (as well as the overwhelmingly personal information of the user’s exact location) are enabled by default, SoundHound directly (inadvertantly or otherwise) contradicts another statement in its own Privacy Policy:

Consistent with the federal Children’s Online Privacy Protection Act (COPPA), we will never knowingly request personally identifiable information from anyone under the age of thirteen (13) without requiring parental consent. Any person who provides their personal information to SoundHound through the web site or applications represents that they are 13 years of age or older.

Some may dispute whether GPS coordinates can be considered “personally identifiable information”, but in respect to any child under the age of 13 operating SoundHound from their own home, it doesn’t get any more personal than that!

You may call me paranoid if you like, but if an App collecting and transmitting your exact location every time you start your device (without ever soliciting the use of that App at the time) is not a privacy concern to you, you may want to ask yourself just how much personal information you’re willing to give away, and what possible consequences that may have on your life.

Update 2

Googling the issue of SoundHound and GPS coordinate transmission, I came across a test conducted by a University Undergraduate Professor where he set up a “sniffer” (system to intercept and read all data being transmitted over a network onto the Internet) the results in which he specifically points out that SoundHound’s Android app transmits his precise GPS coordinates (plain for anyone with a little knowhow to intercept at will) to SoundHound’s server(s).

SoundHound and ShopSaavy transmit your fine GPS coordinates whenever you make a request to them. One of the students typed the coordinates into Google Maps and they nailed me to the proper side of the building I was teaching in.

Note that “ShopySavy” transmitting your fine GPS coordinates makes sense given that ShopSavy’s service is “location-aware”.

It’s also worth noting that, at the time he conducted his test (almost exactly a year ago, in February 2011), he did not observe SoundHound transmitting these details when he booted his device. This (along with the fact that my Android devices have only started doing this in the last few days) adds weight to my insistence that this unwanted behaviour is the result of a very recent update of SoundHound itself, thus almost certainly a deliberate act in an attempt to harvest personal information with greater regularity.

The student professor who conducted this test (Dan Wallach) noted in a comment to his article on the subject

In the case of SoundHound, they clearly don’t need to know where I am in order to tell me what song they’re hearing.

Of course, SoundHound attempts to justify its collection of GPS location data by mentioning only that these details are stored in conjunction with your search history, so that you (the user) can look up when and where you heard a track.

It is not necessary, however, for SoundHound to actually store this location information on their own server(s) to provide this functionality, as the same data could easily be stored on your own device instead. Essentially, if a service is not location-aware (where the results it provides are localized for your convienience such as an app which makes it easier for you to compile a shopping list for your local supermarket), it should not be transmitting your location data over the Internet.
As Dan Wallach also notes in another comment:

They need to offer some value to me in return for my telling them where I am. For example, say they only tracked what city I’m in, they could tell me, in return, something about how many other people in my city have tagged the same song. That would still let them collect and sell interesting aggregate data without having a database somewhere that says exactly where I was at the time I wanted to recognize a song.

This quote expresses my thoughts on this situation better than I can, and it’s also good to know that I’m not alone in being concerned about this unnecessary affront to my personal privacy.

Remember: Even though SoundHound now provides the option to disable its harvesting of your GPS coordinates, in order to disable them, you still have to load their App, which in turn transmits your current GPS location before you’re able to disable it!

Does your Android device have SoundHound bundled on it by default?

I’d like to hear from you! Please leave a comment with the brand, model and carrier of your Android device. Where possible, I shall endevour to contact all those involved in bundling this software on their Android devices, citing the clear privacy concern this software now represents, and urging them to remove this software from all ROMs, as well as provide a simple means for those with existing devices to remove it from theirs.

Remember: In many cases, it is not easily possible for you to remove prebundled apps from your device when using the stock ROM.

If you have the ability, and are confident enough to potentially void your device’ warranty, it may be possible for you to remove SoundHound (and other prebundled apps) from your device by Rooting, or even flashing a clean ROM onto your device.

Motorola Xoom Owners can find my complete guide on flashing the GED (Google Experience Device) ROM onto their devices here on my blog.