Some of our apps at Mobio are written in Java however. We needed a way to allow those apps to use the ads module as well. So we needed to create a REST interface to the Ads module. However the ads service goes further and allows developers and administrators to manage their list of configured ad networks as well as their apps and pages within their apps. Specifically it lets the appropriate ad network and keywords to be used for any app, or specific page within the app, to be configured. Then developers simply call get_ad and identify the app and/or page that they are calling get_ad from. The service then determines the appropriate ad network to connect to.

Administrator Usage

The administrator (or developer) that wants to set up the ads service for an app has two primary tasks: set up the ad network and then configure apps and/or pages to work with those ad networks. First they will need to connect to the ads service from their browser. The ads service currently hosted at http://marge.qa.mobiolabs.com/hub/ads/pages/

Setting Up Ad Networks

After clicking on Manage Networks the administrator should add networks for the mobile advertising networks they wish to use. Their are currently four types supported: Google (AdSense), mKhoj, Smaato and AdMobs. More advertising networks will be added soon.

First enter an arbitrary name for your network that is unique to you. Then choose the type of network (from those just discussed). Then enter the URL to connect to. Some networks may not use this argument, they may just always be available at the same URL. So this is optional for example with Google AdSense.

Then enter the login (client or publisher ID) for your network. Many ad networks (such as Google AdSense) don’t require a password.

Configuring Apps and Pages

The developer will call the ad retrieval method from their app, typically supplying the call with their app name and the page within their app. If it is planned to use a single ad network AND keywords for retrieval for the entire application, then only apps need to be configured.

In either case, first click on Manage Apps and add the name of your application. Then choose a network for it (generally the one you entered above). If you choose a network that isn’t “yours” (your login ID) you’ll just end up making money for someone else! (hence the lack of “security” for this choice).

If you wish some or all pages of your application to use a different ad network and/or keywords than the one configured for the overall app, then enter some pages as well. Supply the URLs of the page in the “page” argument. Or just supply a symbolic name for the page, such as “Home Page” or “Options Page”. The “page” name will only be used to look up pages when the developer makes the get_ad call.

Developer Usage

Once networks and apps and pages have been configured the ads service can be used from your applications. Simply make a call to the get_ad method on the pages controller. Supply arguments of the “app” and/or the “page” within your application. These should match values that have been configured in the previous steps.

Specifically the call looks like this

 http://marge.qa.mobiolabs.com/hub/ads/pages/get_ad?app=<your appname>&page=<some page identifier>

If the ads service can’t find the page supplied then it will drop back and use the ad network and keywords set up for the app. The page argument does not even need to be supplied if you are using the same network and keywords for all pages in your app. The app argument also doesn’t need to be supplied if you’re just going to use pages for lookups. In other words it can be as “simple as you want it to be”, though many developers find having a hierarchy of pages with specific ad networks and keywords and overall apps when pages can’t be found to be a helpful set of abstractions.

To make this even more concrete, here’s a more specific sample call:

 http://marge.qa.mobiolabs.com/hub/ads/pages/get_ad?app=<your appname>&page=<some page identifier>

Terms of Service

This is a developer testing instance of the ads service. We do keep it running. But we don’t guarantee any terms of service for it. Also note that its not “multitenant”. The assumption is that any developer using it will create their own app. The only thing that will happen by using someone else’s configured app in your code is that you will end up crediting their publisher ID and giving them money. So if you do choose to use this for development and experimental purposes you’ll want to set up your own app. If you want to use this in a production app, contact me and we can arrange for use of one of our production instances.

In general we will be making all of our platform available for other mobile app developers soon. So access to a production ready ads service will just be a natural outgrowth of that.

The code inside the module to allow this is

if MOBIO_CONFIG['ad_network']
  adlib="rmobio/ads/" + MOBIO_CONFIG['ad_network']
else
  adlib='rmobio/ads/' + 'no_network'
end
require adlib
eval("include " + adlib.camelize)

What this does is build up the specific class for the ad_network that is configured in the generic RMobio configuration file (RMobio.yml). If no ad network is configured, we still want to have calls to getAd and getAdByPage not fail. So there is a module called no_network.rb with those calls stubbed out.

We then do the require of whatever ad library is chosen. Finally we generate the code dynamically (using “eval”) to do the include of the module name (using the handy camelize function to get the module name from the filename). This generic technique of dynamically determining the right module to include can make your code a briefer and terser. We use it in the RMobio gem and I’m hoping it catches on wider in the Ruby community.

