Hardware platform
The main constraint is to have hardware that's easily available as a physical artefact, as well as being able to be used on a device emulator. The three main contenders are iOS, Android, and WinPhone.Android's the most ubiquitous of the three, and you can pick up a cheap Android handset for not very much. I think that's the one to support. If the same software can be made to run on different devices, that's a plus.
Software platform
There are lots of choices. I'll go through a few of them.Native Java
The traditional way of building native applications. Apps can be built on a PC, via something like the Eclipse IDE and an emulator, or directly on the device with AIDE.
Advantages- An easily marketable skill. The use of Java would build on student's existing skill sets. It would also act to consolidate their existing learning.
- Students get fine control over everything in their apps.
- GUIs are possible and responsive
- Students can create any app, including highly-reactive GUIs and Services (long-running threads).
- Existing code examples to crib from, and existing third-party libraries to exploit.
- It requires that students be proficient in Java, which limits the audience of the module.
- There's lots of control, but there's also lots of moving parts. The control and detail required mean that developers have to manage a lot of detail.
SL4A (Scripting Layer for Android) + Tasker
SL4A is a simple API that sits over the Android virtual machine. It supports a number of scripting languages, including Python and Ruby. It allows access to the sensors on the device and control of the device (camera, GPS, etc.). It can create dialogs, but it can't create Activities (general screens) or Services (long-running operations, generally without a UI). Interestingly, it can create Intents, which allows it to exploit existing applications on the phone (such as asking for the default email client to send a mail).
Scripts can be written on the device or sideloaded from elsewhere.
Tasker is an Android automation app. It makes the phone perform various actions (e.g. alerts, changing settings, running an app) in various contexts (e.g. time, location, movement, when receiving a call). It's quite functional in itself. It also allows for the creation of GUI screens (though limited) and can continually monitor the state of the phone (similar to a Service). It can also call SL4A scripts.
Tasker scripts can only be created on a device, but completed scripts can be downloaded or sideloaded. That would allow scripts to be written on an Android emulator on a PC then sent to a real phone.
Together, the two apps can do a lot. Tasker can handle the UI and provide Services. SL4A can handle more features of the phone and provide more functionality more conveniently.
Advantages- Easy to get started
- Allows for a range of scripting languages to be used
- Fragmented implementation, with some features in the Tasker and some in SL4A
- Tasker is a graphical app builder, so it can be hard to see what's going on.
- Tasker Scenes aren't great for building responsive IDEs
- Tasker continues to be developed, but I'm not sure how vibrant SL4A is.
HTML5 + CSS + JavaScript + PhoneGap
You can build some very capable web apps with HTML5 +CSS+JS. With PhoneGap, you can compile them down to something that will run natively on most devices. PhoneGap apps also have access to the phone's hardware. With the right SDKs, PhoneGap will target most mobiles, including Android, iOS, Blackberry, and Symbian. Development and testing can happen in a web browser.
It's all written up nicely in an O'Reilly book, Building Android Apps with HTML, CSS, and JavaScript (Beta version).
Advantages- Saleable, transferrable skills. HTML5 powers web apps, but also Windows desktop widgets and various other things.
- Truly platform independent.
- Many third-party JS libraries allow for complex functionality and responsive UIs to be quickly developed, such as allowing drag-and-drop.
- JavaScript isn't the easiest language in the world to learn, with automatic type conversion, poor support for OO, and some idiosyncratic coding practices.
- Development can be a bit fiddly, especially when bits of the UI are spread around HTML, CSS, and JS.
Ruboto
Ruboto is a JRuby implementation that runs on the Dalvik VM on Android. It also provides a Ruby-flavoured access to all of the Android API and a Ruby-flavoured way of describing Activity layouts (it ends up looking similar to XML Builder in Ruby).
Advantages- Close integration with the Android API, giving full access to everything the phone can do.
- Ruby is much terser than Java, so you can get things done quicker.
- Full access to standard Android layouts, making GUI design easier.
- It's another language to learn.
- You still need to know the details of how Android handles Activities, Intents, and Services, the Activity life cycle, and the Bundles that get passed around.
Rhodes
Rhodes looks like Ruby on Rails for Mobile. Like Rails, it's intended to allow people to build database-backed apps easily. It can also easily interact with databases over HTTP, such as traditional Rails apps. It uses JavaScript (JQuery) to handle UI niceties.Advantages
- Capable and handles data-heavy apps well.
- Requires JavaScript in addition for GUI polish.
- Requires apps to fit the MVC model, so that needs learning along with Ruby and Android.
TouchDevelop
TouchDevelop is for Windows 7 phones. It's a development environment that runs on the phone itself. Scripts are written in a script-like syntax (akin to Python, Ruby, and the like), but not exactly the same as them. It seems to have full support for all the phone's hardware. It also has a very nice physics engine built in for the development of games.Advantages
- Unified development environment.
- Physics engine with support for games.
- It runs on Windows phones, which are few and far between.
- Another language to learn which won't translate to another context.
Kivy
This is a cross-platform app development environment using Python. GUI design uses some standard layouts, customised with a very simple markup language. Behaviour is specified in Python. The API includes support for all the device hardware. It looks like to can be embedded into PyGame for easier game development, but I've not yet investigated that fully.
Advantages
Disadvantages
- Uses Python, which students should already be familiar with and is well-supported elsewhere.
- GUI design easy, but not sure about drag-and-drop..
- Probably integrates with PyGame (but needs checking)
- May not have complete access to everything on the hardware.
Conclusion
There's a lot of choice, and a range of capabilities. Apart from raw Java programming, all of the solutions require third-party tools which may not be suitable in future: they may move behind paywalls, or may not support future versions of mobile platforms.
Raw Java is out, as it's probably too complex.
Rhodes is out, as it requires too much additional expertise with MVC frameworks
TouchDevelop looks lovely, but the low availability of WinPhones rules it out.
That leaves SL4A+Tasker, HTML5+PhoneGap, Rubuto, and Kivy. The four offer different degrees of power, flexibility, and easy of use. It's difficult to choose between them.
I think that the best approach is to code up a sample note-taking app (with drag-and-drop list ordering and photo capture) in all four to see how capable they are and how easy it is to build.
What do you think? Any recommendations?
What do you think? Any recommendations?
No comments:
Post a Comment