May 15

I am spending part of this weekend preparing for a presentation I’m delivering this coming week for the Boston/New England Windows Phone User and Developer Groups. My upcoming presentation software development-focused and, as is usually the case, I will be using demonstrations of programming techniques to enforce the learning. After close to 20 years of developing this type of content for training and presentations in many different programming languages and technologies, I still face the same dilemma regarding the approach I take to the application code I present.

In an ideal world, a teacher strives to make learning content as relevant to the “real world” as possible as a way of reinforcing the the concepts being presented. When learning mathematics, for example, the reinforcement of an equation is often demonstrated by placing it in a real-world scenario (presenting the dimensions of a room and asking for the square and/or cubic feet the room occupies, for example). By putting concepts to use in real world situations more often than not helps in the grasping of the concept and increases comprehension for the learner. In the ideal world, a learning content developer would normally strive to place everything into a real world context. However, the “ideal world” brings with it some distinct challenges and drawbacks.

When developing learning content, the developer is often constrained by any number of factors, including (but not limited to) -

  • Time to deliver the material. We all would love to have unlimited time to learn, but time is simply not that available. As a result, the content creator is often constrained by how much time can be allocated to teach a concept. The more complex the real world example is, the more time it takes to teach.
  • The pre-existing knowledge of the learner. For “advanced” learning content, prerequisite knowledge is usually assumed. As a result, the information used to build the real world scenario is often easily understood by the learner and can be delivered in a shorter timeframe. For “introductory” learning content, however, real world scenarios often will take more time to build than the concept they are trying to teach.
  • Complexity of the real world scenario in relation to the concept being taught. I find this constraint to often be the most dangerous when building learning content for software development as its impact is felt in multiple dimensions (more on this shortly).

As a learning content developer, the challenge becomes finding a successful balance between providing real world applicability without causing a “tipping point” due to constraints that diminishes the overall goal – to teach a concept that is both comprehendible and retainable to the learner.

When developing learning content for software development, the time and knowledge constraints are usually obvious to me and are relatively easy to manage. I know how much time I have to deliver the material, so I therefore control the scope of how much I can teach in the time allotted. I generally know the baseline knowledge of learners receiving the material (at least when I set the goals for learning and prerequisite knowledge; we’ve all had people in a room who don’t meet the prerequisites). The complexity constraint is the one battle for the content developer that is most difficult to manage. The best explanation of this can be made by example.

Suppose I want to teach the concepts of data access to a new programmer. I could simply provide the minimal amount of application code to demonstrate this concept. However, one could argue that I am not being “real world enough”. So, how do I make for a more realistic example? I could (and often do) provide a context for accessing the data. Perhaps a simple application with a user interface that, when the user provides some input or action, retrieves data and displays it. While this may still seem rather simple, the additional number of lines of application code to make this happen can be in the tens (or even hundreds, depending on the programming language). Depending on the example and the pre-existing knowledge of the learner, the complexity of this additional code can become a distracter to the more important concept being taught. I liken it asking someone to extract a single fact out of a chapter in a textbook; while you can eventually find that nugget of information, you also run the risk of being distracted by all the other information that the chapter provides (as an aside, this is why I have never liked any teacher who “teaches from the textbook”).  As an example of how this issue of complexity can apply to teaching programming, consider the following two code examples. Both attempt to teach the concept of retrieving application settings from Isolated Storage in Silverlight for Windows Phone  7 -

Example 1

IsolatedStorageSettings mySettings = 
IsolatedStorageSettings.ApplicationSettings; txtName.Text = (string)mySettings["Name"];

 

Example 2

private void getSettings()
{
    IsolatedStorageSettings mySettings = 
IsolatedStorageSettings.ApplicationSettings; if (mySettings.Contains("Name")) { txtName.Text = (string)mySettings["Name"]; } if (mySettings.Contains("Address")) { txtAddress.Text = (string)mySettings["Address"]; } if (mySettings.Contains("Zip")) { txtZip.Text = (string)mySettings["Zip"]; } }

