When using a ContentDialog in UWP to allow the user to make some kind of action that depends on a service or other asynchronous call, you probably want to ensure that call completes correctly before dismissing the dialog window. Otherwise, the result is just forgotten about. In our UWP sample app, users can give gold to a particular photo they like and leave a comment. In the GiveGoldDialog the user inputs their comment text and then presses the “ok” button, which the app then fires off actions to handle gold balance transactions and creating the comment on the photo. Before dismissing the GiveGoldDialog, we wanted to be sure that those calls completed.
When handling the PrimaryButtonClick event, before initiating the actions get a ContentDialogButtonClickDeferral object from the ContentDialogButtonClickEventArgs parameter. Creating this deferral object will prevent the button click from finishing until you complete it, suspending(or canceling) the dialog from closing until your service call finishes. Based on your service’s actions, you can even stop the dialog’s button click from closing the dialog by setting the args’ Cancel parameter to true. This could be done to tell the user that the request wasn’t able to complete and try again or that maybe their content failed some kind of validation. In our sample app we would cancel the the action if the user’s gold balance was too low to complete the transaction.
async void Dialog_PrimaryButtonClick( ContentDialog sender, ContentDialogButtonClickEventArgs args )
// Get the deferral because we need to await the
// annotation to post.
var deferral = args.GetDeferral();
// Get creation status and if failed, let's
// keep the dialog opened.
var success = await ViewModel.MakeFooServiceCall();
args.Cancel = !success;
// Complete deferral to close the dialog.
When we originally wrote this code, the deferral object wasn’t very well documented and it took us some digging to figure out what it was and how to use it. Now it seems to be well documented within an example, but maybe this post will still help someone :)
I’ve been working on writing some code samples for our Universal Windows Platform, they really are pretty neat how they enable a single app to run across Windows desktop, phone, Xbox One, and even HoloLens eventually. We’ll have the code sample released in the near future, but for now I wanted to blog about some small issues I’ve run into, couldn’t find any relevant documentation or stackoverflow answers, and I ended up figuring out the solutions on my own.
In this case, we were creating a listview and each item we wanted to be clickable to navigate to a detail page regarding that item. The listview control does have a selected item functionality built in, but we didn’t want to use that. A simple command to execute when one of the items is clicked is exactly what we wanted.
Seems like this will get the job done, but compiler kept throwing us this very helpful error.
Cannot add instance of type 'Microsoft.Xaml.Interactions.Core.EventTriggerBehavior' to a collection of type 'Microsoft.Xaml.Interactivity.BehaviorCollection'. [Line: 27 Position: 95]
Cannot add instance of type 'Microsoft.Xaml.Interactions.Core.InvokeCommandAction' to a collection of type 'Microsoft.Xaml.Interactivity.BehaviorCollection'. [Line: 29 Position: 99]
Cannot add instance of type 'Microsoft.Xaml.Interactions.Core.EventTriggerBehavior' to a collection of type 'Microsoft.Xaml.Interactivity.BehaviorCollection'. [Line: 28 Position: 95]
Well, after a bit of digging I found out that a data template does not support an event trigger behavior for the event name as ItemClick. The ItemClick event is actually specific to the ListView xaml control, which is why the compiler complains that it cannot be added to the BehaviorCollection, so in our event trigger behavior we had to use a different event entirely. The Tapped event is the event we want, it is a high level event to cover both touch and mouse interactions.
This issue came up as I was dealing with the Spring Portlet ResourceRequest change(before I found the problem/solution). Still not getting the portlet to render views via ResourceRequests properly, I decided to test with Spring 3.2.x to see if the problem would follow. I was also curious to see what changes would be made on the portlet side of things, any added improvements or shortcuts? Based on the 3.2.x changelog, not much was changed regarding portlet support(ctrl+f “portlet”). But its never that simple, right?
Enter SPR-8684. This change actually makes things easy for most Spring webapps; automatically prepending the contextPath and servletPath in the Spring form tag is an easy shortcut. But for portlets, this renders the form tag essentially useless. Portlets don’t want their forms to be prepended with their own contextPath, they should resolve to the portal’s contextPath. The good news is that my request for a fix was accepted almost instantly, SPR-10382. So I’ll just have to wait to use Spring 3.2.3.
I know many of my most recent posts have been about problems using Spring, but I don’t want to sound like a complainer. Without Spring I would be without a brilliant framework to code portlets with, and its a pretty niche area to be honest. I love Spring because they are constantly moving forward by adding new ideas and technologies into their product. Also, the community support is pretty fantastic!
I am currently in the process of updating some of our portlets to use Spring 3.1 and the new Portlet 2.0 spec in preparation with a portal framework upgrade taking place for ZotPortal this summer. A problem we were experiencing using the new Spring 3.0 annotations for our portlets was the new way Spring handles validation/binding errors for forms. Before, the validation is done in the action phase, then the error(s) are stored in the model attribute, and if errors are present you can redirect back to the render phase so the initial page form will be displayed again with the submitted data but this time displayed with error messages that explain to the user why it failed validation. I was surprised when the validation would fail this time and redirect back to the page form but no errors would show. Apparently something changed in the way Spring handles objects placed into the model via the @ModelAttribute annotation. Now Spring would replace an object even if it is associated with errors and they will not be present/displayed when redirected back to the form.
A few solutions have been proposed across the spring forms, stackoverflow, and the interwebs;
Validate the form object during the render phase as well. This will generate the errors and have them displayed on the form when the rendering completes
Explicitly preserve the form object or errors after the redirect and ensure they get passed to the form when rendering completes
Instead of using @ModelAttribute, persist the form object as a session attribute so it persists across the action and render phases
Option 1 isn’t an option for our applications. In the initial render phases the form object would not pass our validation tests because it isn’t filled out yet! We don’t want to display validation error messages to the user upon the first load of the form when they haven’t had a chance to submit any data yet, it would seem a bit rude in my opinion. Validation should occur if data has been submitted. Option 3 seemed to be overkill, submitting a simple form shouldn’t need to persist the form object in the session which lives well past the action phase of the submit. I believe Spring has some nice ways of handling these session attributes, but I haven’t played with it very much.
I decided to use option 2. When the render phase is deciding what object to populate the form with it first checks to see if an applicable object with errors already exists in the model, if it does it lets that object stay in the model to populate the form. The previous submitted data and errors get passed through the render phase and displayed on the form for the user to see and fix so it can be validated properly.
Okay, I know this might be posted little bit late, but I loved this talk.
So much truth in who we are can be seen in our motivations. Looking at my own I notice a number of things:
Creating software and web applications are not simple, straightforward tasks that can be completed without thinking. Working software requires a lot of thought. Furthermore, working software that is also well designed software is honestly more art than it is science.
I want to work on cool, interesting ideas. Compensation isn’t the driving force here, I am. I am passionate about programming. I love it.
Motivation is more important than compensation.
Right now I am winding down in my first job search for after college. It has been a fun journey with lots interviews, some let downs, a few surprises, and tons of experience. When confronted with my end choices of possible employers, I’m not looking at where I could make the most money. I’m looking at where I think I will get the most motivation and paid enough for my work. I don’t want to think about money, I feel like that is a waste of thought. I want to think about my work, and create interesting things. I am passionate about programming after all, and not money.
As you know, I am currently programming web applications for the University of California Irvine. I mainly work on web content for the student portal, ZotPortal. If you aren’t too sure of what a web portal is, think iGoogle–lots of different content pieces all together in one place. These content pieces are called portlets and I design, engineer, and maintain them on ZotPortal. I want to talk about about two different things in this post, 1) a portlet I designed that enables people to search for on campus organizations at UCI and 2) some different ways of obfuscating email addresses(or other data) from potential spammers. The connection will become apparent later.
Now, on each organization’s information panel we supplied a mailing address so a user could contact the club leaders. And since this portlet is accessible from the guest view, there is potential for spam bots to troll through our student portal and collect all of the club email addresses to sell or send spam to. I wanted to hide the email addresses from the spammers while at the same time enable the viewer to use the email. So, I spelled out the symbols in the email to confuse any would-be spam bots reading through my portlet data. Instead of firstname.lastname@example.org, coolclub[at][you see eye][period]edu. An average spam bot wouldn’t recognize this as an email address, spam avoided! The only thing that bothers me with this approach is the fact that the user has to do the work of replacing [at][you see eye][period] with”@uci.”. Sure, it isn’t very difficult or time consuming, but it would be a lot better if the user could simply copy/paste or click a mailto tag.
I found someone in a similar dilemma and a really good answer was provided to him. Examining these different methods of obfuscation allows us to pick the best one for our situation.
The author of this study (credit to Silvan Mühlemann; his original post can be found here) even watched of these methods for 1.5 years just to see the different amounts of spam each strategy would receive. These were his findings…
To kick this Project site off I figure I’d start revisiting some work I did a couple quarters ago at UCI in an AI project course. We set out to experiment with some different Checker strategies and see how they would fair against each other, against us, and (most importantly) against another team developing another Checkers AI system. It was an interesting project to say the least. I’ve created a simple game from my own ideas, but I haven’t created a game from a preexisting set of rules before or have the game play against the human. The game system is pretty self explanatory; moves are hi-lighted, jumps are mandatory, a piece becomes a king on the other end of the board, and you win when you lose all your pieces or when you can’t make a move. I really wanted to build this in something other than a Java applet, since they aren’t used much these days, but it was the closest and easiest tool to use for what I needed. The AI depth search uses a min/max and alpha/beta pruning strategy to allow the massive move set to be shortened so a move decision can be made in reasonable time, but a search of depth 10 still makes a noticeable pause.
The most interesting part of this project is the AI strategies we implemented.
The AI selects a move at random. Hardly a challenge
The AI examines all possible moves within the search depth value. It then selects the move that allows the AI to be in the position were losses and gains will be the most beneficial. Ideally, the more pieces it can take and least amount of pieces it can lose will increase the probability to win the entire game. This strategy is easily countered by tricking the AI with bait, and then trapping and taking its piece. The best choice is based on an average score derived from a couple of heuristics.
Taking pieces(+ for regular; ++ for kings)
Loosing computer pieces(- for regular; — for kings)
Moving a piece from a ‘King Me’ square(–)
In addition to the the heuristics above for the basic strategy, a piece table is also incorporated into the score for a move. The piece table gives each square a value and it is added into the the average score for each move. This is the piece table used for the Checkers game. Each number denotes a square worth value. The higher the value, the higher the worth of keeping a piece on that square. Notice that all ‘King Me’ squares hold the highest value of 4, these spots are very important and a player would only want to move a piece from this location as a last resort. Squares close to the sides of the board also have the value 4, and closer inside is 3, are the least vulnerable from attacks. On the other hand, the squares in the very middle of the board hold a value of 1. These squares get vacated as fast as possible since they are most susceptible from attacks. The numbers make a sort of spiral from the outside, decreasing in value as they come closer to the middle. This strategy is very strong since it combines the heuristics from the Basic strategy to minimize losses and maximize gains as well as achieve optimal piece placement on the board to further minimize more losses and maximize more gains. I have not been able to beat this strategy.
Overall it was a very enlightening project to work on. I learned a lot working with massive decision trees, different strategies, implementing given rules, and classifying data sets using a range of scores. I was quite happy with the outcome of an AI that can easily beat its creator, and with the fact that we smoked the other Checkers project team. Try your luck playing against it in the Code/Src tab.
I have a couple of planned changes for this application’s future:
Simplify the button options
The three buttons on the GUI made sense at the time I created them, but many users have reported that they have trouble knowing which one to click when. Combining the Resign and New Game button into a single one will free space for an AI vs AI option. Another problem is that when the Make AI Move button is pressed the player switches sides. They have to click it again to resume play as the original red color.
Allow the player to select his color at start of game