The first one that I’d like to discuss is the “ads module”. This lets you easily add mobile advertising to your Rails apps without being familiar with the syntax for the API of each particular ad network. The networks that we support include: Google’s Mobile AdSense, AdMobs, mKhoj (an India-based mobile advertising network) and Smaato (an ad aggregator which serves up mobile ads from many other ad networks).

You will need to work with one or more of these ad networks to get a “publisher ID” before using our ads module in your Rails apps. But you will not need to learn any of their APIs. You’ll simply embed calls to either “getAd” (which takes a keywords argument) or “getAdByPage” (which assumes that the ad network “scrapes” your page to determine appropriate content) in your controller methods. Then just use the @ad variable inside your views. The specific ad network used is configured by setting the ad_network: variable in the rmobio.yml file used to configure all rmobio gem capabilities (the specific instructions appear below).

This whole approach makes it very easy to both start monetizing your applications with ad networks and also switch it easily later without making code changes.

Steps to Add Advertising to Your Apps

Follow the specific steps below to add the ads module to your apps:

1. In environment.rb, add the following two lines to the bottom of the file (we want to load the configuration statically):

   require 'rmobio/config_manager'
   

2. Edit the file rmobio.yml in the config directory (creating it if necessary) and add the ad_network property in the appropriate section (development:, test:, or production:). For example the following sets the ad_network to ad_sense in the development: instance.

   (in file config/rmobio.yml)
   development:
     ad_network: ad_sense
     ad_client: pub-0061196910475770  # use your own publisher ID here or the money will go to us!
   

   Valid values are: ad_sense, ad_mobs,m_khoj, and smaato.

3. Embed the ad module in your controller. Specifically add “require mobio/ads” to the inside of your controller. Note that your ads module does some “tricks” to not have you have to do the “include” as well. We’ll describe this technique for making “requires” and “includes” DRYer in a later post. For now here’s an example of how to use it:

   class HomeScreenController <ApplicationController
     require 'rmobio/ads'  # note no need for include here
   

4. Call ad retrieval functions from your controller methods. The function “getAd(keywords,adClient)” takes a set of keywords separated by spaces. It also takes your publisher ID. For example the call below will invoke Google’s Mobile AdSense (if the ad_network is set to that value in rmobio.yml) for ads related to the keywords “India” and “cricket”. You can also call “getAdByPage(adClient)”

      def index
        getAd("India cricket",MOBIO_CONFIG['ad_client'])
      end
   

5. Use the ad variable in your view. The getAd method populates an instance variable called @ad. You can that use that variable in your view. For example:

       <h3>Your cool content
   
     ... the rest of the page...
     <%if @ad%>
     <%=@ad%>
     <%end%>
   

There are a few significant differences:

1) nothing concrete is available today but the XML schema for controls and elements.

That’s not a bad thing. I applaud Yahoo for publishing their roadmap in advance.

2) in “phase 1″ of the Blueprint platform, no Model-View-Controller capabilities of XForms are present

This is a bit surprising. MVC is the source of much of XForms’ power. Clearly its coming eventually. But many developers may decide that the learning curve of another syntax is not worthwhile before they see the key benefits of the XForms approach.

3) the documentation says that XPath is not available now for data binding

Confusingly they say “the current Blueprint implementation, however, has a limitation of one model and one instance per page, so there is no need to include such details”. Even with one model, I still want to be able to use XPath to perform data binding. In other words, XPath is not only useful in a case of more complex MVC separation, where a view or controller may use multiple models. Its also useful to grab data from more complex single models, especially where the model (data) may be coming from an existing web service with a nontrivial mapping to your view.

4) unnecessary deviation from the XForms standard

Where XForms has a working syntax for controls or containers, we use it. We add plenty of proprietary controls and extensions as we need to.

5) the current set of controls is fairly simplistic.

As they put it “there are no spinning image cubes”. Well and good. They are phasing things right. We couldn’t use Blueprint today though to give the look and feel of the applications that we’ve built.

Overall I think Blueprint is a great thing for both the industry and for Yahoo. If I was a mobile developer without benefit of the Mobio platform, I would certainly start using the Yahoo platform over, for example, using a procedural Java-oriented, statically compiled approach like Android.

