Starting out

Wireframe of what your business wants

So, you’ve been looking to build a view that is mainly a table, yet has something, maybe some instructional text or even a little description of what the view is for, more to make that view easily understood by the user, but you don’t want to sacrifice the use of your table header either. Of course, this probably came as a result of some sort of downfall you had seen in a previous application that does similar things, so you’re sold on this being the “right” way to do it.

But how do you actually do this and ensure that the view scrolls not just the table, but everything in that view? This was something I struggled with for a few hours, Trying time and time again to manpulate a UIScrollView XIB with a UITableView nested inside. All that did was override the scroll features of the UIScrollView to the UITableView, making the only thing you can scroll the table; not the entire view as desired. Before you lose all of your hair as to why, it’s basically due to the UITableView being a subclass of UIScrollView.

How it’s done

OK, now that we’re past trying to get our way through force, let’s get try some finesse. Given that we’re really trying to add more information to a UITableView, so why don’t we try something along those lines. First, we need to create the classes and XIB that will be our view when we’re done. Do this as you normally would by choosing File -> New File or Command-N if you’re keyboard motivated. When the New File screen comes up, choose Cocoa Touch Class under the iPhone OS section, then UIViewController subclass. Make sure you check the two options available; UITableViewController subclass and With XIB for user interface. Choose Next, and create the .m and .h files.

Now you should have three files available to you: your .m, .h and .xib file so it’s time to make the XIB do what we want. Open the XIB file either by double-clicking it in XCode, or manually by opening Interface Builder, finding the file and opening the XIB file. To add in the necessary label which is the root of all this additional work, we simply need to do only two more things.

The two steps

The first thing to do is to add a UIView as a child of your Table View. Easy enough, just find the UIView in the Library within Interface Builder and drag it into your XIB view where you’re looking to drop it. Simple enough. The next step is just as simple. We need to add the label. Again, find the Label in the Library and drag it under your UIView that you just added.

I’m sure you’re thinking, “It can’t be that simple, can it?” Well, believe it or not, it is. When I figured this out, it was just a shot in the dark as I had first tried everything I could think of by using a UIScrollView and embedding a table inside of it.

There is still a little formatting you will need to do to ensure your view and it’s label have enough space at the top of your view. But, once you’re done though, you should have the view of your XIB looking like the image below. You can also add another view and using simple positioning, place it at the bottom of your view, creating the same effect after your table.

In close

There are drawbacks, of course. Yes, everything has to have some drawback, nothing is free. The one that you need to be aware of is that you cannot build your code for an iPhone OS under 3.0. If you’re still building apps for 2.2.1 or below, this would be a great opportunity to change that.

If you’re wondering what spurred me into finding a solution for the problem at the beginning of this article, it was for an application where the “My Profile” tab is able to be updated by the server, so we needed a short label informing users that they can download their profile, but changes are not reflected at the server and a button to start the (potential) login and download processes.

]]> http://walterg2.com/2009/12/09/getting-more-out-of-your-uitableviews/feed/ 1 http://walterg2.com/2009/12/07/adding-svn-revision-numbers-to-your-applications-version/ http://walterg2.com/2009/12/07/adding-svn-revision-numbers-to-your-applications-version/#comments Tue, 08 Dec 2009 04:45:47 +0000 walterg2 http://walterg2.com/?p=48 Recently, I’ve been given an oppotunity at my employer to participate in the next great version of our iPhone application. While it isn’t something fun and exciting, like ConvertBot or a game such as Eliminate Pro, it does allow me to get my hands dirty in Objective-C and iPhone development. With this experience has come a few things that I found difficult, at best, to spot an answer to within a single location. One of these things is something that, within a large corporation such as the one I work in, will help your support staff determine what version of your application a user currently has. Yes, there are items such as CFBundleVersion and CFBundleShortVersionString that accomplish this for you, but sometimes those may not be enough. Wouldn’t it be great if you could put the most recent commit revision number from your code repository? Good news, you can!

Setting up your info.plist file

Example info.plist file

