There are generally two architectures applied to apps for mobile devices: connected, and occassionally connected.
"Connected" means the app only works when it can connect to the server. Examples include Google's map client and Microsoft's Live client. Both nice apps, but useless if the device has no active Internet connection.
"Occassionally connected" means that the app works against a local database on the device. The app works as long as the device works, and the local database is synced with a server whenever an Internet connection is available. Examples include all the email clients on most devices, where you can read/send email even without a data connection, and outbound email is delivered when a connection becomes available.
You need to decided between these architectures first, before doing anything else, because this has a dramatic impact on your technology options.
If you assume the “Connected” model, then (in my
view) the best architectural model to pursue is an SOA model.
In that case you are building two separate applications that
interact with each other.
You are writing one application that runs on the server, and
which has an message-based “UI”, where the messages are XML.
And you are writing a separate application that runs on the
device, and which uses XML messages as a data access layer to some external
data source (which is, of course, your server application).
It is critical to remember that these are separate
applications. As soon as either one starts making assumptions about the other
one, then you are in trouble, because you lose the ability to independently
version either side, which will seriously harm your overall maintainability.
This also means that your server-side app has to have a very
good versioning strategy. You need to be able to create new versions of the
server app over time, while still hosting and running the previous versions.
With a mobile app this is even more important, because it is often very
difficult to get people to update their mobile installs in a timely manner.
To bring this back to CSLA, it is quite realistic to think that
you’d create the server-side app using CSLA. This is similar to what I do
in Chapter 11 – but you need to be very careful in designing your XML “UI”
so it is message-based, forward-looking and versionable.
In my view, your service methods should have only two possible
method signatures – EVER:
1.
void DoSomething(RequestType arg)
2.
ResponseType DoSomething(RequestType arg)
RequestType and ResponseType are DataContract types that define
the request and response objects. Ideally you’d also define FaultException
attributes on your service methods.
The end result is that your service interface is defined as a
set of operations (service methods). And each operation is defined as one-way
or two-way (choose a method signature), with the following properties:
1.
Operation name
2.
DataContract for request
3.
DataContract for response (if two-way)
4.
DataContract for any FaultContract attributes
This will get you a long way toward having a maintainable
message-based interface. From here, you can read Greggor Hohpe’s book on
enterprise messaging patterns and get all sorts of good ideas J
On the client you may or may not choose to use something like
CSLA. Certainly I’m designing CSLA Light to enable this model (as one
option) for Silverlight – where a client-only application can be created,
and the DataPortal_XYZ methods (on the client) can interact with a
message-based (async) server interface. The same basic concept should work well
in the mobile environment as well.
But it may be hard to get parity between that sort of client app
and a non-.NET one, because you’d have to port CSLA CE to Java (or
whatever). You have to evaluate whether it is worth that investment.
Rocky
Copyright (c) Marimer LLC