Building a mobile application for dot netnuke v3

Bruce Chapman
iFinity Software

BUILDING A MOBILE
APPLICATION FOR DOTNETNUKE

Presentation Agenda
 Brief Introduction to Mobile Applications +
DotNetNuke
 Demonstrate how to build a Mobile Application
that uses Service Layer of DotNetNuke to
interact
– Understanding the Service Layer
– Building Service Endpoints
 Example Application : “Dnn Dash” – allows
access to the Dashboard of any 6.2+
DotNetNuke site
– Building Mobile Application

Mobile Applications
 Purpose built (device specific) Mobile
Applications are a superior way to deliver a
mobile experience
 Html 5 can provide a rich experience, but cannot
match purpose built at this point
 The theme of Mobile App vs Mobile Site is
currently a hot topic of debate

Html 5 vs Native Apps

Html 5 Native App

Conclusion
• Write once – run anywhere • App per platform
•Choose
• Server-side code easily according to require lengthy
• May
changed requirements release process
• Sandboxed, no access to • Full access to device
features •Services layer may features – camera, GPS
be largely
• • In-device discovery +
No App Store Presence in either case
the same purchase
• Speed dependent on
connection • Faster + more stable
• Direct monetization more • Monetization by app or in-
difficult app purchase easy

Mobile Applications and DotNetNuke
 DotNetNuke 6.2 introduced the Services
Layer, which exposes key DNN API
features
 DNN Services layer is easily extended for
module specific purposes
 An entire new field of DotNetNuke
application development has been
created

Mobile Application Types
 Corporate development : customising
apps for in-house use on mobile + tablet
platforms
 Commercial development : new
applications that provider web + mobile
experience
 Open Source development : providing
applications + back end processes

A Natural Fit : Mobile + Cloud

Building a DotNetNuke Mobile Application

Understanding the Service Layer
 6.2 – Uses the MVC Service Layer
 7.0 – Uses the Web API for the Services Layer
 Two aspects to layer:
– Built-in DNN API
– Extension for Third-party modules
 Provides authentication based on DotNetNuke
user accounts and profiles
 Provides simple pattern to design service
endpoints
 Flexibility in format (Json/Xml/others)

Extending the Service Layer
 2 Basic Components to API Extensions
1. Controller
 Definition of Methods and layer on top of
business logic
 Inherits from DnnController

2. RouteMapper
 Defines what Urls map to which
Controller methods
 Inherits from IServiceRouteMapper

Example Service Layer Call

 Url to call:
http://example.com/DesktopModules/DnnDash/API/Dash/Ping

Deconstructing Services Layer Url
http://example.com/DesktopModules/DnnDash/API/Dash/Ping
 http://example.com => domain name
 /DesktopModules => fixed part of Url, denotes module Url
 /DnnDash => specifies module
 /API => fixed, denotes services layer
 /Dash => specifies controller [ DashController ]
 /Ping => method name [ Public string Ping() ]

 NOTE: /DesktopModules/DnnDash doesn‟t
necessarily have to exist

RouteMapper registers Url Routes

 MapRoute configures what Urls will work:
– “DnnDash”  /DesktopModules/DnnDash
– “{controller}/{action}”  Class/Method
 /API/Dash/Ping  DashController.Ping()

 No other configuration required

Services Authentication
 Authentication:
– Identifying & Authorising User accounts
– Preventing Unauthorised Access
– Avoiding opening exploitable holes
– Providing „context‟ for current user within
service calls
 Web-browser based services call use cookie-
based authentication (ie AJAX calls)
 Mobile devices use digest authentication to
provide authentication
– Username/password pair provided with each
call

Services Authentication cont.
 Services methods access level can be marked
with:
– AllowAnonymous – no authentication
– RequiresHost – if true, must be SuperUser
– StaticRoles – named DotNetNuke roles
 All „regular‟ DNN objects are available in context
for service calls:
– Portal Settings (current portal, alias, settings)
– UserInfo (authenticated user)

Tips for Writing Services
 Use RESTful method / parameter naming
principles
 Stick to common return format in project
(Json/Xml/String – whatever)
 Plan for infrequent service calls in Application
Design
 Be frugal with data going backwards and
forwards – this may require custom serializing of
objects

Installing Services with your Module
 A service-only module only has an Assembly
 Install with ordinary Module install package
 DotNetNuke manifest file used to specify
configuration and safe uninstall

Writing a Mobile Application
 „DnnDash‟ application on Windows Phone
 Reads installed DotNetNuke dashboard
components for display on mobile devices
 Uses DnnDash services layer to send back Xml
of dashboard information
 Host-level access required to run
 DnnDash module/phone app available from
dnndash.com

Accessing Services from Windows Phone
 Uses System.Net.HttpWebRequest
– Asynchronous method
– Check Http status code to monitor correct
authentication (401 returned when not
authenticated)
 Each call from the device provides user
authentication username/password pair
 Uses Xml from Service call to create UI

Authenticating Phone User
 Username/Password supplied
with each call
 Defaults to Digest
Authentication –
Username/password not
plaintext

Requesting Data from Service
 Mobile requests data using Asynchronous Web
Request.
 Response body is read from
Response.GetResponseStream()
 Once response is received, conversion to the
response format
 Example uses both Xml and Json responses

Posting Data to a service
 Posting is much the same as retrieving data
 Post generally means changing server state
 Posts should be idempotent
 Failure should allow for re-submit without losing
client state

Considerations for Mobile App Design
 Store-posted apps can have lead-times for
changes in design
 DotNetNuke modules can be changed + patched
immediately
 Therefore, introduce flexibility into design that is
data-driven, side-stepping requirements to re-
release mobile clients

Conclusions
 Mobile Internet usage will soon overtake fixed
line, if it hasn‟t already
 Hardware sales growth in mobile devices
outstrips desktop computing
 DotNetNuke provides a perfect bridge between
mobile devices and your data, especially if you
want to put it in the cloud
 Building modules for the services layer is simple
and fast
 Mobile Apps are the next big thing in
DotNetNuke

Questions
 Dnn Dash application code available from
http://dnndashservice.codeplex.com/

 Slides available at
http://www.slideshare.net/brchapman

Building a mobile application for dot netnuke v3

More Related Content

What's hot

Viewers also liked

Similar to Building a mobile application for dot netnuke v3

Building a mobile application for dot netnuke v3