silverlight

How to Handle the User’s Refusal of the License Agreement/Privacy Policy in WP7 Apps

Posted on February 3, 2012 by WP7 0

Its a good idea to put the apps privacy policy, or license agreement or whatever you need the user to agree on before using the app, in a separate page and navigate to it in the first run.
There are two scenarios to do this, you either set the privacy policy page as the default and check if the user agreed on it on every run using the IsolatedStorageSetting. If the user did agree, the app navigates to the MainPage. Personally, I do not prefer this way because the privacy page is loaded on every run.
The more feasible scenario is to load the MainPage and during its loading, check if the user have agreed on the policy or not. If not, the app navigates to the policy. Sounds simple, doesnt it? No its not.
What should happen if the user reject the agreement? The app should close itself, right? Sorry, this can not happen in Silverlight apps (its possible in XNA though). There is not single command in Silverlight that gets the app to shutdown.
There is a possible solution to go around this. First of all, we will be using the second scenario where the app’s MainPage is loaded first and after checking the IsolatedStorageSettings, the app navigates to the privacy policy page. If you are not familiar with IsolatedStorageSettings, there is a very simple tutorial that was put together by the good folks at WindowsPhoneGeek.

You can create a setting called “AgreedToPrivacyPolicy” and assign to it a “TRUE” value after the user agrees to it. The main trick here is that on the policy page you should put only one button “I Agree”. Do not put an “I Don’t Agree” button because there is no command to handle it straight forward. To facilitate the use of the IsolatedStorageSettings in the application, identify the settings in the “Partial Public Class MainPage” like this:
[crayon lang=”vb”]Partial Public Class MainPage
Inherits PhoneApplicationPage
Private appSettings As System.IO.IsolatedStorage.IsolatedStorageSettings = System.IO.IsolatedStorage.IsolatedStorageSettings.ApplicationSettings
‘the End Class comes at the end of the app code
[/crayon]
In the MainPage_Loaded sub put the code:
[crayon lang=”vb”]
Private Sub MainPage_Loaded(ByVal sender As Object, ByVal e As RoutedEventArgs) Handles Me.Loaded
If appSettings.Contains(“AgreedToPrivacyPolicy”) = False Then
NavigationService.Navigate(New Uri(“/PrivacyPolicy.xaml”, UriKind.Relative))
GoTo Jumpiiii ‘Yes I love to use GoTo in VB
End If
If NavigationService.CanGoBack = True Then NavigationService.RemoveBackEntry()
Jumpiiii:
End Sub[/crayon]
Line 6 is very important, and I will explain to you why later on.
After navigating to your privacy policy, the user clicks on I agree and in the button_click sub you add the lines:
[crayon lang=”vb”]
appSettings.Add(“AgreedToPrivacyPolicy”, “True”)
appSettings.Save()
NavigationService.Navigate(New Uri(“/MainPage.xaml”, UriKind.Relative))
[/crayon]
If the user wishes to reject the privacy policy, the user will hit the back button. This would navigate the app to the MainPage and the checking that we added earlier will be invoked again, and again this will navigate the user to the privacy policy page, where it should in fact take the user out of the app. This can be easily achieved by adding the following code to the PrivacyPolicy_Loaded sub:
[crayon lang=”vb”]
Private Sub Page1_Loaded(ByVal sender As Object, ByVal e As RoutedEventArgs) Handles Me.Loaded
NavigationService.RemoveBackEntry()
End Sub[/crayon]
Line 2 here removes the MainPage from the back list such that when the user presses back, the user goes directly out of the app without invoking an exception. This is, in my opinion, the best way to exit and application.
One more thing is the case where the user accepts the agreement and then the app navigates to the MainPage. What happens if the user presses back from there? Will the user be navigated back to the PrivacyPolicy page? The answer is NO. Because we covered that already in line 6 in the first code snippet in this article. We told the MainPage to check if there is a previous page in the Back Stack and if there is, erase it.

The KeyCode Glitch in Windows Phone 7

Posted on February 3, 2012 by WP7 2

Mobile application development is a very new field for me. Being a university professor has got me through some VB courses that were not so deep, but I might not call myself a professional developer. Anyway, few weeks ago I had an increasing interest in mobile application development and I decided to start with WP7 development because I had some experience in the VB environment.

I installed the Visual Studio 2010 Express for Windows Phone. I started having some trouble when I needed to get a TextBox (which is a simple text entry space) to receive only numbers from the user and not allow the user to enter anything but numbers.

A simple solution would be the use of an event called KeyDown that is triggered whenever a key is pressed. Afterwards, I need to filter the pressed key such that if it is a number, it would pass, and any other key would be ignored. The easiest way to do this is through the key codes from 48 to 57 which are the correspondent codes to the keys “0”, “1”, “2”,….”9″. So I wrote a simple line of code to do the required:
[crayon lang=”vb”]Private Sub YOURTEXTBOX_KeyDown(sender As Object, e As System.Windows.Input.KeyEventArgs) Handles YOURTEXTBOX.KeyDown
if e.PlatformKeyCode < 48 or e.PlatformKeyCode > 57 then e.Handled=true
End Sub[/crayon]
This line basically ends the handling of the key that is pressed if it is not a digit.
What came as a shock to me was that when testing the app on the emulator on the computer, I found out that other characters (some symbols) where also showing up in the textbox along with the numbers. Symbols like ( ) $ % where also “pressable” in the text box. After digging for a while, I found out that these symbols had the same key codes as the digits ..!!!
To get a solid ground of this finding, I created a simplified app that simply shows the key code of the key that you are pressing on the virtual keyboard. Yes. Numbers and few symbols have the same key codes. After testing, the numbers and the symbols having the same key codes such as were frustrating; number 2 and @, number 3 and #, and all the others. The capital and small letters also have the same codes.
Apparently, I was not the only one who had this few other developers also had that issue. Since I have not yet received my Windows phone, I was not able to confirm that this is an Emulator glitch or an OS glitch.
If you have an unlocked Windows phone and Visual Studio, and you would like to confirm, or deny, that issue, download the .xap file of the app I did to view the codes of pressed keys and comment back in here. Here is the app download link to the KeyCodeDisplay.xap.

Moving on to the app development, if you are wondering how to go around this in the WP7 app that you are developing, here is one of the solutions. Use an event called KeyUp instead of the KeyDown used earlier, and put this code in it

[crayon lang=”vb”]Private Sub YOURTEXTBOX_KeyUp(sender As Object, e As System.Windows.Input.KeyEventArgs) Handles YOURTEXTBOX.KeyUp
Dim T As String, a As Char, b as Integer
T = “”
b=YOUTEXTBOX.SelectionStart
For i = 1 To YOURTEXTBOX.Text.Length
a = YOURTEXTBOX.Text.Chars(i – 1)
If a = “0” Or a = “1” Or a = “2” Or a = “3” Or a = “4” Or a = “5” Or a = “6” Or a = “7” Or a = “8” Or a = “9” Then
T = T + YOURTEXTBOX.Text.Chars(i – 1)
End If
Next i
YOURTEXTBOX.Text = T
If T <> “” Then YOURTEXTBOX.SelectionStart = b
End Sub
[/crayon]

I know that changing the InputScope can handle the situation with a PhoneNumberInputScope, but still the special characters such as “.” can cause you a problem. Another case is when you need a limited number of characters to be acceptable instead of the whole keyboard. I needed to use a similar method in my app PassworderPro when I had to create a textbox that accepts only capital letters.

Visit my publons profile