SDK Improvement Thread

[prempador]

Hello everyone,

as we are getting a lot of feedback regarding our SDKs, I will now open this issue with the main points we want to address in the upcoming days and weeks the keep track of what is and will be done.

1. Refactor of Constructor
   As there seems to be a lot of confusion, mostly caused by not-complete documentation, integrators think that the constructor sets up a http-request. This is not true, the constructor just makes a call to the fiskaly client, thus being able to throw errors. We heard that some people see throwing errors in the constructor as bad practice we will opt into making the functionalities that could cause an error into an own (init) function. Therefore we can no longer be sure that the fiskaly Client is properly initialized and we have to trust that the initialize function is called by integrators. We will make sure to properly document all steps needed to work with the SDK as intended. (Note: This will be added into all of our SDKs to be consistent, even with those that use the service instead of the library)

2. Re-adding armv7 (Carthage update error #23)
   We know that some of our integrators still need armv7 support and we are trying our best to re-add it into the SDK. There is a lot to do with compiler flags etc., so we can't really make an estimation of when the support will be here again.

3. Adding Cocoapods (Check in closed source client into repository  #21)
   We will add a podspec to make it easier to integrate our SDK. We heard that Cocoapods needs i386 arch as well so this task is kinda dependent on the above task.

4. More and better Documentation
   There is not really much to say, besides we will work on a better, clearer and more precise documentation for all our SDKs.

5. Tests
   We will also increase the amount of tests in our SDKs. This not only helps integrators when integrating but also helps us when adding new features.

Thank you everyone for the feedback and also for your patience.

Best @prempador

---

Checklist:

• Refactor Constructor
• armv7 Support
• Cocoapods
• Documenation
• Tests

[prempador]

After some playing around I just released v1.2.001 with a .podspec and armv7 enabled again. Other changes mentioned in this Issue will follow soon.

[prempador]

Until I get to update the Documentation properly here is an example Podfile:

# Uncomment the next line to define a global platform for your project
platform :ios, '9.0'

target 'TestApp' do
  # Comment the next line if you don't want to use dynamic frameworks
  use_frameworks!
  source 'https://github.com/CocoaPods/Specs.git'
  # Pods for TestApp
  pod 'FiskalySDK', '~> 1.2.001'

  target 'TestAppTests' do
    inherit! :search_paths
    # Pods for testing
  end

end

[svenmuennich]

Great! Thank you for adding CocoaPods support 🎉

I just checked the registry on cocoapods.org and noticed that no pod named FiskalySDK is available there. Is that something you are still working on?

For the time being, the pod needs to be added like this:

pod 'FiskalySDK', :git => '[email protected]:fiskaly/fiskaly-sdk-swift.git', :tag => 'v1.2.001'

[prempador]

Hey @svenmuennich,

I pushed it to trunk about 2 hours ago (CocoaPods/Specs@9671116). Above Podfile uses the Specs repo.

I am not 100% sure if I missed a step or if it just takes time to show up on cocoapods.org

[svenmuennich]

I pushed it to trunk about 2 hours ago

Then it probably takes some time to show up in search results. Thanks for clarifying.

[prempador]

Then it probably takes some time to show up in search results. Thanks for clarifying.

$ pod search FiskalySDK

shows a result for me. So I guess it works, at least with pod search.

__
As of July 30th it also shows up on cocoapods.org.

[svenmuennich]

I'd like to add another point to the list of possible improvements: Logging.

Currently the only way to configure logging is by calling FiskalyHttpClient.config(debugLevel:debugFile:clientTimeout:smaersTimeout:httpProxy:) and pass it a file path where the log output is written to. However, when using a logging system like CocoaLumberjack or Apple's SwiftLog it is desired to pipe all log output through the same logging backend. Allowing to pass a logging closure instead of a file path would make such piping less cumbersome to achieve.