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

2. Background
Enormous demand for applications.
Made with complex SDKs 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. ChallengesApp Inventor Doodle Jump
Jumping mechanicimplemented 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
Tagvalue 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. ChallengesAIR 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 Inventors 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 AIRs 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 TinyWebDBs 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 Inventors 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.
AIRs 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.
21. 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 theysuccessfully removed the intimidating barrier of learning code.
RAD tools have much potential for both educating beginners and quickly developing smaller projects.