ppti.info Fiction Asp.net 3.5 Social Networking Ebook


Wednesday, October 9, 2019

The full social network application is available for download from the Packt website, for you Andrew Siemer | Packt Publishing | | E- Sentral Ebook Portal ppti.info Social Networking by Andrew Siemer from in category. ppti.info Social Networking. Andrew Siemer. December pages. 17 hours 24 minutes. An expert guide to building. Read "ppti.info Social Networking" by Andrew Siemer available from Rakuten Kobo. Each chapter starts by showing the user experience we are going to.

Asp.net 3.5 Social Networking Ebook

Language:English, Spanish, Portuguese
Published (Last):26.02.2016
ePub File Size:30.84 MB
PDF File Size:20.64 MB
Distribution:Free* [*Regsitration Required]
Uploaded by: BLANCH

Read "ppti.info Social Networking" by Andrew Siemer available from Rakuten Kobo. Sign up today and get $5 off your first purchase. Each chapter starts by. Editorial Reviews. About the Author. Andrew Siemer is currently the enterprise architect at OTX Kindle Store; ›; Kindle eBooks; ›; Computers & Technology. ppti.info Social Networking [Andrew Siemer] on ppti.info *FREE* shipping on qualifying offers. This book will show you how to create a scalable.

Neil Smyth. PHP Hacks. Jack D. Java for Programmers. Harvey M. Core Python Applications Programming. Wesley J Chun. MySQL 5 Essentials. Programming JavaScript Applications.

Eric Elliott. JSF 2. Anghel Leonard. Java SE8 for the Really Impatient. Cay S. Expert Python Programming. Kevin Forsythe. Odoo Development Essentials. Daniel Reis. Ryan Vice.

Benjamin LaGrone. PHP Certification Review: Equity Press. Odoo Development Cookbook. Alexandre Fayolle. Odoo 11 Development Essentials. Programming Razor.

Jess Chadwick. Larry Ullman. Django By Example. Antonio Mele. Zend Framework 2. Beginners Guide. Krishna Shasankar V. PHP Web Services. Lorna Jane Mitchell.

Browse .NET / ASP.NET Titles

Learn PHP 7. Steve Prettyman. Yannick Lefebvre. WordPress 3 Plugin Development Essentials. Brian Bondari. Programming with Swift4.

Beginning Swift Programming. Wei-Meng Lee. PHP 5 Social Networking. Michael Peacock. Pro React. Cassio de Sousa Antonio. Burkhard A.

Programming Firefox. Kenneth C. React Design Patterns and Best Practices. Michele Bertoli. Beginning Java Programming. Bart Baesens. Learning Python Design Patterns. Gennadiy Zlobin.

Microsoft Windows Workflow Foundation 4. Andrew Zhu. MySQL for Python. Albert Lukaszewski. CakePHP 1. Mariano Iglesias. Essential App Engine. This will contain your tracking information All our estimates are based on business days and assume that shipping and delivery don't occur on holidays and weekends. Delivery with Standard Australia Post usually happens within business days from time of dispatch. Please be aware that the delivery time frame may vary according to the area of delivery and due to various reasons, the delivery may take longer than the original estimated timeframe.

If you have not received your delivery following the estimated timeframe, we advise you to contact your local post office first, as the parcel may be there awaiting your collection.

If you have not received any information after contact with Australia Post, please contact us to confirm that the details for delivery logged with us are correct. We will then contact you with the appropriate action. The specific part of the presenter's Init method, which is of interest here is as follows: In case you are wondering won't a direct call to the Profile.

The routing engine by default excludes all calls that match to physical files. A news feed allows us to see what we have been doing with our account, friends, our photos, and any other changes in the system. More importantly, it will allow us to see what our friends have been doing with all their data such as when they add a new photo.

This system will be built on the alerts system that we have already discussed. Any time we want to add a new alert to the system based on an action performed by our user or the system, we simply make a call into the AlertService and select the appropriate method such as AddNewAvatarAlert. Once the site is peppered with the addition of alerts to the system we will have fairly active news feed to follow. Now, we just need a place to read this feed!

