Dojo Mobile TweetView Series Tutorials – Create a Setting View

Author: David Walsh

Translation: Siqi ([email protected])

Original: TweetView: Creating the Settings View

In the third tutorial of the Dojo mobile TweetView series-Tweets and Mentions view, we consolidated the file structure of the TweetView application, reviewed the goal of creating TweetView and wrote tweetview._ViewMixin And tweetview.TweetView created Tweets and Mentions views. This tutorial will focus on introducing the “Setting” view in TweetView: the dependencies of classes, how the Setting view is connected with the Tweet and Mention views, and writing the code for the Setting view.

Version: 1.6

Difficulty: Intermediate

Series: TweetView

Dependency of the “Settings” view

The Settings view is the simplest of the three views. This view contains two titles (main title and subtitle) and a list of Twitter accounts. Each Twitter account corresponds to a switch to control whether the account information needs to be displayed in the other two views. After looking at the following renderings, you can know that the following controls will be used:

• dojox.mobile.ScrollableView-entire view

  li>

• dojox.mobile.Heading-main title “Setting”
• dojox.mobile.RoundRectCategory-subtitle “Show”
• dojox.mobile.RoundRectList-account list container< /li>
• dojox.mobile.ListItem-account list element
• dojox.mobile.Switch-switch space

The rendering also clearly illustrates us We will need to get the user’s avatar information from Twitter, so we also need some other Dojo resources:

• dojo.io.script-Use JSONP to get information from Twitter
• dojo.DeferredList-allows us to process the data returned by multiple Twitter information requests at once

These resources will help us successfully complete the Settings view. Similar to how we created the Tweets and Mentions views, we will create a custom class for the Settings view: SettingsView.

! If we don’t display the user’s avatar information in the Settings view, we don’t need dojo.io.script and dojo.DeferredList. We can write down the path of these avatar pictures, but in this case we need to manually update the path of these pictures every time the user changes their avatar. Fortunately, the code of the TweetView view we created earlier already contains these resources, so using them in the Settings view will not cause code bloat-the classes provided by these resources are already available!

Develop Setting View

Our SettingsView class is very similar to TweetView class, they both inherit dojox.mobile.ScrollableView and tweetview.ViewMixin. The important point is that the SettingView class is just a container that wraps the tweetview.ACCOUNTS object used by the entire application to obtain account information. After understanding this, let’s take a look at the specific implementation of the Settings view.

New class: Settings view

Our new class is called SettingsView, and its basic structure is the same as TweetView:

< /p>

// Provide UI class dojo.provide(“tweetview.SettingsView”); // Import dependencies dojo.require(“dojox.mobile.ScrollableView”);dojo.require(“dojo.DeferredList”);dojo.require(“dojo.io.script”);dojo.require(“tweetview._ViewMixin”); // Declaration class; it inherits from ScrollableViewdojo.declare(“tweetview.SettingsView”, [dojox.mobile.ScrollableView, tweetview._ViewMixin], {// methods and properties will be added here});

The dependencies have been imported and our class has been declared.

! This class will be placed in the same folder as TweetView and _ViewMixin: js/tweetview

SettingsView properties

SettingsView will have three customizations Attributes. The first is accountTemplateString: a string containing HTML tags to represent the layout of each list element in the account list.

// template string accountTemplateString:’<img src=" /wp-content/uploads${avatar}" mce_src="/wp-content/uploads${avatar}" alt="${user}" class="tweetviewAvatar" />‘ +’</p> <div class="tweetviewContent" >‘+’</p> <div class="tweetviewUser">${user}</div> <p>‘ +’</p></div> <div class="tweetviewClear"></div> <p>‘,

< p>

The second attribute is views, which represents an instance of TweetView. Why does SettingsView need to know the ID of the TweetView instance? Because SettingsView needs to adjust the tweets in the corresponding TweetsView instance according to the switch status of each account. The views attribute accepts a string consisting of the IDs of multiple TweetView instances, each ID is separated by a comma.

// TweetView referenced by SettingsView views: “” ,

The last custom attribute is serviceUrl:

