1. Emerging Trends, Tools and Techniques in Mobile Software Applications Development Seamus Mc Gurgan

2. Background Enormous demand for applications. Made with complex SDK’s which required a considerable time investment. Emergence of Rapid Application Development (RAD) Tools which claim no programming experience is necessary. This study aimed to assess the effectiveness of RAD from the non-programmers perspective.

3. Problem Statement “Using both Google App Inventor for Android and Adobe Integrated Runtime as examples of emerging Rapid Application Development Tools, to what extent can a person with no programming experience be realistically expected to become successful in app construction and at what point will they face complexity so great they cannot continue without seeking the aid of an expert programmer?”

4. Objectives Identify what these emerging tools offer to a person without a background in programming. Determine how successful this type of user can be at constructing apps with RAD tools. Assess the design on the tools and how they cater to their audience.

5. Objectives Investigate the methodology of RAD – marketing buzzword or genuine method of producing quality results quickly? Record how the tools influence the non-programmers’ thought process while building apps. Discover limitations of tools and their scope for providing key application features.

6. Methodology To measure the effectiveness of RAD, two emerging tools were chosen and two popular mobile apps were recreated in these environments. Google App Inventor Adobe Integrated Runtime (AIR) Doodle Jump FourSquare

7. Analysis of the Tools

8. Features of the Tools– App Inventor

9. Features of the Tools – AIR

10. App Selection

11. Challenges App Inventor – Doodle Jump Jumping mechanic implemented by pixel displacement, counter or timer? Blocks showed options. Bouncing platform – discovery of if else. Spring and Doodler navigation – success by experimentation of numbers. Saving score to TinyWebDB – purpose of lists unknown to the non-programmer. HCI – screen arrangers, no customisable components and workaround for multiple screens.

12. Challenges AIR – Doodle Jump Installing AIR on phone required command line argument entry. Publish settings were unreliable. Discovering the structure of the language with little feedback – how to define variables, name controllers, order of commands, syntax. Disabled property – confusing syntax highlighting. Co-ordinates VS stage width – mixture of both had to be applied. Score – glyph embedding. Unsolvable – shooting sprite overlap, establishing connection to database.

13. Challenges App Inventor - FourSquare Tag–value system unpractical for intricate database – complete dependence on position in list. Limit to number of friends – unable to dynamically create components via code. Inability to search values of TinyWebDB – location co-ordinates had to be stored within code. Adding friends– had to be manually selected from device contacts while also being unable to import Twitter friends.

14. Challenges AIR – FourSquare Connecting to the database – Microsoft Access database was made, but a full connection could not be established. The barrier of SQLite proved too challenging and without its implementation, much of the functionality of FourSquare could not be recreated. Translating the equation to calculate distance into Actionscript – puzzle structure of App Inventor replaced by brackets. External API had to be manually installed – maps function not available by default and contacts API was not compatible.

15. Development of the Non-Programmer The development process of each app educated the author on the basics of programming. Use of variables to make large quantities of code manageable. Application of if else statements and lists. App Inventor’s conceptual metaphor of puzzle pieces aided trial and error construction. On the whole, much more was learnt about the fundamentals of coding through experimentation with App Inventor than was gleaned by reading the comments provided by AIR’s code snippets – this was an unexpected finding.

16. Key Advantages Found App Inventor: This study proved that the Blocks Editor helped a beginner programmer to learn the structure of code. The sensible categorisation of components and blocks made finding objects intuitive. The TinyWebDB’s method of storing data as a tag and a value was seen to be an easy concept for the user to understand. AIR: Code Snippets provided rapid design of complex methods and their comments acted as a translation into common English. Timeline frames allowed for the easy development of multi-screen apps. Invisible buttons promoted good design capabilities.

17. Key Limitations Found App Inventor: Not able to freely position components. Limiting to one screen apps meant good design was sacrificed to find a workaround for multiple screens. Poor emulator performance. Inefficient database system that does not permit searching, ordering, saving of images or multiple simultaneous calls. Orientation sensor demanded powerful phone to achieve realistic results. Sprite collisions were not able to be accurately defined. GPS functionality not able to be replicated on connected device. Zoom and Undo features are rendered unusable.

18. Key Limitations Found AIR: At times functionality was heavily dependent on the overall structure of the code. No search function provided for the library of methods and calls. Installation of Adobe AIR on the phone was frustratingly difficult. SQLite was not accessible to a new user. Feedback from failed publish attempts was often indecipherable to a person who does not understand the jargon of programming. Emulator was visually inaccurate.

19. Comparing the Tools Scope for design - App Inventor’s methodology of screen arrangers pales in comparison to the freedom offered by the stage in AIR. App Inventor outshined AIR in terms of code construction and ease of learnability. App Inventor simplified data storage to a paired tag and value system – this was found to sacrifice functionality and data integrity in its efforts to make the tool more accessible. Poor emulators meant a real device was required to produce applications that depend on mobile functionality for both tools.

20. Comparing the Tools The overall order of the code had no bearing in App Inventor but had great influence in AIR. AIR’s comments can be used as a notepad and unused code can be placed within them, while App Inventor only allows the deactivation of blocks. SQLite allows expansive controller over data, but at the cost of the excommunication of new users.

22. Objectives Met This study concluded that App Inventor was the easier tool to learn via trial and error for a beginner. It was shown that a both tools allowed an inexperienced user to create functional applications within a short amount of time. While most of the functionality for both apps could be recreated with Google App Inventor, AIR struggled to provide the tools necessary for a beginner to create these applications. AIR makes no effort to abstract its complexity, and this repelled the user.

23. Objectives Met Neither tool can be considered ‘rapid’ – App Inventor required time spent finding workarounds to absent features and AIR demanded the learning of additional languages. Confirms RAD is a marketing buzzword, but still has a place in rapid development of smaller projects. List of recommendations to be made to tools was made – App Inventor updated with two of these changes.

24. Future Work and Implications To assess the effectiveness of RAD tools as a whole more tools would need to be examined, such as AppCat and Visual Basic. Another worthwhile expansion on this research would be to have an expert carry out the same tasks with the RAD tools and comparing findings – allowing for a more accurate identification of strengths and weaknesses. Using these tools in academic studies at both secondary and higher level education could provide an excellent source of learning - allow for the teaching of more complex concepts earlier in the course. RAD tools are limited by subjectivity - if a project specification is within the confines of the limitations presented within this study, the tools can be more cost effective than more conventional environments.

25. Conclusion Both beginners and experts alike can gain much from RAD tools, but new users will be misled by the tools’ claims to be rapid. The author learnt how to program mobile applications to a good degree without receiving teaching. Validates the ‘no experience required’ claims of the tools and shows how they successfully removed the intimidating barrier of learning code. RAD tools have much potential for both educating beginners and quickly developing smaller projects.