Archive for the mobile platforms Category

We posted our RMobio gem for mobile Rails development on RubyForge about a month ago. I’ll be doing a series of blog posts describing how to use the various goodies inside it over the next few weeks.

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:

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'

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.

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:

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

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:

Last week Yahoo announced their new mobile platform, Blueprint. It was very gratifying to see that what they have built, is, like our platform, derived from XForms.

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.

I took some time over the last week to port our CheapGas application (which finds the lowest priced stations near a given vicinity) to Android. I wrote this application in Rails originally. It supports both our runner and arbitrary WAP clients (using just one controller via techniques described in this blog). This port was to just build an Android client and call back to the my Rails-based controller of the production CheapGas app.

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.

You may have noticed that we release many of our apps as both locally installed rich clients AND on WAP simultaneously. For example we have a rich client “CheapGas” application and a WAP CheapGas. Some users have asked “do you really write two separate codelines for each way that you deliver these applications?”.

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.

.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.

I’ve gotten a lot of response to my posting on WAP. The predominant theme has not actually been defending WAP in any way. But instead has been “ok but what about mobile Ajax?”. Mobile Ajax, of the type capable by browsers such as Opera and Good Technology’s Good Mobile Intranet provides several of the capabilities missing in WAP apps. Specifically it will allow for executing logic locally, such as rich validation and dynamic forms. It also provides some separation of presentation and data in the ability to download data asynchronously without browser roundtrips.While Mobile Ajax is a big step forward over WAP and provides a much better user experience. It still has several limitations:

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.

Following up on my previous post on how we believe the best mobile apps are built , I’ve been asked what the somewhat nebulous term “mobile 2.0” means to me. From a technology perspective I would summarize it as the following things:

locally executing applications that work to some level even when disconnected and thus have…

locally cached data

leveraging relevant open standards where possible. for example be opportunistic about the presence of Opera, Minimo, IE, Nokia on peoples devices

controls that are optimized for the capabilities of a particular device and the unique functionality required by mobile apps. there is a natural tension between this goal and the previous point of just using a browser

From a user experience perspective I would suggest that it is the following three things:

“context and user aware applications”: delivering the app to users with knowledge of their preferences, their previous uses, their defaults and their likely current actions, to accelerate their tasks and put them into the right form/page/screen/action without a lot of navigation

“shared knowledge among applications” – in order to ease the previous goal of minimizing user data entry and navigation on mobile devices, applications should share information about user profiles, preferences, authentication, past usage and defaults. in this context its worth the extra effort to perform this integration

user interaction and content contribution – this is probably the only point that truly echoes web 2.0. mobile 2.0 apps should incorporate user feedback and results in intelligently rapid ways

From a business perspective the following trends will drive massive user adoption and make mobile applications tools that everyone uses

low to no cost through an advertising and transaction revenue model – users shouldn’t have to pay for services

cheap to free data plans – this still has to happen and may be the biggest barrier to entry

tools and platforms to make the nontrivial technology and user experiences described above happen for many applications and content in as cost effective and rapid way as it did for the web

Some of you may be using our Mobile Movie Times application or seen the demos of our various other mobile consumer apps. You may say “that sure looks a lot better than WAP”. Yes, all of our apps are locally executing rich clients optimized for their devices. Many of you may have noticed that most consumer-focused large web properties are pursuing (google, yahoo, ebay) are also not building WAP portals but instead focusing on locally executing optimized apps targeting a particular platform. So why is this? WAP’s been around for years. What’s wrong with it?The big problems with WAP that we see are no ability to execute functionality locally, lack of separation of presentation and data, a murky future standards picture, no ability to work with data offline, and no ability to take advantage of an increasingly diverse set of mobile device capabilities.For the record, there are several applications and use cases where none of these are problems, especially one way delivery of text only information. It may be that in an effort to allow an application to run on as many platforms as possible without rewriting them as native locally executing apps that use of WAP on some devices can be a way to multiply the payoff of investing in building the backend of a mobile application. That said, for most applications the following issues all inhibit WAP from delivering a truly optimal user experience on targeted devices<h3>Executing Logic Locally</h3>
The best applications (mobile, web-based and desktop) all execute some portion of their logic locally. This can be for:

validation

modifying forms, menus and screen display based on user behavior

rapidly showing different data based on user actions and interests without roundtrips to the server

These ideas are behind much of the current trend of Ajax-oriented websites: highly responsive, interactive, adaptive web pages and user interfaces.

WAP sites don’t do this and they don’t have enough of a scripting model to enable these features. AJAX-capable browsers can try to do these things (the pros and cons of mobile Ajax browsers are the subject of another post). But most web and mobile app providers trying to create optimal user experiences are building “native applications” in the APIs of the mobile platform to achieve these benefits.

Separating Presentation and Data

Neither WAP nor traditional HTML pages separate presentation from data. Form controls and their embedded data are tied together in one stream of information. This is why most WAP sites that interact with users are painfully slow. By contrast, optimized native applications run locally on the device and send only the changed data back and forth. It is possible to approximate these benefits with Ajax and other use of Javascript on a mobile browser, but it is inherently more difficult and the data exchange less efficient (again, we’ll talk more about Ajax browsers later).

Future Standards

At one time it seemed like the mobile web industry might come together on some standards based on some derivative of both WAP and XHTML Mobile Profile. That effort ended with major vendors each taking their own tack on the mobile web using divergent subsets of a proposed WAP 2.0 standard. We’ll talk more about that later. But at this point, it is not a controversial statement that WAP 2.0 and XHTML MP are not being used consistently and robustly by major mobile software providers and device manufacturers.

Working with Data Offline

Mobile networks are still not always available with 100% coverage and this is likely to remain true for quite a while. The best mobile applications (such as Blackberry’s email) are optimized for syncing intermittently and transparently and allowing the user to use the application offline. The best usage experience even for “vertical” single purpose apps are written to the native device operating system, making optimal use of available storage, trickle syncing data to and from the server transparently to the user, and allowing the user to be as interactive as possible when not having coverage. WAP browsers (and Ajax browsers) are not capable of this.

Taking Advantage of Device Capabilities

Mobile phones are a diverse lot and, with the emergence of new “more than just voice call” features, becoming moreso by the day. There are several major device operating systems: BREW, Symbian, J2ME, Linux, Windows Mobile to name a few. More importantly phones have an increasingly differentiated set of capabilities: everything from taking pictures to recording voice to playing music to syncing contacts and PIM information to voice dialing to GPS. The best applications take full and optimal advantage each device’s capabilities in all of those areas and more. Browser based applications (of any flavor) just don’t do this. To do this requires writing to the APIs of the device, even when a device uses supposedly “open API” such as JSR extensions to J2ME for specific capabilities.

So How Do We Build Such Optimized Native Apps Efficiently?

All this said, its quite expensive and difficult to write application to these various devices in their native operating systems with their unique APIs in C, C++, or Java. And it becomes moreso once you want to target multiple devices. J2ME offers a variety of devices, but certainly not the majority of the market.

But this hasn’t daunted the the biggest web properties(such as Yahoo and Google) with extremely horizontal apps such as email and maps that can be targeted to many millions of users. The cost of hiring large teams of developers to spend months to years writing apps can pay off in these situations.

But is it possible to write apps at a higher level than the native procedural languages (maybe even higher level than WAP or HTML)? And can we do so and still allow single applications to be executed on a wide variety of other devices? And perhaps even better allow the apps to function at a gracefully degraded level by delivering content WAP and AJAX browsers on platforms and devices that its not economical to devote a lot of attention (while still just “writing them once”, as is referred to in another post here). All this is a topic for another post some time soon.