First thing that you’ll need to do is set up the info.plist file in your project to carry the appropriate keys you’re going to need for your project. These are your CFBundleVersion and CFBundleShortVersionString, or, if you prefer to use the interface provided within XCode, ‘Bundle version’ and ‘Bundle version string, short’. These are used by Apple and iTunes to let the users know which version of the application you are using. From some simple tests I have done, they appear to check for the ‘Bundle version string, short’ key if it exists, and, if not, then fall back to the ‘Bundle version’. For our purposes, we know we do not want the build number shown within the App Store and iTunes, so we need to set up both of these variables.

Since the ‘Bundle version’ is going to change at build time to the latest commit revision, you can set this variable to anything you’d like. I prefer setting it to the same number as what will go in the ‘Bundle version string, short’ value. This ensures that, no matter what, an appropriate version number is given to the user.

Creating the Run Script

Target Build Steps

Now that the base is established, it’s time to move to getting the revision number added at build time. Why at build time do you ask? Basically, if this was added at any time other than during the build, it would put you into a loop where your application’s revision number is always one commit behind. If the update was done at any other time, you would run into the issue of changing info.plist to be the most recent commit statement, then having a sync to get this code into SVN, thus putting you a commit behind. Repeat ad nauseum until your eyes cross and you give up on the effort altogether.

This is where Apple has stepped in and given you an extremely powerful tool within the build process which allows you to create new Build Phases within your project. During the build of your project, you can execute code in multiple languages including, the Bash Shell, Ruby, Perl and Python, just to name a few. Now, your builds can add additional features such as this revision number by simply adding in a script in the right order in your build.

Example shot of the New Run Script Build Phase

To do this, you have a few ways to do this. Within XCode, you can choose Project, New Build Phase, New Run Build Script Phase or from the Target in Groups and Files, CTRL+click on your application, choose Add, New Build Phase, New Run Build Script Phase. This will open a window to allow you to write your script in.

Now, for the fun part. In the language of your choosing, write your code. For this post, I’m going to use a Bash Shell to add the code necessary for the addition of our SVN Revision number. What we’re going to do is accomplished in only three lines of code, which, as anyone can agree, is awesome! The down side is that the code isn’t the most readable unless you’re very familiar with SED scripting.

REVISION=`svnversion -nc | /usr/bin/sed -e 's/^[^:]*://;s/[A-Za-z]//'`
APPVERSION=`/usr/libexec/PlistBuddy -c "Print CFBundleShortVersionString" "${TARGET_BUILD_DIR}"/${INFOPLIST_PATH}`
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $APPVERSION ($REVISION)" "${TARGET_BUILD_DIR}"/${INFOPLIST_PATH}

Now, let’s explain what we’ve done. In the first line, we’re getting the SVN Revision number for the project. This is accomplished by using the svnversion program with two flags set, -n and -c. The -n flag removes the new-line character from the response (something we really don’t want anyway) and the -c flag asks for the most recent commit for the specific project you’re running under. We pipe that information into SED and run a quick regular expression on it. Why do we need a RegExp? Well, svnversion -c returns more information than we really need. It sends us back the initial version from when project was created followed by the last committed version. For instance, if you created the project and it was assigned version 500, three weeks later you’ve had quite a bit of code activity and your final check-in gives you revision number 847. When you run svnversion -c within your project folder, you will get back a result of 500:847. That’s great, but within you’re application you’re only looking for the last number. That’s where the SED command comes in.

The next line is something I’ve done in my project, but is, obviously not something that has to be done. Within that code is something important, it’s a call to an application that comes with XCode called PlistBuddy. PlistBuddy, in short, is a tool to read and update plist files which is exactly what we’re looking to do. The call is simply to store the value of CFBundleShortVersionString from our info.plist file to a local variable in the shell script. Since some developers (eh-hem, @chadpredovich) like to create their projects within a directory structure with spaces in it, the ${TARGET_BUILD_DIR} is wrapped in quotes to ensure the script doesn’t fail. Of course, TARGE_BUILD_DIR and INFOPLIST_PATH are variables within the build wrapper that is executing this script, so they’re available to us as well. Nice, huh?

The final line again uses PlistBuddy, but this time to set the CFBundleVersion to the values stored in our two variables, APPVERSION and REVISION.

