1. Software Engineering & Mobile Apps

2. Importance of Software The economies of ALL developed nations are dependent on software. More and more systems are software controlled Software engineering is concerned with theories, methods and tools for professional software development. Expenditure on software represents a significant fraction of GNP in all developed countries Software costs often dominate computer system costs. The costs of software on a PC are often greater than the hardware cost. Software costs more to maintain than to develop. For systems with a long life, maintenance costs may be several times development costs. Software engineering is concerned with cost-effective software development.

3. The Age of Internetification The basic assumption behind mobile computing is that we are living through an age of internetification similar to the age of electrification in the early 20th century. Over the span of several decades, electricity evolved to a sensation in which electrical engineers were the computer scientists of their day, and ultimately to a utility whose ubiquity & simple UI belies the complexity of the grid. We don’t think about it much today, but our world became electrical: every device that could conceivably benefit from electrical power became powered by electricity. Edison’s electric light bulb goosed the buildout of the electrical grid, and it was soon used to power irons, sewing machines, and (over time) factories

4. The Age of Internetification Today we are seeing internet connectivity evolve from flaky 56k modems towards the idea of wireless broadband as a utility whose presence you can increasingly simply assume. Just like the process of electrification packaged up an enormously complicated grid into the trivial UI of a wall plug, we’ve likewise started to move from wrestling with WinSock configuration to the trivial UI of an Airplane Mode switch. And with internetification our world will become mobile: every device that can conceivably benefit from an internet connection will be connected to the internet. Jobs’ internet-connected smartphone goosed the buildout of the mobile internet, but it is now being tasked with connecting locks and thermometers and mines.

5. The Age of Internetification The logic of internetification is inescapable, which is why mobile computing is not just a trend, but the future of computing. Mobile web applications in particular promise to leave behind desktop web applications in the same way that desktop web apps left behind native desktop apps, and for similar reasons. The fundamental user and developer conveniences afforded by an application downloaded from the internet & continuously updated (i.e. a webapp) generally trumped the fancier widgets that desktop apps provided. Similarly, the sheer convenience of having an app that is constantly in your hands at all times - and that can either change its state based on your location or else make your physical location entirely irrelevant - will increasingly trump the fancier widgets and increased screen real estate afforded by desktop web apps

6. Mobile With an estimated world population of 7e9, global mobile penetration is roughly 70% for all phones and 20% for smartphones

7. Detailed breakdown of smartphone users by geography.

8. The installed base of smartphones and tablets has roared past that of PCs

9. Is Mobile a fad? No…… The answer to this so simple that it boggles the mind. The reason is that human beings are mobile. We are not sessile organisms confined to a single location for all our lives. If you look at every other technology ever developed, you’ll see that the ability to carry it around and use it in arbitrary locations vastly increases its utility and versatility. Therefore, the emergence of (1) sufficiently powerful computing processors to run a client device and (2) always-on low-latency global coverage to link these clients to an arbitrary cloud computing and storage resource means that computing power is now mobile. Computers are an incredibly useful tool, but now you can carry a powerful one around thus removing the constraint that you sit in a single location if you want to do any computing and furthermore, extending the available things in the world upon which you can apply computation.

10. The Mobile Present We begin with the obvious: the dominant players are Samsung and Apple (on the hardware end) and Google’s Android and Apple’s iOS (on the software end). iOS is still on top from a monetization standpoint, as reflected in the fact that as of 2013, YC startups still developed for iOS first. Nearly all build for iOS first and then maybe one day port to Android. There are a few exceptions who use Android to do things you can’t do on iOS. And of course Apportable has been very successful auto-porting iOS apps to Android. However, while Apple has cumulatively paid developers more than $10 billion over the five year lifetime of iOS, Google is gaining major ground. Android has long been the frontrunner in the mobile space by handset volume, is about to catch up on downloads, and has closed the app revenue revenue share gap from 81%/19% to 73%/27% in the span of a year. Android also rolled out new web services (e.g. gesture typing, Google Now) that iOS can’t seem to match. While cliche to state it, with Jobs’ passing it is likely that the long-term game is going to to Google.

