You can run OpenWhisk in a development environment of your own, or try it out by signing onto IBM Bluemix Note what we’ve done here – we’ve just converted the function signature expected by OpenWhisk into a class where we replace “main” with “run”. You’ll find the Swift runtime setup on GitHub in the “core” directory with the other runtimes. If you’d like more details, feel free to look at the setup yourself, as the entire OpenWhisk platform is open source and released under the Apache 2.0 license. The Swift package includes some useful libraries you can use in your code-including SwiftyJSON, the Watson Developer Services for Swift, and the Kitura-Net framework for networking. At runtime, your code gets loaded into the container, compiled as part of a Swift Package, and then executed as an OpenWhisk action. Swift-based actions execute in the OpenWhisk Swift runtime, which is a Linux container currently supporting Swift 3.0.1. An action takes JSON (in the form of nested dictionaries) as input parameters and outputs JSON (You can code your actions in a single language-Javascript, Java, Python, or Swift-or you can mix and match actions written in different languages. The programming model centers on the concept of “actions”. Let’s take a closer look at Swift on OpenWhisk. They can potentially do all of this using Xcode-yes, I said Xcode-while letting OpenWhisk take care of operational concerns like managing and scaling infrastructure. Using Swift to code in OpenWhisk, mobile app developers gain the powerful advantage of leveraging a growing eco-system of cloud services like Cloudant, push notifications, Slack, Git – the list goes on. With the Swift runtime, iOS developers can write backend code using the same language that they already know from creating user experiences with apps running on the mobile device. That’s where serverless computing IBM Bluemix OpenWhisk, now generally available with Swift runtime support, offers one of the most exciting combinations of technologies for end-to-end mobile application development. In iOS development, there has been no easy answer. In this “outside – in” building process, backend requirements are already implied in the user experience goals.īut who actually develops the backend for the app? The teams I’ve worked with took a very Mobile First approach, in which a good client-driven user experience is paramount. I’ve spent a fair amount of time building mobile enterprise applications for different industries using iOS and Swift. Not only do you have to get out of your seat, grab your luggage, find and board another train, you may need to meet up with others at the transfer station and perhaps even wait for them there. While you’ll still be using the same mode of transportation – like trains, coding environments provide familiar structure – the mere switching of context disrupts development. You’re comfortable plugging away at the code for your client app, and then you reach a point of transfer to developing the backend. Developing mobile applications that use cloud services is a bit like train-hopping-especially if you’re writing about that topic (as I am) on a long train trip.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |