A Moving T arget

1. A Moving Target Our experience of teaching mobile programming on different platforms at Staffordshire University Cathy French Dave Gillibrand Trevor Adams

2. Staffordshire University Computing • 2012 intake: 365 first year students + >100 postgraduate • degrees in • Computer Science, Computing Science, Software Engineering • Web and Multimedia • Digital Forensics and Cyber Security • Computer Networks • Computer Games Programming • Applied Information Technology (Stoke Campus)

3. Mobile Computing at Staffordshire University • from 2001 offered degrees in • BSc Wireless Networking Technology • BSc Mobile and Wireless Business Systems • BSc Mobile Device Technology • MSc Mobile Computing • MSc Mobile Computer Systems • MSc awards popular with overseas students • BSc awards attracted little interest • individual modules very popular options across all awards

4. Mobile Modules • across all levels, different emphasis • introduction to mobile systems and technology • wireless architecture and signalling • programming for mobile devices • mobile systems • main platforms: • Java ME • Windows CE – class set of PDAs • good for interface design, socket programming • now moving to Android, iPhone and Windows Phone

5. Two second year programming modules • Programming for Mobile and Handheld Devices • Dave Gillibrand • games • Java ME -> Android • Software Development for Mobile Computer Applications • Trevor Adams • mobile apps • JavaME -> Android -> iPhone

6. CE00922-5 Programming For Mobile And Handheld DevicesDave Gillibrand • Development of 2D games are taught in this module • Java ME was previously used but this year for the first time we used the Android platform • Previously JavaME with Netbeans was quite a nice environment to teach with • JavaME seamlessly integrates into Netbeans • Students found it straight forward to code, compile and run • Later editions of Netbeans introduced a designer where a visual designer allowed students to create an application with little need to recourse to code • This wasn’t used as by handcrafting code it was felt that more of what is going on is understood.

7. JavaME - Architecture • The architecture of JavaME was easily understood • Once MIDP (Mobile Information Device Profile ) , CLDC (Connected Limited Device Configuration), AMS (Application management software) and the MIDlet life cycle were explained to them they were up and running

8. Language and IDE • Most of the students were new to JavaME (having studied java in their first year) • Because of the explosion in popularity of Smart phones we switched from JavaME to Android teaching essentially the same content i.e. At the end of the module the students were expected to write their own game • As an IDE we used Eclipse hooked up to the Android platform • There were more technical issues that the students (and staff) had to sort out, initially setting up the environment and when using the IDE. • The emulators are more complex having the ability to emulate saving to an SD card as well as reading in GPS data • There is lots of help on the Android developers web site

9. Android Architecture • The Android architecture is inherently more complex than the previous JavaME architecture. There are the following concepts • Activities • Services • Content Providers • Intents • Broadcast Receivers • Notifications • You can also specify HCI in Android using xml files which are inflated at run time • Excellent way of designing your application • Separation of concerns • But new to the students

10. Game Programming in Android • As the module is about writing a game we focussed on Activities, Threading and specifying the HCI in xml files • The code to write the game loop in a thread in Android is quite complex and difficult to understand involving the SurfaceView class, SurfaceHolder and SurfaceHolder.Callback interfaces • An example was provided for the students which they could modify • This leads us to the teaching paradigm employed: • Give an example • Understand the example • Modify the example

11. Teaching Paradigm • Is this how we all learn? • We applied the above paradigm in teaching the module • The first 3 weeks were an introduction to the basics of Android • In week 4 we explained how threading is done in Android and demoed a Simple Game loop. The following slide is what we expected the students to do in the week 4 tutorial

12. Tutorial wk4 animations Tutorial wk4 part3 The result of the previous code Tutorial wk4 part4 Tutorial wk4 part5

13. Some Points • When developing in Android compared to JavaME the high level design is the same, a continually executing game loop • But obviously the APIs are different • In JavaME we had a Sprite class which you could extend, not in Android • So it’s fun developing your own Sprite class with basic functionality which you can extend • Functionality related to it’s position, movement and the ability to detect collisions • Other things to consider • A real device is far better than an emulator • E.g. if you use an emulator you are fixed to a particular orientation (portrait) • On a real device unless you fix the orientation in manifest.xml or programmatically it switches between portrait and landscape depending on how you hold the device

14. Some Points • Other things to consider - continued • This has consequences! Can lose all of your state information unless you specifically program to save all your state information between orientation switches • Battery Life • If you develop GPS applications which constantly monitor your position then it can drain your battery. • Out on a long walk you could get lost! • You may need to take this into account when developing GPS applications so you limit your GPS usage

15. Some Points • Other things to consider - continued • Keyboard input • The emulator has a full set of hard keys where you can use the keys to trigger events • Most smart phones use touch events to trigger game actions (the emulator supports this) but clunky on the emulator • This can restrict the number of different game actions, you can detect the direction and length of the swipe, also supports multi touch, but obviously you have to program this – added complexity • You can detect the pressure as well !

