Two Thoughts On Today's Adobe MAX (2011) Day One Keynote

I'm not going to try and summarize the keynote:  you can either watch the replay at http://www.max.adobe.com/online/ or read a brief synopsis at http://max.adobe.com/news/2011/keynote_day1.html.

My first thought is actually about some news that wasn't part of the keynote, but was announced on the Internet during the keynote:  Adobe's acquisition of PhoneGap.  PhoneGap is an application framework that allows developers to build mobile apps using web technologies (HTML, CSS, and Javascript) and the PhoneGap API (to access particular device functions like geolocation, the camera, internal storage, etc) and then package and deploy those apps such that they work on most mobile operating systems (Android, IOS, Blackberry, and a few others).

What struck me about that news was that it means Adobe now provides two ways for app developers to develop cross-platform apps.  If a developer is already familiar with Flash and Flex development, they can build mobile apps using Flash Builder and Adobe AIR.  If the developer is more skilled with web design and programming, they can build apps using PhoneGap.  In both cases, the end result is an app that runs natively on your device of choice (IOS, Android, whatever).

First of all, it's yet another example of Adobe's willingness to support both Flash and HTML5 as development platforms going forward.  A number of tech analysts contend that Adobe's development of new tools that play nice with HTML5 is a capitulation of some kind to the way the industry is moving.  I don't see it that way: Adobe may be synonymous with Flash, but it's never been all about Flash with them.  They have always supplied the tools that the digital and web creation markets have demanded, just as any sane company would, regardless of what their internal preferences might be.

The other thing about the PhoneGap acquisition is that it will expand the number of developers using Adobe tools and technologies to create mobile apps for both Android and IOS.  And now suddenly Adobe potentially a big player in the smartphone and tablet space, not by release their own mobile OS or mobile hardware, but by providing the tools to any developer who wants to write on any and all of these platforms.  To be clear, at the moment there are certain kinds of apps or app functions that a developer would want or need to develop in native OS code, but as the Adobe tools provide ways to overcome those limitations (such as the ability to include native code extensions in Flash/AIR apps), the number of reasons for writing an app in native OS code (and hence writing a second version for deployment on another platform) are going to become fewer and fewer.

My second observation regarding the keynote concerns the suite of touch-optimized mobile apps - the Adobe Touch Apps - coming in November to Android devices and later to IOS devices.  While some of the apps are geared more towards visual designers, the Proto wireframing app is something I could use in the design phase of my web and mobile application work, and, well, who wouldn't want a touch-optimized version of Photoshop to use to mess around with their photos?

And that's when the thought occurred to me:  here were some apps that I could use to be productive with a tablet.  I'm an application developer who writes code.  I have access to two tablets and I don't use either of them to write code or generate digital content of any kind.  For me, tablets have always been digital consumption devices (something Amazon seems to recognize with their new Kindle Fire tablet) for viewing video, looking at pictures, or reading web pages or books, and kinda superfluous given I can do all that and much more with a laptop (to be clear, I do love my Nook Color as an e-reader, but I rarely use it to surf the web or anything else).

But the apps Adobe showed off today made me feel like I would in fact want to use them on a tablet, because they were designed specifically with tablets and touch-interaction in mind, not as desktop apps shrunk into a mobile form factor.  That to me is a step in the right direction, and it's apps like those that are going to grow the tablet market by making the tablet experience more compelling.

An Overview of buzztouch, A Mobile App CMS for Non-Programmers

The other day I stumbled on a Make Use Of article about buzztouch, a "iPhone, iPad, Android app builder and content management system."  Since we're researching options for creating cross-platform mobile applications, and the article indictated that it was worth checking out, I decided to sign up and give buzztouch a spin.

buzztouch is designed to let non-programmers build a mobile app on the buzztouch website using a collection of web-based forms.  The app-building interface prompts you to create certain items, like a launcher icon for the app, a banner image for the home screen, and an "info" page for the app, but you choose what other content you wish to provide from a drop-down list of different components.  One component lets you create a screen of formatted text using CKEditor, while another lets you create an app screen using HTML, CSS, and Javascript.  There are components for pulling in remote content such as web pages, YouTube pages, streaming audio and video files, and RSS feeds.  One component lets you pinpoint one or more locations on a Google Map with brief location information that a user of the app can then use to get driving directions to those locations from their current position.  Even though I was casually playing with the system, I was able to create an app using several of these components in under two hours.

