- Introduction
- Creating a Sample Project
- Writing Code to Create Logs
- Testing the Application
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Writing Code to Create Logs
Since generating logs isn't automatic in LightSwitch, you need to write some code. This isn't a big effort; however, it requires you to write some code snippets. Since you should rewrite the same code a lot of times, one easy option is to create a shared method that can be used anywhere in the application. In Solution Explorer, enable the File View. When LightSwitch shows the list of projects that are part of the solution, right-click the project called Common and then select Add > Class. Call the new class LogHelper. Listing 1 shows the code for the new class.
Listing 1—Implementing a shared method for generating new logs.
Public Class LogHelper
'Create a new log
Public Shared Sub CreateLog(taskType As String, Optional ByVal notes As String = Nothing)
'Create a new data workspace which ensures isolation from user data
Dim ws = LightSwitchApplication.Application.Current.CreateDataWorkspace
'Add a new instance of the Log entity
Dim log = ws.ApplicationData.Logs.AddNew
log.TaskType = taskType
log.TimeStampe = Date.Now
'The application class must be reached including the root namespace
log.User = LightSwitchApplication.Application.Current.User.FullName
If notes IsNot Nothing Then log.Notes = notes
'Save the log
ws.ApplicationData.SaveChanges()
'Release resources
ws.Dispose()
End Sub
End Class
The CreateLog method receives two arguments:
- The taskType argument is supplied by the calling code and specifies the type of activity that must be recorded.
- The notes argument is optional; it's supplied by the calling code and provides additional information.
One very important thing to consider here is that the code creates a new data workspace in the first line of the method body. Every data workspace is a unit of isolation between data. Therefore, if you write logs using the active workspace, when you save changes for your logs you would also save user changes over data. By creating a new workspace instead, you ensure that only the data in that workspace is saved, so saving logs won't interfere with data on which the user is working.
In Solution Explorer, revert to the Logical View; then double-click the Contacts table. What you'll do now is call the CreateLog method every time the user inserts, updates, or deletes a contact. In the Table Designer, select the Contacts_Inserted method from the Write Code drop-down in the upper-right corner. This will open the code editor, pointing to the ApplicationDataService code file. Delete the empty method stub and write the code shown in Listing 2.
Listing 2—Generating logs for user actions.
Public Class ApplicationDataService
Private Sub Contacts_Inserted(entity As Contact)
LogHelper.CreateLog("Inserted a contact", "Contact ID=" + entity.LastName)
End Sub
Private Sub Contacts_Updated(entity As Contact)
LogHelper.CreateLog("Updated a contact", "Contact ID=" + entity.LastName)
End Sub
Private Sub Contacts_Deleted(entity As Contact)
LogHelper.CreateLog("Deleted a contact", "Contact ID=" + entity.LastName)
End Sub
End Class
There are other places where you can write logs (such as Inserting, Deleting, and Updating), but this is enough to show how the mechanism works.
Next, imagine that you want to create a log every time the user opens or closes a screen. Open the Screen Designer for the CreateNewContact screen and then click the Write Code button. Listing 3 shows how to generate a log every time the user opens or closes the screen.
Listing 3—Recording screen opening and closing.
Private Sub CreateNewContact_Created()
LogHelper.CreateLog("Opened a screen", "Data Entry")
End Sub
Private Sub CreateNewContact_Closing(ByRef cancel As Boolean)
LogHelper.CreateLog("Closed a screen", "Data Entry")
End Sub
In this particular case, the second argument of the CreateLog method is being populated with a value that specifies the type of screen, but you're totally free to replace it with something different.
Another common situation is recording the moment in which the user starts the application. This must be done in the so-called "application code," but it requires the Access Control feature to be enabled. (In other words, anonymous authentication doesn't fire the appropriate events.) To reach the Application's class code file, follow these steps:
- In Solution Explorer, right-click Screens.
- Select Edit Screen Navigation.
- In the designer, click the hyperlink called "Click here to view application code" (see Figure 4).
)
Figure 4 Click this link to access the application code.
There's a method hook called Application_LoggedIn that you can handle as shown in Listing 4.
Listing 4—Recording logins.
Public Class Application
Private Sub Application_LoggedIn()
LogHelper.CreateLog("Logon")
End Sub
End Class
By using these techniques, you can track anything in your applications and provide all the details that you need for further analysis.