Mobile Dev 101

1

[Read Objec,ves]
2
[Read]
The key concepts of mobile applica,on development are important because this is an
area web developers are constantly being asked about. A developer may not develop
mobile applica,ons exclusively, but will need to know the concepts in order to make
informed decisions for customers, clients, stakeholders, bosses, etc. In return, this
could lead to professional development in general, and specifically a higher paying
salary down the road. A commitment to learning new technologies and con,nuing
educa,on is something that is appreciated by most folks in any industry.
3
[Read]
4
[Mo,on towards upward trend of graph]

We see here that smartphone penetra,on is growing.

iPhone vs. Android, June 4, 2010, Don Kellogg, hPp://blog.nielsen.com/nielsenwire/
online_mobile/iphone-‐vs-‐android/

5
[Point to the three large slices of the pie]

Here we see that the top three players in this space are Blackberry, iPhone and
Windows Mobile.

6
[Point toward mobile/Internet data]

These are the data features used within the last 30 days. We see here that mobile
Internet is #2 on this list with over 70% of the 11k users using it in some form.

7
8
[Read]
A mobile web applica,on is wriPen and conforms to the code that has been
standardized by the W3C. This code is accessible using a URL or Uniform Resource
Locator and is op,mized for use on a mobile device i.e. the dimensions, file sizes and
code standards match that of the preferable seangs for which the mobile
environment is most known.
9
[Point out that this picture represents well-‐formed, standards-‐based HTML code.]

[Read]
This is an important point when dealing with mobile web applica,ons in that we need
to place the emphasis on standards-‐based code. That is, code that conforms to the
generally accepted syntax which will run in most web browsers. We are talking about
the basic building blocks of HTML, Javascript and CSS. In many cases, mobile web
browsers support more advanced technology than their desktop counterparts, thus
allowing us to use advanced technologies not yet available in tradi,onal web
development i.e. CSS3 and HTML5. We will talk about these later in the course.
10
[Point out blue arrow]

[Read]
This slide represents both the governing body for HTML and CSS standards and also
provides an example of a web applica,on that is built on standards, thus accessible
through current web browsers.
11
[Read]
Accessibility means that anywhere there is a web browser and a connec,on, your
applica,on may be able to run.
12
[Read]
Mobile sites must first be detected by either a user direc,ve reques,ng a mobile site,
or auto-‐detec,ng the user agent of the web browser. This can be done using any
technology that can read the browser’s user agent and manipulate the header prior
to the page loading.

Custom stylesheets are used to display a web site based on the user agent e.g. if
mobile, make site smaller. Mul,-‐column layouts are generally reduced to two
columns. Tabs, accordians (tabs with collapsed content) or other JavaScript effects
are used to promote the most effec,ve use of space. “Display: none” is set on
any unnecessary elements and padding/spacing are reduced to free up space.

A mobile site can be as small as 128x160 or as large as 320x480.

Some phones have touch screens, others do not. For our purposes here, we will
mostly be talking about the former, to cover the most popular phones which are
available today.
13
[Read]
Wikipedia is a web applica,on that is op,mized for both desktop and web browsers.
It dynamically changes the browser’s size and layout based on the user agent sent in
the request string.
14
[Read]
This is the resul,ng web page, as seen from a mobile browser. No,ce the “m.” in the
URL.
15
[Read]
A smaller browsing experience means less real estate to work with and has
implica,ons for the UI. Here, no,ce the large ac,on buPons.
16
[Read]
Again, we see large buPons inside a table with three columns. Inside a mobile web
applica,on, considera,on must be given to the lack of real estate and the
implica,ons it has on UI.
17
[Read]
This is Walmart’s iPhone web site. This site is a mobile web applica,on which is
op,mized for the iPhone.
18
[Read]
Walmart product lis,ngs are here.
19
[Read]
A quick way to get a look at a variety of mobile web applica,on designs can be found
here.
20
[Read]
For the purposes of this course, we will focus on the iPhone applica,on plamorm as
an example of launching a na,ve applica,on. This course will not explore na,ve
applica,ons in depth, but instead will focus on the key differences with mobile web
applica,ons.
21
22
[Read]
Since you most likely own a mobile device and are familiar with the app store, we will
focus on something most web developers don’t have much knowledge about which is
objec,ve C. Naturally, these steps will differ depending on the mobile plamorm for
which you are coding, but this is what the process would look like currently if you
were to begin wri,ng a mobile applica,on for the iPhone. You would first visit the
Apple Developer Connec,on at developer.apple.com where you would learn the
details of developing an applica,on including guidelines for how the architecture is
laid out, sample code, faq’s, etc. You would then set up inside the Xcode
development environment, which is not mandatory, but recommended by Apple.
Next you would familiarize yourself with the Cocoa API and begin to develop your
applica,on using the Objec,ve C language. As stated before, these steps are all
unique to developing for Apple’s iOS, but they are a good representa,on of what it
takes to develop for a specific environment.

