Thanks to the great response (and many hundreds of visits to this page over the last two days), I’ve gone ahead and created a real project website for AML at http://www.amlcode.com, as well as the @amlcode Twitter account. If you’re interested in more updates, check those out. Thanks for all the comments and ideas! Keep them coming!
This post still has some good info and some great comments, so don’t neglect it completely. It might get lonely.
I gave myself a crash course in Android development over the last few days. I’d officially been part of an Android team as part of a project management class in my last quarter at Cal Poly Pomona, but some of the other members on the team ended up doing most of the actual development, so my instructive coding experience was pretty minimal. I knew enough to get the Android SDK installed in Eclipse (which is painfully slow, by the way!), but that was all. Everything else was new to me.
Now, I am very familiar with C, C++, and Java, even though most of my coding for my job is done in PHP, so picking up the Android vocabulary within Java was much easier for me than it would have been if I had no programming experience at all.
I don’t have a specifically defined project to work on yet, but I do have some general requirements for the Android app(s) I’m sure I will be developing in the near future. Specifically, I know I will need these features:
- Native implementation (Android UI, not HTML5)
- Dynamic externally generated content and navigation
Both of those two features together are, I believe, not a common combination. It’s simple to have dynamic externally generated content and navigation, if you use HTML and a browser. It’s also simple to have a native UI support externally generated content, if that content always fits into a pre-defined structure which you build into your app. But what if you want an app that supports a system with very little known ahead of time—just an email address and password, for instance—and the rest of it need is determined based on parameters, permissions, and a web service API?
Then, I thought, why not write a native Android library that will accommodate that very thing?
And that’s what I did.
I even had the presumptuous audacity to give it an official-sounding name, though it is by no means official (or truly useful) just yet. There is no W3C specification for it. And for all I care, it may never become official, but even if I’m the only one who uses it, this library it will certainly make things easier for me. And on top of that, it’s been a great learning experience over the last four days.
Ladies and gentlemen, I introduce to you AML, the App Markup Language, a simple XML-based language that allows you to easily build a clean, functional application for your mobile device.
It resembles HTML in some ways, but it is not a subset of HTML. It is designed to be intuitive and easy, and while it does not implement every possible feature achievable with native Android code, the goal is for it to cover the vast majority of what is necessary for information-based apps, and leave the rest up to you to implement as you desire. It probably won’t help out much with games, but it’s perfect for mobile implementations of websites. It can even be used as part of a local-only application to quickly build the UI instead of using Java code or Android’s layout XML structure.
Additionally, I would love at some point to extend AML in two directions: one, to have it support other devices (namely the iPhone and iPad), and two, to support different languages for the markup (namely JSON, perhaps YAML). While I don’t need these right now and may not actually need them for some time, there is nothing really Android-specific or XML-specific about the language. I have never written code for iOS, so I don’t know if the behavior is inherently different enough to cause a problem, but I bet it isn’t. You should be able to use the same AML markup to generate nearly identical experiences on Android and on iOS.
So, why is AML so cool? Why would anyone want to use it? Check this out.
The images on the right shows a set of different input objects in an Android app. It’s just an example, obviously—an app in the Market that looked like this would be odd indeed. However, it does illustrate a very basic layout with a few different objects.
Now, anyone who has done any Android development know that there isn’t anything truly difficult about building something like this. If you write your own “main.xml” layout file and use it for your Activity object’s content view though, it can be a little tedious. You can use a tool like DroidDraw to speed things up (which is an excellent idea if you need a static layout), but with both of these approaches, your design will be hard-coded into your app. You can only make changes on the fly through clever uses of the LayoutInflater service.
Your other option is to build the layout using only code. This allows for more dynamic design, for sure, but doing this manually is still tedious. AML bridges the gap between an external data source and the native application, so that the external source can very simply instruct the app what to build and how it should behave.
This is the Android layout XML necessary to create the layout shown above in the screenshot on the right:
<LinearLayout android:orientation="vertical" android:layout_width="fill_parent" android:layout_height="fill_parent"> <Button android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="Test Button" /> <CheckBox android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="Test Checkbox" /> <ImageButton android:layout_width="wrap_content" android:layout_height="wrap_content" android:src="@drawable/icon" /> <ToggleButton android:layout_width="wrap_content" android:layout_height="wrap_content" android:checked="true" /> <EditText android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="Test Text" android:singleLine="true" /> <EditText android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="Test Password" android:password="true" android:singleLine="true" /> <RadioGroup android:layout_width="fill_parent" android:layout_height="wrap_content" android:orientation="vertical"> <RadioButton android:layout_width="wrap_content" android:layout_height="wrap_content" android:checked="true" android:text="Radio Button 1" /> <RadioButton android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="Radio Button 2" /> <RadioButton android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="Radio Button 3" /> </RadioGroup> </LinearLayout>
Keep in mind that the above code is basically fixed, and cannot really be customized at runtime on a large scale. Now, for comparison, here is the AML necessary to create the layout above:
<aml> <input type="button">Test Button</input> <input type="checkbox">Test CheckBox</input> <input type="togglebutton" checked="yes" /> <input type="imagebutton" image="drawable/icon" /> <input type="text">Test Text</input> <input type="password">Test Password</input> <radiogroup> <input type="radiobutton" checked="yes">Radio Button 1</input> <input type="radiobutton">Radio Button 2</input> <input type="radiobutton">Radio Button 3</input> </radiogroup> </aml>
It’s that simple. Additionally, for my tests, this layout info was actually being pulled from a web service, just so I could prove to myself that I could do it. The web service dynamically built that layout.
Seriously, can it get any easier than that? You can store this kind of layout definition in your app code and reference it directly from there, or you can use a web service to build this stuff on the fly and send it to your app (though you might want to implement some sort of caching mechanism in that case, for efficiency). The AML library is in its own package, and doesn’t require any imports from your package to work. You do need to put the template layout XML files into your
/res/layout folder, but that’s all. AML doesn’t require you or your web service to know the details of how Android builds its views. It doesn’t depend on some extra plugin installed on your device, and it isn’t passing your app code through another service. You probably still have to write some Java code to accomplish your goal, but this makes the whole thing easier.
So far, what I have written only supports layouts, but no actions. Many objects support attributes like
bgcolor, to name a few. The rest of the code just isn’t there yet. I have been building the
hold attributes into buttons and other clickable objects, but I’m not done. I haven’t done a date picker, time picker, or spinner (Android’s version of an HTML
<select> element). But it’s coming together very quickly—a lot faster than I thought it might. It’s been an awesome learning experience so far though.
I’m writing this for me, honestly, but I’m really interested in any kind of outside interest. Any questions, comments, or recommendations? Has anyone else done this? Would you be excited to get your hands on this code? If you used it, what would you need it to be able to do?
Let me know in the comments!
I’m a web developer, not an android developer–but typing from my android phone. A few thoughts:
1. AML makes mobile development less scary to noobs
2. Implementation on other platforms such as iPhone or Win7 could be huge
3. The web is evolving to support many behaviors and concepts unique to mobile phones (e.g. accelerometers, touch events, multi-touch, etc.) But native Apps will never go away
4. Have you thought about making a script that tranforms AML into html? Maybe AML could be a general templating language? Maybe it would be possible to create web/mobile apps with the same templates
Thanks for sharing!
Thanks for your feedback! Your first point is exactly what I was thinking, and is my primary motivation for wanting to give this to the community once I make it work for me (or even before then, depending on how the development goes). I assume by “Win7” you are referring to the Windows 7 Phone series, and not the desktop OS. If so, I’d definitely like to see that happen as well, though for faster adoption and higher interest, I think I’d want to put it on the iPhone platform first.
Your third point gives me hope; I sometimes wonder if that’s the case particularly for the kind of app design I’m hoping to streamline with this project. I think games will probably never migrate away from native code, simply for performance reasons if nothing else. But I can imagine that HTML5 and better browser implementations may evolve on mobile devices to the point that something like AML won’t be as appealing to a developer because, while it is easy, just building a web page for a mobile device is even easier and accomplishes 90% of their goal.
For your fourth point, that also is a really interesting idea. I’m not sure if that would have enough perceived benefit for developers though, since the visual limitations of most mobile devices might make it seem like making your web app the exact same structure as your mobile app would be a bad idea. You can do so much more with HTML5 and CSS3 that if all you had was a mobile-like interface, a full desktop web visitor could be dissatisfied. Perhaps AML could strip out non-mobile-friendly elements from the design though during the native mobile conversion process…hmm. That will be good to keep in mind while I keep working on it!
[…] This post was mentioned on Twitter by Richard Laksana. Richard Laksana said: Rapid Android Development with AML – http://su.pr/2hRDiM […]
I can absolutely see that this (or something similar) could be useful in some scenario’s and I will keep an eye on this.. Always good to see some one trying out ideas and pushing things forward.
I have some comments though:
In your scenario it removes clear separation between the back-end service and the front-end client. The back-end service providing AML is deciding how it should be rendered, rather than providing data and allowing the client to decide how to render it. Fine in an entirely captive scenario but not entirely ideal or usual.
Also, instead of creating an entirely new mark-up to learn, could you dynamically create the standard Android XML in you back-end service and create some kind of re-usable client in Android that would inflate this XML using LayoutInflaters to create views on the fly.
Overall, I’m not sure I want to learn a new mark-up (and it will be a new mark-up because of all the Android nuances) for a reasonable niche scenario. Creating Android XML is not that painful most of the time and it is quite powerful once you understand it well. It is not that difficult to generate dynamic content as you can combine Android XML with code generated components.
Those are good points. It does remove separation between the data and client, to a degree. At least, it departs from the general behavior of the device as the client and the web service as the data provider. It essentially turns the device into a thin client, using the web service for data as well as visual behavior. This is definitely not something you would want to do for every app, but for some it makes sense. My need is for an app that provides a logical mobile implementation of a web application. The web app is built in a modular fashion on top of an extremely basic framework, and I didn’t want to have to update the mobile app code every single time I wrote a new module for the web app. AML will (hopefully) allow the mobile app to evolve at the same pace as the web app without needing constant revisions.
As for the need for a new markup language, I honestly wasn’t absolutely thrilled with the idea of throwing yet another vocabulary into the mix of the thousands of little niche languages that are already out there. And you’re right that the Android nuances do make it necessary; hijacking pure HTML for example, and bending it to fit a native mobile UI, would have been even more confusing and probably not a good solution at all. I also wondered about using the web service to generate pure Android layout XML content and sending that to the device instead, but what I found makes me believe that isn’t currently possible:
If the Android team ever changes that, then it could be possible to do what you suggest. I agree that building Android XML isn’t really that difficult once you get the hang of it, and it certainly does give you more power and flexibility than the relatively limited AML is able to give.
And yes, you can generate dynamic content by combining Android XML with code generated components. At the most basic level, that’s exactly what AML is doing–it uses LayoutInflater with pre-defined, bare-bones Android XML files and then customizes them using native code. AML is just a library that abstracts that process into a really simple bit of markup. It just makes it really easy on the developer. I anticipate that some devs will like this, while others will decide against it because they want to control everything directly, and/or they want to be able to do more than what AML is capable of.
I would prefer
as checked = “yes” makes no sense on type=”text”
QtQuick/Qml has a nice json syntax.
I’m not sure what you mean about
checked = "yes"on
type="text". You are right that it wouldn’t make sense, but why would you put it there in the first place? You can do the same thing in an HTML input element, and AML will react the same way, by ignoring it. Putting
checked = "yes"on an input with
type="text"will have no effect. The AML parser won’t even look for a
checkedattribute on a text input. I am wondering if something got lost or malformed in your comment between the words “prefer” and “as.”
QtQuick/Qml is intriguing. I’ll definitely check it out for reference when implementing JSON-style syntax for the libary.
About AML already being taken…hmm. I’m not totally stuck on using AML for the name, and I’m open to suggestions. But on the other hand, is it absolutely necessary to have a unique name for something like this? Confusion is not my goal, but further Google searches show multiple groups or individuals using “AML” to describe different things. Within the Android idea space, am I safe to keep this? Will developers get confused otherwise?
AML is already taken
Hi, it is a good idea…I am working on a similar one…did you plan to make it opensource?
Thanks! I am indeed planning to make it open source. Absolutely. The only reason I don’t have the source up right now is that as it is, missing a few key features, it isn’t really useful as a library. Once I get some event handling in place, I’ll make all the code available and hopefully write some basic instructions. Good luck on your similar project–unless you just want to wait for this one now.
Thanks! I hope to have a useful tool available for you all shortly. I’m glad you like how it’s turning out so far.
So far, there is nothing in the code that requires a specific screen size, while there is a density detection feature that should help standardize the behavior across multiple sizes. Android has a nice unit called a “dip” or simply “dp”, meaning Density Independent Pixel (as you may already know). Unfortunately, directly building views with code only allows you to specify absolute pixels; you can only use a “dp” unit in the /res/layout XML files (grr!). However, the API provides a way to detect screen density and simply calculate a scale factor. This is done automatically by the AML main build method, and then it is used automatically whenever pixel values are given. So, if I specify a
padding="6"attribute on a table cell, it will automatically multiply it by a scale factor of 1.5 on my Motorola Droid (854×480), and use a literal pixel value of 9. This feature will ultimately be optional, but it does work great for now.
The same AML code works in both portrait and landscape mode as well, though it is my goal to allow a unique view definitely on the same Activity screen for portrait and landscape mode, so you can rearrange things based on orientation if it makes sense to do so. That feature isn’t there yet though.
As for theming: although you can specify foreground and background colors on individual objects, I realize this falls short of what will be necessary. I have read a little bit about Android’s themes and styles, but that’s it so far. I’m thinking maybe something analogous to CSS, and/or something to access styles built into the app. That’s lower on the priority list than getting the basic functionality to work, but still important.
wow, that looks great and very promising. I would definitly prefer this “aml” to android layout xml. So the yes i definitly would want to get my hands on this!!
I just wonder how does it behave with multiple screen sizes and also how would I theme it, make it look presentable.
… very interesting, like the concept. So I read your post first thing this morning and think “how come heavy weight companies don’t come with tool sets ala VB6 when releasing wonders like Android?” Leaving VB6 aside, the general concept of reducing dev’s workload makes life so much easier for all involved.
Then later this morning this comes out:
Wow, that is awesome! It’s like DroidDraw on steroids and provided by Google. That is a great move on their part—though I tremble to think of the deluge of lame apps that may flood the Android Market as a result of this. Not to knock it though; I’d much rather have to wade through 100 lame apps if the same tool also produces one absolutely stupendous one. It certainly does lower the barrier to entry for Android development, that’s for sure.
I think AML will still be able to fill the “thin client powered by a web service” niche though, and some developers may still prefer coding to the GUI-based experience provided by AppInventor. I personally like VB for some tasks, since it really is easy, but I know some people who don’t care for it. I’ll have to play with AppInventor for a bit now.
…. my thoughts exactly, the beauty of it all is that Google leaves a lot of open room for everyone, so there’s a place for what you’re developing. Even more important IMHO is the massive seeding of a robust dev community. Low entry barrier is critical. Not sure if your a fan of soccer (pardon my language), but sure has low entry barrier. Kids play it with about anything, starting with pebbles, to tin cans, to the latest and grates from Adidas. Eventually some end up holding the trophy at the end of a global festival, transcending every barrier human kind is capable of fearing up.
[…] [2010-07-13 04:57:29] ravikbhatt RT @darshanabafna: Rapid Android Development with AML – http://www.sectorfej.net/2010/07/10/rapid-android-devel [2010-07-13 04:57:25] pedronveloso Steve Jobs Rewriting Android History? http://bit.ly/cfL1pt [2010-07-13 04:56:50] […]
[…] shared a blog post about what I came up with on D-Zone, and received a tremendous response—over 800 visits in […]
[…] Rapid Android Development with AML | SectorFej […]
[…] This post was Twitted by aringhosh […]
[…] at http://www.amlcode.com. The website has all of the important info transferred over from my original blog post about the project, and a much more structured layout (obviously). There’s a feedback form for […]
it was very interesting to read.
I want to quote your post in my blog. It can?
And you et an account on Twitter?
No problem, go right ahead. Please feel free to quote anything you like. My twitter account is @sectorfej, and the new one that I created for the AML project is @amlcode.