In the bigger picture, the tag-based approach that our platform would be a better way to do this. We could just send out tags and a “forms runner” running on Android could spew out the appropriate Android widgets dynamically. This has the obvious advantage of allowing a single codebase for multiple platforms. But, more fundamentally, it allows for a more dynamically changing user interface on the device, driven by server-based business logic. This also happens to be the approach taken by ZK Mobile. Certainly this is part of the appeal of web-based applications in general, and given Google as the standard-bearer of web-based apps versus “thick desktop” equivalents, it’s curious to see the out of the box Android bias towards statically designed interfaces.

Exploring that apparent paradox might be another post. Today I’ll just provide some more tactical feedback on what I’ve seen in building a single application, with conventional upfront XML-based layout and the application running locally (as opposed to a runner interpreting server-delivered UI elements and forms). To start off with, let me say that, given the constraints of wanting to build an application that is laid out up front, I like the Android toolkit. I was able to build a functioning application fairly quickly. The overall Eclipse-based environment is easy to use and debugging was a breeze. That said, I have several bits of feedback of areas for improvement:

• The API is just not completely documented. I found myself guessing and experimenting many times to determine the precise behavior and requirements of an API call. Example: setting underline paint style doesn’t work to create underlined text (e.g. “textField.setPaintFlags(android.graphics.Paint.UNDERLINE_TEXT_FLAG);”). Instead it creates a strange, faintly visible font. There may be some other way to do it, but it just plain isn’t documented. There are ways to set bold and italic styles, but apparently not underline (or its just not done yet)
• The componentry is a strange mix of simple low level “simple individual controls” (editable text, spinner, checkbox, radio buttons) and “high level” controls such as imageswitcher and gallery (which are somewhat overlapping). What is needed is more of the “intermediate controls”. For example, more advanced list and grid behavior (such as our “fisheye” control). One guesses that they are waiting for third parties to supply these. Or they just haven’t done them yet themselves.
• Would be nice to have XPath with DOM usage instead of being forced to use just DOM navigation methods (e.g. getElementsByTagName). This is a potential memory and performance hog.
• The Android emulator is astonishingly slow. Yet despite Android’s own slowness, calls to other systems which take reasonable amounts of time result in timeout dialogs popping up. These include not just calls to my own server-based backends over the Internet, but also calls to other Android activities such as their contacts list and phone dialer.
• Linkify.addLinks() is a very handy utility method to create links from text (though I’m not even sure how I found it). It would be even cooler if that utility could optionally create onClickListener() methods for those links. The code for creating those onClickListener() methods to respond to those links is repetitive and should be automatable.
• It would be very useful to be able to create indexed arrays of elements (that can then be iterated through) through XML layout
• Given Android’s lightly documented state, a drag and drop layout designer would obviously be desirable. DroidDraw is a useful utility but doesn’t expose all options.

[Posted Later By Adam in Response to DroidDraw Developer Brendan – Since Mephisto Comments Mysteriously Stopped Working] As far as “unexposed properties” it would be nice to have “maxlines” on TextView control (that’s one that springs to mind, I think there may be a few others). What would also be nice to have is either dropdowns on control height and width properties for wrap_content and fill_parent options. It would also be useful to be able to specify width in other units available (px, ems, etc.) by switching between units from a dropdown list.

Well of course not. Almost any app developer would get some codesharing here. But in a previous post I discussed how you could write single controllers and controller actions and still support multiple client types. And do it in a way that is much terser and more elegant than the standards Rails 1.2 “responds_to” method that tends to lengthen and obfuscate your controller methods.

But you can go even further than that to allow literally writing one application, with the same controller AND views to support two different client – something I hadn’t seen done before. Leveraging some of the magic of Rails and RXML templates combined with our own Rails helper functions we’ve done just that. For example, the CheapGas app (which I worked on quite a bit personally as a “demo app” before its release) does this: just one controller and view for the app whether its delivered as WAP or HTML or to the Mobio rich client runner.

The way that we do this is to both use RXML templates and also replace the standard HTML tag helper library (which contains functions for creating dropdown boxes, input fields, forms, and so on) with equivalent functions that generate either WAP code, XHTML tags, or tags to our own runner, depending on what kind of device is accessing it. The example .RXML template for the CheapGas search page (which supports our runner, WAP and even XHTML from just one Rails controller and view) is shown below.