Now that you have the script set up, simply place it in the correct order within the Build Phases. In our case, we want to do this immediately after the ‘Copy Bundle Resources’ step inside your Target as the image illustrates.

Time to add the pretty little bow

NSString *version = [@"Version " stringByAppendingString:[mainBundle objectForInfoDictionaryKey:@"CFBundleVersion"]];

Now that you have the revision number added into the info.plist file, it’s as simple as pulling that information back out where you want to show it in your application. A little Obj-C magic and your support staff can rest easy that they can easily reproduce the issue a user may be having within your application by ensuring they are building the code from the exact code base that went to Apple.

Update!!! (2010/01/12)

When we tried to submit our app to the Apple App Store for review, it was rejected due to an improperly formed CFBundleVersion. It turns out, and is consequently poorly documented, that the CFBundleVersion can only be in the following format NN.N.N Where N is a number from 0 to 9. As you can tell, this means that in an application versioning, the app’s major version is a number between 0 and 99, minor and revision between 0 and 9. I’m not sure whether the version numbers are strictly upheld, but I can say that the above post will not be accepted.

Well, back to the drawing board on this one!

Whether the developer work in the .NET, Java, C++, C# or another application development space, most resumes that have web development experience at least mention the use of JavaScript, HTML and even, in some situations, CSS. To an interviewer that isn’t necessarily a strong developer in the languages they are hiring for, this looks like a dream come true; finally, someone that can develop the application from all aspects of it. MVC at it’s finest! But there is commonly one thing that most people ignore or forget, especially with contractor firms and that is that resumes are bloated with information even if the user has only done something as simple as read and debug a piece of code that wasn’t working well.

Of course, this situation occurs all the time without anyone to being the wiser in most situations. Corporations do not generally have individuals with advanced knowledge in languages other than the main server language they are employing. In fact, code reviews for these pieces of code are usually done by a development lead with around the same knowledge of these front-end languages so items get missed. But what items do you ask?

Let’s take for example some code I recently reviewed. Within this code is a simple timer when a user is logged into their account that will notify them shortly before the session actually expires to remind the user that they are logged in. Sounds simple enough; a timer and a message to the user to remind them, but how could the implementation go wrong? Well, let’s start by looking at the code.

1
2
3
4
5
6
7

var interval;var timer;var lengthToWait;
 
function startTimer() {
  if (timer) {
   clearTimer(timer); 
  }
  timer = setTimer("someFunction();",lengthToWait*60*1000);}

Looks fine, but can you see the innate problem with this code? We have globally exposed variables that are generically named. The developer, while working on this specific code made sure that it worked specifically for the needs of this code itself, but what about all of the other code the site could possibly run during a user’s visit? What are the chances that another developer decided to use the same variables? If there are a lot of developers working on this code base, a pretty good chance. And finding the issue could be a daunting task given that the problem most likely would not be found until the regression testing suite that covers this piece of code and then, it’s doubtful that the tie would be made quickly, if at all, that the issue is with the variable naming in the global space.

So, what can one do to keep this from happening? Well, two items come to mind. The first, what a developer that knows enough of the JavaScript language to be dangerous would do, and the more appropriate way, which, ironically, would be the way the developer would fix the issue if they ran into it in their server language.

The first is not optimal, by far, but is the one most easily employed by our weekend JavaScript developer. It gets the job completed and everyone is happy until the next incident during another effort sometime in the future. The second approach takes a little more skill in the language, but it keeps the variables needed wrapped in an object that is only used within itself.

So, how do we get the best coding practices put in force? Hiring a group of User Interface developers would be the easiest solution. A team of developers that work daily in the languages used in this tier of the application space. Unfortunately, even though most companies need developers with these specific knowledge sets, it’s cheaper and faster to simply hire someone that knows enough to get the job done.

To close, I’ll leave you with this. You wouldn’t hire someone to build your house that has only tinkered with a hammer and nails, would you?