All that said, there are definite pros to any na,ve applica,on. Once wriPen, your
applica,on would run on the device and have access to most of the hardware
features e.g. camera, speakers, etc. In addi,on to this, the built in marketplace helps
push your applica,on out to networks you might never reach otherwise. However,
embedded in these posi,ve notes on na,ve development are nega,ves. For example,
con,nuous integra,on of new features is throPled by the app store. Addi,onally,
23
[Read table]
24
[Read table]
25
26
[Read]
One major challenge to mobile web applica,on development is the limita,on on
bandwidth. One way to look at a mobile web applica,on is that it is similar to coding
for a dial-‐up connec,on. Assume no level of connec,vity and only serve up what is
necessary. This is where AJAX helps in that it only serves the parts necessary,
hopefully just in ,me.
27
[Read]
There are too many phones to list them all. The laPer two phones on this slide give us
a good sense of what a mobile web applica,on will need to support today. We have
keyboards with small viewports, touch screens with slightly larger view ports and
everything in between. If our applica,on will run on both of these devices, we may
safely say that it is portable by today’s standards.

[Point toward Blackberry and iPhone]
28
[Point to graphic]

[Read]
Un,l recently, we had around 320 pixels of width and in between 240 and 480 pixels
of height to work with for support of the most popular mobile devices. iPhone 4
increased this to 640x960, staggering dimensions rela,ve to mobile. Chances are this
will mo,vate others to do the same, thus increasing the amount of phones with ultra
high resolu,ons such as this.
29
[Read]
We will talk more about Flash video since there are some caveats its implementa,on.
The other three tags, however, are just examples of new methods available in
HTML5. The take home point for the web developer is that it is finally ,me to go back
to the book store and buy a new HTML book since, for the first ,me since 2000, the
HTML spec has a significant release.
30
[Point to HTML5 row.]
[Read]
HTML5 support is currently spoPy, but picking up across the browser world.

[Point to codec row.]
[Read]
Regarding HTML5 video support, think of Ogg and H.264 as containers for the video
(like zip files). Both have patent/licensing issues that we will not get into here, so for
now we are stuck with forked support for html5 video.
31
[Point to HTML5 with Flash Fallback]
[Read]
For implemen,ng HTML5 video, we embed mp4 first, then ogv, which is important
for iPad support, then finally we have a Flash player fallback. hPp://
www.webmonkey.com/2010/05/embed-‐videos-‐in-‐your-‐web-‐pages-‐using-‐html5/

[Flip back to Browser Capabili,es II and point to Codec support]
[Flip back to Browser Capabili,es III]

[Read]
This code will allow us cross-‐browser support for almost every browser currently
available, provided that the browser is was released in the last two to three years
and/or has Flash support. Also note that Flash is *not* na,ve to the browser and one
would need to use a compiled Flash player to serve the video on line #6 above.
32
[Read]
This is where we get back to the basics of old school web development. HTTP
requests should be limited. That is, only make the requests necessary to load the
page, and if you can, do them in a limited amount of sockets. Use packing tools to
compress your javascript. Look into web server modules that will compress files
before they are sent to the web browser. Images or other binary files can be
problema,c because generally speaking you cannot compress them on the fly. The
best scenario is when the tool used to input such files automa,cally re-‐sizes them
e.g. 340px image files are in your document repositories already resized. This is not
always the case, and if it isn’t for you, you might look into using a third party like
,nysrc.net to help you resize them. As with all web services, there are no guarantees
with this service, so make sure to have a back-‐up plan if the service goes down.