Knowing that this news feed will easily be one of the most active pages on our site, we should put it on the users' homepage so that they can see it as soon as they log in. To implement this, all we need is a repeater with a label in it, on the homepage, which we can hook up to a list of alerts for the current user. We get the list of alerts, convert them into a list of strings and pass it to the view to display.

Add item. Summary We have covered a lot of ground in this chapter. We have discussed the concept of a profile and a way for our users to manage their data.

We have also built a way for our users to manage their privacy regarding their profile data. We have also created tools for our users to manage a custom avatar as well as a way to hook up to their centrally stored Gravatar. With all of these features out of the way, we have created a public profile for our users.

And finally, we also created a default landing page for users where they can see their alerts. Your friend features will be the main reason for people to interact with your community. It is also the biggest drive for your users to advertise for you. I love it, so will you! A circle of friends can be thought of as a sub-community within a community.

This chapter will show you how to take advantage of people's nature to congregate around things that they enjoy, find useful, or that intrigue them. We will start this chapter by extending the framework to allow for relationships to be built between our users.

We will then add some features that allow our users to locate all of their existing friends, as well as make new friends. Then we will have a discussion about providing real time status updates in the form of a micro blog so that all of our friends can stay in touch with everything we are doing.

Problem There are many aspects to building relationships in any community—real or virtual. First and foremost is initiating contact with the people whom you will eventually call your friends. The easiest way to locate someone who you might want to call a friend is to directly invite the people who you already know as a friend. We will do this in a few ways. Friends 1. First, we will provide a way for our users to search the site for friends who are also the members.

Second, we will create a form that allows you to enter your friends' email IDs and invite them directly. Third, we will create a form that allows you to import all of your contacts from the Outlook.

All of these methods of inviting a friend into the system would of course generate an email invite and eventually a system-based message—see next chapter. The user will have the ability to then follow the link into the system and either sign up or log in to accept the request.

Social Networking Website Using ASP.net

We will need a way for our users to view all of their friends. We will also need a way for our users to remove the relationships for those users who are no longer friends! Finally we will need to add friends to our user's public profile. While this is a good first pass at integrating the concept of friends into our site, there are a couple more steps for true integration.

We need to add a friend request and friend confirm alerts. We also need to modify the alert system so that when users modify their profile, change their avatar, or any other alert that is triggered by users of our system, all of their friends are notified via alerts. In the current world, anyone who has an online presence is also typically active on Twitter. It is a micro-blogging platform and mostly gets used by people for: Users can update this and the updates will be sent to their friends as alerts.

Each of these updates will also be shown on the updates view and in their alerts view. Design Now let's talk about the design of these features.

Friends This chapter is an attempt to throw light on the infrastructure needs and more heavily focus on the UI side for creating and managing relationships. That being said, there is always some form of groundwork that has to be in place prior to adding new features. This concept is a relatively simple one as it is really only defining a relationship between two accounts.

We have the account that requested the relationship and the account that accepted the relationship.

This allows an account to be linked to as many other accounts as they wish. Finding friends The Friends feature will not go anywhere if there is no way for people to find friends. For that reason the various ways to locate and invite someone to be your friend is our first topic.

Searching for a friend The easiest way to locate friends who might be interested in the same site as you are is to search through the existing user base. For that reason we will need to create a simple keyword search box that is accessible from any page on the site.

This search feature should take a look at several fields of data pertaining to an account and return all possible users. From the search results page we should be able to initiate a friend request. Inviting a friend The next best thing to locating friends who are already members of the site is to invite people who you know out of the site. The quickest way to implement this is to allow a user to manually enter an email address or many email addresses, type a message, and then submit.

This would be implemented with a simple form that generates a quick email to the recipient list. In the body of the email will be a link that allows the recipients to come in to our site. Importing friends from external sources An obvious extension of the last topic is to somehow automate the importing process of contacts from an email management tool. We will show how the user can export their contacts from Outlook and import them via a web form.

The user should then be able to select the contacts that they want to invite. We could simply send out an email with a link to the site. However, we need to maintain: In the email, rather than just inviting people in, we want to assign the user a key so that we can easily identify them on their way in. We will use a system-generated GUID to do this. In both cases we will populate the invitation with the invited user's Account ID so that we have some history about the relationship.