16. Some Points • Other things to consider - continued • Using Http connections to connect to a JavaEE6 application glassfish server. • Problems developing an android mobile applications client which talked to a glassfish server • For development and testing purposes for the client you couldn’t use localhost or the local web address in the android client, the server had to be externally visible

17. Assignment • The students were required to produce an application with the following functionality: • A games design (storyboards) • Background Scrolling • Player Sprite - creating and displaying • Animation (simple or more complex) • Enemy Sprites • Firing of pellets • Collision detection • Animation when players(including enemy) die • A welcome and finish screen • Displaying scores • Storing and retrieving scores

18. An Example of a students work

19. FYP (Final Year Project) • At Staffordshire University we have a FYP which comprises 3 (out of 8) modules in the Final Year • the project is related to the award they are on • Increasingly more of them are choosing mobile devices to develop their application on • often they pick a platform they haven't previously been taught • and learn it themselves • One of my FYP’s this year developed an applications which runs on a Windows 7 phone, it was a very good FYP • Location based app which located nearby restaurants and displayed menus on a phone, allowed customers to write reviews, allowed restaurant owners to edit their details • Hosted on a webserver with a database which worked from a real device • Created web services to enable the functionality • Developed it using an agile method • Used test driven development and Kanban boards • Used subversion for version control

20. CE00343-5 Software Development For Mobile Computing Applications Trevor Adams • Longstanding 2nd year module • Aimed at general computing students • computer science, software engineering, web, ….. • until 2010 - JavaME • 2010-11 Android • 2011-12 iPhone – Objective C • This is a popular module with 3 times as many students electing to do this module compared with the Android level 5 module (games). • everyone (thinks they) wants to do iPhone development!

21. iPhone vs. AndroidDevelopment Environment • the most obvious barrier to teaching iPhone development is the development environment • need a lab of Apple Macs • where are your students going to do their practical exercises and assignments? • some will have their own Macs • others will hate the idea of being tied to a lab • can they get enough access? • not very mobile! • have to enrol on Academic Developer Program (free) • need iPhone / iPods for testing – have to register each device • not as simple as hooking up the USB cable (Android) • cannot create commercial apps without paying a fee

22. iPhone vs. AndroidLanguage • our students already know Java • first programming language • can jump right in to Android framework • iOS uses Objective-C • not intuitive or obvious if used to .dot notation • requires a few weeks to cover the language basics • but is an opportunity to look at programming fundamentals in a new way • need to allocate memory explicitly • Android has garbage collector

23. Efficiency • Mobile programming gets students to appreciate the ‘cost’ of code • In both time and space – crucial on mobile devices • Most students do not consider this • They do not seem too impressed about having to • Generally do not have enough memory to be luxurious and you have to allocate it properly • Bad programming here has ramifications • Increased battery use, memory limit etc.

24. iPhone vs. AndroidFrameworks • Most of the concepts required for iPhone/Android are common across OO languages • However, these concepts are obfuscated under layers of framework and API • Necessary, for app reliability / security • Does not make the step up easy • The concepts are similar in general • But often implemented in platform specific ways • iPhone – requires Model-View-Controller • Android – requires Model-View-Presenter • can't just output a simple "Hello World" to the Console!

25. iPhone and AndroidDesign Patterns • Cannot escape them in either platform • MVC, observer, delegate, proxy, strategy • Entire books on subject • Buck, E. M. and D. A. Yacktman (2010). Cocoa design patterns. Upper Saddle River, NJ, Addison-Wesley. • Challenge – teaching design patterns as you go • You cannot avoid them • Point out the architecture in examples • Show how it fits together with worked examples • Break the problem type down it overcomes • Show how the pattern addresses the problem • Then name it!

26. iPhone vs. AndroidHardware • Android – many devices, many manufacturers • APIs are numerous for many different devices • No consistency between device characteristics • Input, screen size, memory, cameras and others • Some large shifts between API levels • Activities, intents and data sources. • Open devices, requesting access to device resources via use of config. and query • Students can use their own phones easily • Just connect USB • iPhone – limited devices, single manufacturer • API is fairly steady and stable • A lot of consistency across versions • Limited variations – common feature set amongst devices (iPhone/iPad) • To use hardware requires code signing certificates and membership to Apple Developer Program

27. Student expectations • There is an expectation of simplicity • Get a reality of complexity • Mobile seems to be considered ‘easy’ • Less functionality than PCs - should be easier to develop • Mobile Apps are smaller / simpler than desktop • Their impressions seem to be fuelled by their experience as a consumer • At least early on • Lack of size != lack of complexity • Usually, the simpler something is to use, the more it does under the hood in mobile • The constrained device gives the impression of simplicity of application • Making things simple requires a lot more thought

28. General Conclusions • students are keen to learn mobile programming • smartphone development is more difficult than they think • not suitable as an introductory module • Java ME and Windows CE development was more straightforward • but this learning curve makes it an ideal second year topic • gets them to really appreciate and understand advanced topics • different language paradigms • user interface design • memory management • program efficiency • threading • testing • object-oriented concepts • design patterns • developing complex applications • and it's fun!

29. QUESTIoNs?