Programming mobile phones (Part 2) .. Android wins

I have made more progress on the mobile phone subject. We are going with Android as the platform but the bulk of the subject will be platform agnostic.

The initial plan was to use iPhone as the device for teaching (driven by their popularity). However, after carefully considering the practical aspects (need for dedicated Mac labs, teaching Objective-C and the learning curve involved) we are going with Android.

Broad topics that we will cover are:

1. Mobile devices -- Hardware and Operating Systems (we will cover general principles with Android & iPhone as case studies)
2. Interaction Design and UX (mainly usability related aspects and applying a design approach that works well -- navigation and state charts)
3. Development Tools, Libraries and Frameworks (Android and iPhone. Will add Windows Mobile 7 if sufficient detail is available)
4. Design Patterns for User Interface Development (Splash screens, Status updates, MVC, Passing information around, modality, state handling, event handling etc.)
5. Data Handling (File, Network I/O, Local DBMS like sqLite, Resource bundles)
6. Mobile Web Applications (Concepts, Principles, Design patterns, HTML5)

7. Programming mobile devices (Concept-Design-Program-Deploy. Android as the dev. platform)

Teaching method will be based on lectures with demos, spikes, 2 short tests and a portfolio.

I am currently working around 1 hour lecture and a 2 hour lab session model.

We are also planning to develop 3/5-day short courses that are going to focus on training iPhone programmers and Android programmers.
========

One of the interesting things that I find in touch devices is the complete lack of a concept of 'tool-tips' as you hover over a button or a link. This essentially means that the icons have to be really well designed to convey the meaning of the action (or) we need labels -- esp. when you first start playing with an application. But, given the small screen size labels are a challenge -- so what if the user presses a button to learn what the icon does?

There a number of other little subtle aspects that need to be carefully considered when designing applications, esp. related to algorithm efficiency, data capture/handling/representation and strorage.

-- rv

Programming mobile phones ...

I am currently designing/developing a new subject that will teach students how to build software for mobile devices. It is proving to be a real challenge. Especially finding a suitable balance between showing how to use API and the higher level design/engineering concepts.

Why is this hard? For a number of reasons Universities want to be seen as places of 'education' rather than 'training'. That is, they want the students to have a greater depth rather than knowledge of the API. Personally I prefer to the training first and then principles later approach. I find that the best way to get students moving forward is to get them started and learn by example (doing stuff even it is a bit sloppy) --- build deeper understanding at a later stage.

Why not start with concepts first? The simple answer is that the brain has a reference point to start with and the conversations are a lot more meaningful. A weak analogy is that we do not start 2 year old kids on language semantics/grammar and spelling first -- we just talk to them and worry about semantics of a language later. That is the learning is via a process of incremental refinement -- and most of the time we do not even bother correcting poor grammar.

Will they pick up bad habits if we do not give them deeper concepts first? Well, that depends on the teacher. If you use sloppy and poorly thought out examples -- then sure, they will pick up bad habits and potentially do a lot of damage to their learning.

Back to the mobile phones ...

I have not programmed a mobile phone at any serious level except for a small JavaME software that convinced me that JavaME was a dead technology. Currently I am systematically learning how to program an iPhone taking a lot of notes to reflect on my own learning experience.

Based on progress so far ...

• The baseline knowledge required to build a reasonable piece of software for the iPhone is quite high. This is not a platform to start students new to programming on. Need to have skill in use of design patterns, events, user-interface construction/APIs and OOP.

• XCode IDE does require some level of formal 'tool training' to speed up the learning process (and more importantly to ensure that students do not feel dumb/lost -- quite important because the motivation to learn drops rather fast once that feeling of being lost sets in).

• Designing each screen and the various iterations on paper is proving to be very helpful. I am not sufficiently familiar with the API and libraries, so I do not yet know what is available out of the box and what requires custom engineering. As a part of this exercise, I am looking at different software designed and built for mobile devices and writing down how they may have been assembled -- mostly as an experiment to see if they helps me learn developing for these devices faster. So far the results are promising, I'll not try this technique with others and refine as needed.

• I am planning to use a few systems as case studies and get students to decompose them in order to learn how they are built. Essentially a critical review process to understand the design patterns, navigation strategies, UX issues etc.

• I am allocating quite a bit of time for the mobile operating system related issues -- how processes / apps are scheduled / allocated resources etc. File I/O, Network I/O.

• Data handling is slightly different and things like sqlite need to be discussed within the context of mobile applications.

• Mobile web applications (HTML5/CSS/Javascript) -- mostly the considerations are to do with design rather than the actual technologies. Esp. touch interface considerations.

• These devices have very different usability issues associated with them. The simulator is just not enough.

Well in a few months I have to make the harder choices -- identifying and defining a final set of learning outcomes that can be achieved in a single semester and then start building out the material.

-- rv