The first example is quite literally the most basic of programming code demonstrating the steps of getting an instance of of the application’s settings and extracting a single piece of information from those settings. Useful syntax, but not a lot of real world context. The second example does the same, but comes from a very simple application that includes a user interface with three fields. The application logic also does a bit of checking to see if the setting even exists before exacting the setting for each field. Just this little bit of adding real world context has added complexity to the code sample. Note that I could have gone even more “real world” in the coding techniques used for error handling and “best practice” that would would have resulted in more distraction (questions like “why are you using a ‘using’ statement?” or “What is this generic collection syntax really about?”). In even the most simplistic of examples like the ones shown here, it becomes clear that “real world” leads to “complexity” in code, and complexity in code runs the risk of reducing the ability to comprehend and retain the primary learning objective; in this case, how to retrieve a setting from the application’s isolated store. As a content developer, this is an example of having to deal with one type of complexity – code complexity. However, this complexity runs the risk of being made exponentially more difficult to manage if another real world concept is introduced.

I have had both the fortune and misfortune to work on a number of projects over the years that attempt to create a “reference application” for learning. In these situations, the goal is well-intentioned. An application is created that is real world in nature and provides by code example the best practices for achieving the required business goals of the application. I have always liked the idea of a reference application, but only when used in a proper context for learning. Unfortunately, reference applications are misused.

In almost all of the cases where I have been involved in developing a reference application, a design goal is being able to repurpose the application code to teach every learning concept, regardless of context of the learning objective or knowledge of the learner. Translation – make the reference application code apply even to introductory learning objectives. This goal invariably fails miserably for introductory training for two reasons. The first reason is one I have already introduced in terms of code complexity. When a code sample from a reference application is used to teach a basic concept, there is typically an incredible amount of “distracting” code associated with it. As a result, the learner is either trying to wade through a lot of potentially unfamiliar application code to find the relevant learning material, or is being confused by code that they have yet to learn about. Even if an instructor or material can help to point the learner in the right direction, the collateral code can often lead to confusion or a desire to understand that which is not intended to be learned about at the moment. As an instructor, I cannot tell you how many times I have had students “wander from the path” when it comes to these situations, resulting in difficulty in learning the current learning objective and spending value time discussing/covering information not intending to be covered. If this level of complexity is not difficult enough to overcome, reference applications usually introduce a higher level of distraction for learning – the business process learning complexity.

Imagine that I were to hand to you a text book written in your native language. This book covered a business concept of which you had no prior knowledge or exposure (for arguments sake, let’s say quantum physics). Within this book lies a specific bit of knowledge I want you to learn. While you can read the words in the book, many of those words, sentences and paragraphs will relate to concepts totally foreign to you, and will require you to learn them in order to learn the true objective. In other words, I need you to learn about other secondary knowledge prior to learning the primary objective. This is the additional complexity that using a reference application often adds to learning about programming.

Because reference applications are designed to present application code in a real world context, they are fundamentally designed to solve a business (not technical) problem. They often take the form of solutions around order entry systems or customer relationship management. When I have been asked to teach from a reference application, many of the learners in my audience usually have no business experience in these areas. Even if I am teaching experienced application developers, I often find myself explaining the business rationale that makes up the code rather than the primary learning objective. For example, I cannot recall how many times I have found myself explaining in a programming class why an order entry system does not actually delete cancelled orders, instead marking them as “deleted” in a field in a record. This discussion did not come about because I was teaching order entry concepts; it occurred when I was teaching how to update a record in a database (the primary learning objective). Business learning, therefore, becomes a distracter to the true learning objective.

Reference applications do have a place in the bigger picture of education for application programmers. However, it is in the context of the first word of their definition – reference. I find reference applications to be most useful in the same way as other reference materials; when they are used after primary learning is achieved and the learner wants to learn more. Most importantly, reference applications are most useful when the learner is not constrained by time or business complexities that exist in a classroom or introductory learning. Reference applications are most useful in advanced and self-paced learning scenarios.

If you’ve managed to get this far in your reading, you’re likely wondering what the proverbial “moral to the story” is here. As I mentioned at the onset, I am once again tasked with the development of learning content for software developers. Over twenty years of developing and delivering content of this type, for structured multi-day classroom learning to 90-minute presentations, has taught me a very valuable lesson – there is a difference when presenting application code for learning purposes in comparison to developing actual applications. When I “code to teach”, I have one goal in mind – to present the code in a way that makes my audience understand and retain a learning objective. Anything that distracts from this objective does nothing to serve the audience. While getting more “real world” might help in achieving a learning objective, it can hurt it as well. It is also often very easy for the content creator to leverage existing application code to teach, be it from a formal reference application or even code “just lying around”. When you use code of this type, however, you should carefully consider the implications. Put yourself in the shoes of your intended audience and ask -

  • “What am I trying to learn here?”
  • “When I look at this code, do I see what it is I am trying to learn?”
  • “How much help do I need to find the relevant code?”
  • “Does looking at the code make me think of questions not related to what I am trying to learn?”