11. Money on Mobile Apple makes about $1B in profit annually from the App Store Google did $17.5M in May on $350M in revenue ($210M profit on $4.2B revenue annualized). However, Google’s real mobile monetization is through mobile ads (roughly $8B annual revenue as of 2013) Apple’s real monetization is through first party hardware sales (roughly $160B annualized revenue and $40B profit as of Q2 2013, of which the majority comes from iPhone and iPad sales). Samsung actually is the party that was making real money from Android hardware sales, toting up an impressive $8.3B in profit on $50B in revenue in Q2 2013 alone. Thus right now the revenue from the mobile hardware buildout currently leads that from the software buildout by a significant margin. It’s almost tautological that this is the case - one needs devices in people’s hands before one can install software - but this lag still means significant opportunity.

12. Mobile Cannibalizes HW while Growing SW Hundreds of millions of new customers bought handheld computers while they thought were buying phones, thereby vastly increasing the theoretical market size for internet-connected computers and applications. Moreover, in addition to simply being a mobile computer, smartphones in particular can be thought of as replacing a wide swath of specialized devices and enabling new modes of user interaction: the phone as a remote, the phone as a docked device, the phone as a port for more specialized sensors or devices. The combination of these trends means trouble for traditional purveyors of standalone consumer electronics hardware (e.g. Garmin, Sony) and tremendously more reach and distribution for software developers. An increasing no of hardware device equivalents are now available at all times, and interesting apps like Square combine these built-in HW APIs in clever ways. Square used the fact that the iPhone headphone jack was actually an active port that received a signal input from the headphone jack. They used this to make a hardware device that plugged into the headphone jack and sent credit card information over this low-bandwidth channel, thereby creating a cross-device front-facing credit card scanner, avoiding Apple’s tax on devices that use the Dock Connector, and spawning a company with a $3.25B valuation.

13. A mobile phone replaces a slew of specialized devices.

14. Mobile Constrains Business Strategy If launching a SW startup, it is important to think about a way you can put a fundamentally mobile app (native or web) at the core of your service. Businesses that did not think about this up front have been forced to adapt. Apple was one of the very first to see this changing from Apple Computer right before the launch of iPhone, to redefine as a mobile devices company. It’s obvious that mobile apps are useful for transportation, tourism, maps, and anything related to a change in location. Yet what does mobile have to do after all with (say) business expenses or furniture shopping? However, then you start thinking “oh, I’ll turn the phone into a mobile scanner for business receipts” and you get Expensify. The reason this “think mobile” constraint is actually useful is that if you can figure out a mobile angle for your app, you will have come up with something new that was technically infeasible 5 years ago (before iOS App Store) and practically infeasible until relatively recently (now that ubiquitous smartphone penetration in many countries can be assumed). As such your app will invalidate the assumptions of incumbents in the space, granting you a competitive advantage.

15. End of Part 1

16. THE SOFTWARE LIFE CYCLE A fundamental concept in software engineering is the software lifecycle. Software, like many other products, goes through a cycle of repeating phases.

17. The Waterfall Model

18. The Incremental Model

19. The development process starts with the analysis phase. This phase results in a specification document that shows what the software will do without specifying how it will be done. The analysis phase can use two separate approaches, depending on whether the implementation phase is done using a procedural programming language or an object- oriented language. The Analysis Phase

20. An Example Data-Flow Diagram (Forouzan: Foundations of Computer Science)

21. An example of a state diagram (An Elevator State)

22. An example ‘use case’ diagram

23. An example ‘class’ diagram

24. Design Phase The design phase defines how the system will accomplish what was defined in the analysis phase. In the design phase, all components of the system are defined.

25. A structure chart

26. Classes with attributes and methods