Finally, use a profiling tool. Joe HewiP’s Firebug has set the standard for such tools
and raised the web developer’s troubleshoo,ng toolkit significantly.
33
[Point to profiling tools]

[Read]
Here are stats from iHigh.com mobile site. Here we see the pecking order of size
which starts at the Google Analy,cs JS package. Second place is a banner graphic.
Third in file size is index.html. The total size is around 65k.
34
[Point to index.html]

Here we see index.html as #1 in size. Total size for m.espn.com is around 28k. The big
difference here is that we aren’t pulling in a large analy,cs package, which is
surprising given the size of ESPN network.
35
[Point to news.html]

Digg.com comes in at 172k, most of which are in the form of text/html. We don’t
know all that goes into this news text/html, but one would assume that using a
deflater on the server side could substan,ally compress this content before it gets
into the mobile web browser. There may be a reason why the developers at digg did
not do this, but the point for this course is that profiling your site against others, and
looking for op,miza,ons is an important part of mobile web development.
36
[Read ques,on to class and ask for verbal answers]

[Read answer and open for discussion]
The answer to this is C. The implica,ons of building it in as a na,ve applica,on are
that one would need to build three separate applica,ons. If the app is a web
applica,on, only one build is necessary.
37

A, na,ve applica,on. Currently, there is no way to access the na,ve GPS hardware of
the device through the web browser.
38

B, HTML5. See slide ,tled “Browser Capabili,es III”
39

True, it can support any layout a typical web browser can support.
40
41
[Read types]
42
[Read]
CSS detec,on is useful when all you want to do is style the site differently e.g. hide
the side column.
It is not useful if you need to control the content which is being delivered. There is a
tempta,on to simply re-‐style a web site for mobile, and then leave it alone. This is
not advisable for most web sites due to typical size of a normal web applica,on. If
performance is valued, then one must consider only serving appropriate content that
is device specific, i.e. don’t make the user wait on content they cannot use.

43
[Point out the code difference between devices that support media queries and those
that do not]

44
[Read]
Server detec,on is detec,on based on user agent string sent by web browsers using
a language such as PHP. Once detected, the applica,on serves styles or alternate
content. This type of detec,on has the most compa,bility for automa,c detec,on
methods.

45
[Point out the user agent string of the rewrite condi,on]

[Read]
This code is missing a lot of user agents and would need to be updated with these
and any others which you will no doubt want to support with your applica,on. It is
very basic to detect user agents and rewrite an url or redirect to an alterna,ve site,
the problem comes with the fragmenta,on of the various devices which we will
discuss later.
46
[Point out the isDevice() method]

[Read]
This method basically does a string match against the various user agents. As you can
imagine, there is not anything special about this code, only that it is unique to mobile
web applica,ons, but could be wriPen in various languages.
47
[Read]
With CSS we can detect the size of the browser and adjust the styles. With the server,
we can use the browser’s user agent string to do the detec,on and alter the en,re
web applica,on.

When building your user agent strings, you might look into using the Wireless
Universal Resource File which is a frequently updated XML file containing informa,on
about device capabili,es and features. Another promising resource is the User Agent
Profile specifica,on, which asks device manufacturers to supply a link to a structured
data file along with each user request from the device. To date, the consistency of file
availability is not very useful, but the hope is that it will eventually be a reliable
resource for developers of applica,ons to take advantage of.
48

