Although Tasker is a simple app, we've built it to mirror a typical enterprise setup, as shown in the following diagram:

The mobile device (say, the user's phone) is considered the presentation tier of the app; this is where the data is displayed to the user and where they can manipulate it. Although this book is a PhoneGap book, we actually won't deal with this tier until Chapter 5, Communicating between Mobile and the Middle Tier, and later, since we need to establish the foundation of the app first.

The mobile device doesn't have to live on the enterprise's network. Depending on the sensitivity of the data, the mobile device might be expected to connect to the enterprise's network using a Virtual Private Network (VPN). This essentially means that the device exists within the enterprise's network. Since this adds an extra burden on the user (they need to connect to the VPN prior to using the app), this isn't always desirable. For...

It is important that you identify the data models your app will need prior to writing any code. Consider your data models the foundation of your app as a whole. We don't have sufficient space in this chapter to cover all the various complexities a large data model design needs to address. Instead, we'll discuss some basic ideas and also explain our mindset while going through the design for Tasker.

Simply, a data model describes the kind of data your app will store as well as the relationships between the data elements. Having this in place makes it easy to understand the system and makes it easier to code the app.

Let's go through the data models for our app. First up, we have the PERSON model:

The preceding diagram tells us quite a bit about the data we're storing:

When designing your business logic, it is important to think about how your app will need to access your data and what operations it will need to perform. We've defined many of these as part of the data models in the prior data model diagrams—these are the actions that our app can perform on the data. Generally this logic is pretty simple—nearly all of it boils down to something as follows:

We won't take up valuable space in this chapter by including all the code for the business logic—it's pretty boring. Instead, look at the database directory in the code package for this book. Also, note that the backend database was designed to be simple and easy to understand; the design we use is not the most secure model. Data, views, and stored procedures are usually separated into separate...

When it comes to data security, there are usually several tiers. Of course, one wants to secure where the data lives and the transmission of that data; however, most enterprise apps need some level of data permissions as well, that is, certain users should only be able to see certain data or certain users should only be permitted to do certain manipulations.

Tasker's permissions model is inherently simple: every person is a user of the system, and every user can create tasks. Tasks can only be modified by their owner. Users can also manage other users, meaning that users can assign tasks to their subordinates. When a task is assigned to another individual, the assignee can update certain fields, namely progress and status. Both the owner and assignee can add comments to a task.

Of course, this doesn't cover the authentication and authorization or user administration mechanism, and that's by design. Many enterprises will have their own requirements when it...