Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 28 15:48
    ingemarson closed #606
  • Nov 28 15:48
    ingemarson commented #606
  • Sep 25 16:00
    ingemarson opened #606
  • Jul 25 03:45
    timur-st94 closed #605
  • Jul 25 03:45
    timur-st94 commented #605
  • Jul 16 09:48
    alexgarbarev commented #605
  • Jul 16 09:22
    timur-st94 opened #605
  • Jul 02 19:37

    alexgarbarev on master

    Travis config has been updated … (compare)

  • Jul 02 19:32
    alexgarbarev commented #603
  • Jul 02 19:22
    alexgarbarev commented #601
  • Jul 02 19:14

    alexgarbarev on master

    Example project migrated to Swi… Variable replaced to dynamic va… Merge pull request #604 from kb… (compare)

  • Jul 02 19:14
    alexgarbarev closed #604
  • Jul 02 19:14
    alexgarbarev commented #604
  • Jun 28 11:24
    kbakacak opened #604
  • Jun 26 03:45
    yalamandarao edited #603
  • Jun 25 10:51
    yalamandarao edited #603
  • Jun 25 10:23
    yalamandarao commented #578
  • Jun 25 10:23
    yalamandarao commented #578
  • Jun 25 10:22
    yalamandarao commented #578
  • Jun 22 04:38
    yalamandarao opened #603
Jasper Blues
@jasperblues
Great work Jeff. Looks good.
Its nice to see an example of Typhoon with Swift 2. . . one of the features users have had trouble with is with Swift 2 style exception handling. Did you have develop any recommended standard approach for that with Typhoon?
Jeff Roberts
@JeffBNimble
I had a number of problems related to Typhoon and Swift 2, all of which stem from trying to inject classes/protocols that could not be annotated as @objc or subclass NSObject and therefore could not participate in Dependency Injection in the normal way. I did not encounter any issues with Typhoon in regards to throwing functions. I did design API's using "throws", but did not reference any of them in Typhoon. Are you referring to invoking failable initializers or calling throwing functions from Typhoon?
Jeff Roberts
@JeffBNimble
For code I could control since I wrote it, I chose not to change my API so that the classes could participate in Dependency Injection in the normal way. One of the protocols in one of the frameworks I wrote that is used by the app is this : https://github.com/JeffBNimble/swift-protocols-sqlite/blob/master/SwiftProtocolsSQLite/database/SQLiteDatabase.swift. Notice all of the throws functions. Because of those, Swift 2 cannot represent this protocol as an Objective-C protocol. I chose not to convert my API since I designed it with throws in the first place. This led to Typhoon problems.
In another case, look at this code: https://github.com/JeffBNimble/LoLBookOfChampions-swift2-sqlite/blob/master/LoLBookOfChampions/module/ApplicationAssembly.swift#L14. I was trying to inject ReactiveCocoa Schedulers. Schedulers are from the ReactiveCocoa library/framework, which I could not alter and I essentially had the same issue. This led to some unfortunate approaches/code as you can see. I chose to make those particular things global since I was unable to inject them and I needed them in multiple places. I would love feedback and discussion about this since I'm not happy with the choices.
Jasper Blues
@jasperblues
Yeah this is not satisfactory. By the sound of things we can’t recomment Typhoon with Swift 2.
We’ll have to come up with another approach to DI in Swift that doesn’t rely on the ObjC runtime.
Options:
  • Just use the DI pattern with no container/lib
  • Develop a new framework that uses compile-time instrumentation rather than runtime.
Jeff Roberts
@JeffBNimble
For the most part, Typhoon worked as it should. For the Objective-C version of the app, I was able to do everything I needed and not have to make any changes due to limitations in the language. However, with Swift 2, that was not the case. I encountered a handful of things I simply could not do with Typhoon. Again, not because of Typhoon, but because of Swift 2.
Jasper Blues
@jasperblues
Sure, but I wouldn’t recommend Typhoon + Swift 2 as a good combo.
When Swift 1.0 came out we were concerned but hopeful the language would become more dynamic.
But it seems to be moving away from ObjC interoperability.
So the approach to DI will need to be different.
A solution based on the ObjC runtime seems to impose limitations
Jasper Blues
@jasperblues
I’ll discuss with other devs before we make an official recommendation.
Roman Temchenko
@iThinker
Hi guys. If I want to make some factory methods that return same object class but with different configurations, will I be able to do it
?
What will happen in such case?
Jasper Blues
@jasperblues
you mean methods on TyphoonAssembly?
Roman Temchenko
@iThinker
Yes.
Jasper Blues
@jasperblues
Yeah, this is no problem with Typhoon.
Roman Temchenko
@iThinker
  • (Class)object; - (Class)object1;
Jasper Blues
@jasperblues
One of the reasons for creating Typhoon was that other DI containers struggle with this.
Roman Temchenko
@iThinker
How will it resolve dependencies if then I instantiate [Class new] somewhere in code?
Jasper Blues
@jasperblues
Typhoon is a DI container so you should obtain your built instance from Typhoon. . . via the assembly interface.
Take a look at the Quick Start for example.
Roman Temchenko
@iThinker
Oh. Do you mean that having [Class new] objects fully configured is a side effect?
Yeah. I've seen it.
And I've looked at some 3rd paty videos.
I am just not familiar with DI
Jasper Blues
@jasperblues
No. Typhoon won’t touch you class unless you ask for it from Typhoon.
Roman Temchenko
@iThinker
YOu know, we don't have it usually in iOS .:D
Jasper Blues
@jasperblues
DI is a common design pattern. And it applies in all OO languages. . . (though some, eg Ruby, tend not to use/need a library to manage it).
Once you understand DI you’ll have another tool for solving problems.
You don’t necessarily need a library to do DI <—— If you can understand how it works https://github.com/appsquickly/Typhoon-example
Roman Temchenko
@iThinker
Well, I've done only iOS. And I've heard previously about DI. But i've not seen it on any project.
I understand what you mean.
Jasper Blues
@jasperblues
https://github.com/appsquickly/Typhoon-example <—— Here’s an example for you
Roman Temchenko
@iThinker
Why not everything is created in assemblies? For example UINavigationController.
Jasper Blues
@jasperblues
Why are some classes defined in Typhoon and some not?
Roman Temchenko
@iThinker
I am sorry. I did not get your sarcasm.
Jasper Blues
@jasperblues
no, i want you to clarify you question.
Roman Temchenko
@iThinker
Then I did not get your question. There is a RootController. It can show other controllers. But instead of asking assembly for UINavigationController, it takes UIViewController and wraps it into UINavigationController. I thought in case of DI, UINavigationController should be created by factory with proper root view controller.
Jasper Blues
@jasperblues
My question was asking you to clarify your question.
Is that clear?
I understand your question now.