As programmers we constantly use frameworks and libraries while developing new applications. Most of you will probably never deal with frameworks or library design nevertheless a certain amount of knowledge of the topic is useful even working on standalone applications.
The following article is an introduction to the differences between these entities and how they interact to produce a consistent and maintainable product.
We will look at their different roles and scopes, when we need one or the other and the best practices for our development cycle.
The last part contains several tips to write a good library I’ve collected in these past years. Continue reading…
This is my first contribution to the Swift Server Side community; during these months I’m evaluating Swift as backend language for server side programming. In fact it was not my first attempt, but during this year I’ve seen many improvements in all main server projects like Kitura and Vapor.
Moving away from NodeJS is a tricky decision but the advantages of moving to a modern language like Swift are tempting me since the first release.
So while it’s still a long path to the goal I’m slowly moving to see how I can make this a valuable solution.
With this goal in mind I’ve tried to port a first small contribution to the community by porting of the most famous library used in NodeJS in Swift; UAParserSwift is a port of ua-parser-js made for Swift server side. This library aims to identify detailed type of web browser, layout engine, operating system, cpu architecture, and device type/model, entirely from user-agent string with a relatively small footprint. Continue reading…
Sometimes during the lifecycle of an application you may need to change the
rootViewController of your main
UIWindow ; a typical case maybe the transition between the initial on-boarding and the home of the app (ie. a
In order to handle this edge case you may want to create a top controller (typically an
UINavigationController with invisible navigation bar) which enable you to push your new container using a standard push animation.While basically it works fine, the addition of a container used only to handle this single operation is a bit awful to see.
A way better solution is to apply an animated transition (push/pop or slide) to the
rootViewController set so you will get an animate switch from the current view controller to the new one.
Throttling wraps a block of code with throttling logic, guaranteeing that an action will never be called more than once each specified interval.
Throttle is typically used inside search boxes in order to limit the number of backend requests while user is typing for a query; without throttling when an user types fast, backend server may receive tons of non useful request which are quite costly.
Moreover client will be busy updating continuously the UI with no longer relevant results: the entire behaviour causes your app to look cheap and the logic unnecessary complex.
Usually when implementing this kind of feature the first options you may consider is to use an
NSTimer fired/invalidated at your set interval. Repeating this boilerplate code in your view controller its not a good idea; usually you want to avoid any mess logic tracking state in a portion of your code that you’ve been trying to keep stateless.
Another solution involves RxSwift which has a throttle implementation out of the box; btw including an entire lib and use just a function its not a good practice after all. Continue reading…