Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Could you technically use Swift as a programming language for building a website / web app?
Update: Looks like a lot of people are working on this.
https://github.com/PerfectlySoft/Perfect
https://github.com/glock45/swifter
https://github.com/grzegorzleszek/HTTPSwiftServer
https://github.com/izqui/Taylor
https://github.com/crossroadlabs/express
https://github.com/IBM-Swift/Kitura
https://github.com/vapor/vapor
Official support from Apple: https://swift.org/server-apis/
In theory, of course.
Any program that can output plain text can also be used for CGI(Common Gateway Interface) which includes Swift as well.
Therefore, yes, you can use Swift for web programming. However, currently, there are no additional libraries(like there are in PHP or EJB/JSP) to make this process easy for you. Take a look at some popular web frameworks for Swift such as Vapor.
Not sure how active this topic is anymore, but in case anyone finds this in the future, I'd like to announce here that I have started working on a framework for writing FastCGI applications in Swift.
Of course you can use any Objective-C web framework (though there are rather few), and you can certainly use Swift as a scripting language to dump out HTML strings to be regurgitated by CGI. However, (I'm going to get all philosophical here) I think that settling for such an approach is not very "Swift-like" if I dare use the term. The Swift designers went through a lot of trouble to make sure that it's more than "just" Obj-C without the (constraints of) C (in fact, I almost wish they hadn't said that since it's so often misquoted). Swift is also much closer to the functional family than Obj-C (while still retaining solid object orientation AND managing to add Python-esque scriptability). This opens up a whole new world of design choices that I think need to be explored. Also, type safety... but I digress...
All this to say, I've taken it upon myself to create a modular "microframework" that will let you write web apps in Swift at a very high level. At the time of this writing, I'd classify it as a functional proof of concept, but it's still not as abstract as I'd like and is missing a number of key features that would be necessary for real-world use. Contributions are of course welcome. Hope somebody finds this helpful. https://github.com/ianthetechie/SwiftCGI
Swift works just perfect as a web programming language. You can do python like scripting (for rapid development or simple tasks) and later compile the same code with XCode (for speed):
Copy the following script to /Library/WebServer/CGI-Executables/TestCGI on your Mac (OSX Mavericks or Yosemite with Xcode 6.x installed). Make it executable with chmod +x TestCGI. With httpd started call http://localhost/cgi-bin/TestCGI. You will get the call parameters echoed...
#!/usr/bin/env xcrun swift
import Foundation
print("Content-Type: text/html")
print("Content:")
print("")
print("1. Process.argument(s):<br />")
for s in Process.arguments {
print(s + "<br />")
}
print("<br />")
let env: Dictionary = NSProcessInfo().environment
if let requestMethod = env["REQUEST_METHOD"] {
print("2. Request method is: \(requestMethod)<br /><br />")
}
print("3. Number of environment variables: \(env.count)<br /><br />")
print("4. List environment:<br />")
for key in env.keys {
print("\(key) == \(env[key]!)<br />")
}
Apple has now (12/03/15) open sourced the Foundation library (https://github.com/apple/swift-corelibs-foundation) to allow compilation on Linux Servers.
Yes, you can.
Swift does the same as ObjectiveC, but does it easier. Therefore, you could use a very simple CGI-Interface (see http://www.sveinbjorn.org/objectivecgi) to analyse and answer client requests (both GET and POST) on the server side.
Since Swift is strong in string manipulation, it will be somewhere between ObjectiveC and PHP/Perl in terms of abstraction. For many purposes, a SQLite or MySQL frontend isn't even needed. Just drop your data into some text file on the server.
Yes, you can create web apps in Swift. Tailor is one of the web frameworks which allows you to do that. Its source code is on Github.
As per the other answers, you can use Apple Swift in any number of ways as part of a web site/app implementation.
Additionally however, other companies are also developing Swift language compilers which extend the capabilities even further. For example, RemObjects recently announced that in the next major release of their Elements compiler, they would be introducing a new compiler front-end dubbed "Silver", which is a Swift compiler.
As a front end onto their existing compiler technology which already supports ObjectPascal (Oxygene) and C# (Hydrogene), this means that you will be able to develop .NET and Java applications (including Android) using the Swift language. With .NET support, that obviously means you could use Swift to create an ASP.NET web site/app.
Note that this is a native compiler for each platform - there is no source code translation/cross compilation or platform abstraction or compatibility framework involved, as there is with (for example) Xamarin. The RemObjects compiler produces platform specific, native code (i.e. MSIL for .NET, Java Bytecode for JVM etc etc). It also allows the developer to consume platform libraries natively. i.e. when developing for Cocoa, Cocoa classes are exposed directly into the language, ditto Java classes when developing for Java, .NET framework for .NET etc.
This is the case whether you are using the ObjectPascal, C# or Swift language front-ends (and you can mix and match languages in a project, if you so desire).
The 8.0 release has been in beta for a while already so existing Elements licensee's have been playing with it already. :)
In the article Cocoa with Love, you could find an example of HTTP server. It is written in Obj-C:
http://www.cocoawithlove.com/2009/07/simple-extensible-http-server-in-cocoa.html
Here is my attempt to create a swift version:
https://github.com/grzegorzleszek/HTTPSwiftServer
Browsing the web, I've found really nice swift version of HTTP server. It is worth to have a look:
https://github.com/glock45/swifter
Related
I was wondering whether it is good to use swift programming language to create a framework for iOS application. I doubted how do we expose public interfaces in framework If I use swift. Usually ObjC framework has .h files in header folder inside the framework but swift can't.
See below post from apple https://developer.apple.com/swift/blog/?id=2
Appreciate any response on this post.
There are a few limitations regarding distributing Swift libraries, bundles, frameworks, etc...
You will need to document your API as relying on a header files only for developers to peruse won't cut it.
Mixing Swift and Objective-C is easy because of bridge technology but the technology doesn't extend to incompatible types across the bridge (struct is one of them.)
You need to package your Swift libraries in dynamic libraries. There is no way around static libraries in Swift.
Most of the early issues with naming have been ironed out, but there are still some gaps in what's available in foundation.
The C invocation is getting better with and even Swift2 deals with C function pointers in a less obscure way but Swift 2 is not out yet.
Some esoteric things you are used to with Objective-C are harder to implement with Swift. If you are going to lose the safety mode of Swift to be able to bit cast your objects, that defeats the purpose.
For most of these reasons, although I love the new language syntax, I chose to continue development of frameworks used in my app with the proven Objective-C and decided to move all the UI stuff in the application side to Swift. When Swift 2 is released, I will then reconsider this choice.
I have integrated Lua with my ObjC code (iphone game). The setup was pretty easy, but now, I have a little problem with the bridging. I have googled for results, etc... and it seems there isn't anything that could work without modifications. I mean, I have checked luaobjc bridge (it seems pretty old and dicontinued), I heard about LuaCocoa but it seems not to work on iphone, and wax is too thick.
My needs are pretty spare, I just need to be able to call objc methods from lua and don't mind having to do extra work to make it work (I don't need a totally authomatic bridging system).
So, I have decided to build a little bridge myself based on this page http://anti-alias.me/?p=36. It has key information about how to accomplish what I need, but the tutorial is not completed and I have some doubts about how to deal with method overloading when called from lua, etc...
Do anybody know if there exist any working bridge between objc and lua on the iphone or if it could be so hard to complete the bridge the above site offers?
Any information will be welcomed.
Don't reinvent the wheel!
First, you are correct that luaobjc and some other variants are outdated. A good overview can be found on the LuaCocoa page. LuaCocoa is fine but apparently doesn't support iPhone development, so the only other choice is Wax. Both LuaCocoa and Wax are runtime bridges, which means that you can (in theory) access every Objective-C class and method in Lua at the expense of runtime performance.
For games and from my experience the runtime performance overhead is so significant that it doesn't warrant the use of any runtime binding library. From a perspective of why one would use a scripting language, both libraries defy the purpose of favoring a scripting language over a lower-level language: they don't provide a DSL solution - which means you're still going to write what is essentially Objective-C code but with a slightly different syntax, no runtime debugging support, and no code editing support in Xcode. In other words: runtime Lua binding is a questionable solution at best, and has lots of cons going against it. Runtime Lua bindings are particularly unsuited for fast-paced action games aiming at a constantly high framerate.
What you want is a static binding. Static bindings at a minimum require you to declare what kind of methods will be available in Lua code. Some binding libraries scan your header files, others require you to provide a special declaration file similar to a header file. Most binding libraries can use both approaches. The benefit is optimal runtime performance, and being able to actually design what classes, methods and variables Lua scripts have access to.
There are but 3 candidates to bind Lua code to an iPhone app. To be fair, there are a lot more but most have one or more crucial flaws or are simply not stable or for special purposes only, or simply don't work for iPhone apps. The candidates are:
tolua and tolua++
luabind
SWIG
Big disadvantage shared by all Lua static binding libraries: none of them can bind directly to Objective-C code. All require to have an additional C or C++ layer available that ultimately interfaces with your Objective-C code. This has to do with how Objective-C works as a language and how small a role it has played (so far) when it comes to embedding Lua in Objective-C apps.
I recently evaluated all three binding libraries and came to enjoy SWIG. It is very well documented but has a bit of a learning curve. But I believe that learning curve is warranted because SWIG can be used to combine nearly any programming and scripting language, it can be advantageous to know how to use SWIG for future projects. Plus, once you understand their definition file implementation it turns out to be very easy (especially when compared to luabind) and considerably more flexible than tolua.
OK, bit late to the party but in case others come late also to this post here's another approach to add to the choices available: hand-code your LUA APIs.
I did a lecture on this topic where I live coded some basic LUA bindings in an hour. Its not hard. From the lecture I made a set of video tutorials that shows how to get started.
The approach of using a bindings generation tool like SWIG is a good one if you already have exactly the APIs that you need to call written in Objective-C and it makes sense to bring all those same API's over into LUA.
The pros of the hand-coding approach:
your project just compiles with one standard Xcode target
your project is all C & Obj-C
the LUA is just data shipped along with your images
no fiddling with "do I check in generated code" to Git
you create LUA functions for just the things you want
you can easily have hosted scripts that live inside an object
the API is under your control and is well known
dont expose engine APIs to level building team/tools
The last point is just that if you have detail functions that only make sense at the engine level and you don't want to see those when coding the game play you'll need to tell SWIG not to bind those.
Steffens answer is perfect and this approach is just another option, that may suit some folks better depending on the project.
I am in possession of a dictionary application (takes in text as input, outputs definitions + grammar analysis). I have all the source files (about 50 pages of code), written in Ada, as well as Windows and Unix executables. I want to be able to use this dictionary in an iOS app.
I'm not at all familiar with Ada, so my question is, in a nutshell—are there any shortcuts to somehow wrap the application and use it on iOS? Or is the only way just re-writing the entire application in C/Objective-C?
Shark8 mentioned JVM-targeted Ada. ACT sells a version of Gnat that targets the JVM. However, I do not believe iOS devices currently run Java. Apple does not want to lose control of the platform, so they do not allow any development environments other than their own, which is Objective C based. I understand the Java folks are working to fix this, but even if they do Apple will probably refuse to allow any such app into their online store. Note that this is not a problem unique to Ada. Any app written in any language other than C or Objective C has the same problem with iOS. (This is one of the many reasons why developers tend to prefer to target Android platforms than iOS).
So what you really need is something that can get your code compilable with Apple's Objective C compiler. Supposedly Objective C is a strict superset of C. If this is true for Apple's implementation, then an Ada compiler that outputs compilable C sources should do the job for you.
Fortunately, there is such an Ada compiler (or at least there used to be). AdaMagic at one point had C available as a "target". It is now sold by SofCheck. When last I saw a discussion of it years and years ago, they referred to it as a "service" as much as a compiler, so it may not be cheap. But if you have a real business need, it would certainly be cheaper than spending man-years rewriting a working app.
Your other option of course would be to say "Screw Apple and their facist OS", and shoot for Android instead. Sadly, for business reasons, that may not be feasible. :-(
Update (2016/2012): The assets of SofCheck have become available from AdaCore, as the two companies have merged in early 2012.
I want to be able to use this dictionary in an iOS app.
Well, if there is an Ada compiler that targets iOS -- and there probably is considering that GCC has an Ada front-end -- then re-using the packages should be straight-forward so long as the source isn't compiler- (for a different compiler) or architecture-specific.
The most experience I have with porting Ada to other architectures was to port some code I had compiling to the native machine to the JVM (there's an Ada compiler which targets the JVM); the "gotchas" were more along the line of the JVM's case-sensitivity interacting with Ada's case insensitivity for naming classes and packages.
This question already has answers here:
Closed 12 years ago.
Possible Duplicates:
What is a framework? What does it do? Why do we need a framework
What is the difference between a class library and a framework
Although I referred to various sources, I still can't understand the proper definition. What is meant by "application framework"?
Here's a simpler answer:
Application frameworks make writing applications easier.
Creating applications is hard. Applications have to provide input and output which they get through operating system semantics. Modern applications are usually GUI based and a GUI app is orders of magnitude more complex than a non-GUI app.
It's that simple. The framework takes all the complexities of interfacing with the operating system and simplifies them for you. It handles all the nitty-gritty details for you. Obviously certain frameworks do a better job at it than others.
There is one drawback to using an application framework that rarely seems to be discussed (presumably because we are all smiling about the amount of work we didn't have to do). In order to provide a simplified view of the operating environment, a framework has to box you into a certain 'style'. If your app is sufficiently different from the usual form of app, you are likely to end up frustrated in the framework as it will make doing what you want very difficult. This is partly because you now have to do all the things that the framework was hiding from you and partly because the framework is probably a closed system.
Frameworks are a special case of software libraries in that they are
reusable abstractions of code wrapped
in a well-defined Application
programming interface (API), yet they
contain some key distinguishing
features that separate them from
normal libraries.
An application framework consists of a framework used by software developers to implement the standard structure of an application for a specific development environment
Wikipedia answers, as you might expect, that an application framework is a framework for developing applications.
An application typically provides a user interface. "Application framework" can be used loosely to refer to user-interface frameworks that provide little more than a collection of low-level user-interface controls -- like MFC, Swing, Qt and the like.
However, it is useful to distinguish these from more powerful frameworks like the Eclipse Rich-Client Platform and the Netbeans Platform, which provide a higher-level framework -- built atop those low-level toolkits -- on which to develop applications.
I personally use "application platform" only for these latter platforms, and refer to the low-level APIs as "user-interface toolkits."
I'm moving away from strict Android development and wanting to create iPhone applications. My understanding is that I can code the backend of iOS applications in C/C++ and also that I can use the NDK to include C/C++ code in Android apps. My question however is how? I've googled quite a bit and I can't find any clear and concise answers.
When looking at sample code for the NDK, it seems that all the function names etc. are Android (or at least Java) specific and so I would not be able to use this C/C++ backend to develop an iPhone frontend?
I'd appreciate some clarification on this issue and if at all available some code to help me out? (even just a simple Hello World that reads a string from a C/C++ file and displays it in an iOS and Android app).
Thanks guys
Chris
Note that I almost exclusively work on "business/utility/productivity" applications; things that rely heavily on fairly standard UI elements and expect to integrate well with their platform. This answer reflects that. See Mitch Lindgren's comment to Shaggy Frog's answer for good comments for game developers, who have a completely different situation.
I believe #Shaggy Frog is incorrect here. If you have effective, tested code in C++, there is no reason not to share it between Android and iPhone, and I've worked on projects that do just that and it can be very successful. There are dangers that should be avoided, however.
Most critically, be careful of "lowest common denominator." Self-contained, algorithmic code, shares very well. Complex frameworks that manage threads, talk on the network, or otherwise interact with the OS are more challenging to do in a way that doesn't force you to break the paradigms of the platform and shoot for the LCD that works equally badly on all platforms. In particular, I recommend writing your networking code using the platform's frameworks. This often requires a "sandwich" approach where the top layer is platform-specific and the very bottom layer is platform-specific, and the middle is portable. This is a very good thing if designed carefully.
Thread management and timers should also be done using the platform's frameworks. In particular, Java uses threads heavily, while iOS typically relies on its runloop to avoid threads. When iOS does use threads, GCD is strongly preferred. Again, the solution here is to isolate the truly portable algorithms, and let platform-specific code manage how it gets called.
If you have a complex, existing framework that is heavily threaded and has a lot of network or UI code spread throughout it, then sharing it may be difficult, but my recommendation still would be to look for ways to refactor it rather than rewrite it.
As an iOS and Mac developer who works extensively with cross-platform code shared on Linux, Windows and Android, I can say that Android is by far the most annoying of the platforms to share with (Windows used to hold this distinction, but Android blew it away). Android has had the most cases where it is not wise to share code. But there are still many opportunities for code reuse and they should be pursued.
While the sentiment is sound (you are following the policy of Don't Repeat Yourself), it's only pragmatic if what you can share that code in an efficient manner. In this case, it's not really possible to have a "write once" approach to cross-platform development where the code for two platforms needs to be written in different languages (C/C++/Obj-C on iPhone, Java for Android).
You'll be better off writing two different codebases in this case (in two different languages). Word of advice: don't write your Java code like it's C++, or your C++ code like it's Java. I worked at a company a number of years ago who had a product they "ported" from Java to C++, and they didn't write the C++ code like it was C++, and it caused all sorts of problems, not to mention being hard to read.
Writing a shared code base is really practical in this situation. There is some overhead to setting up and keeping it organized, but the major benefits are these 1) reduce the amount of code by sharing common functionality 2) Sharing bug fixes to the common code base. I'm currently aware of two routes that I'm considering for a project - use the native c/c++ (gains in speed at the expense of losing garbage collection and setting targets per processor) or use monodroid/monotouch which provide c# bindings for each os's platform functionality (I'm uncertain of how mature this is.)
If I was writing a game using 3d I'd definitely use approach #1.
I posted this same answer to a similar question but I think it's relevant so...
I use BatteryTech for my platform-abstraction stuff and my project structure looks like this:
On my PC:
gamename - contains just the common code
gamename-android - holds mostly BatteryTech's android-specific code and Android config, builders point to gamename project for common code
gamename-win32 - Just for building out to Windows, uses code from gamename project
On my Mac:
gamename - contains just the common code
gamename-ios - The iPhone/iPad build, imports common code
gamename-osx - The OSX native build. imports common code.
And I use SVN to share between my PC and Mac. My only real problems are when I add classes to the common codebase in Windows and then update on the mac to pull them down from SVN. XCode doesn't have a way to automatically add them to the project without scripts, so I have to pull them in manually each time, which is a pain but isn't the end of the world.
All of this stuff comes with BatteryTech so it's easy to figure out once you get it.
Besides using C/C++ share so lib.
If to develop cross-platform apps like game, suggest use mono-based framework like Unity3D.
Else if to develop business apps which require native UI and want to share business logic code cross mobile platforms, I suggest use Lua embedded engine as client business logic center.
The client UI is still native and get best UI performance. i.e Java on Android and ObjectC on iOS etc.
The logic is shared with same Lua scripts for all platform.
So the Lua layer is similar as client services (compare to server side services).
-- Anderson Mao, 2013-03-28
Though I don't use these myself as most of the stuff I write won't port well, I would recommend using something like Appcelerator or Red Foundry to build basic applications that can then be created natively on either platform. In these cases, you're not writing objective-c or java, you use some kind of intermediary. Note that if you move outside the box they've confined you to, you'll need to write your own code closer to the metal.