Adding friend alerts Once we have the framework in place for inviting and accepting friendship requests, we need to extend our existing system with alerts. These alerts should show up on the existing user's Alerts page to show that they sent an invitation.

For existing users, we should have alerts showing that they have been invited.

Once a user has accepted a friendship we should also have a related alert. Interacting with your friends Now let's discuss some of the features that we need to interact with our friends.

Viewing your friends Friends are only good if a user can interact with them. This is a jumping off point for a user to view the profile of friends.

Also, as the concept of a user's profile grows, more data can be shown about each friend in an at-a-glance format. In addition to an all Friends page, we can add friends' views to a user's public profile so that other users can see the relationships.

Following your friends We can extend the alert system so that when alerts are generated for a user, such as updating their profile information, uploading a new photo, or any other user-specific task, all the user's friends are also notified via their Alerts page.

Providing status updates to your friends We have briefly touched on this already in earlier sections. This feature creates a lot of dynamic content on an end user's homepage, which keeps things interesting.

Solution Now let's look at our solution. Implementing the database Let's look at the tables that are needed to support these new features. The friends table As the concept of friends is our base discussion for this chapter, we will immediately dive in and start creating the tables around this subject.

As you have read previously this is a very straightforward table structure that simply links one account to the other. It also holds the key GUID that is sent to the friends so that they can get back into the system under the appropriate invitation.

Once a friend has accepted the relationship, their AccountID is stored here too, so that we can see how relationships were created in the past. Status updates Status Updates allow a user to tell their friends what they are doing at that time. This is a micro blog so to speak.

A micro blog allows a user to write small blurbs about anything. Examples of this are Twitter and Yammer. For more information take a look here at: It tracks who said what, what was said, and when. Creating the relationships Here are the relationships that we need for the tables we just discussed: Open your Fisharoo.

Once you hit Save we should have three new classes to work with. Building repositories As always, with these new tables will come new repositories.

The following repositories will be created: Let's look at each of these repositories one by one. They provide a way to get at one record, many records by a parent ID, save a record, and delete a record. This repository however differs slightly from the norm when it is time to retrieve a list of friends.

It has two sides of the relationship to look at—on one side where it is the owning account of the friend relationship, and on the other side the relationship is owned by another account. Here is that method: Friends where f.

AccountID; f. We want to return List which is achieved by calling friends. It then queries for the reverse relationship where this account is owned by another account. Then it adds the second query to the first and returns that result.

Here is the method that gets the Accounts of our Friends. Add friend.

Other books: MCITP 70-642 EBOOK

Accounts where accountIDs. Contains a. FriendInvitationRepository Like the other repositories this one has the standard methods and we don't list them here. Refer to the code associated with this chapter for details. In addition to those we also need to be able to retrieve an invitation by GUID or the invitation key that was sent to the friend.

In addition to the above method we will also need a way for invitations to be cleaned up. For this reason we have the following method: FriendInvitations where fi. Rather than checking if the invitation already exists when it is created, we will allow them to be created time and again checking each invite during the import process of contacts could really slow things down!

When account B finally accepts one of the invitations all of the others will be cleared. Also, in case account B never does anything with the invites, we will need a database process that periodically cleans out old invitations. StatusUpdates where su. CreateDate descending select su.

AccountRepository With the addition of our search capabilities we will require a new method in our AccountRepository. This method will be the key for searching accounts. Accounts where a. Contains SearchText a. This could of course be extended to their profile data and many other data points all in good time! We will be creating one service per repository added and in addition to that we will also be extending these services: We will need it to tell us whether or not a user is a Friend or not so that we can extend the PrivacyService to consider friends recall that we currently only understand public and private settings!

In addition to that we need our FriendService to be able to handle creating Friends from a FriendInvitation. FirstOrDefault ; if friend! It then verifies that both of the accounts are valid so that we can use them down the road and returns false if either of them is invalid.

We then check to see if the user that is doing the viewing is the same user as is being viewed. If so we can safely return true. We iterate through that list to see if our friend is there in the list or not. If we locate it, we return true. Otherwise the method has failed to locate a result and returns false. Keep in mind that this way of doing things could quickly become a major performance issue. If someone had friends this would not be acceptable.