xml=doctype(xml) do |x|
 xml.head { }
 body(x) do |x|
   action="station/list"
   form(action,x) do |x|
     xml.p 'Search by gas stations by named location or zip code'
     xml.table do
       fields=[]
       xml.tr do
               xml.td { xml.text 'Select location '}
               xml.td {  xml << select_tag("location",options_for_select(@locations)) }
               xml.td {xml << link_to("<small>(Manage locations)</small>", :controller=>"location")}
               fields << "location"
       end
       xml.tr do
               xml.td { xml.text 'Or supply zip code ' }
               xml.td { xml <<text_field_tag('zip')}
               fields <<"zip"
       end
       xml.tr do
               xml.td { xml.text 'Within radius of '}
               xml.td {
                 xml << text_field_tag('radius',"style1")
                 xml.text 'miles'
                 fields <<"radius"
               }
       end
       xml.tr do
         xml.td { xml.text 'Only prices within last '}
         xml.td { xml << text_field_tag('filtertime')}
         fields= "filtertime"
       end
       xml.tr { xml.td {submit_tag('Search',action,fields,x)} }
     end # table
   end # form
 end # body
end #doctype

.RXML templates such as the one above let the Rails view be generated as code, instead of the sometimes awkward mixture of tags and code, which of course would then tie the view to a concrete set of tags. Once its all code then “smart helper functions” (select_tag(), text_field_tag(), submit_tag(), form(), body(), head() and doctype()) can be used to generate the tags for each client ype. These functions use the “client type” variable (populated with a Rails :before_filter function as described earlier) to generate the appropriate the appropriate underlying tag output over the wire. The HTML generation is straightforward. Generating WAP and our own rich client tags is more involved.

The result for the app developer is one set of code, both controller and views, to deliver multiple output types. This is something I haven’t seen in Rails apps (or other apps for that matter) whether its targeting mobile scenarios or otherwise.

Just what it means to generate tags which generate our rich client interfaces (i.e. what is the output if the client type is “Mobio Runner”) is the subject of several future posts.

bias against upfront analysis in conflict with service-oriented development

Agile advocates wax poetic about the inability to determine requirements ahead of time. They state its just impossible to know a system’s inputs and outputs and cite reams “industrial process control science” to do so. But service oriented development applied to a large system hinges on doing just this: determining the major services required by a system, and then designing contracts for their implementation. That investment in some small amount of upfront analysis (scoffed at by agile advocates) pays off in allowing multiple teams to build services independently as long as they comply with the designed contracts.

flaws in the team scaling model

Agile advocates recommend a “scrum of scrums” with scrum leaders represented to manage cross-team dependency. They actually need this because there is no emphasis on service contracts. Problems need to get hashed out in a broader freewheeling way. With service contracts issues are far more likely to get solved bilaterally between the service provider and the service consumer.

“old wine in new bottles”

Much of the better ideas of agile have been done for a long period of time in the more successful development organizations. Such ideas include running projects day to day and driving all work from the bug database (the Product Backlog). At Microsoft and Google and many other companies this is almost a religion. Small teams (7+-2). Daily short status meetings run roundrobin. Continuous builds. Small code reviews before checkins (almost XP). Short releases (less than three months). Due to being fortunate enough to be around some great engineering leaders I’ve been doing projects this way for over 15 years. So why is it a problem to call this agile or Scrum and give these best practice artifacts new names? Teams can lose some of the process maturity and nuance which they’ve built around usage of these techniques.

wholesale process change or “incrementalism” and “team ownership of process”

As mentioned, and acknowledged by agile gurus (such as Schwaber and Beedle) in the better shops most of these best process techniques are already being applied. However, there are almost always improvements that can be made in how a team approaches the development cycle and day to day work. I have found that building on what works already and incrementally changing processes (i.e. not every change in one release cycle, which I also like to be short) works best.I’ve also found that the best thing is to have an open and questioning attitude towards the best next incremental process change, involving all team members in deciding on changes, is valuable. The team that feels that they have made a decision about what the process should be has much better buyin, compliance and consistent volunteer enthusiastic participation in the process. This is better than “ok folks, now were doing Scrum”. Another way of putting it is for any team or organization considering introducing a new methodology (or “antimethodology”) is “what problem in the existing process are you trying to solve?”. Then go solve that problem directly rather than starting from scratch.

arbitrary timeboxes