D, of course. The mobile site is detected and the applica,on is then redirected to an
alterna,ve place.
49
[Read ques,on to class and give 20 minutes to complete task]
50
51
[Read]
We will be styling our document using a div-‐based layout for the purposes of this
course. The instructor feels as if this is preferable over table-‐based layouts, but it
should be noted that either will work properly in the mobile web browser. In
addi,on, we will create a separate stylesheet to prevent sending un-‐used rules to the
mobile device for example, if we were to compile the mobile and the desktop
stylesheet into one, we would be sending a lot of unnecessary rules to the client for
downloading.
52
[Point to mark up]

[Read]
As a web developer, you begin every applica,on with mark-‐up similar to this. Over
the next few slides, we will minimal tweaks to this markup to op,mize it for a mobile
web applica,on.
53
[Point to slide elements e.g. header, list items, picture, footer]
[Flip between basic mark up slide and this slide to illustrate that the code built the
page]

[Read]
Here is our mark-‐up, filled with text.
54
[Point to meta tag]

[Read]
Most mobile devices assume a page is 980px wide. Changing the viewport will
prevent the browser from zooming all the way out. This is was first supported by the
iPhone and recently has been adopted by other plamorms. Also note that the doctype
or character encoding have been let out for brevity. Without them, code will display
properly in the browser, but it is preferable to have these elements in a produc,on
product.
55
[Point to general and header CSS rules]

[Read]
Here we change to Helve,ca, the system default for the iPhone. We also had a style
to the h1 anchor tag which will allow the en,re element to be click-‐able.
56
[Read]
Our goal for menu items is big and blocky to allow for touch screen use. We also pay
special aPen,on to the padding of each element.

[Point to display: block and repeat “big and blocky”]

57
[Read]
Our web page as styled so far.

[Flip back to previous slide and point to “big and blocky” arrow]
[Flip back to current slide and point to big blocks]
58
[Point to webkit gradient arrow, then to header arrow]

[Read]
In the text-‐shadow declara,on, the parameters from let to right are horizontal
offset, ver,cal offset, blur, and color.

The parameters of –webkit-‐gradient from let to right are as follows: the gradient
type (can be linear or radial), the star,ng point of the gradient (can be let top, let
boPom, right top, or right boPom), the end point of the gradient, the star,ng color,
and the ending color.

59
[Point to webkit-‐border rule, then to the associated rounded corner.]

[Read]
On the first list item, add a top let border and a top right border of 8px. On the last
list item, do the same thing on the boPom let and boPom right.
60
[Read]
Based on the demonstra,on above, build the first page of your mobile web
applica,on using your own specified content and run it through the w3c validator as
HTML5 experimental. If the markup does not validate, fix the errors that are listed
and try again.

[Give the class 20 minutes to complete this task]
61
62
[Read]
Oten, legacy applica,ons are not built to be served in mul,ple ways i.e. the
developer expected only one view, thus code is customized for use in that one place.
A new set of view files might require some crea,ve thought on the part of the back-‐
end developer to redirect model/controller logic into a new set of views. In some
cases, this might be impossible and require a whole new applica,on. The important
thing to note here is that not all applica,ons are built alike, and before implemen,ng
any new code, one would be wise to inves,gate all of the op,ons given to them by
the current applica,on. Some,mes par,al integra,on is an op,on if the developer is
willing to spend ,me learning and tweaking the exis,ng code in key places.

Be sure to integrate the analy,cs package of choice into your applica,on, as it will be
important data, especially at the beginning of the launch of your mobile web
applica,on.

The live site s,ll exists and should be available to your users if they need it. Allow for
links to the full site, if they prefer to view it that way. Ensure your mobile site links
work either independent of the main site, or redirect to the main site, if the content
is not available in a mobile format.
63
[Read]
[While reading, point to various elements of assignment on diagram]
Combine all pages of your web applica,on along with naviga,on between each page.
Integrate this with the browser-‐agent detec,on as discussed earlier in the slide deck
and publish your content to a web page. The content should be validated through the
w3c, and any issues should be addressed prior to aPes,ng to the finished product.

[Give class 40 minutes to complete the assignment]

64

Mobile Dev 101

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Mobile Dev 101

Transféré par

Droits d'auteur :

Formats disponibles

1

Vous aimerez peut-être aussi