As our goal is for people to have lots of friends, we generally would not want to follow this way. Your best bet then is to create a LINQ query in the FriendsRepository to handle this logic directly only by returning true or false. An alternative will be to use caching.

Now comes our CreateFriendFromFriendInvitation method, which as the name suggests creates a friend from a friend invitation. Email return false; friendInvitation. AccountID; friend. We then make a call to flush any other friend invites between these two users. Once we have everything cleaned up we add a new alert to the system covered shortly letting the account that initiated this invitation know that the invitation was accepted. Notice that we will also need to add something here to send a message via the messaging system covered in the next chapter!

AlertService The alert service is essentially a wrapper to post an alert to the user's profile. All the plumbing for this was covered in a previous chapter. So the additional methods that we have added are very similar to what was done previously. We will not describe these methods here. PrivacyService Now that we have a method to check if two people are friends or not, we can finally extend our PrivacyService to account for friends.

Remember that up to this point we are only interrogating whether something is marked as private or public. There is only a minor change in the code. Everything else was handled previously! Implementing the Presentation layer Now that we have the base framework in place we can start discussing what it will take to put it all together. Like we said earlier, this chapter is less about framework and more about the UI that utilizes the new and existing framework! Searching for friends Let's see what it takes to implement a search for friends.

SiteMaster Let's begin with searching for friends. We haven't covered too much regarding the actual UI and nothing regarding the master page of this site.

We don't want this to be about design! So we will simply say that we have added a text box and a button to the master page to take in a search phrase. When the button is clicked the site redirects to Search. Search The Search. It expects a value to be passed in from the previously discussed text box in the master page.

With this text phrase we hit our AccountService and perform a search using the Contains operator. The returned list of Accounts is then displayed on the page.

For the most part, this page is all about MVP plumbing. We are going to assume that you are up to speed with MVP, from this point on stick to only the fun stuff. Here is the repeater that displays all our data. The fun stuff in this case comes in the form of the ProfileDisplay user control that was created so that we have an easy way to display concise profile data in various places with one chunk of reusable code that will allow us to make global changes.

You should see that we have. You will also notice that our tag has custom properties that are set in the tag definition. All the logic and display is very standard. You have the MVP plumbing, which makes up most of it. Item e. LoadDisplay Account e. LastName; lblFirstName. FirstName; if account. HasValue lblCreateDate. Redirect HttpContext. These buttons are not appropriate for every page that the control is used in. In the search results page we want to hide the Delete button as the results are not necessarily friends.

We would want to be able to invite them in that view. However, in a list of our friends the Invite button to invite a friend would no longer be appropriate as each of these users would already be a friend.

When will my book be dispatched from your warehouse?

The Delete button in this case would now be more appropriate. Clicking on the Invite button makes a call to the Redirector class and routes the user to the InviteFriends page. An important point to note is the construction of the URL in the LoadDisplay method, which takes you to the user's profile page.

You will recall that we had defined the ProfileRoute in previous chapter to support fancy URL directly linking to user's profile page. This is useful if we end up changing our route pattern, as defined in Global. Invite your friends This page allows us to manually enter email addresses of friends that we want to invite. It is a standard From, To, Message format where the system defaults the sender to you , and you specify who to send to and the message that you want to send.

The only important part in the code behind is the call to the presenter to send the invitation when the Invite button is clicked.

We will skip looking at the ASPX and the code behind file and directly jump to the presenter code. DisplayToData account.

SendInvitations account. FirstName, account. Once the user fills in the emails to be invited, the SendInvitation method is invoked, that takes in the comma delimited array of emails and the message to be sent in the invitation. It then makes a call to the Email. SendInvitations method. NewGuid ; friendInvitation. GetAccountByEmail s ; if account!

CurrentUser, account, friendInvitation. It then adds an alert to the invited user if they already have an Account.

Outlook CSV importer The Import Contacts page is responsible for allowing our users to upload an exported contacts file from Microsoft Outlook into our system.

Once they have imported their contacts the user is allowed to select which email addresses are actually invited into our system. Importing contacts This page is made up of a couple of views, which are created using panels.

