Tag Archives: android

“Don’t take it so hard, you work effectively in this ultra-specific area of technology than. You made a simple mistake.  You’ve admitted and acknowledged it, and you’ve learned from it. And it had no identified impact on customers.  Good!”

Continue reading →

A friend and I walked by a Rogers Wireless reseller recently, and discussed a promotional poster we saw in the window. It showed a bunch of Android phones, and the cost for these was advertised around $80, brand new (on contract, of course… )

Soon, most or all North-American mobile phones will be smartphones. Android is free, and so manufacturers are not obligated to spend any money for including it on their devices. Except, in order to properly manufacture a phone that includes Android installed from the factory, the phones must have certain abilities/features.

As phone prices drop, perhaps the cost to include a touch-screen will become too great for the manufacturer (relative to the cost of the phone itself) and the manufacturer may choose to use a trackball or touchpad like the BlackBerry phones. The possibility of any major manufacturer producing any android phone without a touch screen is a very bad thought. It would wreck most apps, and make the experience of using the phone very terrible. Maybe then it would not matter if it had no touch screen, because no one would buy it!

So, it was a pleasant when I was looking for a list of permanently-available buttons (home, back, search, menu, volume, lock, etc) and I discovered the following, part of the Android Compatibility Definition Document, available in the side column at http://source.android.com/compatibility/index.html

7.2.3. Navigation keys
The Home, Menu and Back functions are essential to the Android navigation paradigm. Device implementations MUST make these functions available
to the user at all times, regardless of application state. These functions SHOULD be implemented via dedicated buttons. They MAY be implemented
using software, gestures, touch panel, etc., but if so they MUST be always accessible and not obscure or interfere with the available application display
area.
Device implementers SHOULD also provide a dedicated search key. Device implementers MAY also provide send and end keys for phone calls.

7.2.4. Touchscreen input
Device implementations:17
• MUST have a touchscreen
• MAY have either capacitive or resistive touchscreen
• MUST report the value of android.content.res.Configuration [Resources, 30] reflecting corresponding to the type of the specific
touchscreen on the device
• SHOULD support fully independently tracked pointers, if the touchscreen supports multiple pointers

7.2.4 says all Android phones MUST have a touch screen. That’s a great discovery! So the touchscreen part of an android phone is not optional.

That’s all for now.

Other blog sites probably have content about this subject, but I felt a desire to share my two-cents-worth.

Now I’ve begun to learn Google’s Android OS and it’s helping me appreciate Apple’s iOS more.  Another reason, I found a blog with some good info on it yesterday and had an article something like “10 great things for ____”, and the author created a list of 5 things, and finished the list saying “I’ll get more written soon.”  That was 2 years ago.  Nothing was posted on the blog afterward.  Seems like one of those late-1990’s websites that were PERMANENTLY “under construction”.

So, this is the beginning of a number of writings about the two mobile smartphone operating systems, and I’m writing a bunch of this now, but posting it separately.

Topics:

• Introduction
• Hardware
• OS & Software
• User Interface
• Apps
• … more later, possibly!!

Introduction

Recently, I chose to put effort, serious and dedicated effort, into learning the Android OS for smart phones.  When doing development, it helps very much to have one of the real physical devices to test and give a sense of “yes it works!” excitement, and the money expense also helps force the progress, since a financial commitment has been made.

So I now own an iPod Touch 2^nd generation, iPhone 4, and Acer Liquid E running Android.  These are my mobile development devices, and I am really getting to understand them both more than I could with only the simulators.  Having the iPod touch for two years before the iPhone 4, and having that 2 months before the Android phone, I would think I understand most everything in terms of how it works on iOS, and be irritated when the Android environment is different.  Well, it’s true in most cases, there are a lot of things I prefer about iOS than the Android OS, but the interesting thing is: I realize that I don’t appreciate Apple’s operating system as much without having something different to compare it to.  Thus I am now beginning to understand some philosophy behind the design in iOS, and how it is different to the Android philosophy.

The main difference is the open-versus-closed models; Android being open-source and you can mess around with the OS and recompile it, and install it on the phone, making it do what you want. That’s for the way-out-there developers, but people can install apps anyway in their own home, downloaded from the internet and installed using the Eclipse IDE, if a person is ambitious enough, and patient enough to go through the necessary steps.   The iPhones and iPod Touches can’t have any app downloaded from the internet and installed… they must be downloaded through the device’s App Store app, or through iTunes on the desktop/laptops and synced onto the phone.  Apps are developed in Xcode on  Mac computers, and can only be installed on the device if a person has paid $100 for a yearly subscription to the “iOS Developer Program”.  Then you can download sample apps from the internet, and install them on your device.

Most the other differences are under the hood, which only developers will see or understand.  For example:  Apple expects apps to be singular, and it’s the normal way of apps on a desktop like Microsoft Word or Firefox/Safari/Google Chrome.  You double click an icon for the program,  or a file that is viewed by the program, and the program opens.

With Android, an app can have different bits that are each disconnected from each-other, but are loosely joined together… for example an app that is designed for note taking, allows you to write notes.  But it can also convert notes to PDF files, and you can email those PDF files with the app.  The PDF part is secondary to the note-creation, and yet the app can be made so that any other app can “create a PDF” and this app will be run, but instead of showing the standard note-taking component, ONLY the PDF converter component will be activated.  I haven’t seen this in practical action yet, because I’m only just learning, but this is the way it is according to the introduction on http://developer.android.com.

So those are two examples of philosophy differences, each with a description for Android and iOS.

Next, the more useful information begins.