At the company I work for today, there are many such individuals that see the web from a certain perspective and don’t seem to understand what it means to use certain techniques or technologies within the web world. Even trying to explain sometimes gets the glassy eyed stare of an individual that either doesn’t comprehend or just doesn’t appear to care to listen to the other side of what it is they’re going to be doing to users. Sometimes it’s as simple as “what if the user can’t see this?” which always seems to get a response of “what do you mean they can’t see this? They click the link and it appears!”

Understanding your audience is key

Knowing that the battle of a usable website for all of your visitors is a balancing act on a ninjato. Very short and very tretcherous. Short, only because without the right knowledge, you’ll never convince the individuals that you need to. Tretcherous because once you start down the path of trying to explain that there are those people that cannot use advanced items like modal windows or other DHTML techniques that deliver that interactive experience that a general web audience expects with today’s sites. With today’s analytic software options on the market today (free and paid), you can tell a pretty accurate story on quite a few items from where your traffic comes from geographically to when those users visit to even how many of them have JavaScript disable and which version of Adobe’s Flash Player they have. But, currently, no screen reader software creator on the market today has made the move to let website owners know that a computer with their software on it has visited their site. Without this knowledge it becomes increasingly difficult to educate your clients on the needs to balance their site with the right kinds of interactive features and good old fashion page refreshes to get a user through their experience.

Then how do I get this information?

Well, until recently, there was little anyone could do to find out if the user visiting your site really needed an alternative experience to ensure they were able to get the full use of your site. When I started looking into what could be done to garner this information, I was only able to find one product which did this; the infamous FlashAid application. While this application did work, it was designed only for Internet Explorer and took approximately 2 seconds to return the information it was built to seek out. Not fast enough by today’s web standards, especially since most dynamic features are set as soon as the Document Object Model is ready for manipulation.

What were we to do? Well, improve upon the design, of course! The thought behind the FlashAid tool is still a great one today. More than 99% of users on the web today have the Adobe Flash Player, and thanks to sites like YouTube and Google Video users are quick to upgrade their player to the most recent one very quickly. This makes a Flash-based tool the perfect host for gathering information on accessibility tools.

OK, so, what’s the code already?!?

Well, the code is in two parts: a Flash component and JavaScript.

While probably all of this could be written directly in Flash, I chose to use a hybrid approach to allow users to more easily change how the component behaves. Yes, it’s two files to download, but with a little finese and proper planning, it won’t make much of a difference.

Enter the JavaScript

Inside the JavaScript package are two functions, first the Assistive Technology check code. This code is the meat behind the technology checker and does two main things. First, it adds, using SWFObject, the Flash application (shown later), stores a cookie on the user’s machine for use in other JavaScript applications and finally gives the ability to post the results of that Flash file to analytic software.

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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131

/*globals SWFObject deconcept dcsMultiTrack escape */
 
/* Assistive Technology Checker
 * Version: 1.0
 * 2009/04/29
 * Author: George Walters II (walterg2_NOSPAM_@gmail.com)
 * Remove _NOSPAM_ to send me any comments/suggestions on improvements
 */
 
/* To launch:  as soon as possible, simply add in assistiveTech.init(debug); where debug is either true or false. 
 * This will allow for the flash to run in as little time as possible and mitigate as much of the delay in this
 * code running as possible.
 * Requires: SWFObject
 */
 