Only by finding a balance between learning objectives and the real world they reflect will your code help your audience to become good programmers.

Mar 12

Last week, I wrote a bit about how HMTL 5.0 holds some promise for some mobile application developers. A critical part of the HTML 5.0 specification relates to it’s ability to work offline when an Internet connection isn’t available. Recently, I’m seeing more and more marketing aimed at cloud computing. When combined with 3G and 4G networks, it appears that the message often being portrayed is that new technologies have become a sort of “magic bullet” for all mobile applications. With that in mind, I felt a little “refresher” on the foundation of many mobile applications is in order.

I remember attending a keynote speech at a Pocket PC Summit event in Philadelphia (which should date how long ago it was; I can’t even remember the year off the top of my head) given by John Landry, whose focus at the time was on Adesso Systems, a company who (again at the time) had a multi-device development platform that was ahead of its time. Mr. Landry talked about mobile devices and application development in his keynote, and talked about what he considered an oxymoron - “ubiquitous wireless access”. The point made in the keynote was that no such thing exists. No one can guarantee with 100% certainty that, when you need it, you will have access to the Internet from any computing device. That oxymoron, along with a term Landry used to describe a paradigm for building applications that can meet user needs while withstanding a lack of network connectivity - “Occasionally-Connected Computing” – have stuck with me ever since.

Let’s turn to the present day. We’ve seen great advances in technology with regards to networking. When John Landry gave his keynote, GPRS speeds of 40-50 kbps were considered “fast”. You were lucky to have a cellular data connection at all when you were indoors, and even being outdoors was a bit dicey. Today, we have multi-megabit transmissions speeds and far greater coverage, but ask yourself a simple question – can you remember a recent time when you either couldn’t place a phone call or connect to the Internet on your device when you wanted to? For most people, they will likely answer with the date, time and specific problem ;-) My point here – things are better but not perfect when it comes to wireless data networks. It is this fact that still makes the premise of occasionally connected computing as relevant today as it was almost a decade ago.

When developing mobile applications, the common goal is to allow users to complete a task or tasks in an effective manner. This basic principle of course applies to software in general. When network access plays a part in completing the task, the goal has to account in some way for what happens when that access is not available. This has been the primary constraining factor for most mission-critical mobile web applications; no network access means no application access. HTML 5.0’s inclusion of offline data storage of potentially large and complex data makes mobile web-based applications a far more viable option. Aside from that fact, though, the more important application principle is designing an occasionally-connected application for mobile devices that is data-dependent requires the ability to efficiently store essential data on the device for non-connected periods, allowing the user to still perform some aspect of the task at hand until the network is again available.

How much work is required to design and develop a good occasionally-connected application is of course contingent specific requirements. A sales force automation application may, for example, require the offline storage of data in order to meet business requirements than a simple contact application. Nonetheless, there is usually the need at either a business or user expectation level that some form of functionality be present in order to at least partially complete the task when offline. In the sales force automation example, it may include the ability to look up customer and product information, and to place an order on the device that is transmitted to the home office once connectivity is attained. For my many years in developing mobile applications for both the desktop (laptop/notebook) and phones, these types of requirements are the norm (if not always the case). New technologies, including faster and better cellular networks and cloud computing have not changes this need one bit.

I guess that the moral of this story that I am trying to convey here is that while advances in technology are opening up a world of new possibilities for mobile applications, fundamental principles still apply. When messages such as “cloud computing is the answer” and “access everywhere” are spreading like wildfire, it’s important to keep them in context. I really believe that cloud computing and better cellular networks are incredible enablers; they are, more often than not, a partial solution to mobile application needs and not the solution itself. When deciding upon the development  platforms and technologies for mobile solutions, the true needs of the application must be factored in. If the solution requires resilience to the still-prevalent issue of occasional connectivity, an extra look at how those platforms can meet your requirements is essential. The answer “just store it in the cloud” is not the answer. The answer “you’ll always have access to the Internet” is not the answer. The answer “I need to consider how my application will function until i have access to the cloud” is the answer (or at least the starting point). The principles behind occasionally-connected computing complete the answer.    

