Would it be possible to extend this to allow the creation of hybrid apps, where parts of the code a written in Swift, but other parts are using the standard Meteor Cordova integration? This would require a transparent hand-over of user credentials from one side to the other.
I’m asking this because I am already developing a hybrid app using Swift and Cordova, but I still have no idea how to handle the hand-over of the user credentials properly and seemlessly, so I have postponed this
I’m not sure I’m clear on your question. You can incorporate try/catch all you want in your Swift client code.
The SwiftDDP Meteor method call api takes a callback with result and error arguments. If the asynchronous method call fails due to an error, you’ll know via the error object, and you can handle the error. It does not throw an exception in the event that the server returns an error.
I really don’t know enough about Cordova’s internals to answer your question, but if you’re using Cordova with Meteor, I’m not sure why you need a DDP/Meteor client written in Swift. You’re already using Meteor’s full-stack database aren’t you?
Thanks for your answer. I do this hybrid approach, because I need to go beyond Cordova’s capabilities. Hence, some parts of my app are native swift, whereas other parts are implemented in Meteor/Cordova. I do this by adding my own WebView and linking it to Cordova’s view controller. Another reason for going hybrid was that Meteor’s startup times were inacceptable (20 secs compared to 1-2 secs for a native app). So I am using native intro pages that come up quickly and load Meteor/Cordova in the background.
When bottom API use result, error processing, there is no throw exception, so on the top try-catch that applies to this API generates no effects. It is common today, even many APIs of iOS are not ready for try-catch using.
Yes, but it was quite hard to make this work. It’s quite tricky to hook Cordova’s view controller into the rest of the application and took a lot of trial and error.
Right - Yea, it’s an interesting thought. I’m game to think about it a little. You can hit me up here or on github if you want to talk about it further.
Great! Would love to hear what ideas you have to make that work. I think it is possible in principle, because Meteor stores the user tokens along with the user record. The question is: how to hand this over to Cordova in the most transparent way.
What kind of sign in are you using? The library currently only has email/username accounts, although I intend to look at Twitter/FB etc. when I have time.
Hi Peter, any chance you’ll support loginWithParameters any time soon? Same need as waldgeist – need to allow login via Facebook from the IOS native (swift) app.
Not sure exactly what’s involved with respect to the Facebook login. I intend to implement it, but I don’t have a timetable. Can you open an issue on github so there’s an easier way to track it?
Right now, there is a login with parameters method, but it’s an internal method. Take a look at it and if there’s value in exposing it, we can look at changing the api.
So, I am the author of SwiftDDP, now archived on Github. I had a look at the library you announced and found that it was mostly my code - sometimes with files renamed or rearranged, but always with the copyright stripped. Note that the MIT license notice beneath the copyright that you removed forbids removal of the copyright. What you are announcing is a fork of SwiftDDP, not a new library. You do note that it’s a new version of SwiftDDP in the readme, but that’s it.
I want to let you know that this is a bad way to contribute to open source. It’s taking others work and presenting it as your own and it’s a sure way to generate bad will among fellow developers. Perhaps more importantly, muddling the license situation means that the software is less likely to be adopted commercially. Presumably, by trying to create an open source library, you want others to adopt it and contribute to it. This hinders that.
I stopped working on SwiftDDP for a variety of reasons. One of the reasons was that the connection to the server can be frustratingly unstable in real-world use. Sometimes, this didn’t show up in casual use, or in the simulator, but it was enough of an issue that I could never have used it in a production application. A look at your code (my code) suggests that package you have published will share this issue. I suggest you look into that.
I’m sure that there are people who would welcome an updated Swift language Meteor client. The correct way to do this is to present it as an updated fork of SwiftDDP, with proper attribution, not as a new piece of software that you have authored.
