CS 394 Mobile Web App Tips
This course is not about programming per se. It's about software development issues and practices that transcend specific platforms and application types. That said, there are certain technical tips, particularly on the web side, that can make a big difference in building robust applications quickly.
Make your page standalone
Both iOS and Android support web pages that can be put on the homescreen like an app and run full-screen without browser chrome. It requires some planning on your part, a few lines in the HEAD of the HTML, and some icons.
If you haven't done it before, here are some helpful resources:
- Optimizing Mobile Web Apps for iOS -- Making web apps look native on iOS, updated for iOS7.
- Adding a web app to the home screen in Android
- Home screen web apps for Android
- Hello World Web App for Android and iOS -- A very simple, recent, annotated example of the HTML and icons you need to create a web app that can be put on the home screen in either Android or iOS.
- IconFinder Free Icon Site -- If you need a distinctive icon for your app, this is one of many sites offering free ones. Be careful! Many such sites host malware.
- Icon Slayer Icon Generator -- An online tool that takes an icon image and outputs it in the many sizes desired by Android and iOS. Also has some nice image customization options
A good book on building mobile web apps, with details on both the design and the use of JavaScript and AJAX for interactivity is Build Mobile Websites and Apps for Smart Devices by Castledine, Eftos, and Wheeler.
Be RESTful
Here are some simple ideas for how to design the API (application program interface) for your web app. These are based on the REST theory for what made the web simple, robust, and so dramatically scalable.
- Use distinct bookmarkable URLs for every distinct
body of information
- This includes profiles, shopping carts, search results.
- Use URLs that name resources, not actions
- A URL for a resource should not include verbs like "show" or "calculate."
- Use GET for all retrieval
- GET is the default HTTP operation a browser uses when you click on a link.
- When you need a form, e.g., a search box, use the
FORM attribute
method="GET"to override the default POST operation.
- Use POST to modify resources
- POST is the default HTTP operation a browser uses when you submit a form.
- For single-click actions like "delete this," submit a small FORM with either a single button or a link using Javascript.
- Use
the POST-redirect-GET pattern
- This leaves the user viewing a resource, not a POST response.
- Note: Frameworks like Rails generate code for this by default.
Postpone Implementing Login
Many apps maintain user-specific information. Many students therefore assume that they have to implement user accounts with
- Forms where users can create an account
- Login authentication and access control code
This is a big mistake. Implementing login is high effort and low value.
- You need to first implement, and then maintain, account creation code and page access code
- Users can't test your app until they create an account
- Users have to track yet another user name and password, or
- Users have to trust you with a name and password they use elsewhere, or
- Users have to trust you with Facebook login
You can easily implement user accounts and user-specific data without any of this, using RESTful URLs that contain the user's ID. This lets you skip all these problems with almost no coding effort.
To give someone a personal account with your application:
- Create a user ID for them
- Give them a bookmarkable home URL with that ID for them to use to launch the webapp
- That's all your application needs to find their specific data
Look at join.me. A unique emailable URL is all they need to give you to run your own screensharing session.
This approach can be easily made more secure later. When you're ready, add code for
- authentication, i.e., login
- access control to user-specific resources
- user-based account creation
What is REST?
Roy Fielding in his doctoral dissertation defined a pattern for web services called REST (REpresentational State Transfer). REST is commonly misunderstood as being about URLs. Most of the theory is actually about content types and the proper use of HTTP headers. The big ideas are:
- The web scaled beyond anyone's expectations precisely because it is not a general system for remote procedure calls, as in XML-RPC and SOAP.
- The web is a set of (possibly virtual, possibly changing) resources, e.g., a static web page or a shopping cart.
- Every resource has one or more unique names, i.e., URLs.
- A client can do just four CRUD (create, retrieve, update, delete)
HTTP operations with resources
- PUT a resource on the server
- GET a (copy of a) resource from the server
- POST updates to resources on the server
- DELETE a resource on the server
Since browsers traditionally only supported GET and POST, POST is often used to mimic PUT and DELETE, i.e., anything with side effects on the server.
Fielding's ideas inspired a number of modern web frameworks, including Rails and Django. Note that early versions of some of these frameworks got it wrong and had to be revised, e.g., Rails and Django's REST framework 2.