27. IMPLEMENTATION PHASE In the waterfall model, after the design phase is completed, the implementation phase can start. In this phase the programmers write the code for the modules in procedure-oriented design, or write the program units to implement classes in object-oriented design. There are several issues to consider in each case.

28. Software testing

29. The Testing Phase The goal of the testing phase is to find errors, which means that a good testing strategy is the one that finds most errors. There are two types of testing: glass-box and black-box. Glass box, aka White Box, Structural, clear box and open box testing. A software testing technique whereby explicit knowledge of the internal workings of the item being tested are used to select the test data. Unlike black box testing, white box testing uses specific knowledge of programming code to examine outputs. The test is accurate only if the tester knows what the program is supposed to do. He or she can then see if the program diverges from its intended goal. White box testing does not account for errors caused by omission, and all visible code must also be readable. Black-box testing is a method of software testing that examines the functionality of an application (e.g. what the software does) without peering into its internal structures or workings (see white-box testing). This method of test can be applied to virtually every level of software testing: unit, integration, system and acceptance. It typically comprises most if not all higher level testing, but can also dominate unit testing as well For a complete software examination, both white box and black box tests are required.

30. An example of basis path testing

31. DOCUMENTATION For software to be used properly and maintained efficiently, documentation is needed. Usually, three separate sets of documentation are prepared for software: user, system, and technical. Note however, that documentation is an ongoing process. If the software has problems after release, they must be documented too. If the software is modified, all modifications and their relationship to the original package must also be documented. Documentation only stops when the package becomes obsolete.

32. Industry Drives the development Tools Android Eclipse IDE and Google Android SDK Android ADT http://developer.android.com IntellijIDEA http://www.jetbrains.com Android Studio iPhone Apple Developer SDK and Tools http://developer.apple.com Windows Phone Visual Studio IDE and Phone SDK http://developer.windowsphone.com Blackberry http://developer.blackberry.com Development Environments are proprietary but generally support the design challenges

33. Software Engineering and Mobility Software Engineering has been a major contributor to the success and expansion of the software industry: It brought order to the initial chaos of fragmented code. This was mainly via the concept of OOP. This is still important for mobile systems. However mobile systems are sufficiently different to merit special consideration

34. Apps are Different Fast time-to-Market International competition Short life cycle? Low unit price Difficult to make money? Can revolutionize a business practice Can generate new businesses Are in their infancy

35. App Design Designers follow ‘Best Practices’ Tendency to ignore Formal Development processes Maybe because of timescale? Agile emerging as a technique Process driven by Industry standard tools!

36. Mobility: Design and Development The design process for mobile apps is different The User Interface is vital Responsiveness is critical Wireless Communications networks are unreliable User sessions are short and ‘bursty’

37. Key Steps for Good design 1. Start with Performance and Stay with Performance Responsiveness and Power conservation are critical considerations, which impact on the entire app design process 2. Design the right User Interface For mobile apps, the User-Interface is critical 3. Get your Data and Memory model right Consuming data, discarding data, managing scarce memory 4. Get your Communications and Input/Output models right Using Local resources? Using external resources? Availability? Reliability? Assume that communications will fail often, so fail gracefully, and recover automatically. Defensive design makes for a good user experience 5. Repeat steps 1, 2, 3, and 4 as Necessary. Modern Mobile Development is an Iterative Process. 6. Package your app for Installation.( Last but certainly not least!) What needs to get deployed with the app? The executable plus images, text, database files, Runtime libraries

38. Challenges & Opportunities Challenges Devices are resource–constrained, Limited Power, Small User-Interface surface, Limited processing power & Limited memory Opportunities Mobility, Information available anytime- anyplace, Location-Awareness, Mapping, Augmented Reality, Context & Sensors

39. Context Apps can be designed to provide information to the user:- Anytime: In any location: Whether or not the user knows they need the information On a PC the user acts first and the PC responds: With a context-sensitive app, it is possible for the App to instigate the communication… The possibilities here are very far reaching Sensors offer Context-detection & Context-Aware Behaviour : GPS, Accelerometer, NFC, Light, Pressure, Temperature, Proximity & Gyroscope

