mindera / alicerce Goto Github PK
View Code? Open in Web Editor NEWA base for iOS Applications made with ❤️ by Mindera 🤠
License: MIT License
A base for iOS Applications made with ❤️ by Mindera 🤠
License: MIT License
Could you please give several networking examples and/or networking stack architecture if possible.
We should integrate SwiftLint in the project (Xcode build phase and CI), enforcing as many rules as possible from our style guide 💪
When creating Alicerce we agreed that (ideally) it wouldn't have any 3rd party dependency.
Even though we love Result
and use it on our projects, this also meant we wouldn't use on Alicerce 😢.
Because of this decision (in great part because of me 😇), we ended up using completion closures with throwing inner closures on our async code (e.g. typealias CompletionClosure<R> = (_ inner: () throws -> R) -> Void
), which are hard to write, hard to read, and honestly quite ugly.
While the idea was for framework users to make their own wrappers around these API's using extensions (and we currently do that with ReactiveSwift
's SignalProducer
, for example), we still have to design and maintain them using this approach, for consistency.
That being said, I am opening up this issue to discuss some possibilities regarding this situation:
Result
Result
Since framework users might only be interested in a subset of the framework's features, it makes sense to allow partial importing.
CocoaPods allows this to be done quite easily by using Subspecs
Carthage seems to have no official support for this (and it might even be against their philosphy)
Perhaps in the future it might make sense to break Alicerce into smaller µFrameworks, because this issue will tend to worsen as we add more functionalities to it 😅
Since Swift 4.0 introduced Codable the library should use it instead of custom JSON parsing via Mappable
.
Since Swift 4.1 that Equatable
and Hashable
conformances can be auto synthesized
We currently have some case were we can most likely take advantage of this 💪
Hey, it looks like the Network documentation is based on an old version of this framework. To me it looks like that the example RESTResource<T: Codable>
class has to implement the RetryableResource
protocol. I added conformance to the protocol and the following implementation which I hope is the way to go.
` var retryErrors: [Swift.Error] = []
var totalRetriedDelay: ResourceRetry.Delay = 0
var retryPolicies: [ResourceRetry.Policy<Data, URLRequest, URLResponse>] = []
typealias Request = URLRequest
typealias Response = URLResponse`
If you would confirm this I would love to make PR in order to correct the documentation.
However I am currently searching for a way to authenticate my network stack using OAuth2 (GitHub API). I think this should be fairly easy be possible by using the NetworkAuthenticator
and AuthenticationChallengeHandler
, but I would love some guidance since I am not quite sure at the moment on how to implement this. Could you help me out here with some information on how to add that to the network stack ?
Implement a proper server trust validator to allow certificate pinning, and integrate it on URLSessionNetworkStack
instead of the very basic AuthenticationChallengeValidatorClosure
.
Even though we intend to break our DiskMemoryPersistenceStack
into smaller, more specialized persistence stacks/stores, we should implement a TTL mechanism on the Disk persistence, so that items can be evicted if they are older than X amount of time.
This is useful so that we don't have to just rely on the less frequently used (last accessed time) to evict stale items from the cache.
As the title implies, should we clear the viewModel
on prepareForReuse
when inheriting from ReusableViewModelView
? With this, we would guarantee that the view/cell is on a pristine state when used again. It should be straightforward to implement as we only need to override prepareForReuse
and set the viewModel
to nil
.
Some part is hard to understand, if there are any example project will help to use this framework
Shouldn't we expose a simple protocol
with just real logging methods?
Our current implementation is:
protocol Logger {
// MARK:- Destination Management
func register(_ destination: LogDestination)
func unregister(_ destination: LogDestination)
func removeAllDestinations()
// MARK:- Logging
func verbose(_ message: @autoclosure () -> String,
file: StaticString,
function: String,
line: UInt)
func debug(_ message: @autoclosure () -> String,
file: StaticString,
function: String,
line: UInt)
func info(_ message: @autoclosure () -> String,
file: StaticString,
function: String,
line: UInt)
func warning(_ message: @autoclosure () -> String,
file: StaticString,
function: String,
line: UInt)
func error(_ message: @autoclosure () -> String,
file: StaticString,
function: String,
line: UInt)
func log(level: Log.Level,
message: @autoclosure () -> String,
file: StaticString,
function: String,
line: UInt)
}
but i think we should have a small protocol only with:
public protocol Logger {
func verbose(_ message: @autoclosure () -> String,
file: StaticString,
function: String,
line: UInt)
func debug(_ message: @autoclosure () -> String,
file: StaticString,
function: String,
line: UInt)
func info(_ message: @autoclosure () -> String,
file: StaticString,
function: String,
line: UInt)
func warning(_ message: @autoclosure () -> String,
file: StaticString,
function: String,
line: UInt)
func error(_ message: @autoclosure () -> String,
file: StaticString,
function: String,
line: UInt)
}
when using logger, i can create a global instance of Logger and only access the real logging methods and not register
, ...
Currently the Resource protocol contains all the closures for parse, serialise and error. Probably most of the times those closures aren't used by the implementations and we have to implement it with fatalError.
Split this in multiple protocols. Any other idea?
This was previously discussed with @p4checo. This is just a reminder so we can discuss this later.
Bringing @danieladias into discussion.
Currently, our Logging infrastructure doesn't support modules/tags, which are useful in some scenarios, like:
The base API should use String
for the modules/tags, and then users can create their own extensions using a more type safe API (e.g. using enum MyModule: String
).
Currently, the Route.Tree
's match
has a limitation where it doesn't fallback (backtrack) to previous possibly valid paths (and thus handlers) when the chosen "matching path" is not completely matched.
Example:
Registered routes:
scheme://host/path/one
scheme://host/*
Received URL:
scheme://host/path/two
In this above scenario, the current implementation will fail to match the URL, because when validating the component path
it will give priority to the exact match on route no. 1, and when it fails on two
(expects one
) it will never backtrack to route no. 2 which has a wildcard on the first path component (and should handle the route).
Fixing this limitation will make the Router more robust and allow creating fallbacks and catch-all routes for some scenarios where a specialized handler might not yet be registered.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.