Tag Archives: Android

Thoughts from the Road

I’m in Tampa, at the University of South Florida, attending the Higher Education Enterprise Mobile Applications Conference (HEEMAC). I’ve seen and heard some really great things that colleges and universities are doing, from a mobile enterprise perspective.

One group, however, is strikingly absent – faculty. I’ve run into Associate Deans, technologists, native app developers, web developers, and even the odd CIO… but only one or two faculty members, out of 100+ conference attendees.

Admittedly, this is an enterprise mobile conference, and not one centered upon pedagogy.

Still.

I believe that faculty are under represented, overlooked, and generally ignored in conversations of campus technology, where they are every bit as much stakeholders as the students we strive to support. This week is only reinforcing – at least, for me – the great divide between academics, and the information technology infrastructure supporting the administrative side of things.

I was heartened to hear words like “enable” and “facilitate” in the context of opening up APIs, mobile development best practices, and providing software development guidance.

I was equally disheartened to hear that some mobile projects are being intentionally “slow walked” in order to have these projects wither and die from neglect.

To paraphrase from Robert M. Pirsig’s Zen and the Art of Motorcycle Maintenance:

“Other people can talk about how to expand the destiny of mankind. I just want to talk about how to fix a motorcycle mobile application.”

We have much yet to do to make our technology decisions inclusive of all stakeholders; not only because it is the right and proper thing to do, but because we are allowing strategic decisions be driven by what is simple to support and easy to do. If we are to innovate, stand out, and convincingly argue our institutions’ cases for value within the current environment of uncertainty, high debt, and questionable sustainability in higher education, then I believe we must do better than simply be “good enough.” We must be exemplary. And that can’t be done on the cheap, nor the easy.

We have real innovation occurring in higher ed mobile. We also have a lot of cookie cutter, least-common denominator solutions.

Is that good enough?

I’m grateful for the forum that our gracious hosts at USF have afforded us to conduct this inquiry into values, technology, and mobile strategy. We have our work cut out for us.

Tagged , , , , , ,

Creating Calendar Events – Using WebView – in Android

Hey – it’s been a while.

No time like the present to write a post about Android coding.

Specifically: “how do I create a calendar event from within a WebView in Android?”

First, let’s talk game plan. I am going to construct an url “scheme” that will indicate to a handler that I want to create a calendar event, and not navigate to a web page; then, I need to call an Intent that will allow the event to be created.

Easy Peasy.

So, for my dates that I wish to portray on a web view, I do something like the following:

<a href='date:beginmonth, beginday, beginyear, 
endmonth, endday, endyear, My Event Description'>
My event link</a>

Then, I construct a shouldOverrideUrlLoading handler that will detect that a date: is being clicked, and handle it specially (see the code below):

final WebView crimeView = (WebView) findViewById(R.id.webview_crime);

crimeView.setWebViewClient(new WebViewClient() {

@Override

public boolean shouldOverrideUrlLoading (WebView view, String url)

{

if (url.startsWith("date:")) {

Log.d(this.getClass().getCanonicalName(),url);

Calendar beginCal = Calendar.getInstance();

Calendar endCal = Calendar.getInstance();

Date beginDate = new Date(0, 0, 0);

Date endDate = new Date(0, 0, 0);

String parsed = url.substring(5);

String[] components = parsed.split(",");

beginDate.setMonth(Integer.parseInt(components[0]));

beginDate.setDate(Integer.parseInt(components[1]));

beginDate.setYear(Integer.parseInt(components[2]));

beginCal.setTime(beginDate);

endDate.setMonth(Integer.parseInt(components[3]));

endDate.setDate(Integer.parseInt(components[4]));

endDate.setYear(Integer.parseInt(components[5]));

endCal.setTime(endDate);

calendarevent(beginCal, endCal, components[6]);

return true;

}

return false;

}

});

Finally, we need code to invoke the Calendar intent. It looks like the following:

 // Create a calendar event
    public void calendarevent(Calendar begintime, Calendar endtime, 
                              String eventName) 
    {
        Intent intent = new Intent(Intent.ACTION_EDIT);
        intent.setType("vnd.android.cursor.item/event");
        intent.putExtra("beginTime", begintime.getTimeInMillis());
        intent.putExtra("allDay", false);
        intent.putExtra("rrule", "FREQ=YEARLY");
        intent.putExtra("endTime", endtime.getTimeInMillis()+60*60*1000);
        intent.putExtra("title", eventName);
        startActivity(intent);
    }

And that, as they say, is that.

Tagged , , ,