Once you've created the app, you can then download the native source code for the app:  you're provided with separated source code downloads for IOS and for Android.  The source code comes in a .zip file, which also contains a readme file with instructions on how to compile the source code for that particular platform and create the native app.  It only took me a few minutes to create an Android app from the source code, and it only took me that long because I had to provide a Google Maps API key to enable the mapping component I'd added (the readme provided exact instructions on the changes I need to make it the code to use the key).  I had my IOS developer colleague compile the IOS version of the app, and it was also smooth sailing for him.  The resulting app on the Android platform looked a little rough simply because of the generic design elements, but the IOS version looked pitch-perfect.

The first time you access any component or screen in the mobile app, there is a pause as the app retrieves the content or content instructions from buzztouch then caches it for local use.  This is where the content management system aspect of buzztouch kicks in:  any changes you make to the app on the buzztouch site get pushed to (or pulled by, not sure which) the mobile app.  So the app owner doesn't need to recompile and update the app through the App Store or the Android Market in order to make content changes.  If the mobile device doesn't have a network connection, then the cached content is used.

So what's my overall take on buzztouch?  I think that if you need to build a mostly informational mobile app, something that serves the same purpose as a mobile-optimized website, then buzztouch is a compelling option because of how easy it is to create the app and then update the content.  Even if your long-term strategy is to redesign an existing "desktop"-optimized website to be mobile-friendly as well, a buzztouch app could fill the void until that goal was reached.

If you need to build a mobile app that's more interactive, one where the user can send and receive custom data, then buzztouch is at best an incomplete solution.  There are no buzztouch components for collecting data (though the app itself will capture GPS info from the device in order to map where the app has been used, which is both useful and slightly disturbing), but you could probably use the Custom HTML component to create a web form that transmitted data via a regular form submit or via AJAX.  And there are as yet no components that let you access device-specific functions like the camera or accelerometer.

On the other hand, if you are capable of doing some IOS or Android coding, the native code provided by buzztouch could serve as a starting point for adding additional functionality:  the buzztouch folks seem to be open to folks using the generated code to advance their learning of native app programming.

So overall, I'm impressed with what buzztouch has done so far with the direction they've taken, and I hope they continue to improve on the platform.

My First Published Android App: NoteToSelf

I haven't been blogging much lately, but that's partly because I was on vacation for a week and partly because I was working on this:

https://play.google.com/store/apps/details?id=org.swartzfager.NoteToSelf

It's a fairly simple app built with the standard Android API, but it meets MY need for a note/reminder list that is right there on my Android home screen and lets me see all of my reminders without having to go into the application. And being able to dictate my reminder (I put in the dedicated dictation button because my Swype keyboard doesn't have a key for dictation like the stock Android keyboard does) makes it easy to add a quick note if you can tolerate a mistranslation here or there.

This version is free, so if you have an Android device running 2.1 or higher, feel free to check it out.

Android Application Concepts: the Activity