Almost all of the timelines and timeboxes for specific events and durations in Scrum are arbitrary. This ranges from daily status meetings, to every other time cycle, meeting or artifact. Doesn’t seem very agile to not react to the exigencies of a specific projects. For example, the one month “Sprints” are a very arbitrary timeline and it is often difficult to build risky and time consuming blocks of features within those timeboxes. Agile advocates acknowledge this and say cite examples of releases with two Sprints: a “feature sprint” and a stabilization sprint. This sounds not just arbitrary but pretty mushy and vague as well. More specifically…

one month Sprints

I’ve already mentioned my generic issues with the arbitrariness of one month Sprints. There is the practicability of such timeframes. Anecdotally (after working on dozens of software projects in my career) my experience is that this can work for “end applications” or simpler websites even from “version 1”. My experience is that early releases of platform, infrastructure or tools code this is not quite feasible. I do accept that in either “app” or “platform” code several releases into a products lifetime the one month Sprints are feasible. There is still then the issue of the arbitrariness and optimality of such a timeframe (there is a high overhead of QA and integration effort for such a short cycle). Again, the question is “what problem are you trying to solve?”. Given that stabilization overhead is decreased as a percentage of effort in a two month release, why is one month better. It may be that “the business” (operations, marketing, sales and of course the users themselves) are not ready to make maximum use of a monthly release.Additionally the “way out” is to say that most projects are much larger than one month sprints and that a project is inherently “a bunch of Sprints”. There are already more mature existing best practices for “themed incremental milestones”. And most successful software-focused organizations have evolved more subtlety and insight about how to handle such complexity than is evident in most agile screeds.

arbitrary guidelines are presented with pseudoscientific justifications of dubious certitude

Much of agile practices that I’ve seen recommended have a core of common sense. My big issue is that the best organizations are already working at a level of sophistication better than those approximations. And those approximations are dressed with questionable garb from parallels to other sciences. For example, 7 as team size doesn’t have much to do with brains ability to handle 7+-2 objects [Schwaber]. In some prominent agile writings, other parallels are drawn to process control, chaos theory and physics . The problem with the dubious connections is that they are held as evidence for arbitrary decisions, rather than grounding them on evidence from development projects themselves.

artificial straw man of traditional best practices

The process and the foibles of “waterfall model” (does anyone really espouse such a completely serial model anymore or use that term to describe how they do things?) mentioned in Fowler’s Agile Manifesto and other books such as Schwaber and Beedle’s Agile Manifesto, doesn’t resemble anything conducted in dozens of projects that I’ve participated in. More normal is that even in the early 90s I worked on teams where product managers prepared requirements, program managers and dev leads wrote specs, devs prototyped code, and QA leads wrote test plans simultaneously early in a project. The desirability of such an approach that was anything but “waterfall” was recognized by most major software companies long before anyone ever used the “agile development”. Microsoft codified this in written form as the Microsoft Solutions Framework. But when I was there it was just “how stuff got done”. Books such as “Rapid Development” summarized what had already become industry wide recognized best practices. But the “words for things” remained the same as they were in the eighties. Much of Agile seems to be an attempt to put new words around widely accepted best practices, and arbitrary guidelines (one month sprints, 7 person teams) around reasonable defaults that most development shops were already more nuanced about.

optimal software process is an evolution

The terminology, milestones and deliverables in “conventional” ideas about the software process has evolved over many years in evolutionary (not revolutionary) response to changing technology and customer expectations. It can and should continue to evolve. For example, there may be deliverables that can be abbreviated or intentionally skipped (e.g. a requirements phase may be folded into a smaller specification). But it doesn’t hurt to make that choice consciously.

modern software tools can make “old artifacts” lightweight and even magnify their original value