Transparent Backgrounds on Android Views

A frequent question encountered when using WebView inside of an Android app is “how do I make the background transparent, rather than the default white color?

This is ridiculously easy:

WebView myWebView = new WebView(this);
myWebView.setBackgroundColor(0);


Happy Coding.

Tagged , , ,

Making Breaking Changes

The decision to make – or not make – a “breaking” change is always difficult.

A “breaking change” is a change made to an application that either forces an upgrade to a new OS, a new piece of hardware, or in any way fundamentally changes the app in such a way that the application won’t work the way it used to.

Sometimes one must make a decision to roll out a breaking change because the gain is much more than the pain felt in not doing the breaking change.

And sometimes, developers make breaking changes for no good reason whatsoever.

Like, for example, the change made by Google’s Android SDK team when they changed the name of their “tools” directory – the directory where all of the utilities needed to build and deploy Android apps – to “platform-tools.”

No new features were added. No additional functions.

Just a change that caused every developer who downloads the latest sdk to have to change his system configuration. And waste 15 minutes or more for a change that adds no value. Zilch.

Even if a change only involves changing a PATH statement (as this change did), why make the change at all if it is only to satisfy some arbitrary naming aesthetic?

It’s stupid.

And makes me want to whup somebody’s tail for being stupid.

Listen – I can appreciate wanting to correct past wrongs. But sometimes, the gain (zero in this case) is not worth the aggravation you cause the entire community by your breaking change.

So please, consider that the most valuable asset we all have is our time.

And when you waste it doing stupid stuff like this, it shows disrespect and a total lack of consideration.

There are absolutely times when breaking changes are warranted. In this case, Google, changing the name of the tools directory was unwarranted and idiotic.

Tagged , ,

A Modest Proposal (With Apologies to Jonathan Swift)

Once again, while working with Android, I’ve been bitten on the backside by differences between devices and how the camera works.

In the latest incarnation, users uncovered a problem where the DroidX camera (using com.motorola.camera) simply stops working. And not just for our app; for all subsequent usage until the phone is restarted.

Simply by taking a picture.

Apparently there is a known issue with the Motorola camera app and marking photos with GPS data.

But here’s the thing – why the hell is it so impossible for Google to simply say, “this is the camera app – use it, or else?”

If I sound frustrated, it is because I am. Camera issues account for 95% of the headaches I have when dealing with Android app problems (the other 5% usually involve memory allocation).

So, borne of my frustration, I make the following modest proposal:

In the future, before certifying a handset as being an Android device, Google should change their licensing to require handset manufacturers / carriers to provide a ROM-identical simulator for every Android device they ship. Running the exact apps that run on the actual device in the wild.

Without having actual hardware on hand, it is impossible – IMPOSSIBLE – to realistically test 100% of a device’s capability.

And when the carrier or handset maker ships a custom camera app, without a physical handset on hand, there is zero hope of testing – and guaranteeing – that an app will work with that particular handset.

It’s a small miracle that more outrage isn’t commented upon. Because it’s certainly out there.

As an Android user, I feel the pain personally. As an Android developer, it is a big point of pride to try and release the best possible software that I can.

But when every handset maker and carrier chooses to pick and choose core peripherals (like camera, video, gps, etc.) that they will support – or not – in a standard – or not – way, it makes the job of creating 99.99% up time, quality software nigh impossible.

At least not without sounding like you’re a whining excuse maker.

It is what it is.

I simply believe that Google must step up and think more of what this is doing to user experience and how app developers are bearing the brunt of the shoddy crap that is coming out of Motorola and the other carriers.

Instead of being concerned with spreading the Android “brand” at the expense of defining what, exactly, it means to be minimally “Android” in  anything approaching a uniform sense.

Tagged , , , , , , , , ,

When Your Baby Is The Ugly One

This scenario plays itself out repeatedly:

Company A releases a great new mobile app. Initially, it runs on only mobile OS X.

Users of mobile OS Y decry how epic this FAIL is on the part of Company A, how clueless they are, and how they are totally missing the boat and losing their business.

Wash. Rinse. Repeat.

Trust me – companies don’t go out of their way to NOT service their customers and consumers.

These decisions are based upon market share, money on hand, time to market, and availability of manpower to build product.

In short, it’s business.

For the most part, this script usually translates as: Company A releases an iPhone app, initially. Users of Android, Blackberry, Palm, etc. are unhappy that they are being slighted. They think the company doesn’t value them.