Mar 05

Microsoft’s recent announcements around Windows Phone 7 Series and first details regarding application development for the platform have made me take pause to think about those of us out in the world of mobile device application development. More specifically, I’ve been thinking about things from the perspective of a developer who supports mobile device platforms in general, not just one in particular. I know I am anything but alone in this situation. An increasing number of independent developers and commercial development companies are in this situation. Additionally, the number of enterprises supporting Line of Business applications to an increasing variety of users and phones fall into this same group. For everyone involved, the dizzying array of hardware types, operating systems, development platforms and programming languages are a challenge, to say the least. That is why I am becoming increasing convinced that for many, the only real hope in being able to support all mobile device platforms is HTML 5.0.

In order to understand the true scope of the current dilemma for so many people, you simply have to break down the potential target phones from a development perspective. You get something like this…

  • Windows Phone – Currently, you have native development with C++ or managed development with the .NET Compact Framework. Moving forward, you will have Silverlight or XNA. The development platform – Visual Studio (running on the Windows operating system).
  • iPhone – Objective-C is the language, with XCode as the development platform (running on the Apple OSX operating system).
  • RIM – A device-specific subset of the Java language, with different development platform options.
  • Android – A device-specific subset of the Java language, with different development platform options.
  • WebOS – A device-specific subset of HTML standards, with different development platform options.

OK – so what does this mean for a developer trying to build a single application that supports multiple phones using native development tools? Well, for starters…

  • From a development computer, the best-case scenario requires an OSX-based desktop or notebook (think iMac or MacBook) with both the OSX and Windows operating systems installed. I have set up such a computer in the past, and it’s not very pretty (or inexpensive).
  • Again from a best-case perspective, I need to know at least the fundamental aspects of -
    • .NET (then the derivatives for the Compact Framework, Silverlight and XNA)
    • Objective-C (C or C++ for starters, but a whole lot of differences)
    • Java (then the SDK-specific derivatives for each device)
    • HTML (and then the specifics for WebOS)

Folks – that’s one specific computer and FOUR programming languages (with a lot of additional knowledge on top of the language basics) just to get my single application to all the major phone platforms. And remember – these are “best-case” scenarios. I didn’t include those applications that are very hardware-dependent (physical buttons versus  touch screens, screen resolution, etc) or graphics-intensive (using GDI versus OpenGLES versus native, etc). Of course, I left out the biggest challenge of them all regarding development – having to re-create one application many times. Even under the best of circumstances (an application where the bulk of application logic resides in a centralized location accessible via the Internet), there is all the work on the client/device of the application to perform. Even under the best of circumstances (Java to Java, for example), there is still lots of platform-specific work to do).  

With all these challenges in mind, what’s a developer to do? Well, there are several options -

  1. Pick your platform(s) is stick to it/them. For many independent developers, this is the only viable alternative. The time and effort for a single person to develop one application for multiple devices without a guarantee of return on investment makes for a simple decision – choose the platform or platforms I can reasonably manage from a time and cost perspective. For larger development groups, there is still the challenges of identifying and allocating the proper resources (developers) to the development efforts, never mind the challenges of keeping everything in sync to assure that work on Platform X doesn’t break or supersede Platform Y. For enterprises, there’s the cost of development, hiring and training the resources required. 
  2. Leverage multi-platform development platforms. This is primarily an enterprise-focused option that is becoming more popular. There are solutions that allow you to ‘write once, deploy everywhere” when it comes to phones. However, these platforms often come with new challenges. In addition to the sheer cost of such solutions (limiting their consideration to larger enterprises with IT budgets capable of purchase), there are infrastructure and capabilities (think “Jack of all trades, master of none” when it comes to these platforms when compared to native development) to consider.
  3. Develop mobile web application development. As any developer knows, the current state of mobile web application development comes with a number of limitations. First and foremost is the issue of being offline from the Internet and the “red flag” this poses for many applications. Despite all the marketing hype, guaranteed mobile device access to the Internet is still a myth (just think about all the times you’ve had dropped calls on your cell phone). Heck – guaranteed wired Internet access is a myth; just think about your home computer and your ISP. Many application rely on being able to work when no Internet connection exists. These applications not only need to function from a user interface perspective; they also need to be able to safely store enough of a cache of data locally when the the connection is lost to be able to allow the user to perform their work. For the most part, most mobile phones do not implement the capabilities within their respective web browsers to make this a reality.
    The current state of mobile device web browsers also makes for a present-day situation I like to refer to as the “Microsoft/Netscape Syndrome”. Anyone who has been developing web applications can remember the days when the differences between the two most popular web browsers at the time (Internet Explorer 3.x and Netscape Navigator 3.x) were so different in what HTML standards they supported that as a developer you were required to essentially build two versions of a web application if you wanted the widest usage. NOTE:  Yes, I acknowledge that this is STILL going on today in the desktop browser world – I just like to refer to the first time that this became an issue that truly affected the development world in a broader scale ;-) Today’s mobile web browsers mostly suffer this same fate. Their capabilities vary by platform, making even the simplest of application development tasks difficult and requiring a lot of conditional coding and rendering logic based upon browser detection (the term “browser sniffing” is has relevance more than a decade after it’s creation).