This allows us to easily show or hide an entire set of controls within a panel. In the initial view we let the user upload a CSV file, which is an exported list of Microsoft Outlook contacts.

There are instructions on the page that help the user with the export operations see the following screenshot. It puts the file reference into a StreamReader and then reads the stream into a string variable named contacts.

Once we have the entire list of contacts we can then call our Email class and parse all the emails out. Multiline ; foreach Match m in re. Contains email emails. It then parses the emails using a regular expression. We then iterate through all the matches in the Regex and add the found email addresses to our list, provided they aren't already present.

Once we have found all the email addresses, we will return the list of unique email addresses. The presenter then passes that list of parsed emails to the view. We essentially have a checkbox list in our panel. This checkbox list is bound to the list of email addresses returned post-parsing in the presenter class. Once they are through selecting the emails that they want to invite, they can click on the Invite button.

We then iterate through all the items in the checkbox list to locate the selected items. Substring 0, emails. This is the same method that we used in the last section to invite users.

Join Kobo & start eReading today

Confirm friendship Having covered all these ways to invite someone into our site, we now need to look at what the invited user sees in the invitation. Let's start with what they would see in their inbox. The user gets an email in their inbox telling them that someone has invited them to become part of the Fisharoo community.

Once they open that email they can see the link that they can follow to the site to take advantage of the invitation. There are two screens that the user might see after this point. The first screen is for the users who are already members and are currently logged into the site.

It asks them to log in again to confirm the friendship. The other screen is for the users who aren't members, or the users who aren't logged in. This happens in the presenter of this page. FriendshipRequest ; if friendInvitation! FriendshipRequest, account. AccountID, account. ShowMessage "There was an error validating your invitation. If we can, then we check to see if the user is already a member of the system and logged in.

If they are logged in we automatically redirect them to the login screen. Otherwise we prompt them to log in or create an account. If the friendInvitation can't be loaded properly then we show an error explaining that. The real magic occurs for the invitation process in the login and registration pages.

Login In the login presenter we have added some logic to the Init method to recognize if we have a friendship request or not. DisplayMessage "Login to add this friend!

Then in the AccountService. If the login is a success and if there is a friend request, we confirm the request and make these two users friends, via the FriendService we discussed earlier. However, before making friends, we need to validate if the friend request is really meant for the account that has been logged into. If not we display appropriate error message and don't allow the user to log in. Once the registration is complete, we not only register them but we also create the friendship.

For this we will add to our Friends section landing page Default. This will be actually quite easy as we will use our ProfileDisplay user control that we created earlier for our Search page. This page will simply consist of a repeater with our ProfileDisplay control. We set the ShowFriendRequestButton to false as these are already our friends. We have not done it yet, but down the road we are most likely to have some form of pagination implemented here too!

To do this we will open the Profile. AccountID ;. We will need to open the master page and add a small section to take in and display a top listing of these updates. In our master page we will add a panel to our global display. It will be responsible for taking in new updates as well as displaying the most recent updates.

Instead of directly binding the entity object to the UI, we create this new value object explained in Chapter 2 which essentially is a sub-set of the StatusUpdate entity object and has only the relevant fields as required by the UI. It can be called as presentation entity. To create this, we also added a new helper class Translator that manages the conversion. The code for these two classes is as below: Add new PEStatusUpdate item.

CreateDate, item. Now; su. AccountID; su. This then takes us to displaying our top StatusUpdates in the master page. To do this we need to add the method that gets the top N StatusUpdates. AccountID, 5 ; repStatus. We will do this with a page dedicated to showing this data. As this is similar to Alerts, we add this to the Profile pages.

But it basically boils down to calling into the StatusUpdateService and gets all the StatusUpdates for a given Account. The only difference between this and showing the TopN StatusUpdates, as we did on the master page, is that we will show all the updates here. This is another page that will eventually benefit from having pagination implemented.

Summary This chapter was certainly less about building the framework and more about reworking some existing items so that they could be more friends-oriented. We have provided various methods to locate and invite friends to join us. We also extended some systems so that our friends could stay in touch with us and what we are doing on the site in the form of alerts and status updates.

We now have a site that allows us to connect with and interact with others. This is the first among many chapters that has really helped us put the community feeling into our community. The primary way for people to interact with one another is through direct communication.