var assistiveTech = {
  assistiveTechLocale: "./flash/assistiveTech.swf",
  replacementDiv: "assistiveTech",
  requireVersion: "9",
  debug: false,
  debugFlag: "",
  techAssist: false,
  cookieName: "assistiveTech",
  init: function(debugFlag){
    assistiveTech.debug = (debugFlag) ? assistiveTech.debugCheck(debugFlag) : assistiveTech.debug;
	var cookieCheck = assistiveTech.cookieExists();
    if (!cookieCheck) {
      var so = new SWFObject(assistiveTech.assistiveTechLocale, "assistiveTechSwf", 1, 1, assistiveTech.requireVersion);
      so.addParam("quality", "low");
      so.addParam("allowScriptAccess", "all");
 
      // Pass the success handler's name to the Flash application. Flash
      // will call this handler using ExternalInterface.
      so.addVariable("callback", "assistiveTech.flashSuccess");
 
      // Try and write out the SWFObject
      var success = so.write(assistiveTech.replacementDiv);
 
      // If there's a problem in writing the tag, try to give the user more
      // information (they've probably got the wrong version of the player)
      if ( success )
      {
          // Successfully embedded. Now give the Flash movie focus
          // or else it will be ignored by the screen reader and not
          // get an update on isActive.
          document.getElementById("assistiveTechSwf").focus();
          if ( assistiveTech.debug ) {
            // Need to figure out what we want to do if debug is turned on and the flash piece succeeds
          }
      }
 
      else {
        // Embedding the Flash application failed. 
        // Display the version message in the assistiveTech div only
        // if we've been asked to do so.
        if ( assistiveTech.debug ) {
          var version = deconcept.SWFObjectUtil.getPlayerVersion();
          if (document.getElementById && (version.major > 0)) 
          {
            document.getElementById(assistiveTech.replacementDiv).innerHTML = "<p>This sample requires Flash Player version " +
                                                                         assistiveTech.requireVersion +
                                                                         ". You have Flash player " +
                                                                         version.major + "." + version.minor + "." + version.rev +
                                                                         " installed. <a href='http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash'>" +
                                                                         " Download the latest Flash Player</a> to run the sample.</p>";
          }
        }
        // Call the failure callback
        this [ assistiveTech.flashFailed ]();
      }
    }
  },
  setCookie: function() {
    var nextMonth = new Date();
    nextMonth.setSeconds(0);
    nextMonth.setMinutes(0);
    nextMonth.setHours(0);
    nextMonth.setMonth(nextMonth.getMonth() + 1);
    nextMonth.setDate(1);
    var expires_date = new Date( nextMonth );
    document.cookie = assistiveTech.cookieName + "=" + escape( assistiveTech.techAssist ) +
                      "; expires=" + expires_date.toGMTString() + 
                      "; path=/";
  },
  getCookie: function() {
    var cookies = document.cookie.split(';');
    for ( var i = 0; i < cookies.length; i++ ) {
      var cookieData = cookies[i].split('=');
      var cookieName = cookieData[0].replace(/^\s+|\s+$/g, '');
      if (cookieName === assistiveTech.cookieName) {	
        return cookieData;
      }
    }
    return false;
  },
  returnCookieValue: function() {
  	var cookieInformation = assistiveTech.getCookie();
	return cookieInformation[1];
  },
  cookieExists: function(){
  	var cookieInformation = assistiveTech.getCookie();
	if (assistiveTech.debug) {
		return false;
	}
	else if (cookieInformation && cookieInformation.length > 1) {
		return true;
	}
	return null;
  },
  debugCheck: function(debugFlag){
  	assistiveTech.debugFlag = debugFlag;
  	if (debugFlag === "on" || debugFlag === "off") {
		return true;
	}
	else {
		return false;
	}
  },
  flashSuccess: function(accessibilityFlag) {
    assistiveTech.techAssist = (assistiveTech.debug && assistiveTech.debugFlag === "on") ? true : ((assistiveTech.debug && assistiveTech.debugFlag ==="off") ? false : accessibilityFlag);
    assistiveTech.setCookie();
    var ATEnabled = assistiveTech.techAssist ? 'Yes' : 'No';
    // Add in your favorite Analytics software call here
  },
  flashFailed: function() {
    // Do something if the user doesn't have Flash 9 or higher installed
    if (assistiveTech.debug === "on") {
		alert('something went wrong');
	}
  }
};

The other piece is a Query String parser. Chances are you already have something to do this or have built one yourself very similar to this one. But, to make the code complete and allow for a debug mode, I’ve included the one below as part of the script. Does the normal items you’d expect from a Query String parser, evaluates the query string and allows you to get the value of a parameter passed on the query string. Very simple.

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