Even more powerful is using modern tools to make such steps in the process much lighter weight, collaborative and distributed. As an example, take the case of two bogeymen of “agile development”: the idea that upfront requirements and specifications are too timeconsuming to be worthwhile. In our shop feature requests collect in the bug database (e.g bugzilla or trac) for a subsequent release (similar to a Scrum Product Backlog). Related sets of features are written up in narrative form on a requirements wiki page often initially by a product manager (this is a chance to include use cases when and where helpful). But they are commented on, and revised (with change control history of course) by many interested team members including the likely assigned developers and QA.After this brief in person requirements review, the feature items are assigned to a responsible engineer for spec and implementation (along with other related features). The dev writes a few paragraphs about the feature set on a specs wiki page, which again invites comments from and revisions by interested parties such as PMs, other devs or QA. As with the requirements wiki page, the value of the spec page is to allowed related features to be discussed, analyzed and described in toto. The scope of just how much specificity is required or optimal is determined by the dev. Often much of the content from the specs page can be leveraged later in a user manual if one is required. More often the specs page is all that is required for anyone who needs to use or maintain the software. When the spec is complete the dev holds a timeboxed spec review with interested parties, and if there is consensus on the approach proceeds with implementation. Its difficult to find the wasted overhead in what is described, and use of tools such as wikis can make these steps introduce very little overhead and slowdown to the process. In my shop we’ve automates the linkages between the wiki and bug database to make this even easier.

There’s nothing magic about this approach. The overall point is that these “traditional artifacts” of requirements and specifications are easier to do with modern tools and their value is I think even higher with the ability of more stakeholders to contribute to and benefit from the process.

In summary, on balance among an existing high performing team, I prefer to see more familiar processes and nomenclature iteratively refined to meet the needs of a particular business, product or team, rather than starting afresh with a new methodology (even one that claims not be a methodology) with a fresh set of names.

Working with Data Offline

Mobile Ajax-based applications do not allow for working with data offline. Native apps can be installed locally and run locally while completely disconnected. Inevitably some platform vendors will try to resolve this with proprietary extensions, similar to AvantGo’s “mobile offline browsing” that they’ve been trying to get adoption of for years. This may work for information feeds (the sweet spot for products like AvantGo). I don’t see it working for transactional applications or websites. Or any apps or web pages with user interaction (which should be a hallmark of web 2.0 properties right?). By contrast, intelligently design natively executing applications handle these offline scenarios quite nicely.

Taking Advantage of Device Capabilities

Browsers, including Ajax browsers, are all about making devices seem the same. On desktops, distinguished for the most part only by differences in screen resolution, this assumption has become more and more true. Mobile devices however are extremely heterogeneous: a dizzying array of screen resolutions, input and directional keys and widgets, and differing sound and video capabilities built into the hardware. That diversity is only increasing. To truly take advantage of a device’s native capabilities in any of these areas, a native application written to the device OS’s native APIs is necessary.

Industry Recognition

These are not observations unique to us. Large web properties such as Google and Yahoo are aggressively putting out native mobile applications for accessing horizontal consumer services such as maps or email. They are doing this with J2ME apps, Palm OS apps (despite the dubious future of the Palm OS) and even, horrors, Windows Mobile. This despite their status as highly competent web Ajax sites, who would presumably be in a great position to build mobile Ajax sites for these services.

Difficulty of Development

The problem with doing native applications is the difficulty and time to do it well. Beyond the diversity of device operating systems (J2ME, Windows Mobile, BREW, Symbian, Palm, RIM), there’s just the inherent step function of writing an actual application in procedural code (and many flavors of them) versus the convenience of maintaining a server-side web application.

The effort in “going native” pays off for truly massively horizontal applications such as email and maps. However, if you go beyond the top dozen or so web applications, to those with less than tens of millions of users, the effort necessary to build a mobile equivalent becomes more difficult to justify. Especially as those web properties or connected applications become more and more about user interaction or transactions.

Does this mean that Mobile Ajax will become predominant in those situations (for those sites or applications that can’t afford to “go native”)? I don’t think so. Most sites are still not aggressively using Ajax. Its just much more work to do so across a diversity of site functions, than to build more ordinary web pages. And once you do so, that mobile Ajax site is still of limited use since it can’t be used offline and is not necessarily taking advantage of unique device capabilities.

A Better Way?

So what are we, Mobio, doing? As you can guess, we build mobile applications that do run natively on mobile devices. As you will see from our forthcoming applications, we do manage to do them across many devices, with applications that are not as broadly applicable as email or maps.

We can and will take advantage of mobile Ajax browsers in the future on platforms that we may not choose to target directly. As mentioned you can create attractive applications with mobile Ajax, but it will be missing some of the offline and device-specific capabilities available with native applications.

However in either of these cases we do our authoring and application development in a way that manages to abstract us from much of the drudgery of creating device and OS optimized native applications, and even allows generation of mobile Ajax apps from the same source code. The way that we do this is the subject of future posts.