40. Part III - The Mobile Future

41. ChromeOS & Mobile HTML5 Mobile HTML5 is going to wax in importance for app dev Google has always thought of native apps as a sort of near- term distraction forced on it by the unexpected success of Apple’s iOS. In this vision, HTML5/ChromeOS was a bet on the future and Android was a bet on the present but seems that HTML5 is now Google’s present, rather than its future. Possible that Android is merged into ChromeOS likely by doing backwards compatible rewrites of many Android Java API calls in Javascript. You might want to start looking at Google Drive Apps, the Chrome Web Store, and the Chromebook Pixel.

42. The Internet of Things The so-called internet-of-things takes mobile even further, moving from items like smartphones or tablets equipped with touchscreens to items which may run mostly unattended and/or be designed to be controlled from a nearby phone’s mobile programmable screen. Note that to produce such items again presumes ubiquitous (a) wireless broadband (“internetification”) and/or (b) handheld computers as a basic assumption. Another basic premise behind the internet-of-things is that every device will ultimately have an IPv6 address or the functional equivalent. The first internet-of-things devices are already on the market, including Nest (thermometers), Lockitron (locks), and PayByPhone (parking meters)

43. An overview of companies involved in the internet of things.

44. Quantified Self Closely related to IoT is the concept of quantified self or Qself The motivation to see what is happening in one’s own body. Sophisticated sensors for the human body that feed data locally into mobile phones or directly to a remote database over the internet Products in this category include Fitbit, Jawbone Up armbands While currently quite modest in market size, QSelf technology is likely to ultimately disrupt the way medicine is practiced. Studies prove benefits of fitness. Yet your fitness is considered to be your own responsibility: you can join gyms but the buck stops with you. But consider how that initiative plays out in healthcare. If you come to a doctor’s appointment wanting to talk about something you’ve researched, doctors generally get vexed. QSelf is going to change all of this, by making many body sensors fundamentally mobile e.g. Fitbit sleep monitor could enable at-home sleep apnea tests, and the Scanadu Scout or an equivalent will likely replace an expensive trip to the doctor’s

45. Mobile Tech: HTTP User Agents & CSS Media Queries HTTP is how browsers talk to web servers (among other things). This protocol is a complex beast that deserves its own class The main thing you need to know for now is that when you connect via browser to a remote web server, you are sending an HTTP Request and getting back an HTTP Response. An HTTP Request can be thought of as a function call (GET, POST, etc.) that accepts a positional argument (a resource like a URL) and a long list of optional keyword arguments (the HTTP Headers). You can generate HTTP requests with: A command line tool (ex. curl) A web browser (ex: Chrome) A library call (ex: node’s restler) A web UI (ex: hurl.it)

46. Examples of an HTTP GET request to the resource https://www.airbnb.com.

47. HTTP Requests When a web server receives an HTTP request it issues an HTTP response. The exact response can depend upon the time of day, the user’s location, or other parameters – including the value of the HTTP request’s User-Agent header. The User-Agent (UA) is the string that the HTTP client presents as self- identification (examples). It is trivial to spoof the UA &thereby pretend that you are a device different from what you are (e.g. Chrome’s User-Agent Switcher). Nevertheless, on the server side one can do so-called “User Agent sniffing” as a first cut approach to determine what device is connecting to our site. While no-doubt fraught with issues related to the sheer profusion and unreliability of UA strings, this technique is nevertheless used by many major websites (e.g. AirBnB) to serve up different content for different user devices. We should note that many references counsel against UA sniffing and recommend feature detection instead, using a library like modernizr. Sometimes feature detection is indeed what you want, e.g. if determining whether the given client supports a particular HTML5 API call