We will build a system to perform this communication in a way that is similar to sending an email from a standard email client such as Outlook or Hotmail. Once a user can create and send messages, we will then create a way for other users to receive and read those messages.

The emails will queue up in their inbox, and from there they will be able to read their messages. Once we have this messaging subsystem in place we can hook up our other features in a way that they too can send messages—such as when a user accepts a friend request we can show the acceptance of that request in the friend's Inbox.

Messaging Problem A basic messaging system should be able to manage messages, senders and recipients, folders that contain the messages, and email notifications.

In our case, we are going to try and keep things simple where it makes sense to do so, but in one area, we will do things in a more complicated way simply because it will result in less wear and tear on the overall system. This is how the messages will be delivered to the users. Rather than following a standard email messaging system where each person gets a physical copy of a message, we are going to build our system in the same way that the MS Exchange server works.

We are going to make one copy of a message and subscribe users to that message. So rather than have 50 messages for 50 recipients, we will have one message and 50 recipient subscriptions. This editor can be downloaded for free here at http: You may have seen this editor already as it is widely used across many popular community sites.

Design Let's take a look at the design of these features. Messages Messages are the core of any messaging system. Generally, a message would contain details like the sender of the message, receiver of the message, and other metadata like time sent, server from where it was sent, etc. In our case, the message will contain the sender, subject, body, and the data sent.

It will also contain one additional field, i. We will need to create a page that allows a user to compose a new message as seen in the image at the start of this chapter. In this case, the recipient subscription is what will be contained in a folder and will have a read status. With this design, we will remove some of the burden from the database.

The overhead of doing this of course means that we now need to manage our data closely, as it is kept in many pieces. A more simple design that would result in more copies of data to be managed would be to create one message for each recipient.

This is easier as each message can easily be deleted and moved around without having to worry about the copies of that message of the other recipients. Having said that, if the message is quite large, and more importantly if we were to allow file attachments, all the copies of the messages would be identical for each recipient. This would quickly bloat your database! Solution Now let's take a look at our solution.

Implementing the database First let's take a look at what tables are needed: In addition to that we will need to know what type of message we are sending so that we can do some more fancy things in the UI down the road. There aren't really any major complexities to note here other than the fact that the Body is made up of a varchar MAX data type.

If you feel this is too large for your system, feel free to make it anything you are comfortable with. The value you eventually use will drive the message for your system. MessageTypes Message Types allows us to assign a type to our messages.

This is purely a lookup table that will allow us to know what the types are during queries. We will keep a list of enums in the code to make the lookups easier from that end.

MessageRecipients A message recipient is simply the receiving party to the message. But as we try to minimize the data that we manage in our system, the message recipient is also a very important part of the message.

In our case, it is the receiving party as well as all the things that the receiving party does with their subscription of that message. We will use this subscription to denote which folder the receiver is keeping the message in, and whether the receiver has read the message or not.

The SQL for this subscription is actually quite straightforward. It tracks a relationship to the message, a relationship to the receiver, which folder the subscription is currently in, and the status of the message for this receiver.

Initially, our interface will only have a TO field. We should add this bit of metadata though just in case we want to expand our capabilities down the road! This is another example of a lookup table that we might need to use in the SQL queries.

In our case, we will have an enum defined that maintains this lookup for us on the code side. This is primarily so that we can change the UI to reflect its status to the recipient. However, we could also create a dashboard down the road for the senders of the messages to know whether their message was read or not and by whom think of all the big brother things one could do MessageFolders MessageFolders in our first round of implementation will simply hold copies of new messages in the Inbox and copies of sent messages in the Sent folder.

We will also have a trash folder and a spam folder.Download this Video course in MP4 format DRM FREE - read and interact with your content when you want, where you want, and how you want Immediately access your video course for viewing or download through your Packt account.

But it basically boils down to calling into the StatusUpdateService and gets all the StatusUpdates for a given Account. This column had Separately been on 10 May , at The returned list of Accounts is then displayed on the page. Web Design.

SAMUAL from Texas
Look over my other posts. One of my extra-curricular activities is renaissance faire. I do like ultimately.