var ParseQueryString = {
  params:{},
  init: function(qs) {
    if (!qs) { qs = location.search.substring(1, location.search.length); }
    if (qs.length === 0) { return; }
    // Turn <plus> back to <space>
    // See: http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.4.1
    qs = qs.replace(/\+/g, ' ');
    // parse out name/value pairs separated via &
    var args = qs.split('&');
    // split out each name=value pair
    for (var i = 0; i < args.length; i++) {
      var pair = args[i].split('=');
      var name = decodeURIComponent(pair[0]);
      var value = (pair.length === 2) ? decodeURIComponent(pair[1]) : name;
      this.params[name] = value;
    }
  },
  get: function(key, defaultText) {
	var value = ParseQueryString.params[key];
	return (value !== null) ? value : defaultText;
  },
  contains: function(key) {
	var value = ParseQueryString.params[key];
	return (value !== null);
 }
};

Don’t forget our friend Flash!

And now for the Flash application. With the help of Michael Krotscheck (@krotscheck on Twitter), an ActionScript file was born. With only 19 lines of ActionScript, we have an application that checks for Accessibility and returns the information to a JavaScript callback function determined from a variable you pass into the Flash application. Since this is an ActionScript package, you can put this directly into a SWF file by use of the Flex SDK.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

package {
  import flash.accessibility.Accessibility;
  import flash.display.LoaderInfo;
  import flash.display.Sprite;
  import flash.external.ExternalInterface;
 
  public class assistiveTech extends Sprite
  {
    public function assistiveTech()
    {
      var info : LoaderInfo = this.root.loaderInfo;
      var method : String = info.parameters.callback;
      if ( method && ExternalInterface.available )
      {
        ExternalInterface.call( method, Accessibility.active );
      }
    }
  }
}

Next Steps

Of course, I’m not finished just yet. With the code I have above, you can see that it’s JavaScript library independent. That is on purpose and I have plans to lock this down a bit more by encasing it into private and public functions, adding options and the like to make this a complete packaged piece of software. More on that to come though. For now, it’s time for bed.

Modals aren’t easily accessible!

That’s right. If you’ve worked with modals on a web page, only the most recent versions of screen readers which have begun to implement solutions that listen for Dynamic HTML manipulations such as modal windows. That, however, only takes you as a developer so far. What about the rest of the users that need assistive technologies and can’t afford to upgrade to the latest and greatest all the time? I mean, at around $900 for the software, who can really afford to stay up to date?

But what can we do about it?

It’s difficult to even tell if you have a user base using assistive technologies most, if not all, screen readers today to not alert you, as a site owner, that a visitor has assistive technologies. Luckily, there have been some individuals who have begun looking into ways to finding ways to tell this information so you can react. One of those solutions is FlashAid.  Sure, it’s been in the 1.0 release for just under 2 years, the JavaScript code on their site only works in Internet Explorer (insert your IE6 complaint here; I’ll save that for a later post) and currently only checks whether an accessibility aid is communicating with Flash, but it’s a start!

Actually, it’s a pretty fine attempt at what we’re really looking for. With a small Flash application (238 bytes) and a little JavaScript, you can effectively test your visitors to see if they’re using accessibility aids on your site. But what do you really do with this information? Well, some options I’m currently trying are to store the response from the Flash file to a cookie (set by JavaScript) and then use that cookie in any and all code that creates modals, dynamically changes and displays HTML  and to pass that information to our analytics software so we can help better our site for all of our users.

Downsides to the current implementation

It’s currently only implemented in Flash 8/ActionScript 2.0 and takes a few seconds before it can tell whether or not accessibility is in use or not on the site. This could result in the user invoking an action that opens one of these inaccessible features. The chance is pretty slim, but of course, it could happen. Placing the JavaScript code which runs this check as close to the top of the body of you HTML pages will help make that time seem less, but a balance would need to be struck since running JavaScript at the top of a page is generally not a good idea.

So, what’s next?

I’ve written some JavaScript which will add the code (with the help of SWFObject) and set a cookie that gives the result from the Flash file which expires at the beginning of the next month. It works well and even has a “debug” mode so you can simulate a PC with an accessibility aid. But it’s only the beginning. Once this piece is added to the site, we’ll be able to tell how many users have an accessibility aid installed and active, but the less accessible code within your application will need to be updated to read that cookie and react accordingly.

I plan on sharing the code once I’ve more fully tested it to ensure it works across browsers and operating systems, so come back soon!