48. CSS Media Queries & Responsive Web Design CSS is used not just to control typography, for layout, and for graphics, but also to detect the screen width and use this to apply styles conditionally. This is called a media query; it’s basically a rudimentary if/then statement which executes different CSS code based on the width of the current browser window. Media queries are the basis for Responsive Web Design (RWD), where the page layout adapts to the screen width of the viewing client.

49. The Mobile Problem: Diversity of Devices An important issue in “going mobile”: namely the multiplicity of screen widths and OS versions on Android, & more generally the wide array of potential API clients In table below, from the point of view of API based design or service-oriented architecture (SOA), mobile means not just mobile devices, but the set of potential clients/distribution targets for your application/content. Note that for several of these targets (iPhone, iPad, Android) one may also need to design an alternate layout of the page for portrait and landscape mode

50. The Android OS Screen Fragmentation Problem

51. Platform Versions

52. Screen Sizes & Densities

53. Real lay of the land While a bit of a pain, the situation is not as complicated as these figures and tables may make it out to be. From a business perspective, you need to consider whether you will be optimizing for sheer global availability (in which case a mobile web app with RWD is the first choice), for maximum current App Store revenue (in which case iOS-first is still the best), or for the maximum number of handset users and potential future app revenue (in which case Android-first may be worth a bet). 2 options for dealing with client diversity in the context of mobile web apps. At one extreme one can use the one-size-fits-all approach of responsive web design. In this case, the server returns the same HTTP response for all clients, with CSS media queries in the body of the response used to implement some conditional logic (e.g. hiding or showing certain divs on a phone or tablet). At the other extreme the server can return different HTTP responses for different User Agents, as specified in the headers of the HTTP request. This can be used to deliver custom mobile-optimized sites and is what Facebook, Google, AirBnb, Twitter, The Guardian & now Github are doing (often via a URL m.example.com). An even more labor-intensive version of this is to build both a mobile web app and a native app for each client.

54. Mobile Design The second approach of custom sites for each client is significantly more expensive, but can be partially facilitated with a so-called API-based design or Service-Oriented Architecture (SOA). In this setup the core of the application is an API calling a database. All clients then simply call this API to create/read/update/delete objects and then render them using the tools of their native environment: e.g. ASCII for the command line, HTML for the mobile web, iOS widgets for iOS apps, and so on. That said, even with this kind of approach one needs engineers to constantly maintain the templates for each and every device (and in both landscape and portrait mode), ensuring that they don’t break or subtly lose functionality as operating systems are updated and new devices come out. While Facebook can afford this kind of investment, for a small company it is infeasible to support many different clients. Picking one platform and test. Steve Jobs’ heuristic was to pick a “technology in its spring”, a technology which is fresh and growing yet has been used in production applications by at least a few people. One way to measure this is by comparative Github forks/stars, Stackoverflow activity, Google trends/search data and the like.

55. Mobile Frameworks: Pure HTML5 vs. Cross- Compilation A framework is a collection of libraries with its own internal data structures and conventions that ends up governing the way you approach a space. The advantage of using a set of libraries is that you have great flexibility; the disadvantage is that in filling the gaps between these libraries you will end up writing your own framework. Conversely, the advantage of a framework is that it’s “batteries included”, but the disadvantage is that it can be hard to do something that greatly violates the underlying assumptions of the framework. Bootstrap framework is popular. Gets you on base quickly on platforms, & is flexible & skinnable as frameworks go e.g. wrapbootstrap.com & bootswatch.com Others include JQuery Mobile (JQM) and Sencha Touch (ST). Both of these are pure mobile-optimized HTML/CSS/JS frameworks which don’t require knowledge of iOS and Android development. The sites built with these are still viewable in a desktop browser but are optimized for the mobile web. With some effort you can mix & match components from JQM or ST into a primarily Bootstrap app (or vice versa), but igenerally easier to stick with one

