A session by Matt Biddulph
| T1 | Overview of Tech Solutions | Get an overview of the Technology stream, see the big tech picture and understand overall architecture. Non techies are particularly encouraged to attend. | Matt Biddulph | 20/9, 8pm (Thurs) |
[the notes in italics and “[]” are my additions, so you can blame me for them :-) ] the rest are just my notes made during his lecture.
What does mobile really mean
It’s a computer
but in your pocket
And yet it’s so much more than that …
- It’s something you’d go back for if you forgot it
- It’s always with you.
- It has many many sensors: it knows where it is, how lit the room is, is it alone, is it facing up, it it moving, and if so how fast.
- It’s a part of the Internet
- It can interact with the Internet on your behalf
[if you have an android device check out elixir its an app that lets you see all the sensors in your device, see their output, amongst a host of other things. Release your inner geek]
[See the post on Mobile Landscape for more details of the history of the mobile, and where it fits on the progression of technology]
Application architecture
whilst there are a range of different ways of designing the code and application structures, one has emerged as the most popular for mobile apps:
MVC – Model – View – Controller
- MODEL is the information used by the app.
[remembering that the model data is likely to be held in the back end for a lot of apps, the model comes from the data model in the database, and many of the MVC frameworks require the use of a database.] - VIEW is how to display the information, how to show the data, typically each state the app can be in has a view, and the view displays to the screen.
[The view will be a range of screens linked to each other.] - CONTROLLER decides how to respond to events and inputs, it’s the glue between the view and the model.
[The controller is the business logic, when an action occurs a part of the controller is called to deal with it, the controller uses the model for it’s data and displays it’s results using a view.]
Other aspects of the architecture are
- Asynchronous [which means that events are not serial in time, but you can make a call, and then wait for a reply]
Asynchronous and multithreaded which allows the app to be doing more than one thing, eg animating the screen while getting info from the Internet. Also means you can handle events that occur better than otherwise.
- Hardware events
Hardware events, the code can ask to get an event if something happens, eg phone is turned over.
- Networking
Networked app typically is an n-tier design where there is an intelligent front end (the app) that makes use of a server based backend that manages the more complex aspects of the solution. So the client runs on the device, and part of it resides in the server accessed over the internet. - Database
Follows the normal database access patterns, though it is possible to store some data on the device (with more recent versions of Android and iOS) however if there any serious database work to do, this would have to be on the server. - Front end / client
Much like above. N-tier arch has been around since mid 70s but the patterns are evolving.
Of course many apps can be entirely on the client. However when you’re using a server it is probably best to consider a Model View Controller (MVC) pattern. Lots and lots of systems and frameworks use this (Spring, Ruby on Rails, and so many others) and the logic of it is clear. There is a future session that looks at MVC so I’ll not put it here (or just google it)
The app server does the heavy lifting, but is only available over the radio, so be warned, because the radio link has two aspects -
- It drains the battery, can be fast. 3G and LTE radios are expensive on the battery, so be sparing where you can, eg strip comments and white space out of the response from the server, if you can.
- The radio access network is not a reliable link, and the throughput rates and the latency can vary quite dramatically.
The common approaches to client server use standard protocols eg HTML, JSON etc, these are the language and semantics about how to communicate with the server. As you might expect use HTML or JSON over HTTP.
[the point here is that it is not exotic or specific, the days of WAP protocols are far behind us, and indeed despite my comments above on the vagaries of the radio access network, it can be faster than home broadband, so no need anymore to be different, re-use those skills you have from web sites]
Here are some of things you need to consider
Network: you have to deal with the reality that the network may disappear at any time, and the speed is very variable, as is the latency.
Battery: make sure you tie into as many of the os events that control how your runs, eg register the location, etc.
[memory: be very careful in your use of resources, CPU and memory, because they are scarce]
Technologies and tools
There are two types of app, native and or web based.
iOS
For an iOS native app you need a mac as everything is mac based
Developer licence is $100 p.a.
X code is an IDE that runs on a mac, and is the environment you use to create the applications in.
Interface builder is fiddly but can remove the need to code buttons, web views etc, and tend to be where the UI folks live.
Android
Use eclipse as the development environment (IDE) which runs on most systems, macs, linux, windows etc.
With Android you need to make a trade off between speed/ device access and diversity in devices.
Adverts in android are ad mob, and iPhone it is iAds.
You delegate a part of the screen, and you get a part of the revenue, [simples]
Amazon’s store uses the amazon profile to try and target the apps to the user
Hybrid
HTML 5 adds the access to the camera, the location.
Most smartphones are HTML 5 capable.
As yet there is no way to package an HTML 5 app into all the app stores, however
Phonegap let’s you create HTML 5 c odds and then wraps it in a native code to allow it to be in the app stores.
If you need or want a cloud based server support then Heroku web cloud is the one to consider.
Prototyping
Wire framing tools like a appcooker, or Blueprint build a clickable prototype right there on an iPad.
Skala for showing on a phone
A/b testing
That is create two versions of a design and look at the differences in response from users.
[this is a good idea because, we are still finding our way with mobile interfaces, and which types work well with different users is still nascent so be prepared to experiment a little, whilst you discover which works best.]
Clear left in Brighton has a device lab, where you can get your sticky mitts on a range of devices for test purposes.
Test flight lets you send a group of users setup an app and let them test it, does not use the app store, but distributes the app itself. Very clever.
Flurry will allow you to collect analytics and then dashboard it
Class was delivered by Matt Biddulph
All Things Mobile 
Posted on October 15, 2012
0