Android applications can be constructed from four different types of components: activities, services, broadcast receivers, and content providers. Of the four, the only one that you must use at least one of in every application (and the only one that I've had to use so far) is the activity.

I'm not going to even try to give a full explanation of what an activity is: the Application Fundamentals page on the Android Developers site provides a thorough (and rather long) explanation of activies as well as the other three components. So I'm just going to list some aspects of activities to give you a conceptual overview of what an activity is:

• Each individual screen within an Android application is an activity, and users can perform actions by interacting with the visual components within an activity. Think of it as an individual web page within a modern web application, where the user can perform certain functions without leaving the page (using JavaScript), but must proceed to a different page in order to access a new set of tasks/functionality.

• Each activity operates independently of one another (again, similar to how individual pages in a web application are separate from one another).

• The visual objects within an activity (blocks of text, input boxes, buttons, etc.) are usually organized and instantiated by implementing instructions within a layout XML file.  They CAN be added individually with regular Java code, but the XML method is the recommended practice.

• The transistion from one activity to another is accomplished through the use of asynchronous messages called Intents. An intent can be used to pass data from one activity to another, and that data is structured using key/value pairs. It's similar to how data is passed when an HTML form is submitted.

• Each activity in an Android application is either a direct subclass of the Activity base class or a subclass of an Activity subclass that provides specialized functionality (such as the ListActivity class which contains methods specifically for the display of data in a touch-enabled list), and is represented in the application package as a single Java class.

• All of the activities in the application must be defined in the application's manifest file, an XML file that keeps track of all of the components, resources, and permissions that make up the application.

• All Android application components, including activities, have lifecycles. The current lifecycle state of a component provides part of the information the Android OS uses when it determines what components can be safely removed from memory in order to free up memory space. All activities inherit a set of lifecycle methods from the Activity base class that are executed when the corresponding lifecyle state of the activity is reached. These lifecycle methods are:

  • onCreate: the code within the onCreate lifecycle method is called when the activity is instantiated/loaded into memory. This is the method in which you want to set up the intial state of your variables, instantiate the visual objects within the activity via your layout file, and bind your event listeners. If you're a jQuery user, think of it as the equivalent of the document.ready function.

  • onStart: the method called when the activity becomes visible to the user.

  • onResume: the method called when the activity is moved to the foreground of the visible space, when the user is able to not only see the activity but interact with it. After the onResume method is called, the activity is considered to be "running."

  • onPause: called when the activity is no longer in the foreground, usually as the result of another activity being started.

  • onStop: called when the activity is no longer visible to the user in either the foreground or background.

  • onRestart: called when the activity is being restarted (made visible again) after executing onStop but not onDestroy.

  • onDestroy: called just before an activity is destroyed/unloaded from memory.

   

• Any activity that isn't currently "running" could potentially be removed from memory by the Android OS if available system memory is low. The more inactive an activity is, the better the chance of it being destroyed to reclaim memory, so an activity that is "stopped" is in more danger of being removed from memory than an activity that is "paused."

• Because even an activity that is "paused" can be destroyed under extremely low memory conditions, it is a best practice to run code to store/save any persistent data within the activity within the onPause method just in case (kind of like how the auto-save function works in Microsoft Office to save your work every few minutes).

• To preserve the current state of an activity (like filtered search results) rather than persistent data, you can use code in the onSaveInstanceState method to perserve that data in a Bundle object (which, like an intent, stores data in key/value pairs).  The onSaveInstanceState method in the activity is called by the Android OS itself as soon as the activity has the potential to be removed from memory. However, onSaveInstanceState is NOT called when the user explicitly takes action to destroy an activity (usually by exiting the entire application).

• It is possible for one "application" to utilize activity objects from one or more different application packages (.apk files), given the proper planning and permissions.

Developing Native Android Applications: Not as Hard As You Might Think

Two months ago, my boss asked me to try and build a native Android application based on the mobile website I had created for the university's annual Maryland Day festival. Both he and I are part of an IT initiative in our department tasked with figuring out how best to provide IT services to smartphone users on campus, and while we have in-house expertise in iPhone development, none of us were familiar with what would be involved in building Android applications. So he asked me to give it a shot.

I started by going to the official Android developer site:  http://developer.android.com/index.html. I downloaded the Android SDK per the site instructions, then downloaded and installed the Eclipse plugins for doing Android development, and the files needed to work with the Android API I was targeting in my application. I went through the "Hello World" tutorial, where I learned the basics of starting an Android project in Eclipse, how to configure a simple layout, and how to run the device emulator. After going through a few more of the layout-oriented tutorials, I realized that I was missing out on a few of the concepts being discussed, so I stopped coding and started reading through the development guide pages on the site, where I learned about the different components you can use in Android applications, what they were used for, and how to use them.

After spending the first few weeks just learning from the documentation and the tutorials, I started to focus more of my attention on how to accomplish the tasks I needed to make my particular application work. The developer site didn't have examples that addressed some of the issues I needed to solve, so I starting searching the web. Sometimes I found exactly the answer I was looking for on an Android development forum. Other times, I was able to cobble together an approach based on answers to similar issues on all-purpose tech forums like StackOverflow. I was always able to find at least a clue, something that would point me to the right package in the API documentation. I also had to stray from the Android developer site anytime I needed to learn more about Java coding itself, as it's kind of assumed that the developer is confortable with Java programming (an incorrect assumption in my case).

By the time I was done, I had created a working Android application that:

• Would check for updated event information at startup by making an HTTP call to an XML page. If the version number on the XML page was higher than the version number stored in the application's database, it would make an HTTP call to a ColdFusion page that output the updated event information as XML, parse the XML with a SAX parser, and update the application's SQLite database with the event data.

• Provided the user with a number of different ways to find events by interest. Each listing (whether it was a list of events, a list of event sponsors, etc.) would be preceded by a search box, and as the user typed in the search box, the list would be filtered on-the-fly based on the search text.

• Gave the user the ability to flag an event as a "favorite" by tapping a toggle button on the event detail page, which would update the event record in the SQLite table and allow them to pull up a list of all of their favorite events.

• Gave the user the option of seeing a satellite map view of where the event was located using the Google Map API, with the event location marked with an particular icon based on what type of an event it was.

• Gave the user the option of seeing a satellite map view that showed the user their current GPS location on campus and where the particular event was located.  The user's position on the map would be updated as the user made their way towards the event location.

Although it worked pretty well, there were a few minor bugs that I couldn't work out before the festival, and we weren't comfortable releasing it to the public having only been able to test it on particular Android phone model (the Motorola Droid), so it wasn't put into production.

Even though I went into the project with an open mind, I really hadn't expected to be able to build such a full-featured application, not as a first Android application and not with being a Java noob to boot. What made it possible was the excellent documentation on the Android developer site, the development tools within Eclipse (the code hinting/code correction, the automated compiler, the debugger perspective, and the device emulator), and the various tidbits of Android development how-tos out on the web. And thougth there were some moments of frustration, I generally enjoyed the experience.

I don't know how much more native Android development I'll be asked to do at my job, but I plan to create some Android apps on my own time now that I know how. And I plan to start blogging about Android development, not as an expert (I have a lot to learn yet) but as someone who's learning as he goes. So you can expect to see more Android and Android development content on my blog from here on out.

New AIR Application: focusTimer

A few weeks ago, Peter Bell wrote a blog post about the Pomodoro Technique, a time management technique that advocates setting aside a set amount of time to turn off all distractions (e-mail, IM, Twitter) and focusing on a single task. I had just recently starting adopting the practice of shutting down my e-mail client once in awhile so as not to be distracted by incoming messages, so the idea made a lot of sense to me.

Not having a physical kitchen timer like the Pomodoro folks use and finding my stopwatch to be somewhat inadequate, I decided to try and write an AIR application to fit my needs. And so the focusTimer was born.

It's a very simple app: set the amount of time you want to focus (the 25 minutes advocated by the Pomodoro folks is the default), and click the "Start" button. I didn't want to get caught up in checking to see how much time was left, so I added a button so I could toggle between seeing the time left and just a status message.

I wanted to keep the window small so that it could be moved out of the way, but I also wanted a strong visual cue for when the time was up, so the color of the window changes to green when you start the countdown, switches to yellow for the "2-minute warning", and ends in red when the timer runs out. In the two days I've been using it at work, I've found that I can move the window to the far end of my secondary monitor and still catch the color change out of the corner of my eye.

Finally, even though the idea is to block out all distractions, there are some interruptions that cannot be ignored, so the "Start" button toggles between a "Pause" button and a "Resume" button once the countdown has started. If your focus session goes completely off the rails, you can use the "Cancel" button to break out of it and start all over again.

Even though I wrote this AIR app primarily for myself, I figured other folks might find it useful, so it's now available for download up on RIAforge: http://focustimer.riaforge.org