I'm a little confused as to why you would *want* to run CSLA apps on any mobile phone as a native application.
My gut feeling is that it seems to be a solution in search of a problem, wouldn't performance would be a huge issue?
What would be the advantage to a native csla app on a mobile device?
A web based app based on CSLA using JQuery Mobile seems to make more sense, it would be super responsive, lightweight, run on just about anything with some tweaking for display formats and input devices.
It also brings Apple devices into the fold.
What am I missing with this scenario?
The mobile space is changing rapidly. While phones are somewhat limited, slates/tablets/pads are real computers, just without a hardwired keyboard.
Suppose that Windows loses real market share to iPad and Android slate computers. I can easily envision a world where half the current laptop users in the world carry slates instead, and where some non-trivial number of slates run iOS or Android.
Those are real computers, just with a touch interface. And they'll be a real target for business application development. Given that MonoTouch and MonoDroid allow .NET code to run on iOS and Android respectively, it seems logical to think that CSLA should be there too.
If all those arguments aren't enough, I live in Minnesota. Minnesota is a state in the center of the US and all the way to the north. Large sections of Minnesota have poor or no data coverage via mobile phone carriers. Nor is there sufficient population density to justify 3G or 4G coverage. And I spend a lot of time in those parts of Minnesota because I love fishing and camping and other outdoor activities.
The areas around San Francisico are rugged, and so while cell coverage is pretty good there, you can lose it by driving over a mountain or hill.
When I'm on an airplane there's no cell coverage (thankfully), and WiFi is expensive and not universal. And I travel a lot.
In short, my view of mobile apps is that if they can't continue to function when there's no data signal then the app is of very limited value. This means a typical HTML based app is often quite useless.
So even on a smart phone, a smart client app trumps stupid web apps any day of the week.
This is why Evernote was so valuable to me, and why I now use Onenote. Evernote was great because it was web-based, but had a smart client for Windows and my phone. Now that I have a WP7 device, Evernote has moved too slowly to get a smart client, but Microsoft has one for Onenote (and Onenote 2010 has a web-based UI as well).
Sure, web-based UIs are good for people who never leave high density population areas and don't fly. But people who like the outdoors and/or fly need smart apps on their smart devices. We actually want to be really mobile, regardless of population density.
So I want to be able to use CSLA to build apps for the iPad, Android phones and WP7 phones, so I can take my apps everywhere :)
I see what you're saying but those are edge cases, not typical. Perhaps there is some non business use of CSLA that is applicable when hiking in the mountains but I suspect the set that overlaps between business users and wireless browsing access is pretty big in general.
I fully understand the lack of penetration of wireless services, I live in an area that I can drive less than an hour in most directions and lose even cell phone service, the thing is that those are not areas I would typically be doing business in if I was running our software.
I'll give you that there is potential for people to need to run software disconnected but how practical is it to run a CSLA app entirely on a disconnected device like a phone or a slate?
Silverlight has no database support without jumping through hoops using COM in OOB mode from what I can see. I'm not too familiar with MONODROID but I suspect it's still not ideal to run a multi tiered app with a database at the back end on such a device.
Comparatively there is a large need *right now* for apps that can run in a browser on small form factor devices, it seems supporting such a UI is a worthy goal for CSLA at the very least on par with MONODROID.
I fully understand that the UI is sort of on the edge of the areas of responsibility for CSLA and the whole discussion as a result is a bit moot but there *are* special helpers for the UI layer and working with CSLA for WPF and ASP.NET MVC and I'd like to suggest a future example designed for small form factor device browsers using something like JQuery Mobile (JQuery being something Microsoft is fully behind these days).
Windows *is* losing market share to other devices but I suspect they aren't losing it in the "wheelhouse" that CSLA normally operates in.
In our market which is business software for service organizations we see people continuing to use desktop PC's in large numbers and they want to use those devices and their phones only for a minimal subset of functionality that is useful when they are travelling or on the road.
CSLA is by it's nature meant for large scale serious business applications, I just can't see the benefit for running them as native apps entirely on a phone or a slate.
Those devices would typically be more like a dumb terminal surely for a typical CSLA app?
That may all be true. I have this gut feeling that 3-5 years from now only a minority of people (mostly developers) will be carrying laptops or using "real computers" in their daily lives. That most people will be carrying around some sort of slate or tablet and using wireless peripherals or docking stations when they need a keyboard or mouse.
OK, maybe not that fast. But I think that's the trend, and that all the "cool kids" will be living that life in 3-5 years, and normal computer users will be unhappily working on their old-fashioned laptops.
This means that anything you envision running on a smart client today needs to run on a smart client in 3-5 years. And that smart client may easily be an iPad version 5 or Android version 4 or something. I'm not willing to bet the future of CSLA on Windows being on 92% of clients (or whatever the number is now). I strongly suspect 5 years from now that we'll see a more pluralistic client computing base, and I want to be part of that.
But when you get right down to it, I develop CSLA as much for enjoyment as anything. Hence I've avoided Windows Forms for the past 2-3 years in favor of XAML, and now I'm interested in mono. New challenges on cool and trendy new platforms.
The last thing any of us want is for me to get bored :)
I am curious though.
What do you think CSLA can or should do to enable building web apps that run on phones?
I can certainly see many things a UI technology like ASP.NET MVC might do to enable building a UI for a phone.
But I'm not entirely sure I see what CSLA should do beyond making sure it provides good support for ASP.NET (Web Forms and MVC)?
I am curious though.
What do you think CSLA can or should do to enable building web apps that run on phones?
I can certainly see many things a UI technology like ASP.NET MVC might do to enable building a UI for a phone.
But I'm not entirely sure I see what CSLA should do beyond making sure it provides good support for ASP.NET (Web Forms and MVC)?
Nothing really at all. I think CSLA 4.x probably fully suffices. I can shoehorn just about anything into anything else.
I'd just like to see some love for a true mobile browser sample that can run on an IPhone / Android / WP7 etc etc. Anything with an HTML5 compatible browser. JQuery mobile gives us a fighting chance to do that. There are special challenges to make it fast, easy to use and easy to code, maintain and test.
It's just that when you did a wpf and silverlight version you came across significant changes to be made to CSLA and helper objects to assist with those interfaces, doing a purely mobile browser interface may spark similar things that save me time. (Selfish I know but there it is. 
)
I'm going from winforms in our old version to wpf and silverlight and asp.net mvc and small form factor html 5 browser interface so everything is interesting to me right now and it's a lot of overload so I'm looking for things that save time wherever I can find them.
Nothing really at all. I think CSLA 4.x probably fully suffices.
I think that's the key, to me at least.
I'm not yet ready to abandon .NET and Windows for the JavaScript/jQuery/DOM world.
Microsoft has many people working on ASP.NET to make it possible for us to build server-side code that projects powerful client-side script. And the ecosystem includes numerous component vendors who are building other server-side components that project even more powerful client-side script.
I'm perfectly happy to let those companies (and their deep pockets) ensure that the script they project runs on the myriad devices and browsers that exist today and into the future. That's a labor-intensive and (to me) extremely unrewarding type of work, so I'm very happy to support those organizations as they slog through the crap to provide me with an easier solution.
If we start to see the browser truly become the new client OS - and I acknowledge that this is possible - we'll probably all start to abandon .NET, Windows, C++, Java, and other modern languages as we all move to JavaScript and DOM programming.
That'd make me sad, because I really like .NET.
But maybe jQuery and the various other script libraries necessary to do meaningful web development are as powerful and fun to use as .NET?
To my mind, if we end up in a position where the dominant client-side dev target is JavaScript and jQuery, then I want a comparable language and runtime environment on the server too. In fact, without some consistent runtime on client and server, something like CSLA can't exist, and we're thrown back in time over 15 years to a world where duplication of code is unavoidable.
That might not be the worst thing though, because that could be the trigger that makes model-driven programming clearly superior. And that could lead to the death of the 3GL - something I've thought should happen for a very long time, but which won't happen as long as things like Java and .NET exist because they are "good enough".
I'm not yet ready to abandon .NET and Windows for the JavaScript/jQuery/DOM world.
Must be nice to have a choice!
It's only the interface and only one of many we need to offer going forward.
Microsoft has many people working on ASP.NET to make it possible for us to build server-side code that projects powerful client-side script. And the ecosystem includes numerous component vendors who are building other server-side components that project even more powerful client-side script.
I would be too and will use any and all I find, however Microsoft have a tradition of taking us always part of the way towards a single code base then leaving us high and dry. Like WPF and Silverlight, whoever *didn't* think there should be as much code reuse between the two as possible while they were still on the drawing board should be taken out and flogged. They missed a huge opportunity there.
Interestingly Microsoft is already embracing JQuery and presumably JQuery mobile down the road so you aren't exactly straying outside the fence if you code with it. It's their safety valve when people like me come knocking and say "how can I make an app with your tools that can be used from an IPhone".
I'm perfectly happy to let those companies (and their deep pockets) ensure that the script they project runs on the myriad devices and browsers that exist today and into the future. That's a labor-intensive and (to me) extremely unrewarding type of work, so I'm very happy to support those organizations as they slog through the crap to provide me with an easier solution.
I would be too, unfortunately they don't, they have too much of a vested interest and war too much with each other to ever be a viable one stop shop, hence things like JQuery Mobile. Silverlight is great if you can force your users to choose a particular device, it's promise is stillborn for the rest of us.
If we start to see the browser truly become the new client OS - and I acknowledge that this is possible - we'll probably all start to abandon .NET, Windows, C++, Java, and other modern languages as we all move to JavaScript and DOM programming.
That'd make me sad, because I really like .NET.
But maybe jQuery and the various other script libraries necessary to do meaningful web development are as powerful and fun to use as .NET?
To my mind, if we end up in a position where the dominant client-side dev target is JavaScript and jQuery, then I want a comparable language and runtime environment on the server too. In fact, without some consistent runtime on client and server, something like CSLA can't exist, and we're thrown back in time over 15 years to a world where duplication of code is unavoidable.
That might not be the worst thing though, because that could be the trigger that makes model-driven programming clearly superior. And that could lead to the death of the 3GL - something I've thought should happen for a very long time, but which won't happen as long as things like Java and .NET exist because they are "good enough".
I'm not sure why you would ever want to use the same tech in the back end just because it's used at the client, that doesn't make any sense at all, right tool for the job and all htat.
Clearly, at least to me, none of these devices are truly ever going to be used for natively running large complex business apps, at the very least they need some kind of server. .Net and CSLA are ideally suited for that aspect. In my mind these devices are nothing more than slightly less dumb terminals. They are just a UI, like any other UI.
They are only one of a myriad of UI's that I need to support if I want to sell any licenses.
In the perfect world I would write an app once that would run anywhere, I want that, my users want that, about the only people who don't want it are the technology companies that provide the platforms, the only thing they all agree on going forward is HTML 5 which nearly every important platform supports *right now*.
Clearly, at least to me, none of these devices are truly ever going to be used for natively running large complex business apps, at the very least they need some kind of server. .Net and CSLA are ideally suited for that aspect. In my mind these devices are nothing more than slightly less dumb terminals. They are just a UI, like any other UI.
Another key quote in my view :)
I spent the first third of my career building apps that ran on servers (we called them minicomputers) and projected a UI to dumb terminals.
That was fun enough, though the minicomputer world wasn't crippled the way web servers are today. It was actually possible to maintain state between server interactions on a minicomputer, whereas web servers all suffer from alzheimer's disease.
Of course having alzheimer's makes web servers more scalable, so there's a clear tradeoff.
My personal interest has always been in distributed computing though, and the last thing I want to do is take the amazingly smart and powerful machines we carry around (including our phones now) and treat them like colorful 3270 terminals. What an incredible and sad waste of power and capability that would be.
When you consider that my WP7 phone is more powerful than the first several computers I owned. And that my desktop and laptop computers are individually far more powerful than the minicomputer I programmed for the first third of my career, it really puts things in perspective - for me at least.
Anything that turns these wonderful machines into $50 terminals is counter-productive.
So when I look at HTML5 I look at it as a new client OS. Not just some arcane markup language, but as a complete programming environment on which we can run large parts of an application.
If HTML5 can't achieve that goal, then I'll only use it within the context of paid engagements. In that case it is boring - just a colorful version of something I did 20 years ago.
Perhaps it is a midlife crisis thing, but I don't feel like I have enough time left in my career to rehash 20 year old ideas.
I firmly believe the future of computing is ubiquitous computing, where we are surrounded by smart devices that perform complex tasks, and only interact with servers for data coordination and perhaps persistence.
I could be wrong, but that's the future I want to be part of. Not a future where we rehash lessons learned 20 and 30 years in the past.
Again, if it turns out that HTML5 becomes a powerful and consistent enough client OS that it enables this type of distributed computing, them I'm interested and excited.
But to achieve what I want - which is best described as mobile agents - there needs to be a way to run the same code on every device and server, so I can write an intelligent agent (you might say object in mainstream wording) that can go where it needs to be in order to perform the tasks it needs to perform.
That's all very academic, and you'll notice that CSLA's mobile object concept is, at best, a tiny slice of that bigger idea. But this is what actually drives me to do what I do.
I find it hard to imagine JavaScript becoming that ubiquitous language, or jQuery becoming that ubiquitous platform. The closest we've ever come are Java and .NET.
If those are to die, in favor of a chaotic array of technologies unique to every server, and perhaps vaguely consistent across browsers and devices, that's fine. That just drives the need for a higher level of abstraction - some meta-language and meta-runtime that allows me to write consistent code that "compiles" into all those different environments.
You ask how CSLA might fit into a "smart client" HTML5 future (or at least that's how I'll take your question)? As you know it today it won't.
But all that research I did to create a CLSA runtime for "Oslo" using the M programming language established one very important thing: it is very possible to create a higher level language that allows the description of rich business objects, where a "compiler" translates those constructs into runtime elements that can execute on a unique target platform.
In other words, if nobody else creates a common way to describe business domain objects that can run in HTML5, .NET, Java, Objective C, etc - then it isn't out of the question to envision a more abstract language that allows people to construct such objects in a way that they can "compile" into every one of those environments.
That's not easy to do, but it is not unrealistic either. And when you consider the overwhelming cost of building software in a future where there's no single development target (or even two like we've had with Java and .NET for over a decade), this type of concept will be very, very attractive to the people who pay for software development.
I feel comfortable in that statement, having watched the rise (and fall) of 4GLs in the past - driven by the low productivity and high cost of the platforms of the time, and the potential for radically lower cost development by using tools that provided better abstraction. Did they actually work? Not overly well. Did they sell well and make the 4GL providers good money? Absolutely :)
The real question is whether we've learned enough since then to make that type of abstraction actually work this time around. And I think the answer is a qualified yes. I was a serious skeptic until I dug into Oslo. And as primitive and incomplete as Oslo was, it did prove that you really can solve this problem.
Interesting stuff. We have very different perspectives but I understand where you're coming from entirely I cut my coding teeth on a CPM machine back in the day.
I can't afford to be philosophical about it, there are things that keep a roof over my head and things that don't. Here in the trenches there is a real need for my apps to not only run on a windows desktop computer but also run on a Mac / Linux / IPhone / IPad / Android / whatever new device comes along and I think the combination of CSLA at the back end and an web / WPF / Silverlight front end makes it happen.
I will gladly embrace your future where smart devices and mobile objects make life easier for us all, for the time being I still don't see where you have stated any concrete real world benefit to running CSLA as a native app on those devices but perhaps you're thinking further down the road than I am on this one. Or perhaps you're just getting bored. 
Cheers and thanks for the conversation.
I'm not entirely philosophical about it either.
Ultimately I need to be able to write books, speak, and produce videos around something that matters to a large group of people, or I can't make money.
Again, you'll notice that CSLA isn't an implementation of mobile agents - that's too academic and abstract to be applicable. Mobile objects are a tiny and very useful slice of the mobile agent concept, so that's what CSLA implements.
And what I find really interesting is that the primary reason most people use CSLA has little or nothing to do with mobile objects. The primary motivators are the data binding support, business rules, code consistency, and location transparency. Only location transparency has anything to do with mobile objects, and that's primarily a side-effect.
Given free reign, I'd implement a complete mobile agent infrastructure :) But that'd almost certainly make CSLA less relevant for most people, so simple economics makes that unrealistic for me.
Late to the conversation here but picking up on the original point, I think it's great that CSLA could/will end up porting to Android. Many years ago I used the .Net 1.1 framework version of CSLA that had been "ported" by one of the members for running on Windows CE/5 and 6 - essentially it had the DataPortal, n-level undo bits ripped out to make it work if I recall correctly. It was a proof of delivery application running on rugged mobile devices over a sometimes up 3G link and Wifi when bank in the yard.
But the great thing was that my business library model on the device was the same code files (with a few #if defs here and there so I could pick which data access methods to call; SQL CE on the device or my web services to receive/send the data back, and back on the server side just point to the DataPortal and SQL 200X). From a design and maintenance view it just worked great.
Now if it ports to the iPhone world as well....icing on the cake :-)
CSLA is .Net's swiss army knife.
I totally agree that porting my CSLA BOs to Android and iOS will offer me a BIG advantage over other developers! And I totally want to get this advantage! Of course if a system is "big" I don't want to port every feature to the phone. But some of them carry a great value for the users and I wish to be able to "say yes" to feature requests without the need to recode the business logic.
That said, I was quite surprised to read Rocky's comment about the most sought after features of CSLA... Personnally, I think mobile objects are the main reason why we chose CSLA. I want to be able to develop maintanable distributed applications and mobile objects are key to success.
Way to go Rocky!
Personally, I think mobile objects are the main reason why we chose CSLA. I want to be able to develop maintanable distributed applications and mobile objects are key to success.
Way to go Rocky!
I agree with this, having feature rich objects that can move around is key for us.
Nevertheless, its the whole package that the CSLA offers that makes it so great. To me, removing any key functionality from the CSLA is like removing a leg from a 3 legged table, the whole thing will collapse.... a bit dramatic but just illustrating the point.
Well I see a lot of "pie in the sky" talk here but I still don't see a single convincing reason why it makes sense that CSLA needs to run *on* a mobile device (as opposed to being a UI for CSLA running on an app server), nor anyone with a good business case for it, nor any testing by anyone to confirm it's even realistic.
What I see is often what I see from our customers, they want everything under the sun and they don't think it through completely, it's just a whim, an urge to them, regardless of if it makes sense or not, we get those kind of feature requests all the time.
I totally see why people want their apps to run on an IPhone / IPad / Android, I do as well, I just don't see it being realistic or even desired that the app run *on* the device as opposed to being run *via* the device but I'll be happy to stand corrected.
I believe there are use cases and several have been given such as running remotely without network connectivity. That is a BIG use case right there, whether you think it is or not. Why are you pushing this issue so much? It's like the person who reads the newspaper but wishes they'd remove the comics because he/she doesn't read the comics. Well others do, if you don't like it, just turn the page.
Because when your users say they want your app to "run everywhere", they mean that - they want the same app to be available everywhere. Or, they are willing to accept a version that still has significant functionality to "the original".
In order to do that, you will need a significant set of "client-side technology" available - validation, dependent properties, etc. Since all that functionality is easily available within CSLA objects, the easiest way to accomplish that is to bring CSLA (or the subset of CSLA necessary to effect those pieces of functionality) directly onto the client.
We're not talking about the entire app running on these devices either - ultimately, we're talking about enabling the kind of rich-client interface you can get from something like WinForms, WPF, and Silverlight. Yes, you can get that in the web, but it requires a whole different set of technology that was never originally designed to do this kind of thing. Yes, these apps (if they're non-trivial at all) need to figure out how to save data when the backend isn't available for whatever reason. There are ways of accomplishing that which are, IMHO, no more complicated than developing a reasonably-rich UI using HTML/JS/jQuery.
Is that "better" than simply generating some mobile-friendly browser code via jQuery/JavaScript? That depends on who you talk to. Your answer seems to be "no". Others will disagree, simply because they don't want to have to write all that stuff twice. And Rocky's point is that he doesn't want to spend a lot of time developing code that translates CSLA .NET code into client-side scripting technologies, with all the browser variants (and sub-variants for mobile-versus-other-platform browsers) to contend with. He's happy to let Microsoft (or some other vendor) spend the money instead, and he'll figure out how to plug into it when it becomes available.
You can certainly argue that were you to write your app as a web app in the first place then you'd "get that for free", and you would have a point. And that's where I think your post is going - there are helpers to make some of what you have to do for ASP.NET apps easier within CSLA. But all those helpers don't do much for the user-interactivity features within the browser - even with the ASP.NET injection of some of the data-annotation features, you're still likely writing a fair amount of JavaScript/jQuery code on your own to complete the picture.
I'd also like to point out that your "trenches" aren't necessarily everybody's trenches. There's still a sizable portion of the community who has yet to come to terms with those devices, or has decided that they have no place in their organization. Thus, the math says that CSLA is likely being used in fair numbers in these organizations. And before you say that they will all be left behind in the dustbin, I'm talking large organizations - including government organizations/entities - who change course slower than a cruise ship and, whether we like it or not, exert quite a bit of influence over what happens in software development. They will not be easily discarded. They are changing, if for no other reason than those entering the workforce are more comfortable with/expect to use those technologies. But these organizations have an inertia all their own that tends to push back against "the new shiny" pretty hard. And like it or not, most mobile devices are still considered "the new shiny'.
Just my two cents...
- Scott
If all you are doing is building HTML apps for the phone then (without giving it to much tough) I would agree with you. However, the idea (I think) is that you would be doing *Silverlight* development on Android. And Silverlight can benefit a lot from a framework such as the CSLA.... more than just mobile objects.
If you where developing for WP7, what would you use? HTML or Silverlight? If the answer is Silverlight, why would't you want to use the CSLA? whats wrong? what are the drawbacks? what wrong with having all that power locally even if you are not going to use it just then? Its there for free right? so whats the problem? You are assuming that performance may be an issue but it may not be. So what is wrong then ?
I deal with apps that are huge databases shared by lot's of people, there is just no practical way to use almost any of that information disconnected. I assumed that anyone who would even consider using CSLA would be in a similar situation since the framework is designed for such a situation but I guess what I'm hearing is people are using it for small personal apps or apps that can have chunks broken out and used as small personal apps.
I don't understand that or how it can be so common or how you can break out portions of your app like that using CSLA, perhaps a whole new EBook for Rocky?
In any case I'm not saying don't make mondroid sample, I just don't see how it will work in practice, I'm simply advocating a sample utilizing what I believe is the far more common case that is needed right now: people using lightweight devices to access a CSLA application via the internet.
It's not fundamentally new, CSLA already comes with an asp.net MVC sample and has had an asp.net sample since day one. Surely there are people using those interfaces with CSLA?
Thanks to the data portal, CSLA supports several key architectural models.
Perhaps the most common is a 2-tier model where the app runs on a smart client and interacts with a database.
Though also very common is the 3- or 4-tier model where the app is continually interacting with an app server for functionality and data.
Another common model is a 2- or 3-tier model where all the code runs on web and/or app servers and a presentation layer is projected to a browser.
Yet another, and this is where mobile devices really fit into this conversation, is a 1-tier model where the app is running on computer or device, and uses a combination of local cache storage and remote service calls (not data portal calls - service calls) to interact with servers.
Even on mobile devices you can choose between 1-, 3-, and 4-tier models. The 2-tier model really doesn't work in any meaningful way.
When I think about a typical CSLA-based app running on my iPad, I think about a 1-tier app that uses local cache storage, and also interaction with REST or SOAP services when connectivity is available.
This is also how I think about a typical CSLA-based app running on my Win7 tablet. Though in this context my "local cache storage" is probably SqlCe or SQL Express, and that 's a whole lot nicer than the XML files we have to use in most mobile scenarios. But I'm sure that we'll see some nice client-side database options for mobile devices as that space matures.
To me the most important thing is to understand two things:
When I think and talk about big picture future topics like this, I personally can't help but think about the future I really want. And that's driven by my areas of professional interest, and by economic reality.
All we can do is guess about economic reality. HTML5 has a lot of hype right now. It won't live up to the hype, but that doesn't mean it won't be widely used. Nor does it necessarily mean the smart client is dead. I heard that in 1997 when the web first went mainstream, and here we are doing smart client work...
But I don't have to guess about my areas of professional interest. I love building apps that run across many computers, many cores, many processes, etc. Distributed computing is just plain cool - to me it is way more cool than pretty much anything else :)
I suspect you're right, the computer as we know it now is definitely on the way out. That's why I feel so strongly about the web browser interface because it's so universal it's future proof for some time.
But beyond that it can and does offer a compelling and rich user experience and is widely used for business applications already and has been for years now.
To me a phone is a thing to play angry birds on or check off your todo list, not run and *host* software and large databases that run your business processes.
I totally get new challenges and new platforms though that is much easier for you than it is for me, I have thousands of users to think about worldwide and a certain responsibility to be ahead of the curve but not so far they can't see our taillights.
In the vein of new and cool challenges on trendy new platforms I urge you to have a look at JQuery Mobile http://jquerymobile.com/
Cheers!
Copyright (c) Marimer LLC