Sometimes you like to present a list of items to the user. But the requirements for that list are so, that it must remain compact, wrap at the screen edge and editable in that sense that you can remove items quickly.
This kind of list is often represented by tags, so how do you do this in an universal app, let me show you how!

First thing that is very important to note, is the fact that we will be using a RichTextBlock with an InlineUIContainer. We do this, because the RichTextBlock handles the screen wrapping/overflow! That will enable us to add tags and each time a new one is added to the list, the RichtTextBlock will validate if it will still fit the current line, if not it will add a new line and wrap.

And to be honest that’s it! Only thing left to do is add the real tags, that are actual Buttons inside the InlineUIContainer. In the current demo application I’m doing this in the code behind of the MainPage file, there is a method called SetTags.

Again a bit the same concept as the removal. For each tag not yet in the current tag list, we create a new button with a specific style and add a click handler that will enable the removal. Once that button is created we add it to the RichTextBlock InlineUIContainer so it will show up on screen.

When the user presses the tag, the click event will fire an the selected tag will be removed from the list.

So I wanted to get my hands dirty with some SQLite in Universal Apps.
Turns out I had my hands full with trying to figure out why stuff wasn’t working… so here a small blog post to help others if they have the same problems.

First problem, while using the SQLite-net in combination with SQLite-net extensions, the SQLConnection method needs an extra parameter to identify for what platform you want to run SQLite.
So what you’ll see in most tutorials:

Second problem, when doing all this, everything works great – but I was unable to check if the database exists after I created it with the SQLConnection method!
Again all tutorial say, just check the local storage like this:

So if you’ll get an exception the file does not exists, so there would not be a DB. But even though I had no file, I was able to perform queries!
Seems SQLite-net uses a pre compiler directive NETFX_CORE that is being hit when I only supply a db name to the SQLConnection method. The code is in the SQLite.cs file here https://github.com/praeclarum/sqlite-net/blob/master/src/SQLite.cs

Back in the SilverLight days when you created a Windows Phone app that needed to store user credentials, there was only one good way to do this!
You had to use the ProtectData class with it’s Protect and Unprotect methods.

Big advantage of using PassworVault, is that it will roam the settings across devices! So in other word, if you first installed the Windows Phone app and entered your credentials. Than download the Windows Store app, you’ll no longer need to enter your credentials because the app uses the same Vault and can already read the needed info out of it!

Now let me show you how you implement these 2 options, so you’ll have a clear overview of how to migrate from one to the other.

First up, the use of ProtectData.
What I tend to do is protect all account data in one go by first creating a json string from the given data and storing that as a protected byte array inside a file on the Windows Phone.
Small note: the Account class in the examples below is just a small POCO with UserName and Password properties.

So you see it’s very easy to store a whole collection of account info in your isolated storage in a secure way!
Now when you upgrade your app to WP 8.1 RT, you’ll want to do this in a different way! By using the PasswordVault to ensure that your credentials are still stored in a secure way AND are roaming across devices.

When you want to use the PasswordVault in your app, you’ll need to select your own app key. Because everything stored and retrieved from the vault is done with that key! This is needed because otherwise, when linking your WP and Win Store app, you won’t be able to read out the same credentials.

Getting all credentials from the vault is done through the FindAllByResource method, supplying the app key. Do note that you’ll need to check for exceptions that can occur by doing this, because if the given app key is not yet present in the vault, you’ll get an exception!
After that, you’ll need to request the password for each credential that you got from the vault! Don’t forget this, because when using the FindAllByResource method the passwords will still be empty. Getting the password is done by using the RetrievePasword method.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

privateasync Task InitializeSettingsService()

{

_vault=newPasswordVault();

IReadOnlyList<PasswordCredential>credentials=null;

try

{

credentials=_vault.FindAllByResource(Constants.VAULTRESOURCENAME);

}

catch(Exception exception)

{

//Just catch the exception! When the vault has not yet setup a collection for the given resource, we get an exception!

}

if(credentials!=null)

{

this.Accounts.Clear();

foreach(varpasswordCredential incredentials)

{

passwordCredential.RetrievePassword();

this.Accounts.Add(newAccount()

{

UserName=passwordCredential.UserName,

Password=passwordCredential.Password

});

}

}

}

So now we already know how to get hold of everything in the vault, but how do we store or remove accounts?
Well there are 2 methods for this, Add and Remove, so as easy as that. Do note there is no Update method.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

publicasync Task AddAccount(Account accountToAdd)

{

//Reinitialize the vault to see if the given account is already available