56. Mobile Frameworks Cross-platform frameworks like Phone Gap or Appcelerator Titanium for apps in HTML/CSS/JS. Cross-compile it to native Android, iOS apps, Windows Phone etc. These kinds of frameworks are a bit of a no man’s land between a pure web app vs. a pure native app. An RWD app with Bootstrap will get you “on base” on each platform with something serviceable, while a pure native app will get you high performance, access to the hardware, easier debugging & native-looking widgets. But a cross-compiler framework is yet another thing to learn, and won’t usually give you the same snappiness of a native app. It’s arguable as to whether it’s really better than (1) just biting the bullet and going native or (2) alternatively, taking your initial RWD web app and making a mobile-optimized 2.0 version. The choice between these two is the question of whether or not you can get a mobile HTML5 app up to the same level of performance as a native app, which is perhaps the most important strategic debate in mobile development today. Facebook tried and failed to do a pure HTML5 mobile app, at least by their standards & with their approach. LinkedIn announced that they also switched back from mobile HTML5 to native due to memory issues and widget snappiness. In general it is fair to say that it is still nontrivial to get a mobile web app up to the same level of snappiness as a native app, but at the same time a mobile web app gives you a reasonable first presence on every device and is quick to build.

57. A Mobile Solution: RWD first, Native immediately after, and then use logs The mobile web (a) is relatively easy and will get you “on base” for each platform and (b) is useful no matter what you do. However, even if ChromeOS & mobile HTML5 are future, present still native. If you really do want to build a mobile app, you’ll want to learn either Android or iOS well, with the mobile web app as an initial stopgap. That said, Note however that Bootstrap would be best considered a CSS framework, and is meant to work with JQuery (a JS library). You can also easily combine Bootstrap with a frontend JS framework (like Backbone or Angular), and a backend web framework (like express for node.js). That is, Bootstrap focuses on the CSS styling of widgets as opposed to their behavior and how they move data around the page (frontend JS) or back and forth from the server (backend framework). By contrast, JQuery Mobile and Sencha Touch have opinions about how data is moved around the page and maintained within widgets. Does all this sound complicated? Yes, welcome to the fast-moving world of web development.

58. A reasonable approach to get started with an app 1. Start with a responsive web design app, built on top of an API. 2. Don’t try to build an RWD framework yourself; this is an enormous effort in its own right. Use Bootstrap or another like Zurb Foundation. 3. Theme your Bootstrap app with an off-the-shelf theme from wrapbootstrap or bootswatch or the like. Customize with Google Fonts or get a designer from dribbble.com or 99Designs.com to do more in-depth customization. 4. Now deploy your site and get some users. 5. Analyze your log data very carefully, looking at User-Agent in particular to determine what devices your customers are using. This approach will let you up and running quickly with something which is functional on virtually every platform. Then you can use the log data with your business strategy to prioritize further targets. Alternatively, you can launch the RWD app and then go with (say) an iOS or Android app, using the log data to prioritize your second target The use of an API at the core of the site will then allow you to generalize to new platforms over time (e.g. Google Glass or Apple Watch, as well as embedding app in Twitter or FB).

59. Mobile Constraints There are a variety of new issues that crop up with mobile. The network is unreliable. While we’re moving towards an age of ubiquitous wireless internet, we aren’t fully there yet. Apps should be designed to work with flaky connections or at least diagnose and display that they are offline. File sizes need to be small. Once you get things working, you’ll want to start aggressively removing unused JS functions and CSS styles from what you’re serving to mobile clients as they are often on low bandwidth connections. Debugging requires logging. You want to log aggressively and provide user bug reporting. The nature of mobile device diversity is that you will not be able to anticipate up front all the odd issues that will arise in the field. Do make sure to get your users’ permission to send these log files back to your server periodically. Minimize user input. Use passcodes over passwords, swipes over typing, and autocomplete over form filling. An example of this is Google Maps autocomplete field. It replaces 5-6 fields (add 1/2, City, State, Zip, Country) & includes error checking. Minimize time to result. Your app should boot quickly (difficult with an RWD app) and offer big buttons with common use cases.

60. The End