// The URL used to obtain user information, here is a simple URL template serviceUrl: “http://api.twitter.com/1/users/ show/${account}.json”,

The serviceURL attribute represents the Twitter service URL used to obtain user information. For SettingsView, we only need to get the user’s avatar.

Implement SettingsView

Now that the SettingsView framework is set up (although it can’t do much yet), it’s time to update the HTML part of the Settings view:

<!-- settings view--></p> <div id= "settings" dojoType="tweetview.SettingsView" views="tweets,mentions"> <h1 dojoType="dojox.mobile.Heading" fixed="top">Settings</h1> <h2 dojoType="dojox.mobile.RoundRectCategory ">Show</h2> <ul dojoType="dojox.mobile.RoundRectList" class="tweetviewList"></ul> </div> <p>

Here are the changes we made:

• The dojoType of this control has been changed to our new class: tweetview.SettingsView.
• Set the views attribute to “tweets, mentions”; that is, the ID of TweetView and MentionView.
• Added the tweetviewList CSS class to the RoundRectList node, so that the control can be distinguished and get its reference

Of course we need to be at the top of our app.html page Import the tweetview.SettingsView class

// Use lightweight parserdojo .require(“dojox.mobile.parser”);// Import Dojo mobile dojo.require(“dojox.mobile”);// Import additional, non-standard dojox.mobile controls dojo.require(“dojox.mobile.TabBar “);// Import compatibility package dojo.requireIf(!dojo.isWebKit,”dojox.mobile.compat”);// Import TweetViewUI dojo.require(“tweetview.TweetView”); dojo.require(“tweetview.SettingsView”) ;// Set the tweetview account information directly under the namespace tweetview.ACCOUNTS = {dojo: {enabled: true }, sitepen: {enabled: true }};

< p>After adding SettingsView to the app.html page, it’s time to create the JavaScript part.

SettingsView _startup()

The startup method of the SettingsView class is the key to the work of SettingsView. Let us look at it step by step. The first is to call the startup method of the parent class (dojox.mobile.ScrollableView) to get the original function:

// Get the startup function of dojox.mobile.ScrollableView this.inherited(arguments);

Get the list control in the view Quote and hide it before adding list elements.

// Get the list child control this.listNode = this.getListNode ();// Hide the list control, because it has not been filled yet this.showListNode(false);

Create an array of accounts and sort them, so They can be displayed in the view in alphabetical order

// Sort accounts var accounts = [];for(var account in tweetview.ACCOUNTS) {accounts.push(account);}accounts.sort();

Create an array of Deferreds returned by requesting Twitter user information:

// Create an array to hold deferred var defs = [];// Process each account dojo.forEach(accounts, function(account){ // Request user information defs.push(dojo.io.script.get ({ callbackParamName: “callback”, timeout: 3000, // “substitute” inherits from _ViewMixin url: this.substitute(this.serviceUrl, {account: account }) }));},this);

! You will see that the URL is generated based on the serviceUrl parameter and an object containing the account name. The substitue method inherits from _ViewMixin, and SettingsView also inherits from this class.

After the Twitter request is triggered, get a reference to the TweetView space:

// Get view widgets this.viewWidgets = dojo.map(this.views.split(“,”), function(id) {return dijit.byId(id); });

The remaining functions are implemented in the callback function of dojo.DeferredList after all user information is obtained. For each account we want to obtain information, if the account exists, there is no protection:

// Create a deferred list to add a callback function for formatting new dojo.DeferredList(defs).then(dojo.hitch(this, function(results) {// For each returned user array. .. dojo.forEach(results, function(def,i) {// If deferred fails, then the user account does not exist or is unavailable if(!def[0]) {// Remove the account to prevent more problems/ / At the same time delete the account from our local sorted account list delete tweetview.ACCOUNTS[accounts[i]]; delete accounts[i]; return;} // Get the user array var user = def[1]; // if The user exists and is not frozen or protected… if(user.id && !user[“protected”]) {// Protected is a reserved word // there will be more codes after that} },this);} ));

Create a new dojox.mobile.ListItem and fill it with our user information template:

// Create a new list element for the user, with a switch var item = new dojox.mobile.ListItem ({}).placeAt(this.listNode, “last”); // Use our template to update the content of the element list item.containerNode.innerHTML = this.s ubstitute(this.accountTemplateString, {user: user.screen_name, avatar: user.profile_image_url, user_id: user.id});

Create one for the list element dojox.mobileSwitch control, we need to consider the activation status of the account:

// Create a switch var userSwitch = new dojox.mobile.Switch({ “class”: “tweetviewSwitch”, value: tweetview.ACCOUNTS[user.screen_name].enabled? “On”: “off”}).placeAt(item. containerNode, “first”);

Add the onStateChange event to the Switch control, in which the enabled state of the tweetview.ACCOUNTS object will be updated. In addition, notify the activation status of the TweetView instance account:

// is Switch add change event dojo.connect(userSwitch, “onStateChanged”, this, function(newState) {// Get true/false value var isOn = newState == “on”; // Update ACCOUNTS table tweetview.ACCOUNTS[user.screen_name ].enabled = isOn; // Call the onUserChange method of each Pane control dojo.forEach(this.viewWidgets, function(viewWidget) {viewWidget.onUserChange(user.screen_name,isOn); });));

Finally, if we receive any valid accounts, display the Settings list node (because it already has content) and refresh each view.

// If we have any valid accounts…if( accounts.length) {// Display a list with content this.showListNode(true); // Start the refresh method of each view dojo.forEach(this.viewWidgets, function(view) {view.refresh(); }); }

The JavaScript code for tweetview.Setting is complete-this control now works correctly! But we haven’t finished all the JavaScript code yet! We also need to implement the onUserChange method for the TweetView class.

TweetView update: onUserChange and remove refresh() from startup()

The reason why we call the refresh method of each view in SettingsView, It’s because we don’t want to send requests to Twitter for accounts that are determined to be invalid. But unfortunately, we have called the refresh method in TweetView’s startup before. Now let’s remove it:

// Get tweets// this.refresh();

The SettingsView instance will call the refresh method of the view when it confirms that an account is valid.

The onUserChange method is called by SettingsView when an account is enabled or disabled. We have several ways to handle enabling/disabling:

Refreshing the entire control-will waste resources and Twitter API usage

Destroy ListItem controls and rebuild them-too much overhead, What if the user immediately activates the account again? That will result in reacquiring all user tweets. Doing this will also destroy our cache function.

Use CSS to show/hide list elements-that’s it! The overhead is very small, we have already obtained the data we need, and there is no need to get them repeatedly!

Implement this method in TweetView:

// Update the display attributes of a tweet according to the user’s account enabling attributes onUserChange: function(account,isOn) {dojo.forEach(this.getElements(“user-” + account,this.domNode) ), function(node){ dojo[(isOn? “remove”: “add”) + “Class”](node, “tweetviewHidden”); });}

p>

Remember that the user-{screenName} CSS class has been assigned to the list element in tweetview.TweetView? We will use this CSS class to find users who need to be enabled/disabled, and remove/add a new CSS class named tweetviewHidden for them to set a list element to display:none or display:block.

Set the SettingsView style

The HTML and JavaScript parts have been completed, now add some CSS classes to our style sheet To make the list look the same as in the rendering:

/ * The switch is on the right*/.tweetviewSwitch {right:10px; top:10px; float:right;} /* Hide the corresponding tweet for disabled users */.tweetviewHidden {display:none;}

TweetView is done!

tweetview.TweetView has been completed in the previous tutorial, this tutorial has completed tweetview.SettingsView, our control is done! Click here to view our controls.

In the last tutorial of this series, we will use Dojo’s packaging system to compress the JavaScript, HTML and CSS used by TweetView, making the entire program more compact.

Download code

Download TweetView

TweetView series Chinese tutorial

One of the Dojo mobile TweetView series of tutorials-Getting started with dojox.mobile

The second of Dojo mobile TweetView series of tutorials-TweetView start

The third of Dojo mobile TweetView series of tutorials-Tweets and Mentions View

Dojo mobile TweetView series of tutorial 4-Create Setting view