Now after saying all of this (including the current challenges around mobile web development), you may be wondering why I think that yet another HTML specification may provide some relief for multi-platform mobile device developers. Well, there are a couple of things around HTML 5.0 that can address these issues -

  1. Reducing fragmentation that has occurred in the years since HTML 4.0 was ratified. A lot of time has past in the years since HTML 4.0. During this time, a lot has changed with regards to the Internet and how we use web applications. We’ve seen fragmentation in addressing these issues as a result. Don’t get me wrong here; I’m not saying that HTML 5.0 will solve all the issues. However, we are already seeing some vendors in the mobile space betting in some way, shape or form on HTML 5.0 and moving away from their own individualized solutions to problems, instead building in HTML 5.0 support in their own mobile web browsers. Heck – Palm has practically bet everything on HTML 5.0 with development for WebOS. As I mentioned earlier, WebOS application development is grounded in HTML standards – HTML, JavaScript, CSS, etc. If that makes you wonder how you could possibly develop applications that work offline, then you need to consider…
  2. The HTML 5.0 Database specification. I will leave the details to this specification to the W3C. However, if you care to look at the HTML 5.0 specification, you will find a great deal of changes dealing with application caches, application sandboxing and databases. All of these changes account for offline HTML applications as well as traditional online access. In essence, the W3C is, with the HTML 5.0 specification, finally officially addressing the use of native HTML as an application language, rather than simply a connected web application language.
    Palm is not alone in moving toward HTML 5.0 for mobile technology. Google (via Android’s browser) and Apple (starting with the iPhone 3.0 and Safari) have started implementing HTML 5.0 standards. One example is with the HTML 5.0 support for location. If you’d like to see this in action and have either an Android or iPhone handy, check out Microsoft Device Application Development MVP Richard Jones’ example (complete with source listing). Bottom line – if the HTML 5.0 as currently written is ratified and if the mobile device platform players implement the standard, it will be much more possible to develop cross-platform applications that meet offline requirements than ever before. While I am certain there will always be platform-specific APIs (likely exposed via JavaScript) to deal with, I think that learning one base language and device-specific extensions is certainly more manageable than four languages that exist today.

Of course, HTML 5.0 cannot solve all multi-platform development problems. There will almost always be application scenarios that require using a development model and language that is “closer” to the device. Gaming applications, for example, commonly require complex graphics processing. While HTML 5.0 is making strides even in this arena, it is likely that it will not supplant the need for more native development solutions that are optimized for and tailored to a specific device. For many other applications, however, HTML 5.0 provides the potential to enable development of applications that can meet the challenges of modern mobile applications, and all under a single development language umbrella.

I applaud those device and mobile operating system manufacturers that are embracing HTML 5.0 as “early adopters”. To those that are not, I strongly urge them to consider not embracing this standard might mean. Early on, I mentioned the “pick your platforms approach”. If HTML 5.0 is adopted by everyone but you, it is more likely that you will be the “odd man out” for a potential audience of thousands of developers. Here’s to hoping that is not the case for any one manufacturer. Here’s also to looking forward to HTML 5.0 final ratification. And finally – here’s to hoping that HTML 5.0 really can live up to addressing one of the greatest challenges posed to mobile device developers today.