A few years back, a number of web development frameworks (e.g. ASP.net) began aiming to target mobile browsers as well as desktop browsers. In order to make this process less labor intensive for web developers they do this by allowing developers to use a generic tag instead of a specific HTML tag (e.g. asp:Textbox instead of input) and then, at run time, looking at HTTP request headers such as User-Agent to determine what sort of markup to actually render to the client. New mappings of headers to markup can be added or tweaked in a core library.
This whole approach was possible because of a brief convergence in the capabilities of desktop web apps and mobile phone web browsers. The former were limping along, the latter had just made a giant stride up from the murk of WAP browsing.
But the convergence turned out to be brief: desktop web apps have shot up in their sophistication and usability, with heavy use of AJAX and local Javascript-DOM programming. Any hope of "auto rendering" these sorts of apps onto a phone browser is a non-issue since the mobile browsers don't have sufficient screen size or Javascript support.
So that whole approach turns out to be a historical artifact. What's next? Maybe Flash Lite, if it would only show up on actual phones in the U.S. I also like the WPF/E concept, although sitting here outside of Redmond, it still looks like a concept both in the implementation and as far as getting it on (non-Windows) phones. In these cases, while there are not quite "magic templates" generating custom markup for each device, it should be possible to produce a single published app which works consistently on all of the participating handsets due to standardized support on the client side.
For Adobe or Microsoft, if it's possible to work the right deal with OEMs and carriers, it should be like shooting fish in a barrel. After all, J2ME is the only real competitor. And J2ME is still more complex than it needs to be, and continues to show no material, credible sign of progress (MIDP 3 included) toward the "write once run anywhere" motto that used to fly on the Java flag.
Friday, May 26, 2006
Wednesday, May 24, 2006
It's Easier Getting Them Out (OO Part 2)
When my wife and I were preparing for the birth of our son, we attended some prenatal classes. One of the instructor's favorite (overused) jokes was that, as far as babies, "it's easier putting them in than getting them out."
When it comes to objects and relational data stores, the opposite is true. Most developers can -- and have already needed to -- learn plenty of query description mechanisms (SQL, OPath and variants, JDOQL, LINQ, and a hundred product specific ones). Learning how to get data out of a store, and putting it into an object, XML schema, structure, whatever is just not that big a deal.
The hard part is putting 'em in. Actually, there are two hard parts.
The lesser hard part is taking data and moving it into a well-defined persistent store. This needs to be done while avoiding egregious transaction, concurrency, and performance problems on the DB side and also not requiring a lot of tuning and locking hints from the developer.
The greater hard part is taking a model built on OO semantics (using a language, UML, etc.) and automagically figuring out how to create a schema and persist this into relational store in a way that (1) does not create all sorts of concurrency and performance problems; (2) is transparent enough that DBA tools can be used for administrative, maintenance, and infrastructural reporting needs; and (3) is amenable to refactoring of the OO model since the in this case the OO model is prior to the persistence, and we recognize the benefits of "refactoring mercilessly" on the model side.
I am glad to see continued work on this problem. But I want to see more discussion right up front on exactly which models have priority in each of these schemes, so that developers can more efficiently choose the right approach for a given project. For example, Rails gives priority to a database schema; EJB 3, Hibernate and the WilsonORMapper take a middle position requiring modest work on both sides of the divide; Persistor.net gives priority to the object model. All good products for the right problem, none perfect.
Microsoft's white papers on ADO vNext suggest avoiding the issue by abstracting up a level: defining models in terms of a more abstract entity definition system. In exchange for defining domain models using Yet Another System, we would be given tools to seamlessly match these entities to objects, on the one side, and storage mechanisms like RDMBSs on the other side. Both the OO languages and the DB become second class citizens to the entity model. Since I'm writing applications in these OO languages, I'm not sure I'm ready for that, but I'll wait and see.
Meantime, if we're not clearer on what we're doing -- putting an object model into a database versus the entirely different affair of pulling database records into objects -- we're going to continue to see grand new schemes that never really take hold.
When it comes to objects and relational data stores, the opposite is true. Most developers can -- and have already needed to -- learn plenty of query description mechanisms (SQL, OPath and variants, JDOQL, LINQ, and a hundred product specific ones). Learning how to get data out of a store, and putting it into an object, XML schema, structure, whatever is just not that big a deal.
The hard part is putting 'em in. Actually, there are two hard parts.
The lesser hard part is taking data and moving it into a well-defined persistent store. This needs to be done while avoiding egregious transaction, concurrency, and performance problems on the DB side and also not requiring a lot of tuning and locking hints from the developer.
The greater hard part is taking a model built on OO semantics (using a language, UML, etc.) and automagically figuring out how to create a schema and persist this into relational store in a way that (1) does not create all sorts of concurrency and performance problems; (2) is transparent enough that DBA tools can be used for administrative, maintenance, and infrastructural reporting needs; and (3) is amenable to refactoring of the OO model since the in this case the OO model is prior to the persistence, and we recognize the benefits of "refactoring mercilessly" on the model side.
I am glad to see continued work on this problem. But I want to see more discussion right up front on exactly which models have priority in each of these schemes, so that developers can more efficiently choose the right approach for a given project. For example, Rails gives priority to a database schema; EJB 3, Hibernate and the WilsonORMapper take a middle position requiring modest work on both sides of the divide; Persistor.net gives priority to the object model. All good products for the right problem, none perfect.
Microsoft's white papers on ADO vNext suggest avoiding the issue by abstracting up a level: defining models in terms of a more abstract entity definition system. In exchange for defining domain models using Yet Another System, we would be given tools to seamlessly match these entities to objects, on the one side, and storage mechanisms like RDMBSs on the other side. Both the OO languages and the DB become second class citizens to the entity model. Since I'm writing applications in these OO languages, I'm not sure I'm ready for that, but I'll wait and see.
Meantime, if we're not clearer on what we're doing -- putting an object model into a database versus the entirely different affair of pulling database records into objects -- we're going to continue to see grand new schemes that never really take hold.
Wednesday, May 17, 2006
Free Toys, No Warranties (Yet)
Although official release is still some time off, our new J2ME phone client is looking great under preliminary QA. So I'm making it available to anyone who wants to jump in and play now. We focused on a few areas where the initial release had trouble on many handsets, and made the new version tighter, prettier, more usable, and compatible with most MIDP 1.0 / CLDC 1.0 phones. That is, this release is designed (*cough*) to run on practically any Java-enabled handset, including Treos and many Cingular Windows Mobile devices.
As we continue our QA process, we will make refinements as necessary to bring the bits closer to this grand goal. But in the meantime, if you're reading this blog, you may well be the kind of person who is excited to make a change and try something new right away.
The easiest way to get it is to send yourself an SMS with the .jad file URLs:
http://www.goskip.com/dl/skip11.jad
and
http://www.goskip.com/dl/skip11nds.jad
The only difference between these two is that skip11.jad includes a MIDlet-Data-Size entry, which is necessary to get good behavior from some phones (e.g. Moto RAZR) but breaks other phones (e.g. Audiovox PM8920); skip11nds.jad (nds = "no data size") omits this entry.
The only instruction which is really necessary (cannot be inferred from the UI) is that all syncing with the server is now "on-demand" -- meaning you press the 0 (zero) button on the handset whenever you want to sync. We found that multithreaded net and record store access was creating difficulties on some handsets, especially when cell network coverage was weak or intermittent. So we made this change to make the app clearer and more user friendly, even (especially) when things aren't working perfectly on the cellular side.
Have fun!
As we continue our QA process, we will make refinements as necessary to bring the bits closer to this grand goal. But in the meantime, if you're reading this blog, you may well be the kind of person who is excited to make a change and try something new right away.
The easiest way to get it is to send yourself an SMS with the .jad file URLs:
http://www.goskip.com/dl/skip11.jad
and
http://www.goskip.com/dl/skip11nds.jad
The only difference between these two is that skip11.jad includes a MIDlet-Data-Size entry, which is necessary to get good behavior from some phones (e.g. Moto RAZR) but breaks other phones (e.g. Audiovox PM8920); skip11nds.jad (nds = "no data size") omits this entry.
The only instruction which is really necessary (cannot be inferred from the UI) is that all syncing with the server is now "on-demand" -- meaning you press the 0 (zero) button on the handset whenever you want to sync. We found that multithreaded net and record store access was creating difficulties on some handsets, especially when cell network coverage was weak or intermittent. So we made this change to make the app clearer and more user friendly, even (especially) when things aren't working perfectly on the cellular side.
Have fun!
Tuesday, May 16, 2006
OO Part 1: Irony
I am writing a post about OO and data, collecting thoughts from recent development experience that have after the latest Microsoft CTP of LINQ.
But before addressing OO/data, I realized I may need to mount a mini-defense of OOAD to set the stage. In particular, I find it ironic that, on the one hand, at the implementation level OO tools, languages, and pattens have become de facto standards (whether .net or Ruby or Java, whether Visual Studio with its built in CASE facilities or Eclipse with its first-order refactoring and semantic search); yet true OO analysis and design (at the human domain level, not the system or design-pattern level) seems to be out of favor. It appears that OOAD practice is still seen as being tied to heavyweight long-running processes (not agile enough).
With respect to the timeline and heaviness of the process (usually measured by the proportion of activities which are bound to non-code deliverables or resource intensive checkpoints such as meetings or workshops), OOAD can be heavy or light. The heavy examples are famous, the light ones less so because there is less to be famous ...
But the power of the OOAD process to solve hard development problems in vertical domains remains remarkable. Let's make this concrete. Some time ago, eTag (the predecessor company to Skip) was prototyping a new form of automated airline checkin. We worked with one of the major carriers in the US. In the beginning, important stakeholders at the airline were convinced that the sort of automation we proposed was an impossible, intractable problem because of the enormous sophistication of their check-in system and related workflow activities (e.g. seat changes, upgrade request processing.) Without being inside the airline and working our way through everyone else's systems there, it would never work, they felt.
Our assertion was that it is possible to execute checkin scenarios, upgrades, loyalty program operations, rebooking, etc. in an airline agnostic manner using only actions (like "change") , objects (like "seat"), and events ("your account is charged when you make some flight changes") that the customer is already familiar with. Or in other words, we asserted that neither the customer nor the front end of the system needs to understand the airline's peculiar internal rules and representations regarding seats. No knowledge of mainframe record layouts, fare codes, or business rules is necessary to fully define these activities.
It is possible to address scenarios such as these using various "more agile" techniques... but the actual clear, articulated OO analysis deliverables were a sine qua non to establish that our approach did work. A partial implementation, code iteration, or a process that meant our team could move like ninjas was meaningless. We needed to show conclusively that the approach could solve the entire problem before we could overcome the objections and meet the risk profile necessary to move forward.
And the full analysis (large in scope but only weeks in duration) allowed us to execute not only the front and middle tier parts, but also the proprietary legacy integration for everything in a matter of a few months. Because we had already validated the shape and behavior of every domain object in the system, even an extremely complex custom integration to ancient, undocumented, and proprietary mainframe components was reduced to "mere implementation detail."
But before addressing OO/data, I realized I may need to mount a mini-defense of OOAD to set the stage. In particular, I find it ironic that, on the one hand, at the implementation level OO tools, languages, and pattens have become de facto standards (whether .net or Ruby or Java, whether Visual Studio with its built in CASE facilities or Eclipse with its first-order refactoring and semantic search); yet true OO analysis and design (at the human domain level, not the system or design-pattern level) seems to be out of favor. It appears that OOAD practice is still seen as being tied to heavyweight long-running processes (not agile enough).
With respect to the timeline and heaviness of the process (usually measured by the proportion of activities which are bound to non-code deliverables or resource intensive checkpoints such as meetings or workshops), OOAD can be heavy or light. The heavy examples are famous, the light ones less so because there is less to be famous ...
But the power of the OOAD process to solve hard development problems in vertical domains remains remarkable. Let's make this concrete. Some time ago, eTag (the predecessor company to Skip) was prototyping a new form of automated airline checkin. We worked with one of the major carriers in the US. In the beginning, important stakeholders at the airline were convinced that the sort of automation we proposed was an impossible, intractable problem because of the enormous sophistication of their check-in system and related workflow activities (e.g. seat changes, upgrade request processing.) Without being inside the airline and working our way through everyone else's systems there, it would never work, they felt.
Our assertion was that it is possible to execute checkin scenarios, upgrades, loyalty program operations, rebooking, etc. in an airline agnostic manner using only actions (like "change") , objects (like "seat"), and events ("your account is charged when you make some flight changes") that the customer is already familiar with. Or in other words, we asserted that neither the customer nor the front end of the system needs to understand the airline's peculiar internal rules and representations regarding seats. No knowledge of mainframe record layouts, fare codes, or business rules is necessary to fully define these activities.
It is possible to address scenarios such as these using various "more agile" techniques... but the actual clear, articulated OO analysis deliverables were a sine qua non to establish that our approach did work. A partial implementation, code iteration, or a process that meant our team could move like ninjas was meaningless. We needed to show conclusively that the approach could solve the entire problem before we could overcome the objections and meet the risk profile necessary to move forward.
And the full analysis (large in scope but only weeks in duration) allowed us to execute not only the front and middle tier parts, but also the proprietary legacy integration for everything in a matter of a few months. Because we had already validated the shape and behavior of every domain object in the system, even an extremely complex custom integration to ancient, undocumented, and proprietary mainframe components was reduced to "mere implementation detail."
Monday, May 08, 2006
Points Of Interest and Mobile Interactions
The other day, when my family was in Miami for my brother's wedding, my dad decided he wanted some ice cream. He had been playing with his Garmin StreetPilot, and imagined that perhaps there was a Haagen-Dazs ice cream stand around, and maybe the data point was in the GPS.
Not only did keying in Haagen-Dazs pull up a location, but it yielded a nearby supermarket with a dedicated Haagen-Dazs freezer case. I was impressed and very surprised: my dad is not the kind of guy who, out of the box, would have gone looking for third-party databases to upload into the GPS. So I surmised that this unit actually ships with either (a) coordinates for all known Haagen-Dazs locations or (b) a mapping that could recognize Haagen-Dazs as a food brand, and infer that a large supermarket would be likely to carry the product.
Either way, someone ensured that the "Haagen-Dazs" literal could be used to find an unaffiliated business (i.e. not a Haagen-Dazs franchise) via the GPS database. A quick check revealed that not every major ice cream brand has the same coverage in this GPS, so I imagine that this is essentially a sponsored search scenario.
This rocks! A company went out of its way to make its product available to my dad in a situation where he otherwise would not have been able as easily to find it -- and they did it unobstrusively. No ads, just the right information at contextually the right time.
Haagen-Dazs has some other interesting GIS features: check out their online "flavor finder". I can't wait until more companies start realizing that greasing the skids just little can bring more sales and massive customer loyalty.
Meanwhile, Garmin has an open interface that allows third parties to publish Point of Interest databases (as text files) that a customer can then import into the GPS device. So if I want to open Adam's Ice Cream, my loyal fans can subscribe to my POI database via RSS, keep it synced to their GPS, and now I'm playing right up there next to Haagen-Dazs. This is brilliant. The two features together (dedicated placement for big brands, and a free open DIY-POI integration for everyone else) is great combo that covers the big bump and the long tail.
Not only did keying in Haagen-Dazs pull up a location, but it yielded a nearby supermarket with a dedicated Haagen-Dazs freezer case. I was impressed and very surprised: my dad is not the kind of guy who, out of the box, would have gone looking for third-party databases to upload into the GPS. So I surmised that this unit actually ships with either (a) coordinates for all known Haagen-Dazs locations or (b) a mapping that could recognize Haagen-Dazs as a food brand, and infer that a large supermarket would be likely to carry the product.
Either way, someone ensured that the "Haagen-Dazs" literal could be used to find an unaffiliated business (i.e. not a Haagen-Dazs franchise) via the GPS database. A quick check revealed that not every major ice cream brand has the same coverage in this GPS, so I imagine that this is essentially a sponsored search scenario.
This rocks! A company went out of its way to make its product available to my dad in a situation where he otherwise would not have been able as easily to find it -- and they did it unobstrusively. No ads, just the right information at contextually the right time.
Haagen-Dazs has some other interesting GIS features: check out their online "flavor finder". I can't wait until more companies start realizing that greasing the skids just little can bring more sales and massive customer loyalty.
Meanwhile, Garmin has an open interface that allows third parties to publish Point of Interest databases (as text files) that a customer can then import into the GPS device. So if I want to open Adam's Ice Cream, my loyal fans can subscribe to my POI database via RSS, keep it synced to their GPS, and now I'm playing right up there next to Haagen-Dazs. This is brilliant. The two features together (dedicated placement for big brands, and a free open DIY-POI integration for everyone else) is great combo that covers the big bump and the long tail.
Thursday, May 04, 2006
Time for a "Platform" MVNO?
A week or so back, Russell Buckley published a post on The Frustrations of Java. In particular, he was speaking about J2ME, the Java platform for mobile devices. After a roundup of the issues that plague those of us using J2ME to deploy products, he concludes that perhaps WAP will end up winning because it's "good enough" in a number of respects.
Russell's right on about J2ME, about carriers, and about handsets. But WAP and its variants have been in the marketplace for over 7 years now, and while cellphones and their users have evolved, WAP continues to be an evolutionary dead end. Not extinct, but maybe only alive on a small remote island. Clearly not "good enough" for mainstream adoption so far.
So where does that leave us?
I believe the carriers are leaving massive cash on the table by retarding the progress of mobile-phone-as-computing-platform, which it definitely could be. Phones are today where PCs were in the mid 80s. Lots of apps, lots of different computers, not yet to the point where the "100% IBM PC Compatible" could became the platform to distribute applications. The "PC compatible" emerged not because it was superior but because its owner could expect to run all sorts of apps on it, and app vendors could expect all sorts of customers to have it. A sort of chicken-and-egg problem helped along in the by killer apps like WordPerfect and Lotus 1-2-3.
In a recent conference call, a developer-relations rep from one of the carriers discussed moving to a more consistent J2ME implementation for their MIDP 2.0 phones. When they began offering phones supporting MIDP 1.0, he said, they let the handset OEM put any Java runtime they felt like on any phone. At first I howled in pain, thinking of the late nights that this laissez faire approach cost us who write code. But I realized: suppose this company had subjected the initial Java deployment to the same standardization and QA regimen that they use for voice-call service ... who knows how many years' delay would have ensued?
So I applaud the company for taking a chance on programmability of what had been a completely closed embedded device. This is the attitude we need, and that willingness to open up is the first half of the solution. The second half will need to address the problems Russell wrote about in his post. I don't know whether this ought to be a wholly new platform that phones support; a new version of Java (J5ME?) with a really tight specification and minimal room for ambiguity; or wider adoption of an existing OS like Symbian or Windows Mobile.
But I do have an idea: how about a MVNO whose differentiator is that it promotes regular handsets (not just high-end smartphones) as a general purpose platform for computing. Perhaps it offers J2ME with all the "extra" (JSRs), or more than one platform, the way some phones provide Symbian+Java, or WinMo+Java+Flash (Cingular).
In any case, on the developer side, there would be rock solid specs for how these phones actually behave, open APIs to the voice, network, storage, and embedded apps. On the consumer side, the phones would actually be promoted as computing devices for all sorts of work. More like the early Palm devices than the Treos. The MVNO would charge for the device and for the network connectivity and could pick handsets that are reasonably capable. Access to add/remove/configure apps would be completely open, and the ISVs could win or lose on their merits.
Would enough people subscribe to cover the overhead? Out of the gate, it's hard to say. Other phones/carriers/networks might seem "better." But wait until the apps start coming. It's why I don't still run a TRS-80 or a TI99/4A.
Russell's right on about J2ME, about carriers, and about handsets. But WAP and its variants have been in the marketplace for over 7 years now, and while cellphones and their users have evolved, WAP continues to be an evolutionary dead end. Not extinct, but maybe only alive on a small remote island. Clearly not "good enough" for mainstream adoption so far.
So where does that leave us?
I believe the carriers are leaving massive cash on the table by retarding the progress of mobile-phone-as-computing-platform, which it definitely could be. Phones are today where PCs were in the mid 80s. Lots of apps, lots of different computers, not yet to the point where the "100% IBM PC Compatible" could became the platform to distribute applications. The "PC compatible" emerged not because it was superior but because its owner could expect to run all sorts of apps on it, and app vendors could expect all sorts of customers to have it. A sort of chicken-and-egg problem helped along in the by killer apps like WordPerfect and Lotus 1-2-3.
In a recent conference call, a developer-relations rep from one of the carriers discussed moving to a more consistent J2ME implementation for their MIDP 2.0 phones. When they began offering phones supporting MIDP 1.0, he said, they let the handset OEM put any Java runtime they felt like on any phone. At first I howled in pain, thinking of the late nights that this laissez faire approach cost us who write code. But I realized: suppose this company had subjected the initial Java deployment to the same standardization and QA regimen that they use for voice-call service ... who knows how many years' delay would have ensued?
So I applaud the company for taking a chance on programmability of what had been a completely closed embedded device. This is the attitude we need, and that willingness to open up is the first half of the solution. The second half will need to address the problems Russell wrote about in his post. I don't know whether this ought to be a wholly new platform that phones support; a new version of Java (J5ME?) with a really tight specification and minimal room for ambiguity; or wider adoption of an existing OS like Symbian or Windows Mobile.
But I do have an idea: how about a MVNO whose differentiator is that it promotes regular handsets (not just high-end smartphones) as a general purpose platform for computing. Perhaps it offers J2ME with all the "extra" (JSRs), or more than one platform, the way some phones provide Symbian+Java, or WinMo+Java+Flash (Cingular).
In any case, on the developer side, there would be rock solid specs for how these phones actually behave, open APIs to the voice, network, storage, and embedded apps. On the consumer side, the phones would actually be promoted as computing devices for all sorts of work. More like the early Palm devices than the Treos. The MVNO would charge for the device and for the network connectivity and could pick handsets that are reasonably capable. Access to add/remove/configure apps would be completely open, and the ISVs could win or lose on their merits.
Would enough people subscribe to cover the overhead? Out of the gate, it's hard to say. Other phones/carriers/networks might seem "better." But wait until the apps start coming. It's why I don't still run a TRS-80 or a TI99/4A.
Subscribe to:
Posts (Atom)
