> 1.) How is AML different from using HTML with Webview? I have an ongoing and interesting discussion with John Coryat about that very thing, after he suggested using WebView to avoid reinventing the wheel. There are situations where you could effectively use either WebView or AML to accomplish your goal, and it will depend on your preference and/or familiarity with Java vs. HTML/CSS/Javascript.
My understanding of WebView before talking to John was almost zero, but I have since learned more. It surprised me to find out that the Gmail app uses WebViews, and I'd love to find out how exactly (I'm guessing for message rendering, but maybe other areas as well). Here are the differences I came up with originally--please keep in mind that I now know these are not all totally valid points: 1a. WebView displays HTML/CSS/Javascript, but does not provide web- based access for directly creating or responding to native UI components. 1b. AML dynamically interprets the markup to create native UI components and capture events. 2a. WebView presents a browser-like interface, so that tapping on a link (for example) is really directing the WebView to a new URL, and not firing a click event within the same Activity. 2b. AML (as mentioned in 1b) attaches and handles native events. 3a. Apart from some outside control by the app, WebView actions all take place within the same Activity (where the WebView object is placed). 3b. AML blocks may define multiple unique Activities which can have objects and events that may direct the user to completely new (and potentially dynamic) Activities or Intents. John has explained that WebView does indeed provide a way (the addJavascriptInterface() method) to use Javascript inside the WebView content to interact with Java in the native App code, even firing events and moving to new Activities. Therefore, all three points above can be overcome at least in a limited way by using WebView. But it doesn't seem efficient to use this kind of method to attempt to create a 100% dynamically built native app, which is what I'm going for. Some people will always prefer a native implementation for some projects, either because of the visual differences, or because it's almost definitely going to be faster, or both. While AML probably wouldn't be faster than WebView if every single user action resulted in a request/response/parse/interpret/build operation, I think the actual flow will be very different. My goal is to have a web application send the complete collection of the whole app interface all in one shot, except for 100% dynamic aspects like search results or detailed views of every discrete data entity. This way, aside from the initial load, the app will be much faster and cleaner than a simple web-based version could ever be. Since a decently complex Activity could be created in perhaps only 2K of AML data, it is reasonable to assume that a dozen or more individual Activities could be built and sent to the device all at the same time. With a clever bit of short-term caching and background loading, it might even be possible to completely hide the fact that each layout was built on-the-fly by a remote host. I don't want to build a "one-page-at-a-time query/response" library, since that would have minimal to no benefit above other options. I anticipate that AML will be used mainly with web app APIs that take advantage of multiple views and caching, and not by just directing the app to parse whatever data is at "http://aml.mywebapp.com/index.php"; and then browsing page-by-page using a limited but native interface. Hopefully that all made sense, and is logically sound. :-) > 2.) I would use it right away if it were available for RIM's OS. That > platform can immensely benefit from a well supported and efficiently > implemented markup language for UI. I haven't thought about supporting that OS, though I definitely don't see why it couldn't be done. I'll keep it in mind and try to do some research in that direction. Thanks for your input! Jeff -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
