It is pretty well known what a backward compatibility means for our APIs - once something was deployed to production and used by the users, we may not change its behavior or break its contracts. It’s far less obvious what a forward compatibility is, even though it is equally important for our APIs longevity and maintainability.
LUKE: Master, moving stones around is one thing. This is totally different! YODA: (irritated) No! No different! Only different in your mind. You must unlearn what you have learned. LUKE: (focusing, quietly) All right, I’ll give it a try. YODA: No! Try not. Do or do not! There is no try. How many times in your life of a professional developer have you tried to do something despite the fact that you knew that you would not succeed? How many times have you tried to finish a project earlier just because your manager asked you to, but from the beginning you knew you would not meet a new deadline? How many times have you promised to add hundred of new features to your demo in two weeks although it would normally take two months? We do it. Let us face it. We do it all the time - we promise things that we cannot achieve. We promise to do something even though it is beyond our capacity. And all this happens because we told someone that we would give it a try. Yet trying is not always enou...
We have nowadays many IT professionals, but let us think for a second what being an IT professional actually means. Is it only about being very good at programming? Is it about taking care of your code every night and day? Or maybe it is about wearing a suit and taking part in all possible IT events? In fact, being very good at programming is not enough to call yourself a professional developer. Professionalism needs something more than that. It is not only about being very good. Being a professional involves having great skills, but I dare to sat that not only skills are important here.
Hi! As you can see, the title of this post consists of two parts. “Are your views dumb enough” refers to managing code between your classes in project, which is really interesting topic, but there is also a second part — “A way to run your tests without simulator”. Managing your code is pretty straight forward topic and you probably know what to expect from this part, but how do I want to run my tests without simulator? Isn’t a simulator something we really need to test an application? Turns out it is not!
In my previous post I wrote about adopting UIApplicationShortcutItems in your app. Now it’s time to implement Peak&Pop - a feature provided by 3d Touch.
With the beginning of the iPhone 6s, Apple has introduced a 3D Touch mechanism which is very cool thing. The 3D Touch is also available on the newest iPhones 7. Nothing indicates that in the future Apple devices will run out of that feature so, here is a quick tutorial on how to improve your app using the one of the three main features of 3D Touch.
Last week I’ve made basic comparison between two libraries that will help you layout your interfaces - PureLayout and SnapKit. You can find this comparison here. Today I’d lake to take the same examples and see how they work with NSLayoutAnchor. NSLayoutAnchor is available to us since iOS 9 and provides us with a new way of creating your constraints. If you do not like creating NSLayoutConstraints using it’s initializers or visual format, and do not want any external dependencies for your layout, then NSLayoutAnchor is for you!
At first, let me clear something out. I’m heavy PureLayout user. I’ve been creating my UIs in code for some time now and it’s not looking like I’m going back to Interface Builder any time soon. I’m not saying IB is bad, but it’s just not the way that I do things. I started working with PureLayout back in Objective-C days and I kept on using it in Swift as well. However, recently I’ve been interested in a framework called SnapKit, that offers a nice “swifty” way of building views in your application. This post is my way of getting into SnapKit. Below, you can find some UI examples, that I’ve written using both PureLayout and SnapKit.
Memory management is a pretty important issue when talking about any kind of system. You can’t pretend that your resources are unlimited, and give them out no matter what. When working with ReactiveSwift it’s really easy to fall into the pit of wasted resources if you don’t follow simple rules.