In fact, the company is probably coping with a small set of developers, looking to get the biggest initial bang for their constrained development resources, and has every intention of getting their product on these other platforms, as time, resources, and money permit.

Apple’s ability to allow consumers to discover new applications is superior to what Android and Blackberry offer. I’m sorry. It just is. You can’t browse the Android Market or the Blackberry App World from your laptop to discover apps. You can with the App Store. Therefore, the chances for new consumers to discover, disseminate, and advertise your new app are greatly multiplied by releasing an iOS version, first.

Again, this is a business decision, not a straight-up fan boy love affair.

Yeah – it totally blows to have to wait for something the other cool kids are playing with now (hear that Twitter? Still waiting on “new” Twitter. Le sigh).

This is how I, as a cross platform developer, look at these platforms when trying to design and develop a new commercial product. I’m keeping “religion” (i.e., the relative merits of open source vs. closed source) out of this discussion in the main, aside from mentioning availability of sample code:

Apple:

Pros: Has maximum reach, best application discovery, best user experience with regard to UI and overall integration, highest quality store; customers spend actual money here. Best UI design tool of any of the mobile smartphone environments (Interface Builder) . Easiest to system test code, because you only have 3 basic iPhone models.

Cons: Strict curation can be an impediment to delivery. Wait times for approval have gotten better, but definitely adds friction to the process.

Android:

Pros: Easiest to ship, fastest growing smartphone OS. Lots of open source examples. No curation to get your app in the market, which means revisions and bug fixes happen in “internet time.” The ability to customize AVMs for creating device simulator configurations is the most flexible across all OS SDKs.

Cons: Horrible UI design tool. No application discovery, aside from third party websites. No curation in Android Market means anything goes. System testing is a nightmare, because you have a cross product of dozens of combinations of hardware and OSes that realistically won’t be fully exercised by small developers. The user experience across carriers is inconsistent – anyone who have ever implemented an application on Android that has to use the camera can attest to the variability in operation, quality, and performance. Fragmentation really doesn’t capture how fast this is getting worse rather than better (see: Verizon and Amazon creating their own market, see: carriers installing root kits to frustrate rooting, see: application filtering by carrier).

Blackberry:

Pros: Huge installed base of devices. Market leader in penetration inside of enterprises. Secure. Dozens of software simulators available for testing.

Cons: Worst SDK of any smartphone OS. SDK runs only on Windows (technology release now available for Mac OS X, but no simulators and it works only for directly attached OS 6 devices, which is one: the 9800 Torch). No UI tools, periodWorst developer community of any smartphone OS (no disrespect to the many fine BB developers I have met the past couple of years. But in the main, most of these guys – and they are guys – are usually company drones that I for the life of me can’t seem to find any actual apps that they have written. Prolly cause there’s only 9,000 apps in Blackberry App World, and unless you have a Blackberry Phone with a data plan, you’d never see ‘em anyway). Multiple OSes, hardware form factors make unit and system testing impractical for rapid releases. Browser – with the exception of the latest OS 6 release – is the absolute worst of any smartphone. Research in Motion also doesn’t seem to really care about software, except for only the sense that it is needed to operate the hardware. They’re a hardware company first and foremost, and it shows in spades.

Your mileage may vary.

But since the majority of application release scenarios we see play out in the marketplace are iPhone First, Android Second, Blackberry when we get around to it, I don’t think my take differs from those actually doing cross platform development, rather than those opining about it.

Nobody likes to have their baby called ugly.

But when it is, it is.

Tagged , , , ,

Android Market Filtering and AndroidManifest.xml

If you have an application in Android Market that is visible to some users, but not others, chances are there is some filtering going on by virtue of some statement you have in your Application Manifest file, AndroidManifest.xml.

Usually, this filtering occurs through a major setting: operating system version, whether the device has a camera or a GPS, etc.

Sometimes, however, it is the little things that get you in hot water.

Take for example the following manifest statements:

<uses-permission android:name=”android.permission.CAMERA” />

<uses-feature android:name=”android.hardware.camera” />

<uses-feature android:name=”android.hardware.camera.autofocus”/>

As constructed, these statements will hide the corresponding app from any phone that does not have a camera AND does not have autofocus capability (not simply that your app can use autofocus).

Likewise, if you have the following:

<uses-permission android:name=”android.permission.CAMERA” />

The implication is that your app uses the camera and ALL features available to a camera (autofocus and flash) – and if the phone is missing a flash OR autofocus, the app will be invisible to Android Market. Double-plus un-good.

The magic secret sauce to requiring a camera, but not requiring that the camera have flash or autofocus, is the following set of manifest statements:

<uses-permission android:name=”android.permission.CAMERA” />

<uses-feature android:name=”android.hardware.camera” />

It is frustrating that something so subtle can severely hinder your ability to market your application, or even allow your customers to even see your application.

Madness, really.

Tagged , , , , , ,

Testing for 4G Networks in Android

In order to test for the presence / absence of WiMax (4G) you need to do something like the following:


private boolean isNetworkAvailable() {
ConnectivityManager connec = (ConnectivityManager)getSystemService(Context.CONNECTIVITY_SERVICE);
NetworkInfo mobileInfo = connec.getNetworkInfo(0);
NetworkInfo wifiInfo = connec.getNetworkInfo(1);
NetworkInfo wimaxInfo = connec.getNetworkInfo(6);

if (wimaxInfo!=null) {
return mobileInfo.isConnectedOrConnecting() || wifiInfo.isConnectedOrConnecting() || wimaxInfo.isConnectedOrConnecting();
}
else {
return mobileInfo.isConnectedOrConnecting() || wifiInfo.isConnectedOrConnecting();
}
}

A little hard won knowledge from the trenches.

Tagged , , , ,

Google and Android Market – Really?

I would love to search for apps on Android Market. But I can only do so from Android Market on a mobile device – not from a laptop or desktop.

Really, Google?

I would love to provide a link to my Android apps on Android Market. But, again, I can only do so from an Android Phone but not a laptop or desktop.

Really, Google?

For a company that is predicated on Search and Links, the current state of Android Market is pretty damned lame.

In so many ways, Google has a more compelling story to tell than Apple and iPhone.

If only they could finish the unfinished bits of the ecosystem.

Like the parts that enable your apps to be discovered, and downloaded.

Stupid.

Tagged , ,

Monday Morning Quarterbacking

I spent a great deal of time with Android over the weekend – more than anyone ever should over a long, hot, holiday weekend.

By and large, working with Android is a not unpleasant experience.

It just isn’t all that great either, in some very important aspects: screen design, camera operations, and available memory.

All Android apps are constrained to a 16MB heap space for memory. This may seem like a lot, but once an app gets up and running, this memory gets fragmented – fast – so that you dont have large available chunks of contiguous memory just laying around for allocation. Throw in a few moderately sized bitmaps, and hello Mr. OutOfMemoryException. All the bitmap recycling and garbage collection in the world can’t always keep an image bound app and on its feet without its share of crashes owing to not enough memory available from the VM to load new images. In fact, the only way to have a moderately stable image intensive app is to be diligent, garbage collect liberally, and don’t be sentimental about hanging onto anything too long in memory.

The horrible state of screen / UI design tools for Android is an embarrassment. This is not particularly surprising coming from a company slanted toward engineers. I have come to love Apple’s Interface Builder all the more because of the shit you have to put up with on Android and Blackberry. Let me just say that designing screens using an XML text editor blows more than Whale. It blows Blue Whale.

Finally, one of my more vehement dislikes about Android, is the non-consistency across handsets in how images are returned back to applications from the Camera. For iPhone developers used to the very powerful UIImagePicker interface, the operation of the Android Camera Intent is a cold splash of “what the eff is this?”

Really, gentle reader, I don’t want to bore you with all the gory details about camera handling. I’ll simply point you to one of the (sadly) more widely read threads on the topic (http://code.google.com/p/android/issues/detail?id=1480, a classic) and let all the other tortured souls in Android Camera Purgatory speak for themselves.

Given all of the preceding, there is still much to be admired about Android. The fact that new releases can be put into the wild as fast as my fat little fingers can bang out and QA code, rather than the Apple “submit and pray” model, is more than a little awesome. It’s very awesome.

The metrics I get back concerning who has bought (or bought and unbought) compared to what I get from Apple’s Financial Reports is also a great plus for the platform. I’m never really sure with Apple what these numbers represent in terms of actual activity, whereas with Google Checkout I get a scary amount of transaction activity information.

I’ve said this more than a few times: I’m a platform agnostic. I live by a very hedonistic calculus with regard to where I spend my time developing mobile applications – if the platform pays, I play.

Being an aesthete about one platform or another when all I really want to do is pay my kid’s tuition and hopefully my mortgage is a total waste of time.

But it doesn’t mean that one can’t have strong likes and dislikes about the environments you’re working on. And then spending a good chunk of a Monday morning bitching about it.

There. That’s better.

Tagged , ,
Follow

Get every new post delivered to your Inbox.

Join 6,735 other followers