portability in cloud and mobile apps

1. Doh! portabilityin cloud and mobile apps http://www.flickr.com/photos/johanl/4934459020

2. What is portability? • The same program runs properly on multiple platforms without changes to code. • Binary portability: the executable is portable • Source portability: the source is portable

3. Example of portability • Writing a mobile app, compile it, and deploying the binary (apk) onto… • Android phones from Android 1.1 through N.N • Or iPhone 1 through N, iPod Touch etc, iPadetc • These are analogous to an application that runs on Mac OS, OS9, OSX, … • [Is there any such thing?] • These are examples of binary portability

4. Example of portability • Writing a mobile app, … • Compile and deploy to Android phones • Compile and deploy to iOS devices • This is similar to writing a C program and compiling it on Mac, then on Windows • These are examples of sourceportability

5. We need some binary portability. • Thought experiment: • What if, every time a new Android SDK came out, all of the apps (every single one) in the app store became outdated & had to be deleted? • And/or if apps didn't run right due to hardware differences (e.g., screen, GPS, camera, …) • Imagine the expense for the developers • Imagine how small the app store would be • Imagine the hassle for end users

6. We also want source portability. • Platforms come and go • iOS Android right now… but what is next? • Don't count Windows & Blackberry out!!! • Ditto for the cloud • What if Google raises the price of GAE? • How hard would it be to move your code to AWS?

7. Promoting portability • Reliance where feasible on standards • Limited use of platform APIs • Isolation of platform-specific code • Creation of facades • Intelligently use available hardware • Evolve forward, not backward • Document and learn from problems

8. Reliance where feasible on standards • Example: In a GAE app, you can store data using the JDO standard or with Google-specific APIs • JDO (javax.jdo.*): Label an object as @PersistenceCapable, get a PersistenceManager, etc… as shown in this course • (FYI, you can use JDO on AWS and most other Java-based platforms. Configure MySQL, install DataNucleus 3rd party lib.) • DatastoreService (com.google.appengine.api.datastore): Access the data store service, create an Entity, store name-value-pairs • So if there's a chance you might need to port to AWS, use the JDO API instead of the Google-specific API!

9. Reliance where feasible on standards • We have covered numerous standards. When feasible, use standards instead of "rolling your own" alternative. • Use standards across languages when feasible • Use JSON or XML instead of some custom format based on language-specific APIs (e.g., use XML APIs instead of java.util.Properties) • Or use language-specific standards when feasible • Java, e.g.: rely on java.* or javax.* • JS, e.g.: use w3schools.com to look up standards

10. Limited use of platform APIs • Example: You need to detect when your mobile app is paused or resumed (e.g., to un/register a GPS listener) • Use the Ti.App.addEventListener APIs • Use Ti.Android.currentActivity.addEventListener • In this case, the platform-independent APIs will work just fine, so use them.

11. Limited use of platform APIs • Choosing platform-specific APIs will always decrease portability • Ditto for platform-specific languages / SDKs • Nonetheless, you might still choose the platform-specific API/language/SDK due to other considerations (e.g., usability) • Moral of the story: Don't use platform-specific APIs unless you have a good reason.

12. Isolation of platform-specific code • Example: Suppose you do decide to use a platform-specific API, such as AWS S3 • Reference S3 only in a single file • Reference S3 anywhere & everywhere • Referencing S3 lots of places means you need to make lots of changes if you move to GAE

13. Isolation of platform-specific code • As much as possible, minimize the number of modules (e.g., files) that reference a platform • For example, make yourself a rule that if a function references AWS-specific APIs, then that function must be located in a certain class/file. • Then reorganize your code to follow the rule. • You may need several such files • E.g., one for platform-specific data-manipulation functions (e.g., with S3), another file for platform-specific compute functions (e.g., with EC2), …

14. Creation of facades • Suppose a few spots in your code need to create a Toolbar or Menu, depending on whether you're running in Android or iOS • Use if/then conditionals to invoke Android or iOS APIs in your Titanium code • Create a single function that makes the determination, invoke your function everywhere • Creating a "wrapper" function would keep your code cleaner and easier to maintain

15. Creation of facades • Create façade functions that hide most of your code from platform-related choices • And put your façade functions into a single file • As discussed a moment ago! Some of your code Some of your code Some of your code Your façade functions iOS APIs Android APIs

16. Intelligently use available hardware • Suppose you want to track location, but not all your users will have GPS turned on • Check if network-based location is available; let user specify a default location, in any case • Crash • Is the choice obvious here? • Often, a similar defaults or backups can be made for other hardware (e.g., touchscreen gestures in place of accelerometer)

17. Intelligently use available hardware • Accept inputs through multiple means • Identify what hardware might be missing • Identify alternatives (including UI-based options) • Write code for each alternative (façade) • Separate event-handling from actual work GPS hardware Event handler Your code that doessomething with a location Network hardware Event handler UI for user-specified default Event handler

18. Evolve forward, not backward • Suppose you want to make an app that runs even on old devices, such as iOS 3 or earlier • Start by creating and testing your app in iOS 5+ and then work backward • Start by creating and testing your app in iOS 3- and then work forward • 9 times out of 10, working forward is easier (since this process emulates what would happen over the years anyway)

19. Evolve forward, not backward • General principle: start simple • All the previous advice now applies • Prefer standards; make limited use of newer APIs; isolate references to newer APIs; use facades; etc • See if your SDK can help • Might need to install an older Titanium toolkit • In you're using ADT, learn about "library projects" • If you're using Objective C, learn about weak links

20. Document and learn from problems • You are going to encounter problems when you try moving from one platform to another. • Avoid similar problems when porting future apps • Encounter the same problems over and over • Duh. We obviously want to avoid trouble.

21. Document and learn from problems • Avoiding trouble requires documenting and learning from your problems. • Write down problems and solutions • Most of this course is organized around trouble that I have encountered & solutions I have found • These PowerPoints are a documentation tool for me • You need to find a method that works for you • Being a professional software engineer calls for continual improvement of your skillss http://www.flickr.com/photos/ajagendorf25/