There’s no need to have the user be forced to keep our app in the foreground while the download is in progress, we naturally want to support background downloads.
For the NSScreencast iOS app I wanted to support downloading videos for offline use. With each video being between 80-200 MB in size, this requires some attention to create a download system that is resilient to failure.
Downloading files on iOS is fairly straight forward. You configure a
URLSession with a
URLSessionConfiguration, create a
URLSessionDownloadTask with the URL that you want to download, and then call
.resume() on it.
Later on, during the transfer, if you want to pause this request (or cancel it), you call
cancel(byProducingResumeData:) and pass a block to it. This block yields to you what is called “resume data”. The docs describe it like this:
A data object that provides the data necessary to resume a download.
I’m working on a client project that has a pretty large legacy codebase. For some new features I’m working inside of an existing architecture, so I’m using a when-in-rome strategy for implementing new features. In other words, how I implement something may be different than if this were a greenfield project.
For instance, the existing application is written in Objective-C. While I would likely write the application in Swift if I were starting over, it makes total sense to continue the application in Objective-C for the short term.
One of my clients is submitting an app to the store under a different Apple Developer account than it was developed with.
This left us with about 50 devices in the old portal that they were using for development & beta testing. I needed to quickly get these over to the new portal.
If you’ve tried playing any games with the Siri Remote, you’ve probably noticed how awkward the situation is. There are some games that lend themselves to such an input device (such as Canabalt or Alto’s Adventure) but most games just don’t work well with the remote.
But other games are really awkward. Almost Impossible, for instance, is actually impossible to play with the remote. It’s clearly not a gamepad.
So I bought one.
The primary input mechanism for Apple TV text entry is a single thumb on a tiny trackpad. Needless to say, entering text is a nuissance. Entering complex passwords is downright painful.
So painful, in fact, that I’d expect most people to just drop out and never come back if you present them with a log in screen.
I’m proud to announce that NSScreencast is now available on your Apple TV!
You can browse all the screencasts straight from your couch, using adaptive quality streaming up to 1080p HD.
I’m excited for tvOS. I’m excited both as a consumer and as a developer, particularly because NSScreencast is a great candidate for a tv app.
I knew I was going to build an app, but there were some choices to make. Should I use the new TVML support for utilizing pre-built templates that you fill with content via XML? Or should I go completely native, utilizing most of what I know with UIKit to build the app?
What is your super power?
Where is your compass pointing?
This got me thinking about my own business. It is truly a difficult question for me to answer.