Showing posts with label android. Show all posts
Showing posts with label android. Show all posts

Wednesday, October 05, 2011

Meeting of Android Australia User Group - Sydney 05/10/2011

I attended my first meeting of the Android Australia User Group - Sydney this evening.

The organiser, John Scott, started with some general announcements, which should be of interest to many.

- There is an Amazon Cloud Drive Developer Tech Talk in Sydney on Monday October 10, 2011.
- Google Developer Day will be on November 8, 2011 in Sydney.

Those interested should register for these events. They're both free, as far as I know.

John then kicked off the first talk of the evening, which was a brief overview of Motorola's IDE for Android application development - MOTODEV Studio. According to John, this IDE is better than the Google Android plugin for Eclipse, which seems to be the de facto IDE for Android, because it has a few extra features like the generation of boilerplate code to make the developer's life easier, and also graphical tools to manage SQLite databases. I found a couple of other discussions on MOTODEV Studio vs Eclipse here and here, but they seem somewhat dated.

The second talk was by Gianpaolo De Biase, a developer with AppCast. Gianpaolo talked about some real-life applications that his company has built (one of which is JustStartWalking, an app for an initiative of the same name from the Chiropractors' Association of Australia). He also discussed two important architectural decisions that his company made when developing these products.

1. When dealing with local databases, Gianpaolo recommends using an Object-Relational Mapping (ORM) tool rather than the raw SQLite API provided by Google. The tool he used is OrmLite, which is Open Source like Hibernate but more lightweight and adequate for the simpler data structures needed for local storage on mobile devices.

2. When making REST calls to remote servers, he recommends using the Spring Android module with its REST Template in preference to raw HttpClient. He did encounter some bugs with Spring Android in the areas of cookie management and SSL certificates, but believes the product is rapidly maturing.

As a side benefit of both OrmLite and Spring Android being annotation-based, Gianpaolo was able to have a single set of domain objects. Each object had two sets of annotations applied, one for persistence and one for interfacing with REST services. [I'm a bit suspicious of the latter annotation, since it looks like the design combines domain objects and message documents into a common entity, a form of tight coupling I've long warned against.]

After a short break, we had our third talk of the evening by James Zaki, a freelance developer with goCatch. This was a high-level description of the goCatch app, which brings together cab drivers and prospective passengers. There was general satisfaction expressed around the room in favour of this cartel-breaking app, since the taxi companies and CabCharge engage in significant rent-seeking behaviour at the expense of both drivers and passengers. goCatch allows the two to bypass the middlemen. I had some reservations about one of the aspects of the goCatch design as described by James, i.e., its statefulness, which led to problems of synchronisation of state held on devices with that on the server. Perhaps a suitable set of messages based on idempotence could solve the problem. I didn't have time to discuss this offline with James.

Our fourth and final talk of the evening was by Darren Younger, CTO of IPScape, in whose offices the meeting was held. IPScape is a provider of cloud-based contact centre solutions catering to both voice and web. One of their interesting applications allows mobile device users to make phone calls not through the device's native telephony capabilities, but through the IPScape app. The server then initiates regular (teleconference-style) phone contact with both the caller and the receiver. The advantage of this is that the server can record the call. Many financial service providers are required by law to record all customer conversations, and it is easier for them to use this app rather than approach the telcos for a voice recording service. A developer API may be coming in a few months.

I also met another attendee, Nanik Tolaram, an amateur Android enthusiast with his own Android-related website.

I picked up a few useful tidbits of information over the course of the evening.

Samsung sent a couple of people to the meeting. They seem keen to understand the size and strength of the Android developer community. Samsung wants to carve out a unique niche even within the Android ecosystem and they have their own app store separate from the generic Android one.

DroidDraw is a testing tool for Android User Interfaces.

Google has a cloud-to-device API.

developer.android.com is Google's portal for Android developers.

Balsamiq is a commercial tool to mock up UIs, including mobile UIs. Pencil seems to be a good Open Source equivalent, and Lumzy is a free one.

Two of the presenters talked about their negative experiences with outsourcing. Although the outsourcing countries were as varied as Israel, India and Singapore, there seem to be some common problems caused by distance as well as the seeming cultural inability of some developers to look beyond the literal specification and to understand the higher abstraction that an application is trying to implement. Errors in the documentation of some specs led to literal implementation of those features even though they patently made no sense. Outsourcing sites like Freelancer.com seem very cost-effective, but the elapsed time to obtain a working solution negates those benefits. Examples: $200 and 4.5 months to develop an app, $800 and 9 months to develop another. The moral of the story seems to be to hire good local developers so communication problems are reduced and results are achieved quickly.

The Android Australia User Group is a good place for developers to hang out. The organisations that some of the speakers represented are looking for developers, and this may be a good way to get introduced.

Thursday, April 23, 2009

Adventures with Android - 1

Since I'm so convinced that Android is going to take over the world ;-), I decided to walk the talk and try some Android development.

My desktop machine runs Ubuntu 8.10 (Intrepid Ibex) and I have OpenJDK 1.6.0_0-b12 installed. Ubuntu 8.10 doesn't give you the latest version of Eclipse (3.4 - Ganymede), so I downloaded and installed it separately.

Then I pointed Eclipse to the Android SDK plugin site and installed both the Android Development Tools and Android Editors. I have no idea what Android Editors are required for, but bandwidth is cheap, so what the hell...

I have no idea why, but I also downloaded the Linux version of the Android SDK separately. (Maybe I downloaded this before the Eclipse plugin, I don't remember.) My standard policy is to install all software under /usr/local with the exploded directory having the full version number, then to create a symbolic link without a version number, which points to the latest directory.

i.e., /usr/local/android -> /usr/local/android-1.1r1

[This way, I can keep multiple versions of software installed simultaneously, while pointing to the latest version through the symbolic link. If required, I'll use the symbolic link in PATH and CLASSPATH variables, so I don't have to change them when I upgrade or downgrade versions. The power of symbolic links...
Unix was pretty cool even twenty years ago :-).]

If I now open a terminal window and go to /usr/local/android/tools, I can execute the Android emulator by typing "./emulator". Be warned that even though the emulator comes up right away, it takes a few minutes for it to fully initialise and display its beautiful mobile screen.


I played around with the emulator for a while. This is pretty cool. The apps actually work. I checked out the browser. I could see my own blog. Then I went to Google Maps and saw my own house. It's pretty eerie, sitting inside my house at a computer running an emulator running a browser that shows a street view of the same house from the outside. MC Escher would have loved that.

Well then, the next step was to follow the tutorial and build my first Hello, World application on Android. The tutorial is designed for Eclipse with the Android plugin. I followed it fairly faithfully and got my first application running.


It was only when I tried to deviate from the script that I ran into trouble. The tutorial advised me to edit the "strings.xml" file in "res/values", but I couldn't see the file in the Java perspective. So I thought I'd create one, but I couldn't because Eclipse told me a file with that name already existed! No problem, I thought naively, let me at least try and create a "strings2.xml". After that, the application simply stopped working. I'm sure it was because of the empty XML file that I had created, but the SDK didn't allow me to even see the file so I could remove it. I don't remember what sequence of steps I followed to finally see the two XML files and remove the offending "strings2.xml". The app started working again, to my relief.

If anyone at Google is reading this, please note that even non-newbie Java developers can find the Android SDK confusing in places.

Anyway, that was my first baby step into the world of Android. I'll continue to blog about this as and when I get time to progress through the tutorials and build more stuff.

Wednesday, April 08, 2009

The Computing Platform of the Future

What will the computing platform of the future be like? (The consumer-side platform, that is)

It'll be a super-slim, compact and lightweight laptop with some innovative folding smarts that will let people carry it around in their pockets, yet open it up to a regular laptop form factor for ease of use. It will feature several important innovations, some of which are already available, or tending towards a tipping point:

1. Really cheap hardware - $50 for the device that you can pick up at the supermarket and toss into your trolley without a second thought (impulse purchase territory)
2. Absolutely free software either on the device (like OpenOffice) or in the "cloud" (like Gmail)
3. Ubiquitous wireless connectivity (some cities do have 'em)
4. High network bandwidth (Australia is investing in this right now)
5. Breakthrough battery technology that lets you work a regular day without power supply

Needless to say, this device will double as a mobile phone, portable music player, portable video player, SatNav, game console and much else. This "computing platform" will be the enabling innovation that will let many others ride on its back. And it won't be a real innovation so much as a perfect storm of many tipping points being reached at the same time.

The key technology to watch is Android. By standardising and commoditising the core software layer, Android will enable innovation both below it (i.e., hardware) and above it (i.e.,applications) in the stack.