Managing time and date values is always a fun trick, for some value of fun. First, UTC is your friend. Embrace it and hold it close. Use it whenever manipulating or comparing time date values. With few exceptions, translation to local time should be reserved for user display. Luckily, most modern operating systems have well developed standard ways of managing date times. Use them. Don’t roll your own without a very good reason. No, one better than that. Anyway, that’s the easy part

Now imagine an app with time and/or date based business rules. Your user should do something every 4 hours, or shouldn’t do something more often than once a day. You store the starting date time and then you compare it to the current date time. But what if your user hopped in a plane and flew across the country, or across the international date line. Were your business rules designed to take travel into account? If a user takes a daily action at 11:59pm, should they be allowed to repeat it at 12:01am? Sometimes the answer is yes, and sometimes the answer is no, but it needs to be solved at the requirements level, not the implementation level. Always look for the edge cases when dealing with date time related business rules and try to decide how (or if) to deal with them before you start implementation.

Now remember that when you’re relying on the system time on the device, that’s a value the user can change at will, even while in the middle of using your app. Is this something that needs to be taken into account in the design? Maybe it’s just let the user deal with any fallout. But if there’s anything security or access related triggered by time, then you need to be ready for users who get their devices to lie to you. (Hey, at least it means they’re using the app, right?) Often the solution to this is that the master time is calculated by your server which the device has to check into. Some users will play thee games maliciously. Some will do it out of curiosity. Just be aware that it can and will happen.

Then there’s the problem of testing apps implementing business rules that span days (or weeks or months). It’s seldom feasible (or reasonable) to read testing out over that span of time, so why not just roll the time forward or backward on the device? Time travel! Except that, unless it’s a dedicated test device, you might run into unwanted side effects. One possible way to get around some (but not all) of those potential side effects is to roll the time back into the past before you start your test, working your way toward the present.

But as soon as your app has to publish to a server, your test results are likely to be problematic. Again, depending on the design. It’s easy to change the time on a device. It’s not to simple to arrange getting the time changed on a server unless it’s an isolated and dedicated server. Even when it isn’t a problem to time shift on the device and publish to a server, we ran into a real life case where our testing time shift crossed the boundary of an SSL certificate renewal. Odd things can trip you up. Be on the look out.

One of my favorite techniques for dealing with business rules that cover large periods of time is to do test builds that substitute a shorter unit of time; seven days becomes seven minutes, or ten hours become ten minutes. A simple substitution of time units makes it easier to set up the test situation with a simple toggle in the code.  Please don’t depend on going in and manually updating every substitution every time you change in and out of test mode as you will eventually miss one.

Happy coding!

Recently I found myself in the office on a Saturday afternoon. It happens. (Deadlines don’t care, but you want your software to be good, yes. Just don’t do it too often. Especially don’t do it too often if you work for yourself.) We’re working in Xamarin, which I am still getting comfortable with, and to make it even more interesting, the bulk of the content of the app is being provided as React code that has to interact with the backend.

Anyway, one of the things I was getting grumpy about was a feature where you can preview a sound by selecting it from a picker. It had to work on both iOS and Android and the implementation used dependency injection. (Playing a sound is highly platform dependent so the code had to be implemented separately for both iOS and Android. The C# code in Xamarin then calls the appropriate method depending on the device. Very nifty.) It was working on Android devices and I wasn’t seeing any defect tickets on the issue, but it wasn’t working at all on my personal device. I had to track down the problem.

First I verified that the call from the javascript front end was making it into the back end.  Then I verified that the code was retrieving the proper full path to the sound file in the app sandbox.  All looked good. Run it in the simulator, there are no errors, and the sound plays. Run it in debug mode on the device, there are no errors, but no sound plays. Grr. I get a fresh cup of coffee and then do a quick search, suspicious that there might be something odd about the Xamarin code we’re using. And I find a post form someone back in 2015 who had the same issue. He had the mute button on his iPhone turned on.

The first time I got bit by this particular problem (because of course this wasn’t the first time, much to my chagrin), was back in 2011 when I was working on an educational app with video content. I don’t know if I felt more silly then or now. The truth is I’ve had this exact same issue about once every three years or so, just infrequently enough that I forget every time. Maybe next time I’ll remember how much I dislike noisy devices.

Whenever you’re working with audio content, don’t forget to check the mute button as well as the volume. In fact, if you’re working with audio content, I strongly suggest reading up on how your OS handles sound channels.

Which reminds me that I should take the time to read up on the specifics of how Android does it.

This is the time of year when I reliably gnash my teeth. I hate it when development tools autoupdate instead of asking for permission first. I’m looking at you, Xcode. Xamarin is even worse. Oh, Xamarin. At least I’ve had enough experience now to have some idea of what’s going wrong when you start throwing cryptic error messages out of the blue. New OS release? Oh yeah.

Yes, I know it’s good to get people to update to the new stuff. Yes, I know that if you give them a solid nudge, that many of them will never update, ever, and will expect you to support your older versions forever. But I hate how easy Apple makes it to accidentally turn on autoupdate for something, and there seems to be no way to turn it off.

Speaking of versions, if you want to do mobile development, get used to the idea that you are likely to need two to three versions of the IDE available at any given time. (Except Xamarin, dang it.) (Yes, you can run multiple versions of Xcode on one machine. Yes, it can get a little wonky sometimes.) This can end up taking up quite a bit of disk space.

For example, I currently have the following applications that I use for daily work: Xcode 9.2, Xcode 8.3.3, Xcode 7.3.1 (about to retire this one!), Android Studio 1.5 (about to retire this one!), Android Studio 2.3.1 (also about to retire), Android Studio 3.0.1 (need to get the latest), the full Microsoft Office Suite for Mac, Photoshop, SourceTree, Sketch, Sublime Text, Slack, Safari, Firefox, Chrome, Fabric, Navicat, Postman, Transmit, and Visual Studio. That’s not counting the extra text editors or a small collection of image optimization apps and random tools.

The moral of the story is that, when you get the chance to spec out a development machine, get all the disk space you can get your hands on.